Windows: new feature using IOMMU to block DMA access for Thunderbolt devices when machine is locked

The latest version of Windows apparently has new protections against PCILeech and related attacks:

ARM adds Shared Virtual Addressing (SVA) for IOMMU to Linux kernel

Jean-Philippe Brucker of ARM sent a 37-part patch, adding SVA support to Linux kernel, excerpts of announcement below:

Shared Virtual Addressing (SVA) is the ability to share process address spaces with devices. It is called “SVM” (Shared Virtual Memory) by OpenCL and some IOMMU architectures, but since that abbreviation is already used for AMD virtualisation in Linux (Secure Virtual Machine), we prefer the less ambiguous “SVA”. Sharing process address spaces with devices allows to rely on core kernel memory management for DMA, removing some complexity from application and device drivers. After binding to a device, applications can instruct it to perform DMA on buffers obtained with malloc.

The device, buses and the IOMMU must support the following features:
* Multiple address spaces per device, for example using the PCI PASID (Process Address Space ID) extension. The IOMMU driver allocates a PASID and the device uses it in DMA transactions.
* I/O Page Faults (IOPF), for example PCI PRI (Page Request Interface) or Arm SMMU stall. The core mm handles translation faults from the IOMMU.
* MMU and IOMMU implement compatible page table formats.

This series requires to support all three features. I tried to facilitate using only a subset of them but enabling it requires more work. Upcoming patches will enable private PASID management, which allows device driver to use an API similar to classical DMA, map()/unmap() on PASIDs. In the future device drivers should also be able to use SVA without IOPF by pinning all pages, or without PASID by sharing the single device address space with a process. Although we don’t have any performance measurement at the moment, SVA will likely be slower than classical DMA since it relies on page faults, whereas classical DMA pins all pages in memory. SVA mostly aims at simplifying DMA management, but also improves security by isolating address spaces in devices. Intel and AMD IOMMU drivers already offer slightly differing public functions that bind process address spaces to devices. Because they don’t go through an architecture-agnostic API, only integrated devices could use them so far. […]

Full patch:
https://lists.linuxfoundation.org/pipermail/iommu/2018-February/025992.html
More info on IOMMUs:
http://pages.cs.wisc.edu/~basu/isca_iommu_tutorial/index.htm
https://github.com/chipsec/chipsec/blob/master/chipsec/hal/iommu.py
https://www.spinics.net/lists/arm-kernel/msg609771.html
https://www.spinics.net/lists/kernel/msg2651481.html
https://www.spinics.net/lists/kvm/msg148819.html
https://developer.arm.com/products/architecture/a-profile/docs/100940/latest/separation-of-kernel-and-application-virtual-address-spaces
https://software.intel.com/en-us/articles/opencl-20-shared-virtual-memory-overview
https://www.khronos.org/registry/OpenCL/sdk/2.1/docs/man/xhtml/sharedVirtualMemory.html
https://lwn.net/Articles/726606/
https://support.amd.com/TechDocs/48882_IOMMU.pdf
https://en.wikipedia.org/wiki/List_of_IOMMU-supporting_hardware
https://software.intel.com/en-us/blogs/2009/03/02/intels-virtualization-for-directed-io-aka-iommu-part-1

 

Intel Whitepaper updated: Using IOMMU for DMA Protection in UEFI Firmware

We recommend firmware developers review this docment to understand threats from unauthorized internal DMA, as well as DMA from non-PCI devices that platform firmware may configure. Using an IOMMU such as Intel VT-d allows fine-grain control of memory protection without broadly disabling bus-mastering capabilities in the pre-boot space.

Note: this whitepaper was originally published under the title “A Tour beyond BIOS Using Intel® VT-d for DMA Protection in UEFI BIOS” in January 2015.

https://firmware.intel.com/blog/updated-whitepaper-using-iommu-dma-protection-uefi-firmware

https://firmware.intel.com/sites/default/files/Intel_WhitePaper_Using_IOMMU_for_DMA_Protection_in_UEFI.pdf

AGESA update info from AMD

[…]Beginning this month, as we promised to you, we began beta testing a new AGESA (v1.0.0.6) that is largely focused on aiding the stability of overclocked DRAM (>DDR4-2667). We are now at the point where that testing can begin transitioning into release candidate and/or production BIOSes for you to download. Depending on the QA/testing practices of your motherboard vendor, full BIOSes based on this code could be available for your motherboard starting in mid to late June. Some customers may already be in luck, however, as there are motherboards—like my Gigabyte GA-AX370-Gaming5 and ASUS Crosshair VI—that already have public betas.
[…]
If you’re the kind of user that just needs (or loves!) virtualization every day, then AGESA 1.0.0.6-based firmware will be a blessing for you thanks to fresh support for PCI Express Access Control Services (ACS). ACS primarily enables support for manual assignment of PCIe graphics cards within logical containers called “IOMMU groups.” The hardware resources of an IOMMU group can then be dedicated to a virtual machine. This capability is especially useful for users that want 3D-accelerated graphics inside a virtual machine. With ACS support, it is possible to split a 2-GPU system such that a host Linux® OS and a Windows VM both have a dedicated graphics cards. The virtual machine can access all the capabilities of the dedicated GPU, and run games inside the virtual machine at near-native performance.[…]

https://community.amd.com/community/gaming/blog/2017/05/25/community-update-4-lets-talk-dram

http://www.tomshardware.com/news/amd-agesa-firmware-update-motherboard,34525.html

 

AMD’s IVRS ACPI table

I just noticed this March-era update to the UEFI list of ACPI specs. It is a large, well-written spec, compared to some of the recent ACPI specs I’ve looked at.

I/O Virtualization Reporting Structure (IVRS)

This document describes AMD I/O Virtualization Technology. AMD I/O Virtualization Technology is embodied in the system-level function called the I/O Memory Management Unit (IOMMU). This document provides the IOMMU behavioral definition and associated design notes. It is intended for the use of system designers, chipset designers, and programmers involved in the development of low-level BIOS (basic input/output system) functions, drivers, operating system kernel modules, and virtual machine monitor (VMM) software. The intended user should have prior experience in personal computer design, microprocessor programming, and legacy x86 and AMD64 microprocessor architecture.

http://support.amd.com/TechDocs/48882_IOMMU.pdf

http://uefi.org/acpi