public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Joseph S. Myers" <joseph@codesourcery.com>
To: Marek Polacek <polacek@redhat.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>,
	Jakub Jelinek <jakub@redhat.com>,
	Jason Merrill <jason@redhat.com>
Subject: Re: [PATCH][ubsan] Add VLA bound instrumentation
Date: Thu, 12 Sep 2013 16:20:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.64.1309121555130.5614@digraph.polyomino.org.uk> (raw)
In-Reply-To: <Pine.LNX.4.64.1309121546080.5614@digraph.polyomino.org.uk>

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.

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.)

-- 
Joseph S. Myers
joseph@codesourcery.com

  reply	other threads:[~2013-09-12 16:05 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-12 12:38 Marek Polacek
2013-09-12 12:48 ` Marek Polacek
2013-09-12 16:12 ` Joseph S. Myers
2013-09-12 16:20   ` Joseph S. Myers [this message]
2013-09-12 17:15     ` Marek Polacek
2013-09-13 10:29     ` Marek Polacek
2013-09-13 11:23       ` Eric Botcazou
2013-09-13 18:01       ` Joseph S. Myers
2013-09-16 11:13     ` Marek Polacek
2013-09-16 13:39     ` Florian Weimer
2013-09-12 16:29   ` Marek Polacek
2013-09-25 13:23 ` Marek Polacek
2013-10-07 20:17   ` Marek Polacek
2013-10-15 13:25     ` Marek Polacek
2013-10-15 15:01       ` Joseph S. Myers
2013-10-24 20:35   ` Jason Merrill
2013-10-25 17:38     ` Marek Polacek
2013-10-25 19:04       ` Jason Merrill
2013-10-25 19:15         ` Marek Polacek
2013-10-25 19:30           ` Jason Merrill
2013-10-30 15:16             ` Marek Polacek
2013-10-30 16:08               ` Jason Merrill
2013-10-30 16:20                 ` Marek Polacek
2013-10-30 20:55                   ` Mike Stump
2013-10-30 22:46                     ` Marek Polacek
2013-10-30 22:50                       ` Mike Stump
2013-10-31 11:12                         ` Marek Polacek
2013-10-31  3:18                   ` Jason Merrill
2013-10-31 19:07                     ` Marek Polacek
2013-11-01 17:35                       ` Jason Merrill
2013-11-01 19:10                         ` Marek Polacek
2013-11-01 20:39                           ` Jason Merrill
2013-11-02 13:06                             ` Marek Polacek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.64.1309121555130.5614@digraph.polyomino.org.uk \
    --to=joseph@codesourcery.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=jason@redhat.com \
    --cc=polacek@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).