[PATCH] x86/vsyscall: Remove CONFIG_LEGACY_VSYSCALL_EMULATE

[PATCH] x86/vsyscall: Remove CONFIG_LEGACY_VSYSCALL_EMULATE

[Andy Lutomirski]

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: x86@kernel.org
Cc: Kees Cook <keescook@chromium.org>
Cc: Florian Weimer <fweimer@redhat.com>
Signed-off-by: Andy Lutomirski <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 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

Re: [PATCH] x86/vsyscall: Remove CONFIG_LEGACY_VSYSCALL_EMULATE

[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: x86@kernel.org
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Florian Weimer <fweimer@redhat.com>
> Signed-off-by: Andy Lutomirski <luto@kernel.org>

Sounds legit! Can we switch the default to "none" while we're at it?

Reviewed-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

Re: [PATCH] x86/vsyscall: Remove CONFIG_LEGACY_VSYSCALL_EMULATE

[Borislav Petkov]

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

Re: [PATCH] x86/vsyscall: Remove CONFIG_LEGACY_VSYSCALL_EMULATE

[Florian Weimer]

* 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: x86@kernel.org
>> Cc: Kees Cook <keescook@chromium.org>
>> Cc: Florian Weimer <fweimer@redhat.com>
>> Signed-off-by: Andy Lutomirski <luto@kernel.org>
>
> 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

Re: [PATCH] x86/vsyscall: Remove CONFIG_LEGACY_VSYSCALL_EMULATE

[Kees Cook]

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: x86@kernel.org
> >> Cc: Kees Cook <keescook@chromium.org>
> >> Cc: Florian Weimer <fweimer@redhat.com>
> >> Signed-off-by: Andy Lutomirski <luto@kernel.org>
> >
> > 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

Re: [PATCH] x86/vsyscall: Remove CONFIG_LEGACY_VSYSCALL_EMULATE

[Florian Weimer]

* Andy Lutomirski:

> 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: x86@kernel.org
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Florian Weimer <fweimer@redhat.com>
> Signed-off-by: Andy Lutomirski <luto@kernel.org>

Sounds a good idea to me.

Acked-by: Florian Weimer <fweimer@redhat.com>

Regarding the mechanics, is it customary to remove the actual code (the
EMULATE enum constant) in later commits?

Thanks,
Florian

Re: [PATCH] x86/vsyscall: Remove CONFIG_LEGACY_VSYSCALL_EMULATE

[Borislav Petkov]

On Wed, May 11, 2022 at 08:35:02PM +0200, Florian Weimer wrote:
> Regarding the mechanics, is it customary to remove the actual code (the
> EMULATE enum constant) in later commits?

It is still needed for

"Emulate mode is deprecated and can only be enabled using the kernel
command line."

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH] x86/vsyscall: Remove CONFIG_LEGACY_VSYSCALL_EMULATE

[Andy Lutomirski]

On Wed, May 11, 2022, at 11:35 AM, Florian Weimer wrote:
> * Andy Lutomirski:
>
>> 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: x86@kernel.org
>> Cc: Kees Cook <keescook@chromium.org>
>> Cc: Florian Weimer <fweimer@redhat.com>
>> Signed-off-by: Andy Lutomirski <luto@kernel.org>
>
> Sounds a good idea to me.
>
> Acked-by: Florian Weimer <fweimer@redhat.com>
>
> Regarding the mechanics, is it customary to remove the actual code (the
> EMULATE enum constant) in later commits?
>

Might be several versions later. This patch intentionally still supports booting with vsyscall=emulate.

[tip: x86/vdso] x86/vsyscall: Remove CONFIG_LEGACY_VSYSCALL_EMULATE

[tip-bot2 for Andy Lutomirski]

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 <luto@kernel.org>
AuthorDate:    Wed, 11 May 2022 10:38:53 -07:00
Committer:     Borislav Petkov <bp@suse.de>
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 <luto@kernel.org>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Kees Cook <keescook@chromium.org>
Acked-by: Florian Weimer <fweimer@redhat.com>
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)