From e673fd6e4eba0d85ea15b497ccf909b3e41219c7 Mon Sep 17 00:00:00 2001 From: Andrew David Wong Date: Mon, 4 Mar 2019 00:31:48 -0600 Subject: [PATCH] Update Hardware Certification Requirements for Qubes 4.0 --- hardware/certified-hardware.md | 39 ++++++++++++++++++++++++++++++++-- 1 file changed, 37 insertions(+), 2 deletions(-) diff --git a/hardware/certified-hardware.md b/hardware/certified-hardware.md index 4049810f..4155abfb 100644 --- a/hardware/certified-hardware.md +++ b/hardware/certified-hardware.md @@ -28,10 +28,35 @@ The benefits of hardware certification include: * You can support the development of Qubes OS. ### Hardware Certification Requirements ### -Please see the [updated requirements] for Qubes 4.x certification. (Please note that these are the requirements for hardware *certification*, *not* the requirements for *running* Qubes 4.x. For the latter, please see the [system requirements for Qubes 4.x].) +One of the most important security improvements introduced with the release of Qubes 4.0 was to replace paravirtualization (PV) technology with **hardware-enforced memory virtualization**, which recent processors have made possible thanks to so-called Second Level Address Translation ([SLAT]), also known as [EPT][EPT-enabled CPUs] in Intel parlance. +SLAT (EPT) is an extension to Intel VT-x virtualization, which originally was capable of only CPU virtualization but not memory virtualization and hence required a complex Shadow Page Tables approach. +We hope that embracing SLAT-based memory virtualization will allow us to prevent disastrous security bugs, such as the infamous [XSA-148], which --- unlike many other major Xen bugs --- regrettably did [affect][QSB 22] Qubes OS. +Consequently, we require SLAT support of all certified hardware beginning with Qubes OS 4.0. + +Another important requirement is that Qubes-certified hardware should run only **open-source boot firmware** (aka "the BIOS"), such as [coreboot]. +The only exception is the use of (properly authenticated) CPU-vendor-provided blobs for silicon and memory initialization (see [Intel FSP]) as well as other internal operations (see [Intel ME]). +However, we specifically require all code used for and dealing with the System Management Mode (SMM) to be open-source. + +While we [recognize][x86_harmful] the potential problems that proprietary CPU-vendor code can cause, we are also pragmatic enough to realize that we need to take smaller steps first, before we can implement even stronger countermeasures such as a [stateless laptop]. +A switch to open source boot firmware is one such important step. +To be compatible with Qubes OS, the BIOS must properly expose all the VT-x, VT-d, and SLAT functionality that the underlying hardware offers (and which we require). +Among other things, this implies **proper DMAR ACPI table** construction. + +Finally, we require that Qubes-certified hardware does not have any built-in _USB-connected_ microphones (e.g. as part of a USB-connected built-in camera) that cannot be easily physically disabled by the user, e.g. via a convenient mechanical switch. +Thankfully, the majority of laptops on the market that we have seen already satisfy this condition out-of-the-box, because their built-in microphones are typically connected to the internal audio device, which itself is a type of PCIe device. +This is important, because such PCIe audio devices are --- by default --- assigned to Qubes' (trusted) dom0 and exposed through our carefully designed protocol only to select AppVMs when the user explicitly chooses to do so. +The rest of the time, they should be outside the reach of malware. + +While we also recommend a physical kill switch on the built-in camera (or, if possible, not to have a built-in camera), we also recognize this isn't a critical requirement, because users who are concerned about it can easily cover it a piece of tape (something that, regrettably, is far less effective on a microphone). + +Similarly, we don't consider physical kill switches on Wi-Fi and Bluetooth devices to be mandatory. +Users who plan on using Qubes in an air-gap scenario would do best if they manually remove all such devices persistently (as well as the builtin [speakers][audio_modem]!), rather than rely on easy-to-flip-by-mistake switches, while others should benefit from the Qubes default sandboxing of all networking devices in dedicated VMs. + +We hope these hardware requirements will encourage the development of more secure and trustworthy devices. + ### Hardware Certification Process ### To have hardware certified, the vendor must: @@ -64,7 +89,17 @@ To learn more about the certification process, or if you're interested in having [System Requirements]: /doc/system-requirements/ [Hardware Compatibility List]: /hcl/ [Hardware Certification]: #hardware-certification -[updated requirements]: /news/2016/07/21/new-hw-certification-for-q4/ [system requirements for Qubes 4.x]: /doc/system-requirements/#qubes-release-4x [contact us]: mailto:business@qubes-os.org +[SLAT]: https://en.wikipedia.org/wiki/Second_Level_Address_Translation +[EPT-enabled CPUs]: https://ark.intel.com/Search/FeatureFilter?productType=processors&ExtendedPageTables=true&MarketSegment=Mobile +[XSA-148]: https://xenbits.xen.org/xsa/advisory-148.html +[QSB 22]: https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-022-2015.txt +[pvh_ticket]: https://github.com/QubesOS/qubes-issues/issues/2185 +[coreboot]: https://www.coreboot.org/ +[Intel FSP]: https://firmware.intel.com/learn/fsp/about-intel-fsp +[Intel ME]: https://www.apress.com/9781430265719 +[x86_harmful]: https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf +[stateless laptop]: https://blog.invisiblethings.org/papers/2015/state_harmful.pdf +[audio_modem]: https://github.com/romanz/amodem/