CONFIG_LEGACY_VSYSCALL_EMULATE is, as far as I know, only needed for the
combined use of exotic and outdated debugging mechanisms with outdated
binaries. At this point, no one should be using it. We would like to
implement dynamic switching of vsyscalls, but this is much more
complicated to support in EMULATE mode than XONLY mode.
So let's force all the distros off of EMULATE mode. If anyone actually
needs it, they can set vsyscall=emulate, and we can then get away with
refusing to support newer security models if that option is set.
Cc: [email protected]
Cc: Kees Cook <[email protected]>
Cc: Florian Weimer <[email protected]>
Signed-off-by: Andy Lutomirski <[email protected]>
---
arch/x86/Kconfig | 18 +++---------------
arch/x86/entry/vsyscall/vsyscall_64.c | 2 +-
2 files changed, 4 insertions(+), 16 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 4bed3abf444d..68c669680c16 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2326,7 +2326,9 @@ choice
it can be used to assist security vulnerability exploitation.
This setting can be changed at boot time via the kernel command
- line parameter vsyscall=[emulate|xonly|none].
+ line parameter vsyscall=[emulate|xonly|none]. Emulate mode
+ is deprecated and can only be enabled using the kernel command
+ line.
On a system with recent enough glibc (2.14 or newer) and no
static binaries, you can say None without a performance penalty
@@ -2334,20 +2336,6 @@ choice
If unsure, select "Emulate execution only".
- config LEGACY_VSYSCALL_EMULATE
- bool "Full emulation"
- help
- The kernel traps and emulates calls into the fixed vsyscall
- address mapping. This makes the mapping non-executable, but
- it still contains readable known contents, which could be
- used in certain rare security vulnerability exploits. This
- configuration is recommended when using legacy userspace
- that still uses vsyscalls along with legacy binary
- instrumentation tools that require code to be readable.
-
- An example of this type of legacy userspace is running
- Pin on an old binary that still uses vsyscalls.
-
config LEGACY_VSYSCALL_XONLY
bool "Emulate execution only"
help
diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c b/arch/x86/entry/vsyscall/vsyscall_64.c
index fd2ee9408e91..4af81df133ee 100644
--- a/arch/x86/entry/vsyscall/vsyscall_64.c
+++ b/arch/x86/entry/vsyscall/vsyscall_64.c
@@ -48,7 +48,7 @@ static enum { EMULATE, XONLY, NONE } vsyscall_mode __ro_after_init =
#elif defined(CONFIG_LEGACY_VSYSCALL_XONLY)
XONLY;
#else
- EMULATE;
+ #error VSYSCALL config is broken
#endif
static int __init vsyscall_setup(char *str)
--
2.35.1
* Kees Cook:
> On Wed, May 11, 2022 at 10:38:53AM -0700, Andy Lutomirski wrote:
>> CONFIG_LEGACY_VSYSCALL_EMULATE is, as far as I know, only needed for the
>> combined use of exotic and outdated debugging mechanisms with outdated
>> binaries. At this point, no one should be using it. We would like to
>> implement dynamic switching of vsyscalls, but this is much more
>> complicated to support in EMULATE mode than XONLY mode.
>>
>> So let's force all the distros off of EMULATE mode. If anyone actually
>> needs it, they can set vsyscall=emulate, and we can then get away with
>> refusing to support newer security models if that option is set.
>>
>> Cc: [email protected]
>> Cc: Kees Cook <[email protected]>
>> Cc: Florian Weimer <[email protected]>
>> Signed-off-by: Andy Lutomirski <[email protected]>
>
> Sounds legit! Can we switch the default to "none" while we're at it?
I think that's a userspace ABI break?
I do not have a *very* strong opinion about this. For one thing, it
would be handy example to have that such deliberate do actually
happen. 8-)
Thanks,
Florian
The following commit has been merged into the x86/vdso branch of tip:
Commit-ID: bf00745e7791fe2ba7941aeead8528075a158bbe
Gitweb: https://git.kernel.org/tip/bf00745e7791fe2ba7941aeead8528075a158bbe
Author: Andy Lutomirski <[email protected]>
AuthorDate: Wed, 11 May 2022 10:38:53 -07:00
Committer: Borislav Petkov <[email protected]>
CommitterDate: Wed, 11 May 2022 20:39:31 +02:00
x86/vsyscall: Remove CONFIG_LEGACY_VSYSCALL_EMULATE
CONFIG_LEGACY_VSYSCALL_EMULATE is, as far as I know, only needed for the
combined use of exotic and outdated debugging mechanisms with outdated
binaries. At this point, no one should be using it. Eventually, dynamic
switching of vsyscalls will be implemented, but this is much more
complicated to support in EMULATE mode than XONLY mode.
So let's force all the distros off of EMULATE mode. If anyone actually
needs it, they can set vsyscall=emulate, and the kernel can then get
away with refusing to support newer security models if that option is
set.
[ bp: Remove "we"s. ]
Signed-off-by: Andy Lutomirski <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Reviewed-by: Kees Cook <[email protected]>
Acked-by: Florian Weimer <[email protected]>
Link: https://lore.kernel.org/r/898932fe61db6a9d61bc2458fa2f6049f1ca9f5c.1652290558.git.luto@kernel.org
---
arch/x86/Kconfig | 18 +++---------------
arch/x86/entry/vsyscall/vsyscall_64.c | 2 +-
2 files changed, 4 insertions(+), 16 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 4bed3ab..68c6696 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2326,7 +2326,9 @@ choice
it can be used to assist security vulnerability exploitation.
This setting can be changed at boot time via the kernel command
- line parameter vsyscall=[emulate|xonly|none].
+ line parameter vsyscall=[emulate|xonly|none]. Emulate mode
+ is deprecated and can only be enabled using the kernel command
+ line.
On a system with recent enough glibc (2.14 or newer) and no
static binaries, you can say None without a performance penalty
@@ -2334,20 +2336,6 @@ choice
If unsure, select "Emulate execution only".
- config LEGACY_VSYSCALL_EMULATE
- bool "Full emulation"
- help
- The kernel traps and emulates calls into the fixed vsyscall
- address mapping. This makes the mapping non-executable, but
- it still contains readable known contents, which could be
- used in certain rare security vulnerability exploits. This
- configuration is recommended when using legacy userspace
- that still uses vsyscalls along with legacy binary
- instrumentation tools that require code to be readable.
-
- An example of this type of legacy userspace is running
- Pin on an old binary that still uses vsyscalls.
-
config LEGACY_VSYSCALL_XONLY
bool "Emulate execution only"
help
diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c b/arch/x86/entry/vsyscall/vsyscall_64.c
index fd2ee94..4af81df 100644
--- a/arch/x86/entry/vsyscall/vsyscall_64.c
+++ b/arch/x86/entry/vsyscall/vsyscall_64.c
@@ -48,7 +48,7 @@ static enum { EMULATE, XONLY, NONE } vsyscall_mode __ro_after_init =
#elif defined(CONFIG_LEGACY_VSYSCALL_XONLY)
XONLY;
#else
- EMULATE;
+ #error VSYSCALL config is broken
#endif
static int __init vsyscall_setup(char *str)
On Wed, May 11, 2022 at 10:38:53AM -0700, Andy Lutomirski wrote:
> CONFIG_LEGACY_VSYSCALL_EMULATE is, as far as I know, only needed for the
> combined use of exotic and outdated debugging mechanisms with outdated
> binaries. At this point, no one should be using it. We would like to
> implement dynamic switching of vsyscalls, but this is much more
> complicated to support in EMULATE mode than XONLY mode.
>
> So let's force all the distros off of EMULATE mode. If anyone actually
> needs it, they can set vsyscall=emulate, and we can then get away with
> refusing to support newer security models if that option is set.
>
> Cc: [email protected]
> Cc: Kees Cook <[email protected]>
> Cc: Florian Weimer <[email protected]>
> Signed-off-by: Andy Lutomirski <[email protected]>
Sounds legit! Can we switch the default to "none" while we're at it?
Reviewed-by: Kees Cook <[email protected]>
--
Kees Cook
On Wed, May 11, 2022 at 11:04:55AM -0700, Kees Cook wrote:
> Sounds legit! Can we switch the default to "none" while we're at it?
I'd say one breakage at a time. :-)
I am fearing us breaking some ancient crap with it and Andy assures me
there shouldn't be anything except some ancient "pin" binary which has
been fixed in the meantime.
I'd say we can do the "none" by default thing but do it as a separate
patch so that it can be reverted easily in case someone screams in a
justified manner.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Wed, May 11, 2022 at 08:36:48PM +0200, Florian Weimer wrote:
> * Kees Cook:
>
> > On Wed, May 11, 2022 at 10:38:53AM -0700, Andy Lutomirski wrote:
> >> CONFIG_LEGACY_VSYSCALL_EMULATE is, as far as I know, only needed for the
> >> combined use of exotic and outdated debugging mechanisms with outdated
> >> binaries. At this point, no one should be using it. We would like to
> >> implement dynamic switching of vsyscalls, but this is much more
> >> complicated to support in EMULATE mode than XONLY mode.
> >>
> >> So let's force all the distros off of EMULATE mode. If anyone actually
> >> needs it, they can set vsyscall=emulate, and we can then get away with
> >> refusing to support newer security models if that option is set.
> >>
> >> Cc: [email protected]
> >> Cc: Kees Cook <[email protected]>
> >> Cc: Florian Weimer <[email protected]>
> >> Signed-off-by: Andy Lutomirski <[email protected]>
> >
> > Sounds legit! Can we switch the default to "none" while we're at it?
>
> I think that's a userspace ABI break?
>
> I do not have a *very* strong opinion about this. For one thing, it
> would be handy example to have that such deliberate do actually
> happen. 8-)
Right, I'm just suggesting switch the Kconfig default, so systems that
don't care will get that setting, and systems that do care can still
pick what they need.
(But yes, a separate patch, etc)
--
Kees Cook