From: Florian Weimer <fweimer@redhat.com>
To: "Joseph S. Myers" <joseph@codesourcery.com>
Cc: Marek Polacek <polacek@redhat.com>,
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: Mon, 16 Sep 2013 13:39:00 -0000 [thread overview]
Message-ID: <5236FEF8.2030901@redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.64.1309121555130.5614@digraph.polyomino.org.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
next prev parent reply other threads:[~2013-09-16 12:52 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
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 [this message]
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=5236FEF8.2030901@redhat.com \
--to=fweimer@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=jason@redhat.com \
--cc=joseph@codesourcery.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).