Hi!
I’ve been messing around with Genode for a bit, which is an operating system with a built-in capability system. The kernel tracks capabilities for each running component and ensures that they are created and passed along securely.
If Spritely Goblins were to run on this OS, would it make sense to try to re-use this system to handle OCapN capabilities as well? This seems like it would have some advantages in having a smaller trusted base (the kernel is already trusted, so no additional trust would be needed for goblin’s version of capabilities).
Is there anything that would stop a version of Globlins from being implemented this way? I imagine the need for networking may complicate things as the OS’s capabilities are designed for inter-process communication.
This is something I’ve been thinking about for some time, I think it would be really interesting to build. It seems to me that creating a zero-copy shared-memory based IPC transport for OCapN opens up so many doors towards building a malleable personal computing environment. On Genode this would probably mean using it’s shared memory IPC primitives discussed here: Shared Memory, GPU access in Genode, a capability-based OS framework and combining this with something like Preserve’s zero copy binary encoding.
Once you have a transport like this, and get OCapN working over it, you would have an incredible computing environment to build out a coherent personal computing stack on top of. GUI applications would be actors that would render their UI to an internal buffer, then send their rendered frame as an OCapN message to the “window manager actor”. Actors could pass around audio buffers using the same transport to give you a capability version of Pipewire.
On Linux there is a project that implements a shared memory IPC system: GitHub - eclipse-iceoryx/iceoryx2: Eclipse iceoryx2™ - true zero-copy inter-process-communication in pure Rust and it’s really neat what you can do with something like this, but it unfortunately uses an “ambient authority” security system. Though on linux, I don’t think there’s a non-hacky way of implementing something like this while using things like mmap() under the hood.
To more directly answer your question: From my understanding of OCapN, it should definitely be possible to use Genode’s IPC systems as OCapN Netlayers and I would love to potentially help implement something like this in the future.
Another zero-copy IPC that I’ve been looking into is CapnProto, perhaps also with Flow IPC. I need to give far more of a look to Preserves / Syndicated Actors. You’re now the second person to say that it seems like a good fit for Genode.
For the “window manager actor”, I’ve been putting a lot of thought (with no results) into how Arcan could work for Genode. It’s a “Desktop Engine” that defers composition as long as possible and has it’s own Remote Video protocol, with multiple layers of granularity (compressed text, draw commands, mouse & keyboard, pixel buffers). It handles audio and video on the same protocol. I’m convinced completely that Arcan, or something like it, is the proper model for a desktop environment. And Genode’s existing GUI interface already works this way and has VNC / Remote Framebuffer.
I’ll need to read the spec in a lot more detail. My understanding of netlayers is that they are mainly a way to send an ordered stream of asynchronous messages between vats, which Genode can handle via Asynchronous Bulk Transfer. So hopefully that’s doable, though if its merely being used to send messages then it would be using the Goblins runtime to manage capabilities rather than the kernel. Which would be fine, but not as cool
I’ll probably try fiddling with it some this weekend and let you know if I get anywhere! Totally down to work on it together too if you’d ever want to as well.
I believe the Genode people have some sort of version of their capability system working on Linux using file descriptors. I don’t know exactly how it handles shared memory though.
I don’t know nearly enough about it to know if this is a good idea or not, but I kinda suspect it would be neat to get Genode working as a linux library, so any apps written for it would be able to run natively on Linux (in kinda the same way Electron apps are native).
Ah yeah. I’ve been meaning to read more into Arcan for a while now, will need to get around to it soon because the more I learn about it, the more it seems related to this sorta research.
So hopefully that’s doable, though if its merely being used to send messages then it would be using the Goblins runtime to manage capabilities rather than the kernel. Which would be fine, but not as cool
Imo I’d almost prefer this because then we’d have the higher-level OCapN capabilities, which would hold a ref to an object running in the same vat, a different vat on the same machine, or on a different machine entirely, and then have the OS-level caps which would be used internally for only Genode-level things. Agreed that this isn’t as cool though!
I believe the Genode people have some sort of version of their capability system working on Linux using file descriptors. I don’t know exactly how it handles shared memory though.
Yeah good point, I wonder if they’re able to get the same sorta guarantees on top of Linux. Lots of reading to do!
