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: Florian Weimer <fweimer at redhat dot com>
- To: Jeff Law <law at redhat dot com>, Eric Botcazou <ebotcazou at adacore dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 21 Jun 2017 21:06:55 +0200
- Subject: Re: RFC: stack/heap collision vulnerability and mitigation with GCC
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=fweimer at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com D07B280467
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com D07B280467
- References: <bef46e40-8004-0f80-4928-ad0795eb76ba@redhat.com> <62416688.h8zfxR0s2T@polaris> <444cbea3-9d10-082b-3a3b-ce517f8a6b14@redhat.com>
On 06/20/2017 11:52 PM, Jeff Law wrote:
> 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.
I think Hotspot does that as well. At the low level, Java programs can
recover from stack overflow (but it's still a VM error which taints the
entire process because these errors can strike at too many places, and
critical invariants could be violated).
Thanks,
Florian