LLVM Finally Buttoning Up Its Stack-Clash Protection For x86 CPUs
It's been nearly three years since the Stack Clash vulnerability was really tossed into the spotlight while such vulnerabilities have existed longer. Now finally in 2020, the LLVM compiler stack -- and years after GCC's mitigation -- is preparing its stack clash protection.
Since last autumn there has been stack clash protection under review for LLVM. This solution is similar to GCC's and exposes the same -fstack-clash-protection flag. When this stack clash protection feature is enabled on LLVM x86/x86_64, inline stack probing is used. "Probe stack allocation every PAGE_SIZE during frame lowering or dynamic allocation to make sure the page guard, if any, is touched when touching the stack, in a similar manner to GCC. This extends the existing `probe-stack' mechanism with a special value `inline-asm'. Technically the former uses function call before stack allocation while this patch provides inlined stack probes and chunk allocation."
Red Hat had engineered GCC's stack clash protection back during summer 2017.
The stack-clash protection code was finally merged today to the LLVM code-base, but quickly reverted thereafter for breaking macOS and Windows builds as well as separately breaking Arm builds. Hopefully the corrected code will land soon.
The LLVM stack-clash protection support can be tracked via this ticket.
UPDATE: The reworked stack clash protection has now landed in LLVM only to then be reverted yet again over test failures.
Since last autumn there has been stack clash protection under review for LLVM. This solution is similar to GCC's and exposes the same -fstack-clash-protection flag. When this stack clash protection feature is enabled on LLVM x86/x86_64, inline stack probing is used. "Probe stack allocation every PAGE_SIZE during frame lowering or dynamic allocation to make sure the page guard, if any, is touched when touching the stack, in a similar manner to GCC. This extends the existing `probe-stack' mechanism with a special value `inline-asm'. Technically the former uses function call before stack allocation while this patch provides inlined stack probes and chunk allocation."
Red Hat had engineered GCC's stack clash protection back during summer 2017.
The stack-clash protection code was finally merged today to the LLVM code-base, but quickly reverted thereafter for breaking macOS and Windows builds as well as separately breaking Arm builds. Hopefully the corrected code will land soon.
The LLVM stack-clash protection support can be tracked via this ticket.
UPDATE: The reworked stack clash protection has now landed in LLVM only to then be reverted yet again over test failures.
Add A Comment