add boot-time IOMMU disable via hardware (flash dump and rewrite).

proposed in issue #5

readme.md

@@ -23,6 +23,7 @@ Hardware attacks are typically only useful for when the attacker has physical ac
 | TPM sniffing: bootmgr communicates with TPM in the clear | Windows Boot Manager communicates with the TPM in the clear, so if a separate TPM chip on the LPC bus is used (ie, not fTPM, or "Pluton"/HSP), a logic analyser on that bus can be used to dump the VMK.<br><br>See also [blog post from Pulse Security](https://pulsesecurity.co.nz/articles/TPM-sniffing), [LPC sniffer Verilog code](https://github.com/denandz/lpc_sniffer_tpm).  | None, but firmware TPMs were not vulnerable anyway | [January 2019](https://web.archive.org/web/20190125001757/https://twitter.com/marcan42/status/1080869868889501696) | marcan |
 | Hardware debugger: some systems do not measure into PCR7 before enabling a hardware debugger | [The TCG EFI Platform Specification for TPM](https://trustedcomputinggroup.org/wp-content/uploads/TCG_EFI_Platform_1_22_Final_-v15.pdf) (section 6.4) includes the following: <br><br>"If the platform provides a firmware debugger mode which may be used prior to the UEFI environment or if the platform provides a debugger for the UEFI environment, then the platform SHALL extend an EV_EFI_ACTION event into PCR[7] before allowing use of the debugger"<br><br>Some systems do not perform this measurement before enabling some hardware debuggers (like Intel DCI).<br>Therefore on such a vulnerable system, a Secure Boot bypass (physical access would allow for at least two with Secure Boot still enabled) or hardware attack (writing to SPI flash directly) can be used to enable the hardware debugger; setting a breakpoint (for example) inside `bootmgr!FvebUnsealCallback` can then allow for dumping the VMK. See also [this article from Digital Forensics Research Conference Europe 2023](https://www.sciencedirect.com/science/article/pii/S266628172300015X). | None, for vulnerable systems.<br><br>An exact list of vulnerable systems is unknown. | March 2023 | Brazilian Federal Police |
 | fTPM glitching: code execution via glitching to compromise fTPM state entirely | If an on-SoC processor/microcontroller that implements an fTPM is vulnerable to glitching such that code execution can be obtained early in boot, the entire fTPM state can be compromised, leading to VMK dumping (etc). See also [the research article](https://arxiv.org/abs/2304.14717), [payloads/etc for AMD PSP](https://github.com/PSPReverse/ftpm_attack) | IntelME: [November 2021 / Alder Lake](https://www.theregister.com/2022/08/12/intel_ups_protection_against_chip/)<br><br>AMD: unknown, none?<br><br>Others (ARM64, ARMv7, etc): unknown | April 2023 | Hans Niklas Jacob, Christian Werling, Robert Buhren, Jean-Pierre Seifert of Technische Universit ät Berlin - SecT |
+| Boot-time IOMMU disable: modifying UEFI non-volatile variable storage with flash dump/rewrite can disable IOMMU at boot | Some UEFI firmwares will not enable IOMMU at boot based on variable data. By dumping flash, modifying those var(s), and rewriting, IOMMU will be disabled at boot with TPM non-volatile state still valid. At that point, an attacker can then overwrite the DMAR ACPI table using PCI DMA before bootmgr launches, boot into Safe Mode and then use PCI DMA again to get a SYSTEM shell. See [the writeup](https://www.mdsec.co.uk/2026/03/disabling-security-features-in-a-locked-bios/).<br><br>It's unknown what component this is in; the writeup uses an Intel system, the relevant code there is provided by the Intel Firmware Support Package. It's unknown if the AMD equivalent (AGESA/CBS) is also affected. | Intel Firmware Support Package: unknown<br><br>AMD AGESA/CBS: unknown | March 2026 | Craig S. Blackie of MDSec |
 
 ## Software attacks