Database/Firmware, BMC & network fabric

Arm Cortex-A and Neoverse cores (Neoverse N1/N2/V1 among them); Trusted Firmware-A
Impact
Branch history is shared across privilege boundaries, so an attacker in one context can poison the Branch History Buffer and make a victim context mispredict into a gadget that leaves the secret in the cache. Practically: a guest reads hypervisor memory, or one container reads another's, at side-channel bandwidth. Slow, but it does not crash anything and leaves no trace, which is exactly the profile that matters when the secret is a customer's model weights or an API key sitting in host memory on a shared Arm node.
Who can reach it
Unprivileged code in any guest or container on an affected Arm core that shares a physical core with the victim. Worse when SMT or aggressive core-sharing is enabled; a dedicated-core scheduling policy raises the bar considerably.
What to do
Layered and none of it is optional. EL3 firmware exposes the mitigation via SMCCC (updated TF-A from the OEM, flash + reboot); the guest and host kernels must run the arm64 Spectre-BHB workarounds (loop or clearbhb sequence per core type). Newer cores get FEAT_CLEARBHB in hardware; older Neoverse N1 parts pay for a software loop on every exception entry, which is a real syscall-path cost. Ampere published AMP-SB-0001 for Altra/Altra Max/AmpereOne. The durable operator-level control is to stop co-tenanting untrusted workloads on one physical core.
References
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.