This is the mail archive of the
mailing list for the GCC project.
Re: RFC: stack/heap collision vulnerability and mitigation with GCC
> But what you end up depending on is undocumented behavior of a
> particular kernel implementation. That seems rather unwise.
And it's the single example of such a thing in the entire codebase?
I don't know the code of the sanitizer much, but from the outside it looks
full of similar tricks...
> Which ABIs have that property? I'll be the first to admit that I've
> purged much of my weird ABI memories.
The original Alpha ABI mentioned by Richard IIRC for example.
> Supporting ABIs which force us into a probe, then allocate strategy is
> actually easy. We can use the existing -fstack-check code, but use the
> value 0 for STACK_CHECK_PROTECT.
> Just replace all uses of STACK_CHECK_PROTECT with calls to a wrapper.
> The wrapper looks like
> if (magic_flag)
> return STACK_CHECK_PROTECT;
> return 0;
> That's precisely what we were planning to do prior to bumping against
> the valgrind issues. That indirection makes it easy to ensure we didn't
> change the behavior of the existing stack-check for Ada, but also allows
> us to change the behavior for the new stack checking option.
Yes, that would seem the most straightforward thing to do modulo Valgrind.
> Ah, so if you're running on an alternate stack, then why probe ahead of
> need? I thought the whole point of probing a couple pages ahead as to
> ensure you could take the signal the Ada.
We run on the alternate stack only when we do _not_ probe ahead, i.e. on
> I've also wondered if a 2 page guard would solve some of these problems.
> In the event of stack overflow, the kernel maps in one of the two pages
> for use by the signal handler. But changing things at this point may
> not be worth the effort.
That was exactly the strategy used by Tru64 (so you needed to manually unmap
the page after you had recovered from the overflow).