On 3/4/23 02:36, Demi Marie Obenour wrote:
On Fri, Mar 03, 2023 at 01:41:56PM +0100, Keno Goertz wrote:
I'm writing because I'm interested to work on FreeBSD jails as an
alternative to Xen for isolation in QubesOS. And I have some questions
about it, that someone on this list can maybe find the time to answer.
There are two major limitations:
1. FreeBSD is a monolithic kernel, so jails do nothing to sandbox device
drivers or the Wi-Fi or USB protocol stacks. One can use PCI
pass-through with bhyve or (you guessed it) Xen, though.
Side note: Linux has come a long way since `chroot` was the only
"freebsd jail"/"solaris zone"/"AIX WPAR"-like mechanism. These days
Linux "namespaces" let you do the same, if not more, on Linux.
I wouldn't recommend spending much time on FreeBSD-as-Xen-Dom0:
The times I've worked with FreeBSD + Xen (including porting some of the
qubes guest tooling to FreeBSD for better FBSD appvm support) it has not
been *great*. It kind of sort of works, but there is a lack of
documentation and the relevant packages are often outdated or compiled
with desirable features disabled.
The bhyve hypervisor would probably be a more natural target for such an
effort, since it would allow running both windows/linux/bsd guests (like
Xen does) as BHyve VMs, with "directed-IO"/"IOMMU" for peripherals etc.
The first and potentially biggest obstacle is th at the Qubes RPC model
is fairly married to two primitives:
- message passing between VMs (in Xen: the vchan ring-buffer mechanism,
in unix: "unix sockets" / "mqueue")
- used for executing commands, setting time,
file transfer, clipboard copy/paste support, etc
- memory sharing between VMs (in Xen: "grants", in unix terms: "shm"[ipc])
- afaik mostly used for the graphical protocol where it's shared
with dom0
Your first step in adding support for a new backend would be to figure
out how to provide similar interfaces to the guests.
The message passing could conceivably use IP communication (much larger
attack surface than vchan, but easy to get started with).
With that implemented in host+guests, you could have a non-gr aphical
qubes system.
I don't know of other users of memory sharing than the graphical
protocol, where it shares rectangular screen updates in 24-bit RGB
padded to a 32-bit word (per pixel). The message passing interface is
used to inform dom0 of the bounds and offsets. So for a full screen
update on full hd screen you need to transfer ~2 million x 32bit = 8
megabytes. This is not practical over a message passing interface, but
you could do it that way in the beginning for a PoC. Eventually you
could hack something up where you used e.g. a small `md` block device in
dom0 mapped to the guest via bhyve for this part.
Joe
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/2012a64a-dc16-2974-f582-5de0324cfda3%40celo.io.
