Commit c3b9819 enabled inserting "bti j" after call to setjmp through lowering
setjmp calls to AArch64ISD::CALL_BTI which is later pattern matched to pseudo
instruction BLR_BTI. However, the lowering to BLR_BTI is infeasible if SLS BLR
mitigation (harden-sls-blr) is enabled because the pattern
Requires<[NoSLSBLRMitigation]>. Therefore, when harden-sls-blr is enabled,
ISel crashes due to the "can not select AArch64ISD::CALL_BTI" error. This patch
fixes this corner case by avoiding lowering setjmp call to CLL_BTI if
harden-sls-blr is enabled.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Not crashing seems reasonable :)
I don't know what the interaction of BTI and the sls-blr is though. Does not emitting the bti actually break things if you have sls-blr and branch target enforcement enabled? Perhaps the __llvm_slsblr_thunk_x would make that all work because it would contain the required btis.
I defer to @kristof.beyls on that one.
This change would lead to a situation where you have sls-blr and bti enabled but you don't get a bti after the setjmp call, which is going to be a hard failure once you return from the setjmp.
Talking to Kristof, we don't think there's any reason that CALL_BTI can't coexist with the sls mitigation. This could be done by following what AArch64call does https://github.com/llvm/llvm-project/blob/6e1ebb916e467f26d3c0cb0819770cd67f956cc3/llvm/lib/Target/AArch64/AArch64InstrInfo.td#L2567.
Since this was my change originally, I will work on a patch to do that.
Thanks for the feedback, @DavidSpickett! Our longjmp implementation does not use br, so this patch is safe for us. Having said that, I do understand your concern over not generating a bti after setjmp when both sls-blr and branch target enforcement are enabled.
Please kindly keep me in the loop once you have a proper fix for this issue. I am abandoning this patch.