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 <[email protected]>
---
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
On Thu, Jul 9, 2015 at 11:40 AM, Andy Lutomirski <[email protected]> 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 <[email protected]>
Acked-by: Kees Cook <[email protected]>
-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
On 7/9/2015 11:40 AM, Andy Lutomirski 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.
>
I would rather do BOTH the default n AND the EXPERT
e.g. the existing hurdle of EXPERT combined with the default
(e.g. off entirely in non-EXPERT, and with EXPERT it is sill defaulting to =n)
On Thu, Jul 9, 2015 at 11:51 AM, Arjan van de Ven <[email protected]> wrote:
> On 7/9/2015 11:40 AM, Andy Lutomirski 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.
>>
>
> I would rather do BOTH the default n AND the EXPERT
>
> e.g. the existing hurdle of EXPERT combined with the default
> (e.g. off entirely in non-EXPERT, and with EXPERT it is sill defaulting to
> =n)
>
>
I figured we could do this for a release or two, then move it into
EXPERT. But I'd be fine with your suggestion, too.
Ingo, Linus?
--Andy
--
Andy Lutomirski
AMA Capital Management, LLC
On Thu, Jul 9, 2015 at 11:51 AM, Arjan van de Ven <[email protected]> wrote:
>
> I would rather do BOTH the default n AND the EXPERT
That basically makes it impossible for "normal people" to test it. You
have to mark yourself as expert, and then get the rest of the
configuration right. Not a good idea.
The kernel config is probably our biggest problem for getting people
to test. Building the kernel? Easy. Installing it? "make install; make
modules_install". Not that hard, unless your distro has screwed it up
(which has happened, I'm looking at you, Ubuntu).
But making a config that is sane? Not easy. Let's not make people have
to mess with their configurations any more than they have to. It's too
painful.
The one thing we might want to do is to rename the config option,
simply to make sure that people who do "make oldconfig" will actually
see the new question and hopefully pick the new default rather than
just getting their old "y" without even seeing it. Call the option
"LEGACY_VM86" or something, perhaps?
Linus
Andy Lutomirski <luto <at> kernel.org> writes:
>
> 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.
Don't forget that it also depends on the null page being mapped, which is
why MS disabled it in Win8 by default.
>>>>> "Linus" == Linus Torvalds <[email protected]> writes:
Linus> On Thu, Jul 9, 2015 at 11:51 AM, Arjan van de Ven <[email protected]> wrote:
>>
>> I would rather do BOTH the default n AND the EXPERT
Linus> That basically makes it impossible for "normal people" to test it. You
Linus> have to mark yourself as expert, and then get the rest of the
Linus> configuration right. Not a good idea.
Linus> The kernel config is probably our biggest problem for getting
Linus> people to test. Building the kernel? Easy. Installing it? "make
Linus> install; make modules_install". Not that hard, unless your
Linus> distro has screwed it up (which has happened, I'm looking at
Linus> you, Ubuntu).
The big problem with the kernel config is the piles and piles of crap
which makes finding the common cases really really hard, and I've been
following this list and building kernels off and on now for 12+
years.
It would be nice if we could come up with a plan to organize the
configuration tree, and make it easier to use, with a little bit more
thought in how it's laid out.
For example, under Device Drivers -> PPS Support -> ???
What the hell is this? Expand and use your acronyms the first time
you use them like "Parallel Port Support (PPS)" so people have a
clue of figuring what you're talking about.
Maybe we could add a 'quick system' menu, where you select common
configurations at the top level, such as x86_64 home PC, which would
turn on all the options you'd pretty much expect for a home PC:
- x86_64 cpu
- max CPUs of 16
- ....
- Device drivers:
- SATA, PATA, AHCI, SCSI, USB, RAID, LVM
- AMD/NVidia/Intel video drivers.
We could have the same for:
ARM boards, PPC, Sparc, etc....
I know this is a hard problem space, esp since I'm sure people will
scream if you move their baby down/up/sideways in the config
hierarchy. But cleaning it up and maybe even just sorting
alphabetically would be a big help!
* Linus Torvalds <[email protected]> wrote:
> [...]
>
> The one thing we might want to do is to rename the config option, simply to make
> sure that people who do "make oldconfig" will actually see the new question and
> hopefully pick the new default rather than just getting their old "y" without
> even seeing it. Call the option "LEGACY_VM86" or something, perhaps?
Absolutely!
The 'default n' makes very little sense without changing the name - most distros
have the old symbol already and will just grandfather in at whatever value it was.
Change the name and also update the help text to make it scarier: point out that
it has known quirks and that we don't really trust the code because it's ancient,
crippled on the hardware side because vm86 mode was never fully documented by CPU
makers, back when x86 CPU makers (and Microsoft) considered virtualization an
enemy of Windows revenue.
Thanks,
Ingo
On Thu 2015-07-09 15:42:27, John Stoffel wrote:
> >>>>> "Linus" == Linus Torvalds <[email protected]> writes:
>
> Linus> On Thu, Jul 9, 2015 at 11:51 AM, Arjan van de Ven <[email protected]> wrote:
> >>
> >> I would rather do BOTH the default n AND the EXPERT
>
> Linus> That basically makes it impossible for "normal people" to test it. You
> Linus> have to mark yourself as expert, and then get the rest of the
> Linus> configuration right. Not a good idea.
>
> Linus> The kernel config is probably our biggest problem for getting
> Linus> people to test. Building the kernel? Easy. Installing it? "make
> Linus> install; make modules_install". Not that hard, unless your
> Linus> distro has screwed it up (which has happened, I'm looking at
> Linus> you, Ubuntu).
>
> The big problem with the kernel config is the piles and piles of crap
> which makes finding the common cases really really hard, and I've been
> following this list and building kernels off and on now for 12+
> years.
And you are lucky not to work on embedded stuff.
If I lost configs for n900, I'd probably not be able to come with
something working...
Given that we already have device trees... it would be nice to
separate real config *options* (like do you want penguin logo on
console? How big font?) from options you need to get right to get
useful hardware configuration, and parse the later ones from dts..
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html