Newcomer's microkernel doubts

[frabert]

Hi everyone, sorry for the possibly stupid questions, but I have some doubts about implementing a microkernel architecture in a x86 system that I can't seem to solve...

It basically boils down to: how do I implement device drivers?
I ideally want to make my microkernel only manage memory, scheduling and message passing, but then how do usermode device drivers communicate with the devices?

Let's take the example of an Ethernet card driver: it will obviously need to communicate with the PCI bus. But raw hardware access is not permitted to ring-3 processes,
so the communication must somehow still pass through the kernel, which presumably exposes some kind of system-call for communicating with the bus...

Doesn't this mean I would theoretically have an interface for every possible means of device interconnection (USB, serial, parallel, SMBus, whathaveyou...), thus
negating the principle of having a microkernel?

Thanks

[iansjack]

Have you thought of letting the kernel grant the appropriate hardware access rights to a device driver?

[frabert]

How so? No matter what the kernel does, it cannot let a usermode process manage interrupts or use

Code: Select all

in / out

opcodes... Also, how would it manage keeping the access exclusive to only one process, how can the kernel distinguish devices?

[OSwhatever]

How so? No matter what the kernel does, it cannot let a usermode process manage interrupts or use

Code: Select all

in / out

opcodes... Also, how would it manage keeping the access exclusive to only one process, how can the kernel distinguish devices?

Doesn't the x86 have a port bitmask that can be set for each user process?

Also, most microkernels indeed only processes the actual interrupts inside the kernel, but this is delegated to user processes using a callback or some kind of message system. The possibilities are many here, and you should have fun investigating them.

There are many microkernels out there, even with source. Check out how they solved it. We have L4, Genode, Mach, QNX, Zircon etc.

[pat]

Doesn't the x86 have a port bitmask that can be set for each user process?

Yes it's the IO port bitmap in the TSS. You can grant a user process access to a port by clearing the specific bit for that port in the bitmap. And yes frabert you can actually use in/out, AFAIK the instructions themselves aren't priviledged, but its the port access.

[frabert]

Yes it's the IO port bitmap in the TSS.

Interesting, so I would actually have to use hardware-based processes, right? I can't get away with one or two TSSs and a software list of processes...

[MollenOS]

My operating system is a hybrid microkernel, and my device drivers run in user-mode. As have already been mentioned in this thread each TSS has an IoMap that actually is a bitmask for the ports on the system. You can set/clear each of these bits to disable or enable the access to each individual port address so the driver can use in/out instructions. In my system each memory-space has each their own io-map that I update each time the scheduler activates a new thread, this way the io-map can be per-process instead of per-TSS. For memory access to physical memory it's of course much easier to simply just map that physical memory range into the user-processes memory on request.

I use the concept of io-spaces that can be acquired by drivers and released. These io-spaces are defined by my device-manager as it enumerates the bus, and then a device-descriptor is sent to each driver as they get loaded in by the device-manager.

[frabert]

In my system each memory-space has each their own io-map that I update each time the scheduler activates a new thread, this way the io-map can be per-process instead of per-TSS.

Ahhh that's very clever, I hadn't thought of that! Well, thanks everyone guys, I'll come back when I'll actually have something resembling multitasking working

[pat]

Yes it's the IO port bitmap in the TSS.

Interesting, so I would actually have to use hardware-based processes, right? I can't get away with one or two TSSs and a software list of processes...

Actually no. The majority of the TSS is useless for software context switching, however fortunately the IOPB is still used. What I do is have a fixed number of known TSS addresses, one for each CPU. I allocate a single page for each process that stores the TSS struct in the first ~100 bytes and the remaining ~4K being the bitmap, and then when they get run by that CPU's scheduler, I map that process's TSS page to that CPU's TSS address. Very similar to what Mollen does it sounds like.

[frabert]

I'm reading the Intel manuals right now to understand what goes into the IOPB field, seems like there's not a specific length for the bit field...

[iansjack]

It would be hopelessly inefficient if you needed a bitmap that covered the whole I/O address range. Hence you have a base and then just need to specify the ports above that. For your average device driver the ports used will fall in a fairly limited range, so the bitmap doesn't occupy a huge amount of space.

Or you could always compromise and have the device drivers as separate loadable processes running at supervisor level.

[frabert]

For your average device driver the ports used will fall in a fairly limited range

Makes sense, the only issue I can see is if a certain process were to use two very distant addresses... I haven't really looked into specific devices, so I'm not sure if this would be an exceptional event or a common occurrence, though.

Or you could always compromise and have the device drivers as separate loadable processes running at supervisor level.

AND HAVE MY SUPER-SECURE OS I HAVE WRITTEN AS A HOBBY PROJECT IN MY SUMMER VACATION COMPROMISED? NEVER!!!

Jk, but I'm here for the ride as they say, I already understand how a monolithic OS manages this kind of issues, so there would not be much fun in doing that... If I wanted the easy way I could have stayed in real mode and let the BIOS do the heavy lifting for me

[iansjack]

Running a device driver in supervisor mode doesn't necessarily compromise your super secure OS. It works for many commercial OSs, which I would venture to suggest are probably more secure than you are ever likely to achieve. After all, your kernel still controls which drivers it is allowed to load - you can use some form of signing to prevent drivers that you haven't written from running. It's true that a badly written driver could compromise the system; but so could a badly written kernel.

But it's entirely up to you as to which compromises are the most sensible and whether you are aiming for elegance or usability. Also, bear in mind that most modern devices can use memory-mapped i/o rather than i/o ports, so that may be a slight red herring. Most kernel are not strictly monolithic ormicro; there are a host of shades inbetween. And if you think either way is "easy" you are in for a few surprises along the way. If you want any sort of serious OS you can't let the BIOS do the heavy lifting. That statement implies that perhaps you understand less of the issues than you think you do.

[Schol-R-LEA]

@iansjack: Perhaps I am wrong, but I think you missed the OP's point. This isn't meant as a serious project; it is climbing a mountain because it is there. Frabert said they'd already made one OS as a monolithic kernel, and that this one was just them trying out a different approach. Frabert is doing it this way because it isn't easy, and they want to learn from it.

[frabert]

Yeah I'm sorry it didn't come through the right way, the remark was meant as a completely non-serious observation Of course, I'm not saying that letting the BIOS do the heavy work in a modern OS is easy, I'm just saying that if I wanted the easy way to manage an HDD I could just do some int 13h or something and call it a day... I have no need to write a secure OS, and my comment was especially a... sideswipe? to those who think that putting everything into userland makes your OS secure.

I apologize if I sounded rude, it was not my intention.