xserver: Branch 'master'

[Adam Jackson]

On Tue, 2008-12-09 at 15:50 +0100, Luc Verhaegen wrote:
> On Mon, Dec 08, 2008 at 01:29:10PM -0800, Adam Jackson wrote:
> >  configure.ac |    1 -
> >  1 file changed, 1 deletion(-)
> > 
> > New commits:
> > commit 58a27d2932164e43c0db42b1286ec2f95250b420
> > Author: Adam Jackson <ajax at redhat.com>
> > Date:   Mon Dec 8 16:28:00 2008 -0500
> > 
> >     Default to x86emu even on i386 linux
> >     
> >     vm86 mode is a bad idea anyway, and using the emulator everywhere
> >     means we get a consistent set of bugs.
> 
> What triggered this choice, where was this discussed?

There's a fair bit of history here.  I've bitched about this furiously
in so many other fora (including at least the last two XD[CS] I've
attended) that I assumed I'd done so on this list too, but it seems I
haven't, so here's the story.

1) vm86 mode is an x86ism.  It doesn't work in long mode, and almost
certainly never will.  64-bit desktops are an increasingly large
percentage of the world.  It's worth having only one set of bugs, for
the same reason we don't ship cfb anymore.

2) vm86 doesn't work under Xen dom0 kernels.  This is, admittedly, a Xen
bug, but it's been there for over two years and doesn't seem to be going
anywhere.

3) vm86 mode is intrinsically unsafe.  For our purposes, it requires the
zero page to be mapped.  This means that while vm86 syscalls are
running, null pointer dereferences in the kernel are not _faults_.  The
kernel will carry on its merry way instead of crashing.  This is a
security problem that (in other forms) has been exploited in the wild.
Current selinux policy does not allow you to map memory that low without
a magic "oh man I hope this is safe" boolean, for exactly this reason.
Whereas with x86emu, you're running in a virtualized address space
anyway, so faking the low page is the same as faking all the others.

4) vm86 mode is intrinsically unsatisfiable.  Many laptop BIOSes will
flip to unreal mode so they can access memory in the E820 reserved
region, the highest 16M or so of address space.  That bit of memory is
part of the kernel's half of the world, and is not directly mappable (in
the MAP_FIXED sense) in user space.  Again, in x86emu, this is not a
problem because you have to fake the whole memory map anyway.

5) vm86 mode is not real mode.  It's a subset of real mode.  Huge swaths
of instructions and addressing modes are legal in real mode but not vm86
mode.  BIOSes do not run in vm86 mode, they run in real mode, and the
instruction set they use reflects this and includes instructions outside
of what's strictly legal in vm86 mode.  The only way we stand a chance
of being resilient in the face of variations across what different CPUs
allow in vm86 mode, is by not using it.

6) For all of points 3, 4, and 5 above, you could work around them to a
greater or lesser extent by trapping the troublesome things and handling
them in the vm86 wrapper, the way we do with I/O cycles already.  But
doing this is equivalent to knowing how to decode every x86 instruction
so you can find the source and destination of each operand in memory,
and then doing just enough partial emulation to finish the op.  If you
think that sounds equivalent to using the emulator in the first place,
you just might be on to something there.

So in short: vm86 is dangerous, doesn't work right, and isn't used on
significant numbers of machines already.

As a bit of empirical evidence, Fedora has shipped x86emu everywhere
since Fedora 7 (eighteen months old now).  Debian unstable changed to do
likewise at about the same time, and will almost certainly release in
this configuration whenever Lenny happens.  Ubuntu has shipped x86emu on
all arches since Gutsy (2007.10), courtesy of Debian rebases.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20081209/2c92ae21/attachment.pgp>