Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #316 from chrisccoulson/preinstall-add-check-fw-pr…
…otection preinstall: Add checks for platform firmware protections. This adds checks for how the platform firmware is protected, with specific tests for whether CPU silicon debugging features are enabled or not locked off, whether a firmware debugging endpoint (such as UDK) is enabled, whether the kernel IOMMU is available, whether the firmware indicates that DMA protection was disabled at some point, and whether the firmware is protected by a hardware root-of-trust (ie, keys fused into the silicon during manufacturing). The main entry point to this is `checkPlatformFirmwareProtections`. There is an implementation for amd64 go builds (x86-64) and then a null implementation for everything that is !amd64 which just returns an error. Some of these checks are based on the HSI checks in fwupd with some minor adaptions, particularly for the BootGuard checks where there are some tests in fwupd that disagree with other publicly available documentation which better aligns with hardware that is assumed to be good (note that Intel do not publicly document how any of this works). This has a significant limitation today - it only works on Intel based systems. AMD support will happen when we figure out how the platform firmware is protected on AMD platforms with the dedicated PSP. There are some other limitations, eg, whilst we detect that the IOMMU functionality in the kernel is enabled, we don't check that external facing DMA capable ports or user accessible internal DMA capable ports are protected by one of the domains (and this feature could be made optional if there aren't external facing or user-accessible internal ports that are capable of DMA). Microsoft say that externally accessible ports can be identified using ACPI tables (https://learn.microsoft.com/en-us/windows-hardware/drivers/pci/dsd-for-pcie-root-ports#identifying-externally-exposed-pcie-root-ports), but we don't do anything like this yet. I'm going to create a follow-on epic to expand support for this feature, and this check will likely end up in there. This does perform a check of the secure boot PCR for an event that is not documented anywhere by the TCG, isn't in EDK2 or any of Microsoft's public Project Mu repositories, but is a Windows requirement (measuring a `EV_EFI_ACTION` event with the string "DMA Protection Disabled" to PCR7 if DMA protection is disabled by any settings in the firmware). Note that strings associated with `EV_EFI_ACTION` events aren't meant to be NULL terminated, although the one on my Dell XPS15 is so the code handles the case where the event data is NULL terminated too. I don't know if this is a Dell bug or if Microsoft generally expects this to be a NULL terminated, but this contradicts the TCG spec for this event type. The only places where NULL terminated strings are used are for `EV_S_CRTM_CONTENTS` when measured by a H-CRTM event, and a NULL terminated UCS2 string in the data associated with `EV_S_CRTM_VERSION` events (yay for consistency!)
- Loading branch information