Fully ephemeral DispVM's

[anywaydense]

I recently wrote a patch that makes all PVH DispVM's fully ephemeral in the sense that all writes to the disk are encrypted by an ephemeral encryption key, with dom0 handling the encryption.

Currently Qubes implements this (when ephemeral=True and vm:root rw 0) for data written to xvda and swap but not for data written to xvdb (i.e /rw). This patch fixes the issue and encrypts ephemerally all data written to disk from a PVH DispVM.

This is accomplished by making xvda, xvdb read-only and ephemeral=True the defaults for DispVM's (three line patching of dispvm.py) and by patching /init of initramfs of the pvh kernel so that all data writes are routed to xvdc using dmapper. This routing is already partially accomplished in qubes by mapping all writes to xvda to dmroot when vm:root rw is set to False. The patch now routes in addition (when vm:private rw 0) all writes to xvdb to dmhome and seamlessly relabels in fstab xvdb to dmhome, before /sbin/init is initialized. The fact that xvda and xvdb are now set to be readonly in DispVM's and only xvdc is writeable and ephemerally encrypted ensures that no data escape is possible.

I wrote a script to implement the patch on a live R4.1 system. It is available at

https://github.com/anywaydense/QubesEphemerize

I would be delighted to hear your comments.

[Demi Marie Obenour]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

This is great, thanks! As far as storage is concerned, you can use a
thin pool and external-origin snapshots, which might simplify some of
the code. You can also use read (a shell builtin) instead of cat in
various places.

There is a chance that the disposable qube’s /rw and/or / could run out
of space, causing I/O errors. With thick snapshots I believe this is
fatal and causes all further I/O to fail. Thin snapshots are slightly
better and “merely” fail all further writes to unprovisioned blocks. To
prevent both problems, one can ensure that the volatile volume has
sufficient space allocated to it, but this increases the amount of
space the disposable qube could consume so there is a tradeoff.
- --
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmKqlrMACgkQsoi1X/+c
IsHEcBAAw4dDm/kbFUVBncdarFE0bgTl6Wj8omSeKZTM2GXioGqg4DvHjoQ/cASO
rEXI9ZKu2tZBQLcFWAYx98AxfXtrq4IESXMY0MziY7qh+JPS/4TN3dHS6sNZnS+3
aLmZq4I4wLrgm1dR+Dr/F1CX1SbjH1ZZvDH5y/lURnDUYX1TF0Zzw6GtSlNEMnlh
wiZUwIS19BJP+yVRyEdaR0AWHdpWC8yypN8BeOTAIOJ7sSurywPiKqw77Z3Kg4L5
hZWDpqHfHUFOXzTfkqnOayi6yUpSAQJpIlJKNHT9xSSOGMBML1+xSJqCfY0G1klw
4tWP6XtytJgslg0gpyBU289re0LJWWe6MXygOIFeImqHy+yHMBepG1QS3G3Va2y9
w0jYDvSwpHUdEXOP8on8Afvi0qET4ldw/xCK0/7hLyGm8afgjHAiG/G6tmyrQm8W
dxarU6+19SuEJQQdWTpsK/LyV1fdW7468LKdBTEggqZAjGSR4IzhocrN+9GufOaG
yktnGliiOqPHc7A+qu06L4VvYyjBj803W8HxdAT6ZcdCeS1qMSBbEpODDmyf1y4U
TrmkfdSfo4NOp9o82SS+9vuSrauNE40xXPJqRLVM2hoooeesvX8hdOSFN0hEC/Eg
tYL9e7ZPd/iRh8yG7vfi+QCRCbTisSg0wgJRs89yeUbBtPoKry0=
=4Qkz
-----END PGP SIGNATURE-----

[anywaydense]

> On Thu, Jun 16, 2022 at 12:34:50AM +0000, Qubes OS Development Mailing List wrote:
>
> > I recently wrote a patch that makes all PVH DispVM's fully ephemeral in the sense that all writes to the disk are encrypted by an ephemeral encryption key, with dom0 handling the encryption.
> >
> > Currently Qubes implements this (when ephemeral=True and vm:root rw 0) for data written to xvda and swap but not for data written to xvdb (i.e /rw). This patch fixes the issue and encrypts ephemerally all data written to disk from a PVH DispVM.
> >
> > This is accomplished by making xvda, xvdb read-only and ephemeral=True the defaults for DispVM's (three line patching of dispvm.py) and by patching /init of initramfs of the pvh kernel so that all data writes are routed to xvdc using dmapper. This routing is already partially accomplished in qubes by mapping all writes to xvda to dmroot when vm:root rw is set to False. The patch now routes in addition (when vm:private rw 0) all writes to xvdb to dmhome and seamlessly relabels in fstab xvdb to dmhome, before /sbin/init is initialized. The fact that xvda and xvdb are now set to be readonly in DispVM's and only xvdc is writeable and ephemerally encrypted ensures that no data escape is possible.
> >
> > I wrote a script to implement the patch on a live R4.1 system. It is available at
> >
> > https://github.com/anywaydense/QubesEphemerize
> > I would be delighted to hear your comments.
>
>
> This is great, thanks! As far as storage is concerned, you can use a
> thin pool and external-origin snapshots, which might simplify some of
> the code. You can also use read (a shell builtin) instead of cat in
> various places.
>
> There is a chance that the disposable qube’s /rw and/or / could run out
> of space, causing I/O errors. With thick snapshots I believe this is
> fatal and causes all further I/O to fail. Thin snapshots are slightly
> better and “merely” fail all further writes to unprovisioned blocks. To
> prevent both problems, one can ensure that the volatile volume has
> sufficient space allocated to it, but this increases the amount of
> space the disposable qube could consume so there is a tradeoff.

> --
> Sincerely,
> Demi Marie Obenour (she/her/hers)
> Invisible Things Lab

Thank you Demi! I was wondering if there is currently a way for a running system to detect whether it is run in HVM or PVH mode? There is a minor issue with HVM's running this patch that I would like to fix.

Alternatively how could I detect in dispvm.py whether the DispVM being created is hvm or pvh? I had some trouble locating the place in the code at which the virt_mode setting is set when creating the DispVM.