[…]Beginning this month, as we promised to you, we began beta testing a new AGESA (v220.127.116.11) 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 18.104.22.168-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.[…]
UEFI_ListPci is a new UEFI Application that uses UEFI protocol to enumerate PCI/PCIe devices.
(There is also the UEFI Shell’s PCI command, included in Tianocore.org.)
Fuzzing PCI express: security in plaintext
By Julia Hansbrough, Software Engineer
Google recently launched GPUs on Google Cloud Platform (GCP), which will allow customers to leverage this hardware for highly parallel workloads. These GPUs are connected to our cloud machines via a variety of PCIe switches, and that required us to have a deep understanding of PCIe security. Securing PCIe devices requires overcoming some inherent challenges. For instance, GPUs have become far more complex in the past few decades, opening up new avenues for attack. Since GPUs are designed to directly access system memory, and since hardware has historically been considered trusted, it’s difficult to ensure all the settings to keep it contained are set accurately, and difficult to ensure whether such settings even work. And since GPU manufacturers don’t make the source code or binaries available for the GPU’s main processes, we can’t examine those to gain more confidence. You can read more about the challenges presented by the PCI and PCIe specs here. With the risk of malicious behavior from compromised PCIe devices, Google needed to have a plan for combating these types of attacks, especially in a world of cloud services and publicly available virtual machines. Our approach has been to focus on mitigation: ensuring that compromised PCIe devices can’t jeopardize the security of the rest of the computer. Fuzzing to the rescue[…]
DMA attacking over USB-C and Thunderbolt 3
I just got an Intel NUC Skull Canyon that has an USB-C port capable of Thunderbolt 3. Thunderbolt is interesting since it’s able to carry PCI Express which is Direct Memory Access (DMA) capable. I have previously demonstrated how it is possible to DMA-attack macs over Thunderbolt 2 in my DEF CON talk “Direct Memory Attack the Kernel”. To attack my MacBook Air in the DEF CON demo I used a Sonnet Echo ExpressCard Thunderbolt 2 to ExpressCard adapter together with a PCILeech ExpressCard. I also got a Thunderbolt 3 to Thunderbolt 2 adapter from Startech and I wanted to try it on the NUC to see if it’s possible to use it for DMA attacks, or if Thunderbolt has been secured. […]
Does not appear to be a public Github project yet.