[PATCH] D147975: [StackProtector] don't check stack protector before calling nounwind functions

Phoebe Wang via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Apr 12 02:19:28 PDT 2023

pengfei added a comment.

In D147975#4260221 <https://reviews.llvm.org/D147975#4260221>, @efriedma wrote:

>> SJLJ, signal
> In practice, most noreturn functions in C are going to be calls to abort()-like functions, not longjmp()-like functions.  And it doesn't really make sense to check the stack canary before we call abort(); the program is going to die before we touch any corrupted memory.
> We could consider trying to encode more information into the IR, I guess.  In a lot of cases, we know a "noreturn nounwind" function is abort()-like, and not longjmp()-like; we just don't bother recording it anywhere because nothing cared before this.
>> And I think they are more risky somehow, because they can catch up hardware exceptions like dividend by 0, segment fault or illegal instructions. These exceptions are relative eaiser for an attacker to trigger than a normal C++ exception.
> Unwinding on divide-by-zero is a Windows-specific thing, as far as I know.  It's possible we want to do something different on Windows?  But there are codesize costs here, and nobody has done any research on the Windows-specific side of this.
>> we noticed certain Linux kernel trees stopped booting after this (in functions trying to initialize the stack canary itself).
> The kernel should probably disable stack canaries for the functions in question?

Thanks @efriedma! Makes sense to me. Seem only Windows may have problem here especially given MSVC supports `__declspec(noreturn)` too. It's not a big deal since we can check `eh-asynch` from module flag, but I don't think we need to do it in this patch.

  rG LLVM Github Monorepo



More information about the llvm-commits mailing list