Ampere Altra and Altra Max UEFI reference design before SRP 1.09 - SMC interface exposing SPI-NOR flash: The OS

CVSS 9.8CVE-2022-32295Firmware, BMC & network fabricAMP-SB-0002Altra SPI-NOR SMC protectioncurated

Impact

The OS or hypervisor can reach the SPI-NOR boot flash through an insufficiently protected SMC. That means whoever owns the kernel on an Altra box can rewrite platform firmware - a persistent, below-the-OS implant that survives reimaging, disk wipe and tenant handoff. For a bare-metal Arm GPU provider this is the canonical tenant-persistence failure: rent a node for an hour, own it for its service life. It also destroys any attestation story you have told customers.

Who can reach it

Any code at host kernel or hypervisor level on an Altra / Altra Max system - which, on bare-metal rental, means the tenant by design. No physical access needed.

What to do

Update to Altra SRP 1.09 or later from the board OEM (the fix hardens the SMC so the non-secure world can no longer drive SPI-NOR). Flash + reboot + drain per node, and the OEM has to ship an SRP build for your specific board - Ampere publishes the reference, your ODM integrates it, so the lag is on them. Independently and more importantly: on bare-metal, verify boot flash contents against a golden image at every tenant handoff. Assume any node rented before the SRP update may already carry an implant and reflash it from an out-of-band path rather than trusting in-band verification.

References

https://amperecomputing.com/products/security-bulletins/altra-spi-nor-smc.html https://nvd.nist.gov/vuln/detail/CVE-2022-32295 https://amperecomputing.com/products/product-security

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.