Intel DCI (Direct Connect Interface) UEFI setting restrictions - Xeon E3 v5/v6, Xeon Scalable, Xeon D: The UEFI setting

Impact

The UEFI setting that is supposed to lock out DCI can be bypassed, re-enabling Intel's closed-chassis debug path. DCI exposes JTAG-class control of the CPU over a USB port: halt cores, read and write all of physical memory including anything a tenant left resident, single-step SMM, and modify the boot chain. This is the strongest possible below-the-OS position on a node and everything it plants survives a reimage. It is squarely a tenant-handoff and colocation problem - a departing tenant with physical or smart-hands access to the chassis can leave the debug door open for the next occupant's data.

Who can reach it

Physical or near-physical access to a USB3 port on the node (or to a KVM/USB-over-IP appliance wired to one). Relevant wherever your halls have shared cages, third-party remote-hands, or hardware that transits an untrusted logistics chain.

What to do

BIOS update from the OEM (Dell, HPE, Supermicro, Lenovo, Quanta, Wiwynn) that correctly enforces the DCI lock - reboot and drain required, and OEM releases for Xeon Scalable server boards lagged Intel's July 2018 advisory considerably. Alongside the flash: set and lock the BIOS admin password, disable DCI and USB debug explicitly in the BIOS profile, physically disable or block front-panel USB on production nodes, and treat any node that has left your physical custody as needing a full firmware re-flash plus measured-boot re-attestation before it goes back into a tenant pool.

References