linux-kernel - Re: [PATCH] x86/kconfig/32: Make CONFIG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 9 Jul 2015 11:43:54 -0700
From:	Kees Cook <keescook@...omium.org>
To:	Andy Lutomirski <luto@...nel.org>
Cc:	"x86@...nel.org" <x86@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Oleg Nesterov <oleg@...hat.com>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Borislav Petkov <bp@...en8.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Austin S Hemmelgarn <ahferroin7@...il.com>,
	Brian Gerst <brgerst@...il.com>,
	Matthew Garrett <mjg59@...f.ucam.org>
Subject: Re: [PATCH] x86/kconfig/32: Make CONFIG_VM86 default to n and remove EXPERT

On Thu, Jul 9, 2015 at 11:40 AM, Andy Lutomirski <luto@...nel.org> wrote:
> VM86 is entirely broken if ptrace, syscall auditing, or NOHZ_FULL is
> in use.  The code is a big undocumented mess, it's a real PITA to
> test, and it looks like a big chunk of vm86_32.c is dead code.  It
> also plays awful games with the entry asm.
>
> No one should be using it anyway.  Use DOSBOX or KVM instead.
>
> Let's accelerate its slow death.  Remove it from EXPERT and default
> it to n.  Distros should not enable it.  In the unlikely event that
> some user needs it, they can easily re-enable it.
>
> I've confirmed that 'make oldconfig' will set leave it set to y, so
> there should be little or no unexpected breakage from this change.
>
> Signed-off-by: Andy Lutomirski <luto@...nel.org>

Acked-by: Kees Cook <keescook@...omium.org>

-Kees

> ---
>  arch/x86/Kconfig | 26 ++++++++++++++++++++------
>  1 file changed, 20 insertions(+), 6 deletions(-)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index aa94fd014fa2..b54994a28168 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -997,14 +997,28 @@ config X86_THERMAL_VECTOR
>         depends on X86_MCE_INTEL
>
>  config VM86
> -       bool "Enable VM86 support" if EXPERT
> -       default y
> +       bool "Enable VM86 support"
> +       default n
>         depends on X86_32
>         ---help---
> -         This option is required by programs like DOSEMU to run
> -         16-bit real mode legacy code on x86 processors. It also may
> -         be needed by software like XFree86 to initialize some video
> -         cards via BIOS. Disabling this option saves about 6K.
> +         This option allows user programs to put the CPU into V8086
> +         mode, which is an 80286-era approximation of 16-bit real mode.
> +
> +         Some very old versions of X and/or vbetool require this option
> +         for user mode setting.  Similarly, DOSEMU will use it if
> +         available to accelerate real mode DOS programs.  However, any
> +         recent version of DOSEMU, X, or vbetool should be fully
> +         functional even without kernel VM86 support, as they will all
> +         fall back to software emulation.
> +
> +         Anything that works on a 64-bit kernel is unlikely to need
> +         this option, as 64-bit kernels don't, and can't, support V8086
> +         mode.
> +
> +         Unless you use very old userspace or need the last drop of
> +         performance in your real mode DOS games and can't use KVM, say
> +         N here.  It disables a fairly large attack surface in the
> +         kernel.
>
>  config X86_16BIT
>         bool "Enable support for 16-bit segments" if EXPERT
> --
> 2.4.3
>



-- 
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/