Hi,
I've been running Qubes for a few years now and I'd like to give
Spectrum a try, as I've been having some hardware and performance
problems with Qubes. Is there some up-to-date guide I can follow? I
found https://alyssa.is/using-virtio-wl/#demo and was able to see the
weston terminal. I also tried updating to the latest commit and was
able to get a nested wayfire window with:
nix-build . -A spectrumPackages && ./result-3/bin/spectrum-vm
(I'm fairly new to Nix, so not sure if this is the right way to do things)
I managed to change the keyboard layout, mount a tmpfs for home, and
increase the memory enough to start firefox, but I haven't managed to
get much further. Things I tried so far:
- I tried replacing wayfire with weston-terminal, to avoid the nested
session. But sommelier segfaults when I do that.
- I tried adding `--shared-dir /tmp/ff:ff:type=9p` to share a host
directory. Then `mount -t 9p -o trans=virtio,version=9p2000.L ff /tmp`
in the VM seemed to work, but `ls /tmp` crashed the VM.
- I tried using `-d /dev/mapper/disk` to share an LVM partition, but
`mount -t ext4 /dev/vdb /tmp` refused to mount it.
- I tried enabling networking with `--host_ip 10.0.0.1`, etc, but it
said it couldn't create a tap device. I guess it needs more
privileges.
Ideally, I'd like to run a VM with each of my old Qubes filesystems,
to get back to where I was with my Qubes setup, before investigating
new spectrum stuff (e.g. one app per VM). Do you have any advice on
this? I see these lists are a bit quiet - I hope someone is still
working on this because it sounds great :-)
Thanks!
--
talex5 (GitHub/Twitter) http://roscidus.com/blog/
GPG: 5DD5 8D70 899C 454A 966D 6A51 7513 3C8F 94F6 E0CC
Hi,
We tried running GUI apps and OS using virtio-gpu directly. Please check it out here https://blog.openw3b.org/crosvm-for-os-and-app-virtualization-on-linux/.
The idea is further reduce the attack surface by avoiding wayland. Please share your views on the same.
This mailing list was very helpful along the way! Thank you.
- Subash
Earlier I was sent a link to a paper called "FlexOS: Towards Flexible OS
Isolation"[1]. I thought the paper was great and subscribers to this
list might be interested in it and what I thought about it.
Like Spectrum, FlexOS is an operating system focused on
compartmentalization, but it takes a very different approach. It's a
library operating system (LibOS, also known as a unikernel). These
operating systems are linked with a single program, and produce an
operating system that only runs that single program. This can make for
very efficient VMs. As a result, FlexOS isn't about isolation between
programs, like Spectrum is, but instead tries to introduce isolation
within a single program, generally at library boundaries. Therefore,
Spectrum and FlexOS are highly complementary.
FlexOS can use several different isolation strategies, including running
different libraries in different VMs. Naturally there's a big
performance overhead to this but amazingly, it seems like it can be on
par with running the program normally on Linux, because the baseline
performance is so much faster running on a unikernel than on Linux (not
even in a VM AFAICT). Of a SQLite benchmark, the paper says: "Somewhat
surprisingly, FlexOS with EPT2 [libraries in different VMs] performs
almost identically to Linux. This is because the syscall latency is
almost identical to the EPT2 gate latency on this system".
Another inspired part of this paper is "Exploration with Partial Safety
Ordering". I don't want to go into too much detail about this because
the paper does such a good job of explaining it, but essentially you can
give FlexOS a performance budget and a benchmark, and it will identify
for you five or so of the best security configurations that meet your
performance needs, across different combinations of isolation primitive,
software hardening, etc.
The biggest limitation I can see to FlexOS is that it is based on C
source code transformations. Programs need to be specifically ported to
it (although it seems like porting an individual program isn't too hard
as long as it has good test coverage), and I don't know how easy it
would be to integrate with another language. But it's definitely
something to keep an eye on that could be useful if we ever find
ourselves with a big C program doing important work in Spectrum. The
use cases presented in the paper are quite compelling, especially the
one about isolating exploitable libraries. And unikernels more
generally are definitely worth keeping in mind if the performance
results in this paper are anything to go by, although A Linux in
Unikernel Clothing[2] is an interesting counterpoint.
Finally, reminder that I collect interesting papers, blog posts, talks
etc. in the Spectrum bibliography[3], where I've just added a link to
this paper. If you come across interesting stuff like this that might
be relevant to my work, please send it my way!
[1]: https://arxiv.org/abs/2112.06566
[2]: https://doi.org/10.1145/3342195.3387526
[3]: https://spectrum-os.org/bibliography.html
