OSDev.org

I was in vacation and I thought a lot about device driver management...
I thought that I can manage some drivers directly in usermode, not like microkernels where drivers are processes, but they'll be shared libraries. Particularly device drivers that need good performances.

For example if I write a graphics driver as a shared library, there is no need to do syscalls and so there isn't any switch of privilege (ring3 -> ring0) for each operation. It would be a lot faster.

The only things I can't resolve are the security things.

What do you think about this?

But that means that you would have to give applications full access to the graphics hardware. Do you want this?

dr_evil wrote:But that means that you would have to give applications full access to the graphics hardware. Do you want this?

Yes.

Also Linux does this for graphics with the DRI (Direct Rendering I..)

Linux doesn't necessarily just give access to the hardware. Devices in the DRI normally have a kernel mode driver which is in charge of doing operations. Some drivers use ioctl()'s and some simply expose the device registers(the NVIDIA proprietary driver does this). So yes, you are partly right, but not completely.

Assuming a badly written driver in kernel mode is more dangerous than in user mode, what is wrong in giving the application full access to the graphics hardware?

Sam

samueldotj wrote:Assuming a badly written driver in kernel mode is more dangerous than in user mode, what is wrong in giving the application full access to the graphics hardware?

Sam

Something in user mode is less dangerous because it doesn't have full access to hardware.

In my opinion, user mode is less dangerous because it does not have access to privileged instructions and also has restricted memory access.

Having said that if the application uses the hardware device to corrupt the memory(DMA), then it is dangerous as a normal kernel mode driver. So if performance is important and the same code(kernel driver) is going to execute on user mode, why not user mode?

Sam

samueldotj wrote:So if performance is important and the same code(kernel driver) is going to execute on user mode, why not user mode?

There is nothing wrong with user mode drivers of course. The thing at hand here is, though, that the OP wants the driver as a shared library. A shared library, by its nature, is just part of the user program, of that process/thread. That means in effect giving all user mode programs full access to all hardware! That would be a very bad thing, imho.


JAL

I disagree in some instances. Some devices are not as subject to abuse as others.

For graphics, it is a matter of implementing a HAL, exclusively for video, in userspace. Since video is memory mapped, it is simply a matter of mapping the video buffer or LFB (only) into each app's userspace. This does not give any userspace apps any access to the IO port bus, or any other memory mapped hardware. If a badly written app "illegally" trashes some pixels on the screen that it does not truly have permissions for, that won't really harm anything -- and hopefully there is a way for the user to find out which app is drawing beyond its boundaries.

iammisc wrote:Linux doesn't necessarily just give access to the hardware. Devices in the DRI normally have a kernel mode driver which is in charge of doing operations. Some drivers use ioctl()'s and some simply expose the device registers(the NVIDIA proprietary driver does this). So yes, you are partly right, but not completely.

In DRI device drivers are shared libraries and applications can use DRI directly without passing into kernel mode.
Graphics device drivers are used frequently, so if there aren't many privilege switchs it would be very faster.

The unique problem is the security. If a device driver in usermode can access to the hardware (port I/O, memory access, etc.), then also the user program can access to the hardware.

If you know how DRI works, can you explain me how it handles security?

I've found also this http://www.microsoft.com/whdc/driver/wdf/UMDF.mspx

I want to know how they handle security...

Hi,

Jeko wrote:I've found also this http://www.microsoft.com/whdc/driver/wdf/UMDF.mspx

I want to know how they handle security...

I would assume that "UMDF supports the creation of user-mode drivers that support protocol-based or serial-bus-based devices." (from Microsoft's page) means that the UMDF driver talks to a lower-level driver that runs in kernel-mode, and has no direct access to hardware (I/O ports, IRQs, etc).

For example, imagine a driver for a USB controller in the kernel that provides an API that UMDF drivers can use, where USB devices (keyboards, mouses, flash memory, disk drives, etc) use the "USB controller API" to control their devices, and don't need to access any hardware directly.

In this case (in theory) "protocol-based or serial-bus-based devices" might include:

• - drivers for devices attached to a USB controller (but not drivers for USB controllers)
  - drivers for devices attached to a firewire controller (but not drivers for firewire controllers)
  - drivers for devices attached to a PS/2 port (but not drivers for PS/2 controllers)
  - drivers for devices attached to a serial port (but not drivers for serial ports)
  - drivers for devices attached to a parallel port (but not drivers for parallel ports)
  - drivers for devices attached to a floppy disk controller (but not drivers for a floppy disk controllers)
  - drivers for devices attached to a SCSI controller (but not drivers for a SCSI controllers)
  - drivers for devices attached to a IDE/ATA/SATA controller (but not drivers for a IDE/ATA/SATA controllers)

I'd assume that the API/s used by UMDF do their own protection checks. For example, if a process asks the USB controller to get data from "USB device N" then the USB controller would work out if the process is allowed to access "USB device N" before doing anything. I'd also assume that only one process is given permission to access each device (so that different processes don't stuff each other up).

However, I'm guessing...


Cheers,

Brendan

In DRI device drivers are shared libraries and applications can use DRI directly without passing into kernel mode.
Graphics device drivers are used frequently, so if there aren't many privilege switchs it would be very faster.

The unique problem is the security. If a device driver in usermode can access to the hardware (port I/O, memory access, etc.), then also the user program can access to the hardware.

If you know how DRI works, can you explain me how it handles security?

I'm not claiming I know how DRI works but most DRI drivers have a kernel driver as well and it uses this kernel driver attached to a char device to access the hardware. My guess would be that the kernel driver handles security.

iammisc wrote:

In DRI device drivers are shared libraries and applications can use DRI directly without passing into kernel mode.
Graphics device drivers are used frequently, so if there aren't many privilege switchs it would be very faster.

The unique problem is the security. If a device driver in usermode can access to the hardware (port I/O, memory access, etc.), then also the user program can access to the hardware.

If you know how DRI works, can you explain me how it handles security?

I'm not claiming I know how DRI works but most DRI drivers have a kernel driver as well and it uses this kernel driver attached to a char device to access the hardware. My guess would be that the kernel driver handles security.

Ok Ok. Also I think that the DRM (the kernel driver) handles security. But I must study the system... But it's difficult to obtain something to read!