[PATCH] D139254: Enhance stack protector
Nick Desaulniers via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed Mar 29 13:36:51 PDT 2023
nickdesaulniers added a comment.
In D139254#4191358 <https://reviews.llvm.org/D139254#4191358>, @xiangzhangllvm wrote:
> In D139254#4190508 <https://reviews.llvm.org/D139254#4190508>, @hiraditya wrote:
>
>> Are there possible optimizations which can be implemented to reduce the code-size impact of this change? I'm wondering if this patch adds the checks conservatively to all instances where stack check could potentially, but not necessarily, be missed/useful?
>
> Seems good idea, but it is hard to guess how the attacker will attack our program. (which no-return should protect or not), and sorry for I am not a defense expert.
> Welcome any good suggestion, or directly add me to related patch's reviewer or subsciber.
I'm happy to see at least there's an option to turn this off.
`-mllvm -disable-check-noreturn-call`
https://reviews.llvm.org/D141556
That said, rereading https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58245#c6 I kind of agree with Jakub. What are you protecting exactly? Why do so only for noreturn calls? Why not prior to every call? Why not insert a stack check guard after every operation? If you're that paranoid, do no meaningful work and just keep checking the stack protector.
I think this would have been better implemented as a new level beyond `-fstack-protector-strong` rather than regressing the code size of every user of `-fstack-protector-strong`.
If GCC doesn't do this, is this something ICC did?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D139254/new/
https://reviews.llvm.org/D139254
More information about the llvm-commits
mailing list