Announcement

Collapse
No announcement yet.

Moving Linux Kernel Drivers To User-Space? Nope.

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Moving Linux Kernel Drivers To User-Space? Nope.

    Phoronix: Moving Linux Kernel Drivers To User-Space? Nope.

    Brought up on the Linux kernel mailing list this week was a short-lived discussion whether Linux device drivers should be moved from kernel-space to user-space in an attempt to provide "greater security and robustness" of Linux systems...

    http://www.phoronix.com/vr.php?view=MTA2MjA

  • #2
    How could device drivers be moved outside kernel space?
    It sounds a bit silly to me, then there should be an interface to give full access to hardware directly from userspace, then it would be even nastier than having some badly programmed drivers.

    Are there some advantages I can't really see?

    Comment


    • #3
      i have like 5h thinking about and i reached like 3billions reason not to do it but 0 to do it

      maybe im too missing something, what i dont trully see is how userspace drivers can improve security at all instead of create a hellbend of security problems

      Comment


      • #4
        I'm sure you could improve security with user-space drivers, but you probably need (or at least would like) to work from the beginning (iow, when you first start designing your kernel) with secure user-space drivers in mind. Otherwise, I'd guess it's like wrestling an elephant into another elephant. o_o

        Comment


        • #5
          what i dont trully see is how userspace drivers can improve security at all instead of create a hellbend of security problems
          The user space driver is restricted to by the means of process isolation to only access the target hardware/ressource, can not mess with the kernel as kernel drivers could do any time. You know the blobs from nvidia and co.

          Care to elaborarte what security problems arise from this?

          Comment


          • #6
            The main advantage of having video drivers in user space is that neither software nor hardware faults in the video system can cause the kernel to hang -- at worst the process will hang, and the kernel can terminate it. I think Windows Vista and onwards do something like this.

            The problem is that you need a carefully designed interface, which is a bit hard to jerry-rig into something like the Linux kernel at this point. You'll also take a considerable performance penalty, and maintaining the interface will be a pain.

            In terms of security, I see very little or no benefit -- if you can't trust your video driver, you're hosed anyway, since it can present anything to the user to trick them into doing whatever.

            Therefore, I think the main benefit is stability.

            Comment


            • #7
              Originally posted by TechMage89 View Post
              Therefore, I think the main benefit is stability.
              I don't how Windows 7 is organized with respect to drivers in kernel/user space that but I've seen it do sth really awesome - recover from graphics driver crash. In my case the crash seems to have been caused by faulty hardware because exchanging the graphics card for an identical one fixed the issue. But it was impressive nonetheless.

              Comment


              • #8
                Drivers are like internal organs, kernel is like brain. Even if you drive your organs from your mind, you will still die if they fail - regardless of you thinking about them or not.

                Comment


                • #9
                  Originally posted by kobblestown View Post
                  I don't how Windows 7 is organized with respect to drivers in kernel/user space that but I've seen it do sth really awesome - recover from graphics driver crash. In my case the crash seems to have been caused by faulty hardware because exchanging the graphics card for an identical one fixed the issue. But it was impressive nonetheless.
                  Something like recovery from a driver failure should be a feature that the Linux kernel should have and decoupling drivers from the kernel should theoretically allow the kernel to attempt a "restart" a driver that has crashed/segfaulted due to bugs or hw faults and put a notification into the system log of that action.

                  Comment


                  • #10
                    Not convinced

                    Drivers in userspace = slower, harder to manage, can crash your system anyway because they talk directly to the hardware, must be run with high privileges and are therefore a security threat.

                    Does it sound familiar? Yes, we already have that in Linux: the X server is a driver in userspace, that's why it needed to run as root, and people are doing a lot of work to get away from that design.

                    Comment


                    • #11
                      Originally posted by DeepDayze View Post
                      Something like recovery from a driver failure should be a feature that the Linux kernel should have and decoupling drivers from the kernel should theoretically allow the kernel to attempt a "restart" a driver that has crashed/segfaulted due to bugs or hw faults and put a notification into the system log of that action.
                      I agree, and I like that because Windows will pop-up a notification that a driver has crashed and then restarts the driver.. In Linux graphics driver crashes more often than not freeze the whole PC solid.. Sure, the driver crashes might be due to a hardware fault, but at least Windows tells you what hardware is failing (at least with graphics drivers and USB devices) while Linux generally does not.

                      I'd think a "A USB device attached to the system has malfunctioned" or "the graphics hardware has stopped responding and has been reset" kind of messaging to the user would go a long way.
                      Last edited by Sidicas; 02-24-2012, 04:03 PM.

                      Comment


                      • #12
                        Originally posted by TechMage89 View Post
                        The main advantage of having video drivers in user space is that neither software nor hardware faults in the video system can cause the kernel to hang -- at worst the process will hang, and the kernel can terminate it. I think Windows Vista and onwards do something like this..
                        I've always wondered how this would actually work.. Like, would it be possible to save the X session, if an application run from that session crashed the vid driver, or would you need to restart the X server too?

                        Comment


                        • #13
                          Originally posted by asdx
                          Moving drivers in user-space is a horrible idea, I don't want latency or a slow experience. Better fix the driver issues.

                          That's why users should ALWAYS report bugs, and developers/users should fix them.

                          Damn it.
                          Exactly. It seems it's terrible idea:

                          https://lkml.org/lkml/2012/2/24/338
                          https://lkml.org/lkml/2012/2/24/253

                          Tanenbaum retro... and another sensational article at Phoronix.

                          Comment


                          • #14
                            Originally posted by TechMage89 View Post
                            The main advantage of having video drivers in user space is that neither software nor hardware faults in the video system can cause the kernel to hang -- at worst the process will hang, and the kernel can terminate it. I think Windows Vista and onwards do something like this.

                            The problem is that you need a carefully designed interface, which is a bit hard to jerry-rig into something like the Linux kernel at this point. You'll also take a considerable performance penalty, and maintaining the interface will be a pain.

                            In terms of security, I see very little or no benefit -- if you can't trust your video driver, you're hosed anyway, since it can present anything to the user to trick them into doing whatever.

                            Therefore, I think the main benefit is stability.
                            A preempt kernel should be able to kill misbehaving kernel threads.

                            Comment


                            • #15
                              I like the idea

                              may be it's because i contribute to ukernel OS in my free time, but I think having a possibility of uspace drivers would be great.

                              most devices use memory mapped registers and those are accessible in uspace without any problems, problems appear when you consider handling interrupts (you cannot disable interrupts without privileged access, thus you need a small piece of code to run in kernel while the interrupts are disabled), but as linux has a mechanism for threaded interrupts it's nothing that can not be solved.

                              of course there are drivers that are more suitable for this design than others, USB drivers and input drivers are the best candidates. I don't think that anyone would be able to notice any overhead (there is MUCH more overhead getting the action to appear on user screen than there would be controlling a device), on the other hand anyone who has seen USB HID specs should be scared to see its implementation having access to kernel memory (and there are more complicated devices).

                              problem with devices controlled from userspace is that kernel can't use it (not in a nice way), that was the case with X, if you wanted something to appear on the screen without telling X you need ask X to surrender the device so that you can control it yourself, configure it and then display, surrender it again and tell X to reclaim it (hence the blinking when switching to consoles and back). Thus if kernel wants to output something nice (like BSOD) it needs to tell X or risk weird stuff when accessing the device (garbled screen, text mode over graphics,...)

                              it's true that bugs are better fixed, but a bugfree system is an utopia, and damage containment is not a bad idea.
                              For all those ppl that hate ukernel design and think that it's an unsuitable for modern use remeber that the OSes that reach high EAL levels are ukernels.

                              Comment

                              Working...
                              X