This project consists of 3 parts. 1) A script (gpu-pt-check.sh) that automatically checks to what extend a computer is compatible with GPU pass-through in its given configuration. 2) A script (setup.sh) that automatically installs and configures your system for GPU pass-through (Only tested on fresh installs of Fedora 28 x64 with Gnome, booted in UEFI mode!) 3) Instructions on how to create a bootable Linux USB stick that automatically runs the gpu-pt-check.sh script when you boot from it without any user interaction required.
TL;DR: a minor adjustment had to be made in tboot so that it picks the right memory protection for itself in the E820 map. The bug only affected PV Linux guests with PCI-passthrough devices as correctly guessed above.[…]
Linux support for PCILeech FPGA PCIe DMA attacks finally released! Huge thanks to @key2fr for the driver making this possible and to ikelos for all time spent on hunting down the bugs! https://t.co/KuTVVzZc5j
Intel just published a draft of their proposed PCIe firmware measurement and device authentication spec. This is one of the things @syncsrc and I were talking about at @shmoocon.https://t.co/Y4X8eErZQC These enhancements allow hardware-backed firmware measurements.
PCI Express (PCIe) Devices may be composed of hardware (immutable) and firmware (immutable and mutable) components. Presently, Vendor ID/Device ID/Revision ID registers convey the hardware identify of a PCIe* Device and there is no defined mechanism to convey the firmware identity of a PCIe Device. In addition to the Device identity, PCIe specification defines various types of capability structures to convey PCIe Device features capabilities. Both the Device Identity and capability can be spoofed and used maliciously by an advanced adversary. This specification introduces the notion of PCIe* Device Firmware Measurement, a method of exposing the identity of Device firmware. The Device Firmware Measurement mechanism used in isolation, however, is subject to supply chain attacks such as counterfeiting and can also be spoofed by an advanced adversary. Additionally this specification introduces the notion of PCIe Device Authentication, which uses public key cryptography to defend against such attacks and to provide higher assurance about the hardware and firmware identities and capabilities. PCIe Device Authentication adapts the USB Authentication mechanism to PCIe—the new elements are the specific PCIe register interface and the associated mechanisms, plus some details that are necessarily specific to PCIe. PCIe Device Authentication result can be used in various scenarios such as: 1) a data center administrator can ensure all PCIe Devices are running appropriate firmware versions 2) system software can ensure a trusted Device is plugged in before enabling the PCIe Address Translation Services (ATS) for the Device. PCIe Device Authentication provides platforms with a way to make trust decisions about specific Devices. This in turn provides value to Device vendors because the Authentication feature is itself a valuable Device feature, and supports the detection of counterfeit and potentially malicious Devices. This specification details the requirements, interface and protocol for PCIe Device Firmware Measurement and PCIe Device Authentication. It also provides general guidelines for implementing these technologies in practice.
The PCIe bus is now the main high speed communication bus between a processor and its peripherials. It is used in all PC (sometime encapsulated in Thunderbolt) and now even in mobile phones. Doing security research on PCIe systems can requires very expensive tools (>$50k) and packet generaration for such tools is not a common feature. PCIe Injector provides a such tool at a more reasonable price. Currently, only few attacks were made on PCIe devices. Most of them were done using a Microblaze inside a Xilinx FPGA to send/receive the TLPs, making it hard to really analyze. (Using embedded C software to generate/analyze traffic) An other way is to use USB3380 chip, but it is also not flexible enough (only supporting 32bits addressing) and does not allow debugging the PCIe state machine.
The PCIe injector is based on a Artix7 FPGA from Xilinx connected to a DDR3 and a high speed USB 3.0 FT601 chip from FTDI. It allows: * Having a full control of the PCIe core. * Sending/Receiving TLPs through USB 3.0 (or bufferize it to/from DDR3) * Using flexible software/tools on the Host for receiving/generating/analyzing the TLPs. (Wireshark dissectors, scapy, …)
MSI support for PCI device pass-through with stub domains by Simon Gaiser In this post, we will describe how we fixed MSI support for VMs running in HVM mode in Qubes 4.0. First, allow us to provide some background about the MSI feature and why we need it in the first place.[…]
[…] New Bitlocker features in Windows 10, version 1507: * DMA port protection. You can use the DataProtection/AllowDirectMemoryAccess MDM policy to block DMA ports when the device is starting up. Also, when a device is locked, all unused DMA ports are turned off, but any devices that are already plugged into a DMA port will continue to work. When the device is unlocked, all DMA ports are turned back on. […]
This policy setting allows you to block direct memory access (DMA) for all hot pluggable PCI downstream ports until a user logs into Windows. Once a user logs in, Windows will enumerate the PCI devices connected to the host plug PCI ports. Every time the user locks the machine, DMA will be blocked on hot plug PCI ports with no children devices until the user logs in again. Devices which were already enumerated when the machine was unlocked will continue to function until unplugged. This policy setting is only enforced when BitLocker or device encryption is enabled.
BIOS Session 1 – System Memory Map BIOS Session 2 – Legacy Region BIOS Session 3 – HIgh Level Overview of the BOOT flow BIOS Session 4 – Transaction flows and address decoding part 1 BIOS Session 5 – Transaction flows and address decoding part 2 BIOS Session 6 – PCI Basics and Bus Enumeration
Experimental PCI Expansion ROM “OS” Code Migrated to GitHub The code for the experimental PCI Expansion ROM “OS” explained in the Building a “Kernel” in PCI Expansion ROM article is now in GitHub: https://github.com/pinczakko/PCI-Expansion-ROM-OS. I made some changes to make it compile-able in current version of Nasm and GCC. I’ve only tested the compilation in Arch Linux (x86-64). I’m not sure it will work in other Linux distros. Give it a try ;-). Quick skim over the resulting binary seems to indicate the result is OK. I’m going to check it with a disassembler later on. If anyone wants to help me with that, please do so and post your result in the comment section below. Many of you might be aware that the code has been modified into pure GCC-only code in the Low Cost Embedded x86 Teaching Tool article. I need to migrate that code as well. But, I’m quite sure it will require special GCC version to be able to emit the correct binary, akin to the one used by Coreboot. I’ll post an update once I’ve updated that one as well. Anyway, it’s rather surprising to me that using Nasm + GCC is more future-proof compared to using GCC alone. It shows that you can’t be really sure about the future-proof-ness of the toolset you used for software development.
Deb McLemore of IBM has submitted multiple updates to FWTS, the FirmWare Test Suite, adding a lot more support for OpenPOWER OPAL firmware.
opal: pci_info: Add OPAL PCI Info validation opal: mem_info: Add OPAL MEM Info validation opal: cpu_info: Add OPAL CPU Info validation devicetree: dt_sysinfo: Add OPAL firmware version checks olog: olog.json: Update OPAL skiboot errors to check on olog scan
There is a lot of useful diagnostic information in this code, example: “You are running in manufacturing mode. This mode should only be enabled in a factory during manufacturing.”