This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH][ubsan] Add VLA bound instrumentation
- From: Florian Weimer <fweimer at redhat dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Marek Polacek <polacek at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Jakub Jelinek <jakub at redhat dot com>, Jason Merrill <jason at redhat dot com>
- Date: Mon, 16 Sep 2013 14:52:08 +0200
- Subject: Re: [PATCH][ubsan] Add VLA bound instrumentation
- Authentication-results: sourceware.org; auth=none
- References: <20130912122655 dot GN23899 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1309121546080 dot 5614 at digraph dot polyomino dot org dot uk> <Pine dot LNX dot 4 dot 64 dot 1309121555130 dot 5614 at digraph dot polyomino dot org dot uk>
On 09/12/2013 06:05 PM, Joseph S. Myers wrote:
On Thu, 12 Sep 2013, Joseph S. Myers wrote:
(Actually, I believe sizes (in bytes) greater than target PTRDIFF_MAX, not
just SIZE_MAX, should be caught, because pointer subtraction cannot work
reliably with larger objects. So it's not just when the size or
multiplication overflow size_t, but when they overflow ptrdiff_t.)
And, to add a bit more to the list of possible ubsan features (is this
todo list maintained anywhere?), even if the size is such that operations
on the array are in principle defined, it's possible that adjusting the
stack pointer by too much may take it into other areas of memory and so
cause stack overflow that doesn't get detected by the kernel. So maybe
ubsan should imply -fstack-check or similar.
I have on my to-do list to make -fstack-check production-ready, by
avoiding unnecessary instrumentation. My initial experiments weren't
too successful, but I think it should be possible to greatly reduce its
overhead. If everything else fails, the idea is to reuse the Go split
stack limit and check against that.
The idea is that this would eventually be enabled in production code,
much like -fstack-protector.
I'm quite busy with other work at the moment, and a patch from me is
probably months away, though. :-(
Florian Weimer / Red Hat Product Security Team