OSDev.org

hi,
have any of you come up with a way to grant system programmers access to ports when they need to write deveice drivers and extra system code that access hardware without leaving your OS open to attacks from malicious programmers?

If the drivers are running in kernel space (ring 0), then they have all the priviledges of the kernel, and can do whatever they like. Some people have experimented with "compile-on-run" and other such methods of checking the driver code before loading it into the kernel, but there are usually large performance issues.

If the drivers run in user space (ring 3), then the port access can be easily controlled via the TSS I/O Bitmap.

Here you have a perfect oppurtunity to break with tradition and use the x86 processor to its fullest. Instead of letting drivers run in ring 0 allow them to run in ring 1 so they have higher privaleges then apps but not as high as the kernel.

Peter

note: the "level 1" is mainly required if both the kernel, the driver and the user apps are run by the same TSS. In this case, you can grant (for instance) level 1 with the full access to I/O ports -- or restrict it to the IO bitmap of that TSS, and use call gates to invoke code of the driver.

If the driver runs in a separate TSS, then it could be at DPL3 just as applications, but the kernel would have granted that "application" with the full access to some hardware resources.

For instance, the "file" server could ask the kernel to give it access to I/O ports for the hard disk, but it couldn't access the video hardware ... If another application requests access to hard disk I/O resources, then the kernel will detect the conflict and refuse access to the later loaded app ...