This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: stack/heap collision vulnerability and mitigation with GCC
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 19 Jun 2017 17:50:56 +0000
- Subject: Re: RFC: stack/heap collision vulnerability and mitigation with GCC
- Authentication-results: sourceware.org; auth=none
- References: <bef46e40-8004-0f80-4928-ad0795eb76ba@redhat.com>
On Mon, 19 Jun 2017, Jeff Law wrote:
> A key point to remember is that you can never have an allocation
> (potentially using more than one allocation site) which is larger than a
> page without probing the page.
There's a platform ABI issue here. At least some kernel fixes for these
stack issues, as I understand it, increase the size of the stack guard to
more than a single page. It would be possible to define the ABI to
require such a larger guard for protection and so reduce the number of
(non-alloca/VLA-using) functions that need probes generated, depending on
whether a goal is to achieve security on kernels without such a fix.
(Thinking in terms of how to get to enabling such probes by default.)
--
Joseph S. Myers
joseph@codesourcery.com