How much hardware within a system belongs to the TCB? The industry has gained greatly from the ability to plug PC cards and PCI devices into computers on whim. Most OS software has been so gullible that maliciously crafted high level signals suffice to compromise the system entirely within the hardware specs. The rogue need not learn the crafts of the circuit engineer. This note is about vulnerabilities to a malicious hardware engineer.
We examine some risks with untrusted PC cards and PCI devices. On most current systems these cards are bus masters with the same ability to read and write RAM as the CPU.
The official interface specs are expensive and I have not recently studied them. I do recall, however, that there are several levels of spec:
|Circuit||This specifies the voltage and impedance required to communicate with the system bus. It specifies the difference between signal and noise.||One man’s noise, however, may be the rogue’s signal.||Custom circuit design|
|Logical signal sequences—Pin Specs||These specify when clean signals on the pins to the card belong to the card, and also when it is permissible to assert a signal.||The rogue card may read addresses and data that belong to another card, or even the CPU.||Custom logic design.|
|Messages||These spell out what messages from the system are meant to convey to the card that the card should concern itself with which areas of RAM. The Cardbus spec spells out the semantics of interface signals to the card relating to where the card may read or write. It is up to the card to conform. A rogue card may not.||A rogue card may concern itself with other areas of RAM, either reading or writing there.||microcode|
|Card Identification||There are protocols for a card to identify itself with a structured name, including identification of the manufacturer.||The rogue card can lie.||microcode|
This allows a secure subsystem to exclude all PC cards or all PCI devices from the TCB except, perhaps, those with rogue custom circuit design or logic design.
It would seem difficult to retrofit an IOMMU to extant OSes not designed with that in mind.
AMD’s IOMMU design addresses most of these issues. (Regarding 2.1 “The IOMMU may optionally include support for remote IOTLBs. A device with IOTLB support can cooperate with the IOMMU to maintain its own cache of address translations.” If “remote IOTLBs” means hardware ‘outside the system’ then we have a problem. Any IOTLB is in the TCB where ever it is.)
See obscure reference to IOMMU here. Here is Intel’s definition of their IOMMU. They think it is only for virtualization.
Neither document mentions hot swapping but they leave the impression that such issues are the realm of the legacy bridge to old cards. There is room here for security design bugs, and also an opportunity to solve some of these problems.
PCI-X and PCI Express (PCIe) are two proposals that are not yet open. (As of 2015 Dec PCI Express still has a paywall before the meat but here is a book. tutorial) Their overviews stress legacy OS compatibility. This would not preclude new modes that controlled RAM access by individual units. Here are recent worries about the PCIe specs.
Of Microsoft’s Palladium plans, Seth David Schoen says that: Even PCI DMA can’t read or write memory which has been reserved to a nub’s or TA’s use (including the nub’s or TA’s code). This memory is completely inaccessible and can only be accessed indirectly through API calls. The chipset on the motherboard is modified to enforce this sort of restriction. I think that they plan to protect RAM by a per page access bit. DMA to each physical page is controlled by a bit for that page.
External: Read it and weep. New modes.