> http://marc.theaimsgroup.com/?l=openbsd-misc&m=114657401630096&w=2 > > If I understand correctly from what I've been told, this is not a > hardware > issue but an 'X' issue.
It is the job of the operating system to shield the hardware from userland processes. That's what every operating system does. Some do a better job of this than others. But when an operating system fails to do this shielding, it is almost always a bug in the operating system. However, in this case, we cannot solve this in the operating system. The X developers have created an X server which *REQUIRES* access the raw hardware. Therefore all the operating systems developers have given the X server such access, by creating a "hole" in their operating system, which permits the X server to access any chip-level registers it wants. This is called the "device drivers in userland" model. It violates all the security models you will hear of in a university class. Having done so, they place operating system designers in the situation of choosing between the two options: "Our users cannot run X" or "there must be a hole in our operating system". Guess which choice every vendor makes? We provide a sysctl to let the user decide -- that is what the aperture sysctl is for. And we admit that is a cop-out. That's because there is no operating system level solution to the problem. At least we did not cop out as far as other vendors, who let any root process play with the any registers. We only let one root process play with the registers at a time. This is not a strong solution, but it the best we can do. But let me be clear -- the X developers are a bunch of shameless vendor-loving lapdogs who sure are taking their time at solving this > 10 year old problem! They spend way more time chasing the latest vendor binary loaded device driver, than they do solving this obvious problem. (Translation: They don't want to change how X works, because it would break the vendor binary drivers from ATI and NVIDIA. That is part of what happens when X developers get jobs at vendors). What Loic found is just one example of perhaps 50 other serious & equivelant security problems. Or maybe more. Most modern video chipsets can DMA all over the address space if requested. Many have processors that code could be loaded into, even surviving reboots. If there is a one bug in the X server, your machine is compromised. How does this get solved? If the X server did not require direct hardware access these problem would go away immediately. This requires that a proper abstraction be designed, so that a kernel device driver did the nasty register bits, and then communicated via a sanitized channel to the X server. This is the obvious seperation model that all other Unix things use. Unix processes use read() and write() to modify files. You don't see them talking directly to SATA chipsets do you? If they show up and provide a simple specification for such an abstration layer between a "kernel video driver" and a "X video driver", and helped us a little bit with the registers, the problem would go away almost immediately. That requires them to do some clever design, but it is clear they know more about past, current, and future video chipsets. They know the hardware, and we do not. They can solve this for all X-running operating systems today, or they can cop out and not solve it ever. They've had 10 years, and yet every year they get more entrenched in the entirely insecure model of "gigantic process running as root, which accesses registers like mad". This problem is ENTIRELY the X group's fault! They have failed us. Ten years ago they were laughing at Microsoft for moving their video subsystem into their kernel, but now the joke is on the X developers, because what Microsoft did solved all these driver security problems! This is 100% an X server bug. It is not a hardware bug, and it is not an operating system bug. [Feel free to forward this anywhere; I feel that Loic's original announcement totally missed at assigning the blame where it lies, and the result is that it is not being fixed.]
