Roadmap 2023

[Alice]

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]?
> 

> [3] https://github.com/nfeske/goa

I did not initially think about it. Now that you mention it, it is likely a good starting point!

Cheers,
Jean-Adrien
-------------- next part --------------
A non-text attachment was scrubbed...
Name: publickey - alice at domage.cloud - 0x173B2B9C.asc
Type: application/pgp-keys
Size: 649 bytes
Desc: not available
URL: <http://lists.genode.org/pipermail/users/attachments/20230116/4fc6d284/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.genode.org/pipermail/users/attachments/20230116/4fc6d284/attachment.sig>