Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n')

[Andy Lutomirski]

On Thu, Sep 3, 2015 at 10:19 AM, Stas Sergeev <stsp@xxxxxxx> wrote:
> 03.09.2015 19:57, Linus Torvalds ÐÐÑÐÑ:
>> On Thu, Sep 3, 2015 at 8:44 AM, Austin S Hemmelgarn
>> <ahferroin7@xxxxxxxxx> 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?
> Yes, good point.
> dosemu complains about /proc/sys/vm/mmap_min_addr.
> Trapping on zero-page access will likely not work, because
> IIRC some distros raise that value even more.
> So yes, please use that to completely disable vm86().
> You won't even break dosemu's checks, because it (obviously)
> tries mmap() before trying vm86().
>

I'm okay with that.  Shall I send a patch?

There's also vbetool, but I think that almost everyone considers it
dead at this point, and it seems reasonably likely that it needs
mmap_min_addr == 0 as well.

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