Linux 6.1 Hardening Retpolines With Ensuring An INT3 After Every Unconditional Jump
The x86/core changes for Linux 6.1 have been merged and are headlined by making sure an INT3 instruction is inserted after every unconditional Retpoline jump (JMP) for the Retpolines handling on both Intel and AMD processors.
Intel engineer Peter Zijlstra authored the change to ensure an INT3 after an indirect JMP occurs. This behavior is recommended by both Intel and AMD. This Retpoline change comes after the x86 Straight Line Speculation mitigation involved adding an INT3 after function returns and indirect branches.
The INT3 x86 instruction was originally designed for use by debuggers for setting a software breakpoint / calling the debug exception handler. But using INT3 in the world of speculative execution vulnerabilities has also proven useful as part of the mitigations as a speculation trap for avoiding speculative execution past that point.
This Linux 6.1 change is basically a safeguard against being built against older compilers lacking the x86 Straight Line Speculation mitigation handling or where SLS isn't enabled. So for most users running a sane distribution/vendor kernel built with a modern compiler and SLS enabled, you won't see any difference with Linux 6.1.
More details via the x86/core pull request that has already been merged for mainline Linux 6.1.
Intel engineer Peter Zijlstra authored the change to ensure an INT3 after an indirect JMP occurs. This behavior is recommended by both Intel and AMD. This Retpoline change comes after the x86 Straight Line Speculation mitigation involved adding an INT3 after function returns and indirect branches.
The INT3 x86 instruction was originally designed for use by debuggers for setting a software breakpoint / calling the debug exception handler. But using INT3 in the world of speculative execution vulnerabilities has also proven useful as part of the mitigations as a speculation trap for avoiding speculative execution past that point.
This Linux 6.1 change is basically a safeguard against being built against older compilers lacking the x86 Straight Line Speculation mitigation handling or where SLS isn't enabled. So for most users running a sane distribution/vendor kernel built with a modern compiler and SLS enabled, you won't see any difference with Linux 6.1.
More details via the x86/core pull request that has already been merged for mainline Linux 6.1.
1 Comment