OSDev.org

Hi,



A micro-kernel sacrifices some performance (due to IPC costs), and the only reason to do this is to avoid the need for "trusted drivers".

You should be able to download a "binary blob" device driver via. a Chinese peer to peer file sharing site (that was uploaded by a guy who calls himself "PawninU"), and use that driver on a server for an international bank without worrying about anything (other than the driver crashing or not working with the device) because you're using a micro-kernel.



That information is trivial to obtain from PCI configuration space BARs. Of course I'd have a "device manager" process that does device enumeration, etc (and starts drivers, and tells kernel which driver should be allowed to use which resources).



It's also trivial to add a few fields to whatever the kernel uses as a "process data structure".


Cheers,

Brendan

At this point, I see three advantages to that method:

• It's intuitive. It'll probably be easier to plumb the driver-hardware I/O through the kernel at first, and later change or rewrite those services later on. As I've never had a working kernel before, I'm putting priority on one that works, rather than one that works quickly.
• The security implications are a little better. It makes a little more sense to me, at least at this point, to leave I/O and memory-map permissions to the kernel as the kernel is already part of the trusted computing base and allowing the devices to abstract over their own access might violate that "total security" somewhat. It's hard to say for sure without a good look at the structure of existing microkernels.
• Portability. If the kernel abstracts much of the I/O and memory/paging access, less has to be changed to port the kernel to a new architecture. In fact, there'd be a significant possibility some drivers, such as PCIe cards, might be able to port over their drivers completely unchanged, or slightly changed for endianness' sake.

Using kernel facilities to limit I/O access also means I can pursue other means of performing the I/O permissions. Such as establishing a table with bases and limits, rather than an individual bitmap like the TSS uses. Putting that faculty in the device manager subprocesses of the kernel also means that each process need not have its own - drivers can query for their permissions from the master on initialization, and they can be updated via IPC when or if it changes. Things such as segmenting various ports into groups, and assigning processes to permission groups during config and changing via IPC.

I'm open for discussion on that idea. The first reason I was looking at doing syscall-based I/O was that it made enough sense, and it was low-speed enough that the performance losses aren't likely to be egregious.

When the blob says "I'm a keyboard driver, give me access to the IO ports related to the keyboard" how do you know to trust the blob?

Of course, linked lists, bitmaps, dynamic memory management and the like are trivial. But so is setting up the IO bitmap. The point is that this method saves no complexity over the other methods.

Also, is there really no concern that the timing requirements of some devices may not be able to be met with this scheme? And if IO is required to be done while processing an interrupt message (prior to sending the EOI at the end of processing) wouldn't there be a concern about the extra time taken to make all the system calls required to process the interrupt under this scheme. I'm really thinking that this method is probably unworkable.

Cryptographically sign or hash the driver. MD5/SHA1, for example.

Cryptographically signing or verifying drivers works for at least production code. There's a bigger security standpoint with respect to I/O permissioning by the kernel, however.

As Brendan said, one should be able to download a questionable driver from a questionable source without worrying about the system being compromised. For example, let's assume that keyboard driver was a keylogger designed to record any key traffic that it processes. It would declare itself as a keyboard driver, via some sort of class code or what not (somewhat like the PCI/PCIe BARs) in a data structure of the driver. That class code would give the driver permission to handle I/O abstraction (and possibly memory interaction) only in the port and/or MMU map ranges as specified by the kernel as appropriate for a driver class of "keyboard".

So what if it logs keystrokes? In order to do anything with these keystrokes, it would have to have access to faculties that are outside of the I/O scope it is designated, namely hard disk or networking processes. Because of the fact that the keylogging driver would only be given permissions to keyboard-related interactions, even a backdoored or compromised driver would not result in the compromise of the system or its users.

Just FYI, neither MD5 or SHA1 are cryptographically secure anymore. I mean, SHA3 is "out" at this point...

- Monk

Right, but because of the avalanche effect in these hashes, a MD5 or SHA-1 sum is still quite useful in determining if a file has been altered or not.

You could sign a driver with a crypto algorithm such as a block cipher, but RSA invokes the issues of efficient large prime number generation and key factorization whereas AES raises the issue of securely transmitting and storing a key within a kernel. It also raises an ethical question (especially regarding open-source projects) because such encryption of drivers could become developer lockout.

MD5 or SHA-1 summing of a driver module for verification/integrity purposes is a relatively passive protection, but it works and I don't think I've ever seen a circumstance where a file has been compromised in a unique way as to yield a collision and therefore the same hash.

It's pretty easy to make the changes an attacker might want, and then add garbage after the file in an "unused" section to cause a hash collision in MD5 or SHA1. Don't use them anymore for anything. MD5 has been completely broken for 5+ years (10?) and SHA1 about half that time.

- Monk

Cryptographically signing the driver might work or might not work. If it does work then there is no need for the kernel API for IO at all and it would be possible to simply use in and out instructions from the certified userspace driver.

I'm still not sure how using a kernel API is a feasible approach. It's slower than any other method, it's certainly no less complex than any other method and it requires a cryptographically signed binary anyway to achieve security.

To address your 3 points directly

• It's intuitive. No, it's much easier to use in and out instructions than pass those parameter to the kernel via a software interrupt or syscall.
  
• The security implications are a little better. No, we now know that we need cryptographically signed binaries anyway so there is no gain there.
  
• Portability. No, the kernel is not required for abstraction. Userspace libraries can do that too.

I'm still not convinced and am still worried about the performance and timing implications. I wonder has anyone on the list made this type of scheme work.

It would be no harder in the long run, once the system call framework is in place, to enable specific I/O input and output operations that accept port data, calling process ID and a string of data than it would be to directly enable the driver to do so directly.



Cryptographically signing the driver binaries and using hashes as a passive verification mechanism on initial driver load is a separate issue entirely to the use of the kernel to establish (and enforce) proper I/O permissions at the software-level for that driver.



Now you have to change and recompile the kernel, the libs, and the drivers for a different architecture, even in light of a common expansion unit or I/O device.

I think the OP was saying that it was intuitive for them.

If you/OP/anyone is using a kernel API for in/out, a cryptographic hash isn't necessary. "Permissions" would be more than enough.

Any OS that requires Userspace to deal with portability is a failure in this day and age (IMHO, IL of some sort is the way to go, compiled at install time) At the very least, it should be as easy as compiling multiple binaries from one codebase without any "#ifdef"s for arch(s).

- Monk

That's the beauty of it. you can always have a manifest of sorts which would list which is ports / IPC services the module requires.
If for example a keyboard driver requires something it is not supposed to ( network stack , filesystem) then don't load it.

That's missing the point. You have to trust some code to be your keyboard driver, no matter what kernel architecture you use. The benefit of a microkernel is that you don't have to trust the blob with anything else.

This was exactly my line of thinking. If the driver identifies itself as belonging to a class (say "keyboard", to keep with the discussion), only grant it permissions for keyboard access. If it attempts to access services that it is not granted permissions to, the OS could either deny those requests or unload the driver entirely, depending on how critical the operation it performs is.

Of course, this doesn't prevent some odd behavior, such as a driver that simply transmutes the data (i.e. when an "A" is pressed, forward a "Q" to the kernel). In practice though, there is no reasonable precaution to be taken against that.

This also allows for the kernel to have some interesting/novel features to aid the programmer, as Brendan alluded to awhile back - the kernel could be instructed to log all driver I/O activity, for example, which would greatly aid in debugging new or experimental drivers.

His full quote began " It's intuitive. It'll probably be easier to plumb the driver-hardware I/O through the kernel at first, and later change or rewrite those services later on." I was just pointing out that it's not easier.
It was the OP who offered that he is going to use cryptographic hashes to protect his kernel API. I never considered such a thing but since he is using them I thought that the kernel API was not necessary.
Here we disagree. And I think that's okay. Remember we are talking about a microkernel here. Device drivers are not part of the kernel and so userspace and userspace libraries by design have more responsibility in this area than in a system with a monolithic kernel.