AMD внедряет аппаратную защиту Zen 6 от атак спекулятивного выполнения

Years of speculative execution attacks have forced processor designers and kernel developers into a defensive arms race. Each new vulnerability exposed another way attackers could train a CPU’s branch predictor to leak data across security boundaries. Now AMD prepares a hardware answer for its next-generation Zen 6 processors. And the Linux kernel already carries the first code to take advantage of it. A patch queued in the x86/bugs branch of tip.git signals the change. Phoronix first reported the development on September 7, 2026. The feature, called BTB context isolation, lets the processor separate branch target buffer entries used by user code from those used by the kernel. It does the same for guest virtual machines and their hypervisor hosts. The hardware itself tracks and isolates these predictions. No longer must software insert the full SafeRET sequence on every kernel return. Borislav Petkov, longtime AMD Linux engineer, spelled out the implications in the patch comment. “Zen6 has BTB protection which isolates the different contexts (user/kernel, guest/host) from one another. This makes the SafeRET mitigation there unnecessary leaving the user/user and guest/guest attack vectors open, whose protection is handled by the Spectre v2 mitigation setting to do IBPB on a context switch. Detect that setting and report it with a new mitigation string.” The quote comes directly from the patch description. SafeRET, born as a response to Speculative Return Stack Overflow on earlier Zen chips, carried real cost. It replaced kernel RET instructions with a controlled thunk that prevented poisoned predictions. On Zen 1 through Zen 4 that overhead mattered. Zen 6 makes the mechanism redundant inside the kernel. The patch removes the need for it when the new hardware protection appears. But isolation stops at the same-privilege boundary. User processes can still influence each other. The same holds for multiple guests on one host. Those risks remain covered by existing Spectre v2 controls. When the kernel performs an IBPB flush on context switch, those same-privilege vectors stay closed. The new code simply detects the hardware capability and updates the mitigation status string shown to administrators. This development fits a broader pattern. AMD has shipped incremental hardware defenses for years. In February 2026 the company posted patches for SEV-SNP BTB isolation, a related mechanism that protects confidential virtual machines. Phoronix covered that effort. The hardware tracks each guest’s BTB entries and flushes them if it detects contamination from outside the guest context. Hypervisors receive a recommendation to run with legacy IBRS enabled rather than automatic IBRS, because the latter behaves differently under SEV-SNP. Recent research shows why such defenses matter. In August 2026 MIT CSAIL researchers Daniël Trujillo and Mengjia Yan disclosed an interrupt injection technique that can neutralize some software-based SafeRET protections. The Hacker News summarized their work. The attack times interrupts to land inside the narrow window after a neutralization sequence but before the return actually executes. On a Zen 2 system with all default mitigations the researchers extracted kernel memory at roughly five bytes per second. AMD responded with a kernel patch that restores register state as if the safe sequence had completed, closing the hole. Yet these software fixes add complexity. They also carry performance penalties that grow with context-switch frequency. Hardware isolation promises cleaner separation. When the CPU itself guarantees that predictions from one context cannot reach another, the kernel can drop some of its defensive thunks. That should improve instruction-cache behavior and reduce the number of serializing instructions required on every transition. Exactly how much faster the result will be remains unknown. No public benchmarks exist yet for Zen 6 silicon. The patch itself focuses on detection and reporting rather than performance tuning. Still, the direction looks clear. Future kernels will query a CPUID bit or model-specific register, set an internal flag, and adjust the mitigation path accordingly. Administrators running cat /proc/cpuinfo will see a new string that reflects the hardware protection. The code sits in tip.git today. It could reach Linux 7.4 during the normal merge window or slip into a 7.3 stable update if urgency demands. Either way, the change marks another step in the long effort to move speculation defenses from software workarounds into silicon. Earlier generations needed retpolines, return stack stuffing, and SafeRET. Zen 6 begins to reclaim that performance. Plenty of attack surface remains. Cross-thread attacks on simultaneous multithreading, unprivileged eBPF, and new microarchitectural timing leaks all continue to demand attention. The interrupt injection research from August proves that even well-reviewed software mitigations can harbor subtle timing windows. Kernel developers must keep refining their defenses. But for workloads that switch contexts frequently, the BTB isolation feature offers tangible relief. Database servers, virtual desktop hosts, and cloud instances that run many short-lived processes should notice the difference once Zen 6 systems ship with updated kernels. The hardware does the heavy lifting. The kernel simply gets out of the way. AMD has not published a full white paper on the Zen 6 BTB mechanism. Details beyond the patch comment stay scarce. That opacity matches industry practice for speculation features. Vendors prefer to document only what developers need to consume the new capability safely. The rest stays inside the microarchitecture. One thing looks certain. The steady march of speculative side-channel discoveries will continue. Each generation of processors adds new prediction structures and new ways for software to observe them. Hardware isolation represents one of the stronger responses available. By partitioning the branch target buffer according to privilege and virtualization context, AMD narrows the attacker’s reach at the source. Linux has tracked these changes through dozens of mitigation flags over the past decade. From KAISER page-table isolation to retpoline, from IBRS to STIBP to SRSO workarounds, the kernel has grown a sophisticated machinery for querying CPU features and selecting the right defense. The Zen 6 patch slots neatly into that existing framework. It adds one more string to the list of known mitigations and removes the need for one heavyweight software sequence. The result feels like progress. Not a final victory, because new attacks always appear. But a practical improvement that reduces overhead for a common case. System administrators will welcome the simpler mitigation profile. Developers will appreciate fewer magic sequences in hot paths. And security researchers will study the new hardware boundaries to see whether any cracks remain. For now the patch sits quietly in tip.git. Soon it will ride into mainline, and the next wave of AMD server and desktop processors will arrive with one less software tax on every kernel return. The long contest between attackers and CPU architects continues. This round tilts toward the defenders.