This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][ubsan] Add VLA bound instrumentation
- From: Marek Polacek <polacek at redhat dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: 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: Thu, 12 Sep 2013 18:28:57 +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 Thu, Sep 12, 2013 at 04:05:48PM +0000, 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
No, I don't have such a list (at least nothing online/public).
> 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.
Works for me.
> Everything about VLA checking - checks on the size being positive and on
> it not being larger than PTRDIFF_MAX, and on avoiding stack overflow -
> applies equally to alloca: calls to alloca should also be instrumented.
> (But I think alloca (0) is valid.)
Yes, good idea. I've just checked and clang doesn't check the size
passed to alloca, I think it'd be good addition to have it.
And yeah - alloca (0) seems to be valid; when expanding
__builtin_alloca we call allocate_dynamic_stack_space and that
contains
/* If we're asking for zero bytes, it doesn't matter what we point
to since we can't dereference it. But return a reasonable
address anyway. */
if (size == const0_rtx)
return virtual_stack_dynamic_rtx;
Thanks,
Marek