[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFyLLq+wwWC5NJP3Q0guSetLva4O5S5seBb7sxVX85gk-w@mail.gmail.com>
Date: Thu, 3 Sep 2015 09:57:57 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Austin S Hemmelgarn <ahferroin7@...il.com>
Cc: Stas Sergeev <stsp@...t.ru>, Andy Lutomirski <luto@...capital.net>,
Josh Boyer <jwboyer@...oraproject.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Andrew Bird (Sphere Systems)" <ajb@...eresystems.co.uk>,
Ingo Molnar <mingo@...nel.org>,
Kees Cook <keescook@...omium.org>,
Brian Gerst <brgerst@...il.com>
Subject: Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and
default it to 'n')
On Thu, Sep 3, 2015 at 8:44 AM, Austin S Hemmelgarn
<ahferroin7@...il.com> wrote:
>
> This lets you turn this on or off at runtime.
Tangential aside: we already effectively have a flag that could turn
off vm86 mode dynamically: /proc/sys/vm/mmap_min_addr.
Sadly (or not) we default it to 4096, which still leaves vm86 mode
usable, although it effectively disables *dos* use for it. Which is
kind of the worst of both worlds: you can use the vm86() system call
for bad things (if you can find a hole in it), but you probably cannot
actually use it for DOS emulation, because the traditional BIOS data
segment is at 0040.
Anyway, what that means is that pretty much the only *valid* use of
vm86() mode is probably when the system maintainer has set
'mmap_min_addr' to zero. So we could probably use that as an already
existing flag that disallows vm86 by our current default values.
Stas - can you confirm that to actually use vm86 mode, you end up
setting that mmap_min_addr thing to zero? Or do you end up using a
mixed-mode setup, where you use vm86() for most things, but emulate
things that trap in the zero page?
Linus
--
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/
Powered by blists - more mailing lists