[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