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 <[EMAIL PROTECTED]> > > 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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg