[PATCH] int10: Remove the vm86 and stub backends

[Adam Jackson]

On Wed, 2011-09-14 at 19:28 +0000, Egbert Eich wrote:
> On Wed, Sep 14, 2011 at 12:25:20PM -0500, Jamey Sharp wrote:
> > From: Adam Jackson <ajax at redhat.com>
> > 
> > vm86 has been defaulted off since 1.6, and is still a terrible idea to
> > actually use.  Time to say goodbye.
> 
> Not a good idea. I've reenabled it in our enterprise product lately.
>
> Reason: I've run into issues with SMIs that were triggered by outb()s
> to specific registers. These SMIs returned their return state in CPU 
> registers whose values were checked later on in the code.
> The emulator doesn't track the state of CPU register itself thus 
> will not catch any such results.

Seems like the better solution is to emulate the state machines of those
ports.  We do a half-baked job of this already for some ports.

Actually, the better better solution is "not int10".

In general I consider vm86 to be completely unsupportable.  Mapping
anything at the 0 page means kernel bugs aren't segfaults, which is the
kind of security bug that's been actively exploited in the wild.
Pretending to care about bugs like the one you describe implies that the
affected machine can only work with vesa on i386 and not amd64, and
that's not the kind of gotcha I want to enable.

int10 services is a losing battle though.  Some vendors ship BIOSes that
actively flaunt their own documentation about what instructions are
legal in vm86 mode (HI INTEL HOW ARE YOU [1]), newer versions of Windows
skip it entirely which means it's going to be increasingly unreliable,
you might not have int10 at all in EFI, you can't get to unreal mode
from vm86 even though some BIOSes expect it... the list goes on.

None of this is news though.  I've already argued for why vm86 is
garbage, and why x86emu is the only thing that can be made to work
safely and reliably.  If other people want more pain in their lives,
that's a thing they can do, people make bad choices all the time and I
can't care about every damn thing.

[1] - http://lists.fedoraproject.org/pipermail/test/2011-September/102549.html

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg-devel/attachments/20110914/a6351346/attachment.pgp>