Re: New user getting started questions

Thomas Leonard
2021-01-27T17:31:50Z

I've made a bit of progress this week:

It turns out that weston-terminal crashes sommelier if started when
the clipboard is empty, due to trying to dereference NULL. I've
patched it to fix that, and now I can run it directly under sommelier,
without wayfire. I made a few other changes to sommelier too:

- I switched to the latest version, which provides meson instead of
common-mk for building. Also, they removed the demos and got rid of
some bogus dependencies. That simplified the build a lot!
- They switched to the stable XDG protocols, but then reverted it
again. I unreverted it to get things going again. Not sure if I did it
right (they migrated from C to C++ so the patch didn't apply
directly).
- I added xwayland to the VM and sommelier command, allowing X
applications to run in the VM.
- By default sommelier runs the program with an already-open socket,
which doesn't work if the program (or its children) want to open
multiple connections.
I was able to fix that by using `--parent` mode, and getting rid of
PEER_CMD_PREFIX (which just adds some chromium paths preventing it
from working).
- Note: in `--parent` mode it waits for the process to exit before
processing events on the socket, so if you just run an application
directly it will hang. I used `bash -c 'firefox &'` as the command as
a work-around.
- Some programs (e.g. firefox) refused to start because the protocol
versions offered by sommelier were too old. I increased the version
numbers and that's working now. It needs doing properly, though. e.g.
I implemented the new "sl_host_surface_damage_buffer" by simply
calling the old damage function, which is obviously not correct but is
working for me so far!
- Annoyingly, using `--parent` disables xwayland support. Maybe we
should run xwayland manually, or use a second sommelier instance?

In general, sommelier seems quite buggy and annoying. I guess it will
need updating constantly to proxy every new wayland protocol. Yet it
can't add any useful security because it runs inside the VM, and is
therefore untrusted.

Some other changes that I found useful:

- I added the generated kernel modules directory to rootfs, which
allows using all the normal features of Linux (e.g. ext4) in the VM.
- I switched from `bash` to `bashInteractive` as the VM shell, which
gets cursor keys working.
- I wrote a Nix package to generate one script for each of my old
qubes. So e.g. I can now run `qvm-start-shopping` to start my crosvm
shopping instance, with its own /home LVM partition and IP address. It
passes the network configuration using some new kernel parameters
(alongside spectrumcmd).
- I put each VM on its own point-to-point virtual network. These
networks are set up by /etc/nixos/configuration.nix. That works well
for my qubes-like VMs, though I guess spectrum will need something
more dynamic.
- I enabled the shared filesystem (VIRTIO_FS), which works nicely. I
use it to provide a (separate) shared directory to each VM that I can
access from the host.
One problem is that the crosvm driver runs in a minijail with a
uidmap that makes every file appear to be owned by root, so only root
can write things in the VM.
Possibly a newer kernel would help; later versions of the kernel
docs say you can include any normal FUSE flags here, so mounting with
`uid=1000` might work.
- Finally, I added a `vm-halt` command that just calls `reboot`, as I
don't want to develop the habit of typing `reboot` without thinking
;-)

If any of this sounds useful for spectrum let me know. I can try and
tidy it up; it's all a huge mess at the moment!

Once this is working more smoothly, I guess the next issues will be
setting up some kind of secure window manager on the host (e.g.
labelling windows with the VM they come from, not allowing
screenshots, etc). Would also be good to get sound forwarding working
somehow (Qubes routes pulseaudio to all the VMs and gives you a mixer
to control the levels for each, but I don't know how that worked). It
also needs some kind of VM manager to keep track of which VMs are
running. And some kind of IPC system like qrexec would be useful. Do
you have thoughts or plans about how to do any of this?

On Wed, 20 Jan 2021 at 13:04, Thomas Leonard <talex5@gmail.com> wrote:
>
> On Thu, 14 Jan 2021 at 12:51, Alyssa Ross <hi@alyssa.is> wrote:
> [...]
> > Oh, whoops, I missed your reply about having worked this out already!
>
> Yeah, disk and networking is OK now.
>
> I also managed to fix the fonts, by using `export FONTCONFIG_FILE
> /etc/fonts/fonts.conf`. By default, it didn't have a monospace font
> available, which was pretty hard to read in the terminal.
>
> I want to get wayland forwarding working next. For now, I'm using `ssh
> -Y` to my VM to forward X. It works, but it's a little slow.
>
> I set `export WAYLAND_DEBUG 1`, and tried weston-terminal again. That produced:
>
> [...]
> [446067.157] -> wl_region@21.destroy()
> [446067.481] -> wl_surface@16.set_input_region(wl_region@22)
> [446068.036] -> wl_region@22.destroy()
> [446068.412] -> wl_surface@16.attach(wl_buffer@24, 0, 0)
> [446069.190] -> wl_surface@16.damage(0, 0, 806, 539)
> [446070.141] -> wl_surface@16.commit()
> [446070.531] wl_keyboard@20.keymap(1, fd 8, 48869)
> [ 1.796076] sommelier[88]: segfault at 30 ip 00007fa5376062c0 sp
> 00007ffe128592c8 error 4 in
> libwayland-client.so.0.3.0[7fa537604000+6000]
> [ 1.798026] Code: ff ff ff 5d 41 5c c3 0f 1f 00 48 8d b7 d0 00 00
> 00 e9 e4 df ff ff 0f 1f 40 00 48 89 77 30 c3 66 66 2e 0f 1f 84 00 00
> 00 00 00 <48> 8b 47 30 c3 66 66 2e 0f 1f 84 00 00 00 00 00 8b 47 40 c3
> 66 66

--
talex5 (GitHub/Twitter) http://roscidus.com/blog/
GPG: 5DD5 8D70 899C 454A 966D 6A51 7513 3C8F 94F6 E0CC