Future certification requirements

[Demi Marie Obenour]

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

I would like to propose the following as future Qubes OS certification
requirements. These would not apply for R4.1, but rather to a future
(to be determined) release. Feedback would be appreciated, especially
from hardware vendors.

1. Network and USB controllers (any device that would be attached to
sys-net or sys-usb by default) must not have persistent mutable
state. This also applies to internal USB devices attached to such a
controller.

Rationale: This ensures that the isolation provided by sys-net and
sys-usb cannot be bypassed by inserting a backdoor into the attached
PCI device. In particular, it means that if sys-usb (respectively
sys-net) is a DisposableVM, a compromise of sys-usb (respectively
sys-net) will not persist across reboots.

2. During any system startup, all DMA-capable devices must be bounced
through D3Cold for long enough to ensure that all on-card
non-persistent mutable state is reset. This must happen before PCI
bus mastering is enabled. Devices that make no sense to pass through
(such as i2c controllers) are excluded.

Rationale: This is to ensure that any non-persistent mutable state is
wiped before the device can perform a DMA attack.

3. The firmware’s network stack (if any) must be disabled by default.

Rationale: This is a large attack surface that is almost never useful
for desktops or laptops, except in corporate environments.

4. The firmware’s USB stack (if any) must not be enabled unless USB boot
is selected. As an exception, if the machine has a separate USB
controller for just HID devices, and the ports connected to this
controller are clearly marked as “for trusted devices only”, the
firmware may enable USB by default on this controller only.

Rationale: This ensures that if someone has plugged a malicious USB
device into sys-usb, and the system reboots unexpectedly, the device
cannot exploit the firmware USB stack on the next boot.

5. Option ROMs for USB, network, and removable devices (including, but
not limited to, Thunderbolt and ExpressCard) must be disabled by
default.

Rationale: This is to remove one means of performing early boot
attacks if option ROMs turn out to be writable, even though they
should not be writable. In the case of Thunderbolt and ExpressCard,
executing option ROMs during boot allows for close-case attacks.

6. Removable devices must not be allowed to perform DMA until the
operating system has explicitly permitted them to do so.

Rationale: This prevents DMA attacks by removable devices, which are
not trusted, even before the IOMMU is brought up.

7. Graphics cards must not have persistent mutable state, including
option ROMs.

Rationale: This is to prevent sys-gui-gpu ⇒ dom0 escalation, and to
ensure that a graphics card that is attached to an untrusted qube
(e.g. for gaming) cannot allow the untrusted qube to escalate its
privileges.
- --
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmKa2aUACgkQsoi1X/+c
IsGMSxAAgbuyRu/8DrPDLt7KcLwgQB1O3JqJFBdeS4ZXMlhIeyBKwPdki3qJTuka
41q/TNRaCiNMPZcu1oRsTTfMuw8JfVuM51y+r2RdpDe6MikiQE1BKnNLI+sAmtwp
pv/u5TyQIaCRlBfXoUjylEnk6gBuPlNECNC7hLjwS7VnMMoQnHkGLMlloEkKHKpP
+AogAeLhRO0lQEWq1Tr/QRl8NnnAeAJ6Q/2d+m1mcu9OILkj2SsO8Q3nmvB6Rdw5
F18SgwB/jodhBcrbmVb5aI7MoD5vu4y/UyKZ5Wq1vPlrAY0NDrRhTasotvgt+7dX
ioh7pWZ4W9JW7qCHhNrzft5aj/+ZJkYpiFpyz4iBQYARZwC4OnJUYiugRPiKxp09
gQXmhp1J9g1DgYR8mLzn1dT/BHFuHo5YS9ggFjg8oZaznU3wY+d8u4KD5m9k5VIW
2pzqCC63tyRQ1Z+GIptMsFtqcbVRuHBVK7Ld7FfcAMH/oHAgQymYJRcynir199zl
u37sAdck1lqbQtMtD4bTbiloA3jenPReHoHywA6heJ0mrCjxdJmA+cxoDsaUjwvP
KTB8QE7+BUERA0KzcyMDp/NI/DQTZ1n05+NKaCHb4qKY9ZUTSQmwEL8uOWv1Yda0
Z6LzdXZ9nITlf7w85R8HEP2bQ+8a1mZAb095jq0pCVDxDO3WdJU=
=nIsN
-----END PGP SIGNATURE-----

[Michał Żygowski]

Hi Demi,

Thank you so much for these requirements. It contains many insights into how software/firmware can do better. Still, I have some questions and doubts I wish you could clarify:

Ad. 1. I find multiple occurrences of the oxymoron "persistent mutable state" in the 1st point and e.g. 7th. Could you please explain what state might be mutable and yet persistent? These terms look contradictory to me.
Ad. 2. D3cold basically means the device has to go to D3hot plus all power cut off from the device. While modern laptops typically support that with modern standby (S0 idle) RTD3, bouncing through D3cold requires a compatible mainboard design. Looking from the workstation's perspective it would not be possible (unless one would do ACPI G3 cycle on each system startup). Please correct me if I'm wrong.
Ad. 5. Some desktop Intel CPUs are GFX-less, which implies the usage of an external GPU card. Would EFI OptionROM be allowed to run on display devices in such case? Otherwise one may end up without the display working in the firmware thus relying on booting in blind.
Ad. 7. See Ad. 5. regarding Option ROMs. There is a way to go: extract the EFI OptionROM, put it into the firmware image, and disable OptionROMs entirely. However, it would require a custom firmware build for each hardware setup/graphics card. Almost nobody would do it given that most people do not have control over their firmware source code.

Please advise on the above concerns.

Best regards,
Michał Żygowski
Firmware Engineer
GPG: 6B5BA214D21FCEB2
https://3mdeb.com | @3mdeb_com

[Demi Marie Obenour]

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

On Wed, Jun 08, 2022 at 02:22:12AM -0700, Michał Żygowski wrote:
> Hi Demi,
>
> Thank you so much for these requirements. It contains many insights into
> how software/firmware can do better. Still, I have some questions and
> doubts I wish you could clarify:
>
> Ad. 1. I find multiple occurrences of the oxymoron "persistent mutable
> state" in the 1st point and e.g. 7th. Could you please explain what state
> might be mutable and yet persistent? These terms look contradictory to me.

“Persistent mutable state” means state that is mutable by the host and
which persists across reboots. This is a problem for PCI pass-through,
as it allows the VM controlling the passed-through device to tamper with
the device, in a way that will not be fixed by rebooting the system.

> Ad. 2. D3cold basically means the device has to go to D3hot plus all power
> cut off from the device. While modern laptops typically support that with
> modern standby (S0 idle) RTD3, bouncing through D3cold requires a
> compatible mainboard design. Looking from the workstation's perspective it
> would not be possible (unless one would do ACPI G3 cycle on each system
> startup). Please correct me if I'm wrong.

I am not at all familiar with these power management details. Is there
some reason an ACPI G3 cycle would be bad?

> Ad. 5. Some desktop Intel CPUs are GFX-less, which implies the usage of an
> external GPU card. Would EFI OptionROM be allowed to run on display devices
> in such case? Otherwise one may end up without the display working in the
> firmware thus relying on booting in blind.

If there is a non-spoofable way to distinguish the GPU card, and if the
GPU card option ROM is not mutable, this would be okay. This could be
ensured by e.g. having the hypervisor intercept and reject writes to it,
together with ensuring that there are no other ways to write to it via
the GPU. Another approach would be to require that the option ROM is
digitally signed by the firmware vendor. Obviously, Thunderbolt device
option ROMs must never be run, as removable devices must be considered
untrusted.

> Ad. 7. See Ad. 5. regarding Option ROMs. There is a way to go: extract the
> EFI OptionROM, put it into the firmware image, and disable OptionROMs
> entirely. However, it would require a custom firmware build for each
> hardware setup/graphics card. Almost nobody would do it given that most
> people do not have control over their firmware source code.

What about something like LinuxBoot? Have the firmware load a basic
Linux system, and have that kexec. This avoids the need for working
graphics in the firmware, since the Linux kernel has its own drivers.

- --
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmKghj0ACgkQsoi1X/+c
IsE7Cg//VNwzsnFtVFZHDT4h2CnZ3uLHMqHqF0LWmFcQ77ofdcNwqMKpArICKC6B
dI0C1+C6+jscJK5NQOp50ge9eCeZA1nVIfYSOkn+7RQ3KoXqHeeeOT7LlmEbfEI5
+pamNZ35SGu153Fw8OQsTH1J3nP5QC/e0vCTVbG1A8qy7+KhXL4G/OBFybgMlpCU
PUSAImv7Y9uQhlqPg6Ll8okJR3ISjy7i2kPBjdC9AuQ7KgBrQkjU+OVCR75Rh87G
0HWF5/ns7ymmfhHEhFxHxvmhAMm89aRu4nRxYgnkoTRvTOsQrBorzk982m6iieou
ga23xMxRZLDpke+z4KK+tuS8SqpHnYbAW/l+jkgkCT8Gts5+YWyzKP9evCuTQtTT
eDf0cYSqRLl4RAoJYBKyrD2E7W8Cy54uUJ7O8Wy5CcwAqwcV4fD2AN8AAI+ah1HT
S/fD6hhQNGs4qdYE8uatLws0E9dwffxwQp7cFI17LfuQajw8YEs3cnOjgWIKs405
stTmNFNKGAWL84aC7bycxcyD/tz3Y6jbLWLBEgW4KhDBd5k3hpb8sbrIJS/xHaQt
t6HrN2N/d4hOdLYHTf7IoOEp17dvjONNZIIicHaWnEmNY2GzJ+2pMxk67z5Lp0fG
ST4UCOopPq+7VV8m7rzNHVPqTQTEBxh2YyNp42o1arIfiZGvldI=
=aDsF
-----END PGP SIGNATURE-----