| |||||||||||||
|
| |||||||||||||
ROTFLROTFLPosted Jul 21, 2004 13:43 UTC (Wed) by alonz (subscriber, #815)In reply to: ROTFL by dmantione Parent article: Kernel Summit: Video Drivers Hmm... Are you proposing then that the kernel hackers stop working on initramfs, hotplug, and on moving all system initialization to user space? Because, you know, these are dangerous... A hotplug script may reconfigure your system so it won't work anymore :-P Seriously--there is no difference whatsoever between doing things in kernel space, and doing them in a properly-architected user space. You just have to have the correct interfaces. That's all. Kernel space is not a "magic bullet" that will cause things to be more robust.
(Log in to post comments)
ROTFL Posted Jul 22, 2004 13:57 UTC (Thu) by dmantione (guest, #4640) [Link] No, I'm not proposing that. The idea of initramfs is to move certain features to user space that are better handled in user space.I.e. the DHCP client, the search for the root filesystem etc. Implementing a specific protocol is typically a user-space task. Many protocols exist you you don't want to have them all-in kernel, that would introduce a lot of code to maintain and any bug in kernel space is crash. Accessing hardware in user-space is not necessarily bad. In a micro-kernel approach, hardware is accessed mostly by user space processes. Such operating systems do have a well architected user space to do hardware access, allthough features like bus mastering transfers and interrupt handled are allways troublesome from user space. We both know that Linux is not a micro-kernel operating system. Currently Linux has nor a total userspace solution (the framebuffer device is in kernel space), nor a total kernelspace solution, since the X-server does its own initialization and mode switching. Anyway, in a full user-space solution you would need to communicate to some privileged daemon to switch video mode etc., which is not the current situation in Linux either; everything is packed together into the X-server; there is no separation between the Windowing system and the graphics access API. I.e. a bug in the X-server, which is megabytes of resident code, can make the system unusable. Kernels are normally designed to prevent user-space programs to crash the system. Some applications (games, competing windowing systems) don't want X. You can argue that anyone should use X, but fact is the desire is there to bypass X. To display a console, the kernel already does need to initialize the graphics hardware. Most hardware is pretty easy to initialize, like the standard VGA. Some is more complex, like the Mach64 family; I have some code for that family in the kernel. So, in kernel graphics is nothing revolutionary and I don't think the kernel can do without graphics support. It just needs to be developed in a fine graphics solution. Some parts of that solution belong in user space, other parts in kernel space. What is revolutionary is that the X-server does things it shouldn't do. Allhtough the XFree86 project needs credit for the stability of their X-server, it does crash seldomly, bringing down the entire system. This is not necessary.
X crashing the system Posted Jul 23, 2004 4:16 UTC (Fri) by giraffedata (subscriber, #1954) [Link] I have only a passing acquaintance with video, but privilege separation always interests me.How can X in user space crash the system? Is it something actually related to driving the video card, or just due to the fact that a superuser process can crash the system in unrelated ways? I always thought the reason X required superuser privilege was simply that Joe User logged in from some remote terminal shouldn't have the right to mess with the system's display -- it's not his to play with. Also, what exactly is the privilege required by X that people achieve by running it at root? Is it just CAP_SYS_RAWIO (ioperm())? Permission to a device file?
X crashing the system Posted Jul 23, 2004 11:30 UTC (Fri) by dmantione (guest, #4640) [Link] There are several things that can go wrong.The first is quite obvious, if the X-server crashes, the video hardware is in an unknown state. I.e. the console subsystem of the kernel is unable to draw anything on the display. A good framebuffer driver might help here by the way, but the matter of the fact is that the framebuffer devices do not reset all graphics card registers the X-server uses. The kernel then still thinks the console is in graphics mode, the keyboard is in full raw mode and therefore both your display and keyboard are unusable. The system might not have crashed in the literal sense of the word, but it is unusable. Second, the X-server mmaps /dev/mem. Therefore the X-server has access to physical memory. If can of a bug, the X-server can write into random memory. Even kernel memory is possible. The X-server also messes with clocks. Personal experience is that clocks are very dangerous. Graphics chips block the PCI/AGP-bus if their clock signal malfunctions, causing a lock up of the entire system. My own experience is that you can get a crash even if you program completely valid values into the clock registers, because the clock signal can get unstable for a few cycles. The X-server also does a lot of tweaking on the PCI-bus, which is not very safe either. And there are propably still a few more ways the X-server can crash the computer.
X crashing the system Posted Jul 23, 2004 11:36 UTC (Fri) by dmantione (guest, #4640) [Link] By the way, if Joe User logs in from remote, he can start extra X-servers andterrorize the user behind the console this way, it is set suid root after all. This is a normal system-security issue which has little to do with how X is implemented that the Linux community hasn't really solved well yet.
X crashing the system Posted Jul 23, 2004 15:50 UTC (Fri) by giraffedata (subscriber, #1954) [Link] Joe User being able to start an X server against the system's console is a problem at a much higher level -- the level at which someone decided to make the X server setuid superuser. On my Linux system, it is not.On Red Hat Linux systems I've seen, there is a setuid Xwrapper, but my understanding is that Xwrapper won't let Joe User start an X server. It has a concept of a uid that "owns" the system console and lets only that uid (or probably uid 0) start up an X server. IIRC the Red Hat "console owner" is the first uid to log into a virtual console since boot.
|
|
||||||||||||