Database/Firmware, BMC & network fabric

ASPEED AST2600 / AST2700 hardware root of trust in OpenBMC builds: AST2600 has a fuse-backed secure boot that verifies
Impact
AST2600 has a fuse-backed secure boot that verifies the BMC firmware image against an RSA key, and AST2700 adds the OCP Caliptra-based scheme. Both ship off. The default OpenBMC build configuration leaves secure boot disabled because that is convenient for board bring-up, and plenty of production images never turn it on. Where it is off, anything that can write the BMC's SPI flash - a compromised BMC userspace process, a host-side AHB bridge write, or a supply-chain-tampered update package - installs code that persists across power cycles, OS reimage, and node redeployment to the next tenant, with nothing in the boot chain to reject it. On a GPU cluster this is the difference between a compromised node you can rebuild and a compromised node you have to physically retire.
Who can reach it
Any write path to BMC SPI flash: code execution on the BMC, a host-side AHB bridge, or a malicious/unsigned firmware update accepted by the update daemon. Not remotely reachable by itself - it is the amplifier that turns a one-shot BMC compromise into a permanent one.
What to do
Enabling it is a one-way door: it means burning OTP fuses with your signing key on every node, which cannot be undone and cannot be done remotely. Practically this is an order-time decision with the ODM, not something an operator retrofits on a deployed fleet. For fleets already racked, audit whether secure boot is fused on each SKU, demand the answer in writing from the ODM, and where it is off, compensate with SPI flash content attestation (hash the image out-of-band and compare against a known-good) plus strict control over who can push BMC firmware. Note that a hardware root of trust also does not help if the signed image itself has a signature-verification bug - see the Supermicro image-parser entries.
References
Related entries
- Intel SGX / DDR4 memory bus (physical interposer): WireTap: a low-cost passive DDR4 interposer reads the memory bus ofNCVD-2025-001-intel-sgx-ddr4-memory-bus-physic · Intel SGX / DDR4 memory bus (physical interposer)Unscored
- AMD SEV-ES / SEV-SNP - transient-execution-amplified power side channel: Graz researchers amplified the power sideNCVD-2025-002-amd-sev-es-sev-snp-transient-exe · AMD SEV-ES / SEV-SNP - transient-execution-amplified power side channelUnscored
- Intel SGX and AMD SEV-SNP / DRAM interposer (memory aliasing): Battering RAM: a cheap DRAM interposer that aliasesNCVD-2025-002-intel-sgx-and-amd-sev-snp-dram-i · Intel SGX and AMD SEV-SNP / DRAM interposer (memory aliasing)Unscored
- AMD SEV-SNP - ciphertext side channels amplified by hypervisor page movement: Two 2025 follow-ups to CipherLeaksNCVD-2025-003-amd-sev-snp-ciphertext-side-chan · AMD SEV-SNP - ciphertext side channels amplified by hypervisor page movementUnscored
- AMD SEV-SNP - RMP entries cached in L1D/L2 leaking physical address bits: Reverse-map table entries cached in L1D andNCVD-2025-004-amd-sev-snp-rmp-entries-cached-i · AMD SEV-SNP - RMP entries cached in L1D/L2 leaking physical address bitsUnscored
- AMD SEV-SNP - DIMM interposer variant of BadRAM (KU Leuven): A memory-bus interposer variant of the BadRAM aliasingNCVD-2025-005-amd-sev-snp-dimm-interposer-vari · AMD SEV-SNP - DIMM interposer variant of BadRAM (KU Leuven)Unscored
This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.