Self-encrypting drives in TCG Opal / eDrive mode

Impact

Three related bypasses that all exploit the same design assumption: an SED stays UNLOCKED once the platform has authenticated it, and only re-locks on a true power cycle. If the drive never sees power drop - hot-plugging a SATA drive while the machine sleeps, forcing a soft reset and booting an alternative OS, or attaching a second SATA connector and an alternate power source before pulling the data cable - the DEK stays live and the attacker reads plaintext with no credential. Included here because this is the CLASS of failure operators keep re-encountering: the newer Solidigm 'locked drive is not locked' CVEs are the same assumption failing again a decade later. BREAKS TENANT HANDOFF for any workflow that assumes a drive is safe because it is locked - locked-while-powered is not locked, and a running or sleeping node is a readable node.

Who can reach it

A physically proximate attacker with access to the running or sleeping machine and its drive cabling - a colo neighbour, a rack tech, or anyone who reaches a node between tenancies while it is still powered. No password required.

What to do

Mostly a policy and platform-configuration fix rather than a drive flash - the drives behaved as the Opal model specified, so there is no universal firmware patch. Concretely: disable sleep/suspend states on bare-metal hosts so the drive is never in the powered-but-unattended state that makes hot-plug work, require full power cycles rather than soft resets in your reclaim path, and verify that the platform re-authenticates the drive after any reset. Between tenants, do not hand over a node that has merely been rebooted - power it fully down as part of reclaim. The durable answer is the same as everywhere else in this category: software encryption with an operator-held key, so that a drive left unlocked still yields only ciphertext to whoever gets to it.

References

Related entries

• Samsung 840 EVO SSD - disk encryption key exposed through wear-levelled NAND and vendor-specific commands: The driveCVE-2018-12038 · Samsung 840 EVO SSD - disk encryption key exposed through wear-levelled NAND and vendor-specific commandsMedium
• Intel TDX module: The TDX module is the software that stands between the host/VMM and every confidential VM on the boxCVE-2025-20044 · Intel TDX moduleMedium
• Crucial/Micron MX100, MX200, MX300; Samsung 840 EVO and 850 EVO (ATA-high mode)CVE-2018-12037 · Crucial/Micron MX100, MX200, MX300; Samsung 840 EVO and 850 EVO (ATA-high mode); Samsung T3 and T5 portable SSDs…Medium
• AMD processors - speculative reordering of loads on shared memory: AMD processors may speculatively reorder loadCVE-2021-26400 · AMD processors - speculative reordering of loads on shared memoryMedium
• AMD SEV firmware - SEV-ES guest attacking an SNP guest: Coarse access-control granularity in SEV firmware lets aCVE-2025-48514 · AMD SEV firmware - SEV-ES guest attacking an SNP guestMedium
• AMD Secure Processor kernel - DRAM mapping into protected areas (AMD-SB-3003): An access-control gap in the ASP kernelCVE-2021-26387 · AMD Secure Processor kernel - DRAM mapping into protected areas (AMD-SB-3003)Low