OSDev.org

Hello everybody,
I'm new to the forum although I've been a frequent reader of both it and the OSDev Wiki. I've registered because I'd love to hear your comments about the feasibility of a project that I'd like to start, that is a RISC-V exo-kernel. I'll answer the questions "why risc?" and "why exo?" right away. I'd like to work on this kind of project because it's small enough to be manageable by a single person (I'm assuming that nobody else will be interested in developing it besides me) and it'll provide me a way for experimenting with RISC-V and the "exokernel" idea, both of which I find very interesting but have no practical experience with. Nothing big then, but at the same time something that can be useful.
My understanding of a exokernel is that its unique purpose is to provide secure multiplexing of hardware resources, without any of the abstractions that traditional kernels force. In practical terms, on a RISC-V system, this kernel would be in M-mode and all the "apps" would run in S-mode.
I would like to know what you guys think, if this is actually achievable on current RISC-V systems. Would it be possible to have multiple "apps" running in S-mode securely, and the kernel in M-mode?

exo wrote:Would it be possible to have multiple "apps" running in S-mode securely, and the kernel in M-mode?

Maybe, but it's not really designed to work that way. If you want applications to have S-mode privileges, it'll be much easier to do that if your kernel is a hypervisor running in H-mode.

Do you really need applications running in S-mode in the first place? The whole purpose of an exokernel is to securely multiplex access to hardware resources, and it's a lot easier to do that when you have access to all of your CPU's security features.

Thank you for replying.

Octocontrabass wrote:The whole purpose of an exokernel is to securely multiplex access to hardware resources, and it's a lot easier to do that when you have access to all of your CPU's security features.

Sorry I don't understand if you mean that everything, kernel and "apps" (or libs as they're called?), should be entirely in M-mode, or if you mean that everything other than kernel should be in U-mode.

The term "exokernel" is somewhat nebulous, so there are different ways you could do it, but if you asked me to create an exokernel on RISC-V, I would want my exokernel to run in S-mode and everything else in U-mode.

Octocontrabass wrote:I would want my exokernel to run in S-mode and everything else in U-mode.

So if I understand this correctly, the kernel basically jumps to U-mode very early on, like almost immediately after entering the main function. Then it provides handlers (ecall/sret) for executing very low level instructions like satp?

That's one way to do it. The handlers would be responsible for enforcing security policies.

Octocontrabass wrote:That's one way to do it. The handlers would be responsible for enforcing security policies.

Can I ask you what other ways there are? I'm kinda struggling to think of another way to do it

There's no firm definition for what an exokernel is, so there's more than one way to build a kernel that fits at least one definition of exokernel.

One type of exokernel is an ordinary kernel stripped down to just hardware abstractions. For example, your exokernel might have a block storage abstraction so applications don't need to worry about whether they're accessing an IDE hard disk or an NVMe SSD or a USB flash drive. However, your exokernel wouldn't have a filesystem - if you want one, it has to be handled by an application in user mode. Your exokernel is responsible for enforcing security, so applications can't access blocks without permission, but it's not responsible for setting security policy - deciding which applications can access which blocks is also handled by an application in user mode (possibly the same one that handles the filesystem).

This hypothetical kernel looks a lot different from what you're imagining, but it's still an exokernel.

That's an interesting take because I was assuming a kernel this small should not provide *any* abstractions, not even hardware ones like block devices. I thought usermode should be able to access memory-mapped addresses directly, so that for example the drivers themselves are in user space.

In the definitions I've seen, an exokernel isn't necessarily a small kernel, just one that doesn't enforce software abstractions. Since that definition still allows hardware abstractions, you can have a monolithic exokernel.

If you're more interested in building a micro-exokernel, then by all means, build a micro-exokernel. That should work just as well on RISC-V as it does on other CPU architectures.