- Spectrum Development - spectrum-os.org

This Week in Spectrum,
by Alyssa Ross 13 Jul '20

13 Jul '20

After I got an isolated Wayland compositor working last week, I wasn't really sure what to do next -- this was a big piece of work that I'd been very focused on for a while. The funding milestone I'm closest to is to do with implementing hardware isolation, which the Wayland work was a part of, so I decided to keep going with that, and explore other types of isolation. More on that in a bit. Wayland ------- Posted my patch for virtio_wl display socket support in libwayland-server[1]. This is what allows it to run in a VM, and receive connections from clients in other VMs. The patch description is very extensive, so I recommend reading it for more detail if you're interested. It introduces a libvirtio_wl, which should also be useful for porting other programs that we might want to communicate with across a VM boundary, if they are written with normal Unix sockets in mind (including transferring file descriptors). This is the evolution of code I previously had put in wlroots, moved to Wayland for convenience. If it ever acquires another user (or maybe even if it doesn't) it might make sense to make it its own package, since virtio_wl is useful even if Wayland isn't involved. [1]: https://spectrum-os.org/lists/archives/spectrum-devel/SJ0PR03MB5581479F3388… crosvm ------ I pushed all my crosvm changes to get the isolated compositor working to the work-in-progress "interguest" branch[2]. Remember, I only got it working last week right before I needed to start writing the TWiS email, so I hadn't even done that yet! I also posted some patches[3] to the list to fix a bug in my previous crosvm deadlock fix, and to improve some related documentation. As usual, these were kindly reviewed by Cole. Next, I turned my attention to other forms of hardware isolation. Wayland was a bit special, because despite crosvm including a virtual "Wayland device", it's not really hardware, and so it required an approach to isolation that will be quite different to other crosvm virtual devices. My hope is that other virtual devices should all be substantially similar to each other. The basic idea for actual hardware isolation is that rather than having drivers in the host kernel for USB, network devices, etc. those will be exposed to dedicated VMs as virtual PCI devices. This should substantially reduce host kernel attack surface. crosvm virtual devices will be run in these device VMs, and communicate over virtio with application VMs as normal. This will require implementing in crosvm a virtio proxy device, than allows for the crosvm running an application VM to forward virtio communication to the virtual device running in userspace in the driver VM. (The reason devices aren't attached to application VMs directly but run in seperate device VMs is that hardware is probably not going to be very happy if multiple kernels are trying to talk to it at the same time. Additionally, this indirection means that application VMs only have to use the one virtio driver for that device category, rather than any of the hundreds of drivers for different hardware in that category. If one of those drivers had a vulnerability, this should help to contain it to the device VM.) So I started writing this virtio proxy. The basic idea is to copy virtio buffers from application VM guest memory into memory that can be shared with the userspace virtual device in the device VM. I can't find any prior art on this (which is not unusual -- not many systems isolate drivers in this way), so this has required a lot of looking back at the virtio paper[4] and spec[5] to make sure I understand what to do here. As I write this, the next problem to solve is integrating some sort of memory allocator that can manage buffer allocations in the shared memory that the virtual device looks at. This is a new area for me that I'd appreciate advice on if anybody can give it -- think of it like, I have a memfd, mmaped into my process, and I would like to dynamically allocate and release memory buffers of dynamic sizes in that region. I'm sure there's a library I'll be able to plug in for this. [2]: https://spectrum-os.org/git/crosvm/?h=interguest [3]: https://spectrum-os.org/lists/archives/spectrum-devel/SJ0PR03MB55819DE7E13B… [4]: https://www.ozlabs.org/~rusty/virtio-spec/virtio-paper.pdf [5]: https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.… As usual, big thank you to Cole for reviewing patches, and for finding room for improvement even in languages/areas he isn't familiar with. It feels nice to have done some thinking about the project at a slightly higher level than I have been recently, and to know where I am on the way to the next milestone. Having taken a lot of time away from the milestone list this year to work on fundamentals, it's good to feel like I'm getting back on track.

1 0

[PATCH crosvm 0/2] Fix deadlock on early VmRequest
by Alyssa Ross 09 Jul '20

09 Jul '20

This is the problem you might have seen me complaining about on IRC a couple of days ago. A detailed explanation of the issue and the fix can be found in the second patch message. The fix consists of two patches. The first just adds an API that's needed by the refactored, fixed code. The actual bug fix is in the second patch. Alyssa Ross (2): msg_socket: introduce UnixSeqpacketExt crosvm: fix deadlock on early VmRequest devices/src/virtio/block.rs | 5 + msg_socket/src/lib.rs | 52 ++++++---- src/linux.rs | 201 ++++++++++++++++++++++++++++++------ vm_control/src/lib.rs | 57 +++++++--- 4 files changed, 245 insertions(+), 70 deletions(-) -- 2.26.2

3 10

[PATCH crosvm 1/2] sys_util: make UnixSeqpacket::recv use libc::recv
by Alyssa Ross 08 Jul '20

08 Jul '20

It's very surprising that a method called "recv" would end up calling read(). When UnixSeqpacket was introduced in 1d44223f9, the method was called "read", so this behaviour made more sense. It was renamed to "recv" in b7196e2a1, but the implementation was not changed to call libc::recv. In most cases, according to recv(2), the difference between read() and recv() doesn't matter: > The only difference between recv() and read(2) is the presence of > flags. With a zero flags argument, recv() is generally equivalent > to read(2) (but see NOTES). But the NOTES section explains that > If a zero-length datagram is pending, read(2) and recv() with a > flags argument of zero provide different behavior. In this > circumstance, read(2) has no effect (the datagram remains pending), > while recv() consumes the pending datagram. This means that, while we might expect UnixSeqpacket::recv(&mut []) to mirror the behaviour of recv() and discard a message despite the empty buffer, it would actually leave it there. This became relevant when I implemented the startup message queue in 5bd2e7f60, because I used an empty recv to drop the ready message from the socket, since it was only used for polling and I didn't care about the content. But, it turns out that my UnixSeqpacket::recv call did nothing, and left the message on the socket. This wasn't immediately noticeable, but it meant that when a message came through on the control socket later, it would actually get the ready message from UnixSeqpacket::recv, rather than the expected message on the control socket. For example, trying to use crosvm disk resize would print a message like the following: > [ERROR:vm_control/src/lib.rs:649] unexpected disk socket result: Ready > [ERROR:devices/src/virtio/block.rs:334] Attempted to resize read-only block device We can see that it does try to process the received message, but first it tries to do something with the Ready message, which should have been discarded by now. With this fix applied, we can see that it now receives and tries to process the correct message (but then fails because the VM I tested didn't support disk resizing!): > [ERROR:devices/src/virtio/block.rs:334] Attempted to resize read-only block device Fixes: b7196e2a1c1eb7123e7eace5418b7eb4a3e24dbe Fixes: 5bd2e7f606b726b598fdc26fe26a9b4029fab6d3 Cc: Cole Helbling <cole.e.helbling(a)outlook.com> --- This is the fix I described in This Week in Spectrum[1]. [1]: https://spectrum-os.org/lists/archives/spectrum-discuss/8736654ij2.fsf@alys… sys_util/src/net.rs | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/sys_util/src/net.rs b/sys_util/src/net.rs index 71ab3eeb5..82b4f5bb0 100644 --- a/sys_util/src/net.rs +++ b/sys_util/src/net.rs @@ -197,7 +197,7 @@ impl UnixSeqpacket { } } - /// Read data from the socket fd to a given buffer + /// Receive data from the socket fd to a given buffer. /// /// # Arguments /// * `buf` - A mut reference to the data buffer. @@ -206,11 +206,11 @@ impl UnixSeqpacket { /// * `usize` - The size of bytes read to the buffer. /// /// # Errors - /// Returns error when `libc::read` failed. + /// Returns error when `libc::recv` failed. pub fn recv(&self, buf: &mut [u8]) -> io::Result<usize> { // Safe since we make sure the input `count` == `buf.len()` and handle the returned error. unsafe { - let ret = libc::read(self.fd, buf.as_mut_ptr() as *mut _, buf.len()); + let ret = libc::recv(self.fd, buf.as_mut_ptr() as *mut _, buf.len(), 0); if ret < 0 { Err(io::Error::last_os_error()) } else { -- 2.26.2

2 6

This Week in Spectrum, 2020-W27
by Alyssa Ross 06 Jul '20

06 Jul '20

I really didn't want this to be another week where I posted about how I was still trying to patch Wayland to do virtio_wl, and I am delighted to have just discovered it's not going to be! crosvm ------ I realised that emulating accept(2) for the Wayland compositor socket in the way I'd planned would require some crosvm rework. I want to have a host proxy program that accepts the connection, then connects the connection socket to crosvm. I had made it possible to dynamically add sockets to the crosvm Wl device through the control socket, but this turned out not be enough, because crosvm would store virtio_wl sockets in a BTreeMap<String, PathBuf>, and then use connect(2) to connect to the socket when asked to by the guest kernel. This works fine for e.g. connecting to a host Wayland compositor, which is what crosvm was designed for, but it wouldn't work for opening a connection socket from accept(2), because you can only connect to a listening socket. So instead, I modified the `crosvm wl add' command to take a file descriptor pointing to the connection socket. I made crosvm store sockets as an enum that looks like this: enum WaylandSocket { Listening(PathBuf), NonListening(UnixStream), } This way, when it gets asked by the VM to connect to a socket, it can either connect to a listening socket at its path using connect(2), or just use the existing file descriptor if it's a non-listening socket. A NonListening socket will be consumed by a connection, so when the VM close(2)s it, it'll go away, and on the host side the connection will finish as expected. Listening sockets can be connected to repeatedly, as before. I also added support to `crosvm add wl' for dynamic socket names. So it's possible to do `crosvm add wl wl-conn-%d', and connections will be added with names like `wl-conn-0', `wl-conn-1', etc. So it's easy to get unique names for connection sockets. The chosen name is printed by the command, so the caller knows what name to tell the VM to connect to. I also found and fixed a bug with the previous crosvm deadlock fix[1]. I had assumed that device_sock.recv(&mut []) would drop a message from the (SOCK_SEQPACKET) socket, without having to read any of it. But UnixSeqpacket::recv calls libc::read, and read(2) tells us that: > In the absence of any errors, or if read() does not check for errors, > a read() with a count of 0 returns zero and has no other effects. So this was in fact doing nothing at all. I don't know why crosvm's UnixSeqpacket::recv calls read() instead of recv(), but it's always been like that and I'm guessing this sort of thing (from recv(2)) might have something to do with it: > The only difference between recv() and read(2) is the presence of > flags. With a zero flags argument, recv() is generally equivalent to > read(2) (but see NOTES). So probably read() just looked like a nicer way to recv() when no flags were needed. But, unfortunately, zero-byte reads are when the aforementioned NOTES section becomes relevant: > If a zero-length datagram is pending, read(2) and recv() with a flags > argument of zero provide different behavior. In this circumstance, > read(2) has no effect (the datagram remains pending), while recv() > consumes the pending datagram. So, my assumption that UnixSeqpacket::recv(&mut []) would consume a message turned out to be quite reasonable -- the surprising thing was that a method called `recv' would call read() rather than recv(). I think the best fix here will be to just make it call recv() instead, rather than modifying my code to do UnixSeqpacket::recv(&mut [0]) or something, to prevent further nasty surprises with this in future. [1]: https://spectrum-os.org/lists/archives/spectrum-devel/20200614114344.22642-… Wayland ------- I created API-compatible implementations of the libc sendmsg(2) and recvmsg(2) functions for virtio_wl sockets. This was quite an achievement, because the API (which allows you to send and receive data and file descriptors, as well as other things I don't intend to support) is rather arcane (see the example in cmsg(3) if you're not familiar with them). I wrote unit tests for them, and it took a long time before they worked reliably. Once I had these, though, I could find the places where Wayland called sendmsg() and recvmsg() and fall back to the virtio_wl-based implementations if the standard functions failed with ENOTSOCK. I stubbed out some stuff that isn't going to work over virtio_wl, like looking up the pid of the Wayland client through getsockopt(2). I also had to resort to a few hacks, like faking support for MSG_DONTWAIT by using fcntl(2) to set O_NONBLOCK on the socket, recv()ing from it, and then removing O_NONBLOCK again, or faking mremap(2) by munmap()-ing and mmap()-ing. We will want to clean these up later by implementing the required missing functionality in the virtio_wl kernel module. In the first case, at least, this should be pretty straightforward, because it supports non-blocking operations if the socket is O_NONBLOCK -- it just needs to accept a MSG_DONTWAIT option as well. The VIRTWL_IOCTL_{SEND,RECV} syscalls don't currently have a flags argument, so that'll need to be added. I implemented this bit by bit, at every step trying to run Alacritty on my host system, connected to the virtio_wl Wayland server socket through the accept() proxy, and using strace and some printf()-debugging to see where the Wayland compositor in the VM would get stuck, and about an hour ago, it finally worked! For the first time, a Wayland compositor running in a VM can display an application running outside of it. (Obviously we'll want the application to be running in another VM rather than on the host, but that's similar enough that it probably works already -- I just haven't tested it yet.) This feels like a huge achievement. I've been working towards it for so long. Next week, I'll be cleaning up this code and posting patches for all of it. Then I'll probably move on to other sorts of device virtualization, like running a virtual network device in a VM. I'm feeling so much more positive about the direction of the project than I was before. It's been difficult to make myself keep going making little progress for the last couple of weeks, and it's great that I've managed to pick things up again so much. I hope that the level of detail in this email is enough to make up for the brevity of last week's! I'm sending late again, too, but only by a couple of minutes -- I didn't expect this email to take over an hour to write, but there we go. Thanks for reading! I hope you're looking forward to seeing where things go from here as much as I am.

1 0

This (Last) Week in Spectrum, 2020-W26
by Alyssa Ross 29 Jun '20

29 Jun '20

This is going to be a very short one, and it's coming a day late, because I have been busy and didn't want to stop yesterday. 2020-W22's TWiS was sent a day early, so the delay is balanced out. :) Wayland ------- I'm finally making progress with the Wayland stuff I've been staring at for the past two weeks! Now that I'm unblocked, things feel like they're moving very quickly. I've modified a Wayland compositor and libwayland-server to use a virtio_wl socket. I've also implemented the compositor side of the accept(2) fallback. Just now, I finished writing a proxy program that implements the host side of that. Next up is testing it. After that, I think we might be there? But it's also possible I have my head so deep in it there's another bit that I've forgotten.

1 0

This Week in Spectrum, 2020-W25
by Alyssa Ross 21 Jun '20

21 Jun '20

Another week that ended up being a detour from the Wayland work I wanted to do, unfortunately. I think this will be the end of it, though. crosvm ------ Fixed[1] an error in my crosvm deadlock fix[2] from last week. Due to an oversight (obvious as soon as I tried to test the affected devices, and from looking at the code in retrospect), this actually broke the devices that were *not* affected by the deadlock, which I had neglected to properly test. Fortunately, it was a very small and easy fix. I also had an interesting (and ongoing) conversation[3] with Cole about the deadlock fix in the mailing list thread. It's one of those situations where getting to talk about the code with another person and having to explain things is going to result in much better code. So we'll end up with a much tidier fix than what I came up with on my own. Thanks to Cole for his feedback and this opportunity. It's great to know that somebody else is passing an eye over my code. [1]: https://spectrum-os.org/git/crosvm/commit/?id=ca5bdd2ac3e473e9b082c44c2870f… [2]: https://spectrum-os.org/lists/archives/spectrum-devel/20200614114344.22642-… [3]: https://spectrum-os.org/lists/archives/spectrum-devel/CH2PR14MB357902F38908… Wayland ------- My current area of attention is modifying Wayland to use a virtio_wl socket as the display socket. Preparing to start implementing that this week, it occurred to me that working on it using my current setup was going to be extremely time consuming. Up until now, I've been doing Nix VM rebuilds when I want to test a change to, for example, wlroots. This means rebuilding, in that case, wlroots and all dependencies (i.e. Wayfire). In the case of wlroots, it's not so bad because rebuilding two packages doesn't take all that long, but it wasn't going to work for Wayland. So I decided that the best way forward would be to create a VM running a traditional Linux distribution, in which I could hack on Wayland without having to restart the VM or rebuild all of its dependents. To that end, I spent much of this week setting up an Alpine VM that can be run under both crosvm and QEMU. (Configuring networking with crosvm is hard for a one-off like this, but QEMU has a built-in userspace networking stack[4] that makes it easy, so when I want to, e.g. install a package, I can boot with QEMU to do that, and then go back to crosvm for testing virtio_wl things.) This resulted in a Nixpkgs pull request[5] to package Alpine's apk package manager, which was used in building the VM image. As of this afternoon, I have this VM all set up and ready to go. I have a script that runs it under crosvm with a virtio_wl socket available to try to connect Wayland to, and another virtio_wl socket connected to the host Wayland compositor for testing. It also sets up some limited networking that allows me to SSH into the VM, but does not allow the VM to access the internet. A separate script runs the VM under QEMU with full networking. The VM has Wayland, wlroots, and Sway (the choice of wlroots-based compositor is irrelevant to this work, and Sway is easier to build) installed from source, and because I can SSH to it I can edit files in the VM easily from my host Emacs using TRAMP[6]. All of this will allow me to iterate on the Wayland work without having to wait upwards of an hour to test each change. This was actually the first time I'd ever booted a VM image in crosvm that I hadn't generated specifically for that purpose myself with Nix. I improved my understanding of crosvm in a few ways in the process (although not anything concrete enough I can think of to write down here). [4]: https://wiki.qemu.org/Documentation/Networking#User_Networking_.28SLIRP.29 [5]: https://github.com/NixOS/nixpkgs/pull/90676 [6]: https://www.gnu.org/software/tramp/ Next week, I'll continue with the Wayland work. It shouldn't be all that much work in the end, but getting set up to actually be able to do it has been annoyingly complicated.

1 0

This Week in Spectrum, 2020-W24
by Alyssa Ross 14 Jun '20

14 Jun '20

An interesting week. Didn't go quite in the direction I expected it to. Documentation ------------- Cole kindly provided[1] some documentation[2] for spectrum-vm for the developer manual. This was especially nice, because it marked the first time I was able to remove[3] an item from the Contribution Ideas page[4] because somebody had done the contribution! Thanks Cole! [1]: https://spectrum-os.org/lists/archives/spectrum-devel/87zh97coks.fsf@alyssa… [2]: https://spectrum-os.org/doc/developer-manual.html#_spectrum_vm [3]: https://spectrum-os.org/git/www/commit/?id=bf7cde0ddd06455f212fb39092b87313… [4]: https://spectrum-os.org/todo.html crosvm ------ My main goal for this week was to start modifying libwayland-server to use a virtio_wl socket as the display socket, as described last week[5]. So, in pursuit of this goal, I started the week by trying to write a test program that would start a VM running a compositor, create a socket, attach one end to that VM, and then start another VM running a Wayland client, and attach the other end of the socket to that VM. Then, in theory, all I had to do was the libwayland-server modifications, and then the compositor and client would be able to talk to each other. Unfortunately, I didn't get that far. The program froze after starting the first VM. I assumed I must have done something wrong, so I rewrote it, and had the same problem. I did it again, and same problem. Some further debugging revealed that the command to add the socket to the first VM was hanging. And also, crosvm was hanging. Running the command outside this program worked fine, though. It returned immediately, and crosvm kept running with the new socket added. What I eventually realised was that the crosvm hang only happened if the command was sent to it early enough. After some intense staring at the crosvm code, I realised that there was a deadlock resulting from trying to wait for a response from a virtual device before the device had been initialized. Despite this issue manifesting with adding Wayland sockets, which is a feature unique to crosvm, a lot of the code for that is adapted from the code for resizing virtual block devices, which is an upstream feature. And that had the same issue, so this is actually an upstream bug. The fix was not easy, and required some fairly substantial refactoring. It's described in detail in the patch message[6]. I think it's probably a pretty interesting read. I also merged in the latest upstream crosvm changes. [5]: https://spectrum-os.org/lists/archives/spectrum-discuss/87tuzm287b.fsf@alys… [6]: https://spectrum-os.org/lists/archives/spectrum-devel/20200614114344.22642-… Nixpkgs ------- I spent a few more hours trying to get libvda (an optional dependency of crosvm; required for virtio-video) to build, and I got it to work, thanks to some help from Puck. There's still a hack in there I'll tidy up before I push it, but it's cool to have this packaged for future experimentation with this crosvm feature. With the crosvm issue out of the way, which ended up taking most of the week to identify and fix, hopefully next week I'll be able to actually get going on those libwayland-server changes.

1 0

[PATCH doc v2] Document spectrum-vm
by Cole Helbling 13 Jun '20

13 Jun '20

spectrum-vm is a handy way to start a crosvm instance for testing crosvm itself, the kernel, or the rootfs. This commit adds some fledgling documentation on its functionality and usage. --- Takes into account review suggestions and tweaks a bit of wording here and there. Specifically, I clarified that rootfs means the root filesystem, added an aside that the serial console can be used to run privileged commands, dropped the full `spectrum-vm --help` text, and moved and reformatted the usage examples. developer-manual.adoc | 53 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 53 insertions(+) diff --git a/developer-manual.adoc b/developer-manual.adoc index b7eb2cb..a98330f 100644 --- a/developer-manual.adoc +++ b/developer-manual.adoc @@ -106,6 +106,59 @@ the https://spectrum-os.org/doc/crosvm/crosvm/[crosvm documentation] for the version currently used by Spectrum is hosted on the Spectrum website. +==== spectrum-vm + +`spectrum-vm` is a shell script that allows for testing various Spectrum +VM components, including crosvm, the kernel, and the root filesystem +("rootfs" for short). The simplest way to use this tool is by running +`nix-shell -I nixpkgs=/path/to/nixpkgs-spectrum -p +spectrumPackages.spectrum-vm --run spectrum-vm` in a terminal, which +will start up an instance of crosvm from Nixpkgs running Wayfire in a +new window. + +**** +Be advised that Wayfire's default keymap is set to Dvorak +https://spectrum-os.org/git/nixpkgs/tree/pkgs/os-specific/linux/spectrum/rootfs/default.nix[inside +of the rootfs] -- to change this to your preferred keymap, just set the +`xkb_layout` option (or remove it altogether for a default of QWERTY). +**** + +Once you are ready to end your crosvm session, switch back to where you +ran `spectrum-vm` and type `reboot` (not `poweroff`). This window is not +limited to just stopping the VM, however; it is a functional serial +console where you can even run commands like `env` and `cat +/etc/passwd`. + +**** +Although it is currently not possible to execute commands as root inside +the graphical environment, one can instead use the serial console to run +privileged commands. +**** + +===== Examples + +As mentioned above, `spectrum-vm` also supports options that allow you +to specify custom components or run arbitrary commands before exiting: + +---- +nix-shell -I nixpkgs=/path/to/nixpkgs-spectrum -p spectrumPackages.spectrum-vm + +# display the currently supported options for spectrum-vm +nix-shell$ spectrum-vm --help + +# run a command that will print out the VM's PATH to the serial terminal and exit +nix-shell$ spectrum-vm -c 'echo $PATH' + +# use the specified crosvm and disable sandboxing +nix-shell$ spectrum-vm -C target/debug/crosvm -- --disable-sandbox + +# use the specified kernel image +nix-shell$ spectrum-vm -k result/bzImage + +# use the specified squashfs as the root filesystem image +nix-shell$ spectrum-vm -f squashfs +---- + ==== Hacking on crosvm There are a few ways to get a crosvm development environment. You can -- 2.26.2

2 1

[PATCH doc] Document spectrum-vm
by Cole Helbling 10 Jun '20

10 Jun '20

spectrum-vm is a handy way to start a crosvm instance for testing crosvm itself, the kernel, or the rootfs. This commit adds some fledgling documentation on its functionality and usage. --- I feel like this is mostly a rough draft, so give me all your suggestions/criticisms/what have you. I put this section above the "Hacking on crosvm" section so that it will be introduced before it is used in an example. developer-manual.adoc | 43 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) diff --git a/developer-manual.adoc b/developer-manual.adoc index b7eb2cb..739dc83 100644 --- a/developer-manual.adoc +++ b/developer-manual.adoc @@ -106,6 +106,49 @@ the https://spectrum-os.org/doc/crosvm/crosvm/[crosvm documentation] for the version currently used by Spectrum is hosted on the Spectrum website. +==== spectrum-vm + +`spectrum-vm` is a shell script that allows for testing various Spectrum +VM components, including crosvm, the kernel, and the rootfs. The +simplest way to use this tool is by running `nix-shell -I +nixpkgs=/path/to/nixpkgs-spectrum -p spectrumPackages.spectrum-vm --run +spectrum-vm` in a terminal, which will start up an instance of crosvm +from Nixpkgs running Wayfire in a new window. + +**** +Be advised that Wayfire's default keymap is set to Dvorak +https://spectrum-os.org/git/nixpkgs/tree/pkgs/os-specific/linux/spectrum/rootfs/default.nix[inside +of the rootfs] -- to change this to your preferred keymap, just set the +`xkb_layout` option (or remove it altogether for a default of QWERTY). +**** + +Once you are ready to end your crosvm session, switch back to where you +ran `spectrum-vm` and type `reboot` (not `poweroff`). This window is not +limited to just stopping the VM, however; it is a functional serial +console and you can even run commands like `env` and `cat +/etc/passwd`. + +As mentioned above, `spectrum-vm` also supports options that allow you +to specify custom components or run arbitrary commands before exiting: + +---- +nix-shell -I nixpkgs=/path/to/nixpkgs-spectrum -p spectrumPackages.spectrum-vm + +nix-shell$ spectrum-vm --help +Usage: spectrum-vm [OPTION]... [-- CROSVM_OPTIONS] + + -c COMMAND shell command to run inside VM + -C, --crosvm PATH path to custom crosvm executable + -k, --kernel PATH path to custom kernel image + -f, --rootfs PATH path to custom root file system image + -- CROSVM_OPTIONS extra arguments to pass to crosvm + +nix-shell$ spectrum-vm -c 'echo $PATH' # print out the VM's PATH to the serial terminal and exit +nix-shell$ spectrum-vm -C target/debug/crosvm -- --disable-sandbox # use the specified crosvm and disable sandboxing +nix-shell$ spectrum-vm -k result/bzImage # use the specified kernel image +nix-shell$ spectrum-vm -f squashfs # use the specified squashfs as the root filesystem image +---- + ==== Hacking on crosvm There are a few ways to get a crosvm development environment. You can -- 2.26.2

2 1

This Week in Spectrum, 2020-W23
by Alyssa Ross 07 Jun '20

07 Jun '20

I wasn't quite back up to normal speed after being sick last week, I think, but we're getting somewhere and I did some cool stuff! Infrastructure -------------- Upgraded Mailman. Most significantly, the Hyperkitty UI has some nice improvements, which I think will make it easier to navigate. :) Nixpkgs ------- I integrated and committed last week's wlroots patch (to make it use virtio_wl-compatible memfds). Spent quite a lot the start of the week working on packaging more Chromium OS components to build some optional crosvm features. They just added support for virtio-video[1], which sounds pretty cool. I managed to get libchrome working again, which I previously had to remove because I couldn't get it to build! I haven't committed any of this yet, because I haven't got to the point where it's useful for building optional crosvm features, and I don't want to add packages that aren't useful for anything, but I did make quite a lot of progress. After a couple of days of this, though, I put it aside to focus on other things, since it would be useful to have, but its not a priority right now. [1]: https://chromium.googlesource.com/chromiumos/platform/crosvm/+/57df6a0ab23c… crosvm ------ I posted a patch[2] to make listing a directory shared with --shared-dir not crash crosvm when sandboxing was enabled. I'd been reluctant to fix this, because --shared-dir (which exposes a host file system to a crosvm guest) is not going to be useful in Spectrum, where shared directories should come from another VM. But it's useful enough in development that not fixing it was more frustrating than just fixing it. I spent a lot of time this week thinking about Wayland connections. My original plan for inter-VM communication was to make it possible to run crosvm devices as standalone programs inside VMs. I still think this is the right track for most virtio devices, but for Wayland it's starting to feel less and less like it makes sense, because the Wayland device is basically a wrapper around a socket, and both ends will be hooked up to sockets. So what I now plan is that a VM running a Wayland client application will connect to a host socket, with the other end connected to a VM running the compositor. The client applications will be run under Sommelier, and so will be able to run unmodified. The compositor will be modified to use a virtio_wl socket. A slight complication here is that a Wayland compositor usually accepts on a socket to receive client connections, but you can't accept on a virtio_wl context. So instead, what we can do is emulate accept by attaching a new virtio_wl socket, and then sending the name of that socket over the main socket. This can be wrapped inside the VM to look very much like an accept. Unfortunately, crosvm virtio_wl sockets could only be set at startup time. So today I fixed that[3]. Adding support for adding virtio_wl sockets at runtime was pleasantly straightforward. I feel very energized now that I managed to bang that out in a day. :D [2]: https://spectrum-os.org/lists/archives/spectrum-devel/20200605234757.28848-… [3]: https://spectrum-os.org/git/crosvm/commit/?h=interguest This is one of those weeks where I can feel writing this that it might not make much sense to anybody else. But the important thing with these weekly updates is that I write _something_ we can refer back to in future, and communicate that things are happening. If you'd like to better understand what I'm talking about here, I'm happy to try walking through it on IRC. Next week, I'm going to work on getting libwayland-server to speak this weird virtio_wl faux-accept.

1 0