VT-d, which provides IOMMU services, is a very important feature for realizing the security promises of Qubes OS. Without it, although the CPU isolates VMs, their memory lies open to relatively easy DMA-based attacks, with network devices and GPUs being some of the more well-known pieces of hardware for executing such attacks.
Finding a system - especially a notebook system - that supports VT-d is a serious challenge. Unfortunately, a great majority of laptop/notebook systems do not even have the hardware necessary to use VT-d, and the presence or absence of this feature is not well documented by vendors. Although the Hardware Compatability List (https://wiki.qubes-os.org/trac/wiki/HCL
) is a helpful resource, it only lists a handful of models, many of which have been discontinued. It is helpful to have a more systematic way of identifying systems that at least have the necessary hardware to support VT-d (BIOS support, discussed below, presents a secondary issue).
What to look for:
For Ivy Bridge, BOTH the CPU and chipset must support VT-d, which compounds the problem of finding a VT-d capable system. The most common issue is that although the CPU will support VT-d, the chipset does not. However, there are systems where not even the CPU has the needed support (such as all of the mobile i3 models?).
To save you some hassle: only 2 (out of 7!) Ivy Bridge chipsets will work: QM77 and QS77. Unfortunately, most systems use the HM7x chipsets...
For Haswell, the issue is simpler, because the CPU and chipset are in a single package, which eliminates mixing & matching. Nevertheless, only some Haswell chips have VT-d support, with most Haswell laptops/notebooks I have seen listed not having VT-d.
On Sandy Bridge, there is VT-d support to be found, although probably with the same chipset issues as Ivy Bridge.
Where to look:
I have found the following two websites very helpful in identifying notebooks with supporting hardware:
Typically, I just drop the CPU or chipset identifier into Google, and the corresponding ark.intel.com
page will show up towards the top of the results.
For VT-d, the feature you are looking for is labeled "Intel® Virtualization Technology for Directed I/O (VT-d)", and you want the table to say "Yes" for this item.
The Intel pages are the authoritative reference for what CPUs and chipsets support VT-d, but how do you determine (a) what CPU+chipset is in a given notebook model, or (b) what notebook models make use of given CPUs+chipsets? With Ivy Bridge, vendors will almost never indicate the chipset model. For one system, I ended up starting from chip markings shown in an iFixIt teardown, and web searching back from that to determine the chipset model.
Luckily, there is at least one website providing a better way to go about this: http://www.notebookcheck.com/
, which has taken the time & effort to document which CPUs & chipsets are present in various models.
For Ivy Bridge chipsets, http://www.notebookcheck.com/Intel-Ivy-Bridge-Chipsaetze-7-Series-Chipsets.88194.0.html
gives links to pages for each chipset, such as QM77 and HM77. Then, on each chipset-specific page is a list of notebooks identified as using that chipset. As I mentioned above, the chipset is usually the weak link, so working back from the supporting chipsets, and then confirming there is also a supporting CPU, seems the way to go.
Here are links to the only two supporting chipsets I mentioned above:
As can be seen on the charts, only the least expensive models in each lineup lack VT-d support. Unfortunately, those are also the models I have most frequently seen included in the announced or released Haswell notebooks. Once you start digging around, you will see most Haswell notebooks include the i7-4500U or the i5-4200M. However, there are Haswell notebooks out there with the right chips. I do not know if this is a result of the lower-end chips getting rolled out in higher volumes at first, but if Ivy Bridge is any indication, most Haswell notebooks will not have VT-d support.
The above info will help you get past the first, but most prevalent, issue of hardware support. If you home in on a few notebook models of interest, I suggest digging a little deeper to find another source that confirms the right chips or VT-d support is in place. I would not expect a salesperson or a level 1 or 2 tech to give you reliable info.
The other piece - BIOS support:
Even if the hardware supports VT-d, it will not work if not properly enabled by the system BIOS. Issues include:
- No VT-d support in BIOS. The BIOS does not configure VT-d at all. This seems to be rare, at least for Intel systems.
- incorrect ACPI tables. The BIOS configures VT-d correctly, but incorrectly reports information via ACPI (usually in the DMAR table), which Xen uses to determine what is going on with VT-d. This seems a little more common than there being no BIOS support.
- VT-d/IOMMU feature must be enabled in BIOS. Trivial to fix, but overlooked many times. Go into BIOS config, find the item, and enable it.
Do not expect a vendor to ever respond to the first 2 issues - just move on. If you already own a laptop, and it's just an ACPI issue, it may be possible to hack around it (which is what I did on my MacBook Air 2012), but just avoid it if you are buying something new.
Once you have identified a model, you can often find a manual covering the BIOS config screens. This can provide a quick way to confirm there is BIOS support, by finding documentation for a config screen allowing you to toggle VT-d/IOMMU.
Test the actual system:
A final step, or perhaps a shortcut around the above steps, would be to actually run Xen or Qubes OS on the machine you intend to use. For example, you could put the Qubes OS installer on a USB drive, boot the system off of it, and run the qubes-hcl-report script. Alternatively, in dom0 (under Qubes OS or Xen more generally) you could grep for "virtualisation" or "VT-d". You should either see "I/O virtualisation enabled" or "I/O virtualisation disabled", or some items about VT-d.
If you cannot physically access a sample of the system (for example, ordering a system online), you might try to persuade the vendor to do the above USB boot, if they will download and run an unfamiliar 1.2GB installer... A smaller image providing a dedicated IOMMU Xen-based tester might be better for this, but does not currently exist. There might be "off the shelf" Linux boot discs with IOMMU-enabled kernels where you could grep through dmesg for the appropriate boot message, although Xen and Linux may have a different take on things.
- Get a system with 6+ GB of RAM. You can run with 4 GB, but it will likely become an issue if you want to run a non-Linux VM like Windows - particularly if more than one concurrent Windows VM. Most "ultrabooks" have 4 GB of RAM and are not upgradeable.
- Get a system with a TPM. Allows use of Anti Evil Maid
. Many consumer laptops do not have a TPM. Note that even when there is a TPM, it often is not listed in the product specifications.
- Probably also make sure the system offers Intel TXT support, using the above techniques for VT-d. Although Joanna et al have exposed multiple issues with TXT as a standalone solution, it appears it will be relevant if you want to run Anti Evil Maid. See https://groups.google.com/forum/#!topic/qubes-devel/c_S06lNpiso
There are a number of CPUs that support VT-d, but not also TXT.
- Possible UEFI Secure Boot problems? I am unfamiliar with this, and it sounds like today this generally can be disabled in BIOS, but there also seems to be concern about future machines only doing Secure Boot. However, Redhat seems to have worked out some kind of a shim boot solution for the time being.
- AMD motherboard vendors made a big mess of things. AMD did a great job pitching IOMMUs some time ago, hardware support is just a matter of the right chipset, and AMD provided BIOS vendors with the code for proper configuration. However, most of the vendors still fail to enable the hardware correctly and/or have bad ACPI tables (which generally causes Xen to disable the IOMMU). I have not seen any instance where a vendor has resolved such issues, even for simple and clearly identified ACPI issues. This issue was prevalent enough to help give rise to Xen Security Advisory 36. If you still want to use AMD for IOMMU, you have been warned...