Dear Norman,
Thanks for your feedback!
Don't hesitate to post your hardware configuration (e.g., the model of the Wifi card) here. Maybe, someone else has already taken steps to enable it?
Sure, I would like to look closely at the issue I encountered so I can provide detailed feedback. I'll join my test machine specs with that discussion. Unfortunately, I did not have the time to do so yet.
Maybe this character-device interface could be designed such that the actual driver code can be operated both in a free-standing fashion (e.g., hosted inside a VFS-less component) as well as embedded in a VFS plugin? So the character driver would actually be a "VFS plugin plugin". That would be great!
A nested plugging interface for "character devices" is attractive to reduce the number of sessions. I did not think of that direction. Currently, the SPI's VFS plugin is the full driver. This solution exposes the entire component to the plugin it is attached to. There are better solutions than this. However, we use it only for the TPM, which fits our needs.
One idea I had was to create two drivers, SPI and I2C, as servers implementing the Terminal session. Then create a "client" VFS plugin that can interface with those drivers. Ideally, only one plugin is necessary to interface read/write on a Terminal session. Such a plugin may already exist. It needs further thinking and experimentation!
From a security perspective, NOVA is preferable over Xen because NOVA's attack surface is more than an order of magnitude smaller, and Genode/NOVA does not require a Dom0 at all. I got the impression that some Qubes developers found prospect of replacing Xen by a microhypervisor (like NOVA) quite intriguing.
On the other hand, we have to keep in mind that Genode/NOVA currently still lacks a few convenience features like suspend/resume. This, however, will be addressed throughout this year.
Speaking of hypervisor candidates, there is current work in progress to enable the use of Genode's base-hw microkernel as hypervisor on x86 as well. So this may become a further option.
Thanks for the overall feedback about Xen. It confirms my initial feeling that it might not be relevant for Genode. This is the way.
I think that it would be best to pick up the existing discussion [1] and interview Marek Górecki so that he can share his views and ideas.
[1] https://forum.qubes-os.org/t/qubes-os-based-on-the-genode-os-framework/11735
The biggest question seems to be how to map the Qubes middleware to the mechanisms available under VirtualBox.
I may formulate a post for the Qubes-os forum. However, I would hold it until I have enough knowledge on both ends to argue what's possible.
Wow, this was more than 15 years ago. I'm not aware of any remaining public traces of this work. Have you tried contacting Julian about it?
I did not try to contact him. Eventually, I would if I retake a deep dive into this. But that was more about curiosity.
The other direction you mentioned - replacing C++ of the base framework with something else - is outside the scope of 2023.
Oh, I am sorry I did not mean to replace C++ entirely :) I was thinking of working on a secondary kernel, like base-hw, but fully implemented with Zig instead of C++. The direction I would take is the same as spunky, replacing part of base-hw at first. Plus, Zig claims great interoperability with C, then by extension to C++ via C.
Have you considered integrating support for alternative languages like zig into Goa [3]?
I did not initially think about it. Now that you mention it, it is likely a good starting point!
Cheers, Jean-Adrien