Talk

Speculative-Execution Attacks And Implications For Confidential Computing

conf 20.11.2025 14:45 – 15:15 La Marive EN

Speculative-Execution Attacks And Implications For Confidential Computing

Modern x86_64 processors still expose subtle speculative-execution pathways that can be weaponized even in the presence of today’s strongest branch-predictor barriers. New families of post-IBPB attacks was analyzed by ETHZ. PB-RRSBA breaks Intel Golden-/Raptor-Cove cores by exploiting the fallback Restricted Return Stack Buffer Alternate (RRSBA): when the architectural RSB underflows, RRSBA continues to predict returns from historical instruction-pointer patterns that an attacker can poison, steering speculation into attackerchosen gadgets. PB-Inception shows that on AMD Zen 1/2, the return predictor retains speculative state across context switches despite an IBPB, enabling unprivileged code to mistrain the kernel’s return path. We further show an ASLR bypass concept by ETHZ via BTB aliasing, recovering the lower 32 bits of victim return addresses and paving the way for reliable exploitation. We place these techniques in the context of Confidential Computing. Although AMD SEV-SNP encrypts and authenticates VM memory, decrypted instructions and data are still processed speculatively inside the core. By crafting RRSBA poison payloads, we induce the secure guest to speculatively execute attacker-controlled gadgets, exfiltrating plaintext secrets to an unencrypted buffer and breaching VM isolation. A proof-of-concept (PoC) RSB-poisoning attack leaks kernel-resident data from a protected guest. This PoC is effective only on Linux kernels < 4.15 where RSB flushing at context switch is not mitigated. Second, we contribute a PB‑RRSBA proof‑of‑concept that targets the fallback Restricted Return Stack Buffer Alternate; unless a system both advertises RRSBA_CTRL and the kernel (>= 6.9) sets the new IA32_SPEC_CTRL.RRSBA_DIS_U,S bits, this predictor remains trainable across context switches, allowing speculative user‑to‑user and user‑to‑kernel data leakage despite IBPB and RSB‑stuffing defenses. The findings reveal that existing IBPB-based mitigations do not provide complete return-prediction isolation. We outline immediate software countermeasures, such as aggressive RSB stuffing and fine-grained speculation barriers and call for architectural fixes that hard-partition or flush all return predictors on domain transitions.