From: "Diego Elio Pettenò" <flameeyes@gmail.com>
To: gentoo-dev@lists.gentoo.org
Cc: gentoo-qa@lists.gentoo.org
Subject: [gentoo-qa] Portage to die on sure-enough _FORTIFY_SOURCE overflows
Date: Tue, 28 Sep 2010 11:43:28 +0200 [thread overview]
Message-ID: <1285667008.13141.31.camel@yamato.local> (raw)
Hi all,
since the last time I asked Zac about this it came back to bite me[1]
this time I'm going to send the announce to the list first, and if
nobody can actually come up with a good reason not to, I'm going to ask
Zac tomorrow to re-enable the feature.
What is this about? Portage already reports some of the overflow
warnings coming from the glibc fortified sources (-D_FORTIFY_SOURCE=2
-O2 — enabled since gcc 4.3.3-r1 and even stronger with gcc 4.5 and
glibc 2.12+, afaict), but they really are divided into two categories:
- might overflow (depends on combination of parameters and variables the
compiler can't completely untangle);
- _will_ overflow (whenever that code path is hit, an overflow will
happen).
The former we should highlight but not die upon; the latter, though...
As Mike and me expressed on the linked bug, code that is built with that
warning is code that is going to crash as surely as
char *foo = NULL;
foo[3] = 'a';
which could result in nasty surprises for users (see [2] for the whole
reasoning).
Now, we've not seen "proper" false positives (in the Portage sense I
mean — because even if the C library hits a false positive, it _will_
crash with an abort() from its own code!), but Kumba pointed me at a
case that wasn't entirely clear, and took a bit of detective work to
track down [3] so you could have users report issues you cannot easily
identify or reproduce. I cannot make promises, but if all else fail I'll
see to be around to help you with those cases.
So if you want to have your say, gentoo-qa is there for that.
Thank you,
[1] https://bugs.gentoo.org/show_bug.cgi?id=337031
[2]
http://blog.flameeyes.eu/2010/09/14/not-all-failures-are-caused-equal
[3]
http://blog.flameeyes.eu/2010/09/12/some-_fortify_source-far-fetched-warnings-are-funny
--
Diego Elio Pettenò — “Flameeyes”
http://blog.flameeyes.eu/
If you found a .asc file in this mail and know not what it is,
it's a GnuPG digital signature: http://www.gnupg.org/
next reply other threads:[~2010-09-28 9:43 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-28 9:43 Diego Elio Pettenò [this message]
2010-09-28 19:33 ` [gentoo-qa] Re: [gentoo-dev] Portage to die on sure-enough _FORTIFY_SOURCE overflows Alec Warner
2010-09-28 22:35 ` Diego Elio Pettenò
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=1285667008.13141.31.camel@yamato.local \
--to=flameeyes@gmail.com \
--cc=gentoo-dev@lists.gentoo.org \
--cc=gentoo-qa@lists.gentoo.org \
/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