This is the mail archive of the
mailing list for the glibc project.
Re: Undefined behavior in glibc
- From: Alexander Cherepanov <ch3root at openwall dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: Dwight Guth <dwight dot guth at runtimeverification dot com>, libc-alpha at sourceware dot org
- Date: Wed, 10 Feb 2016 06:44:19 +0300
- Subject: Re: Undefined behavior in glibc
- Authentication-results: sourceware.org; auth=none
- References: <27c31890079f41775175b94a4abedb0c dot squirrel at server316 dot webhostingpad dot com> <alpine dot DEB dot 2 dot 10 dot 1601282115100 dot 6102 at digraph dot polyomino dot org dot uk> <CACLXh_1_dQ5D1QrKQN0pVPzt001WmS4BgwcKZkULK8XnbEMb+g at mail dot gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1601282246340 dot 6102 at digraph dot polyomino dot org dot uk> <CACLXh_3rAudocTEbtZQpVoDcWgm_ww3KcX6j9XCkSRTZVPTUMg at mail dot gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1601282251350 dot 6102 at digraph dot polyomino dot org dot uk> <20160128225845 dot GE14840 at vapier dot lan> <alpine dot DEB dot 2 dot 10 dot 1601282311351 dot 6102 at digraph dot polyomino dot org dot uk> <20160128234356 dot GH14840 at vapier dot lan> <56AAB6CE dot 8060101 at openwall dot com> <20160129005816 dot GK14840 at vapier dot lan> <56AC16C8 dot 4030202 at openwall dot com> <alpine dot DEB dot 2 dot 10 dot 1601311559210 dot 31071 at digraph dot polyomino dot org dot uk> <56B1F294 dot 5020105 at openwall dot com> <alpine dot DEB dot 2 dot 10 dot 1602031234280 dot 31480 at digraph dot polyomino dot org dot uk> <56B4E8E3 dot 5010308 at openwall dot com> <alpine dot DEB dot 2 dot 10 dot 1602051835320 dot 3446 at digraph dot polyomino dot org dot uk> <56B50010 dot 20202 at openwall dot com> <alpine dot DEB dot 2 dot 10 dot 1602052233360 dot 21033 at digraph dot polyomino dot org dot uk>
On 2016-02-06 01:35, Joseph Myers wrote:
On Fri, 5 Feb 2016, Alexander Cherepanov wrote:
If you take an address of the array itself then you can access any of its
bytes but I don't think the standard permits you to go back from working with
chars to working with longs. Roughly speaking, the structure of the object is
forgotten. While you stay at the beginning of the object you can go back --
it's a general rule: you can convert unchanged pointers forth and back freely
(modulo alignment). But if you move from the beginning then you lose this
freedom. The standard doesn't describe going from an unrelated pointer to char
to a pointer to an (sub)object.
I think going from the pointer to char back to a pointer to long is valid
in GNU C and in common usage C, provided you never access the same memory
with different non-character types (other than signed/unsigned variations)
in ways that would require a union to do without conversions between
Not sure this plays well with other principles. AIUI (from , , 
etc.) you want to retain the freedom in gcc to optimize based on Q16 in
DR 017. But going through char* seems to permit cheating. Suppose you
have a 2d array and a pointer to char which points to the boundary
between two rows. What you get after converting it to a pointer to the
type of the elements -- a pointer pointing past the end of the previous
row or a pointer to the first element of the next row? What are the
limits for pointer arithmetic with this pointer -- one row, two rows,
I've got a question regarding separate compilation etc. What's the
problem with explicit_bzero then? Just compile it separately and no
barriers are required, right?
A couple of additions to my previous emails.
On 2016-02-03 15:29, Alexander Cherepanov wrote:
> Pointer wrapping
> Likely to be miscompiled in the future. Already reported:
I should have included in the list the bug report by Pascal Cuoq:
It motivated me to look for other cases of checks for pointer wrapping
in glibc. There are links to it in my PRs but I think it should
explicitly mentioned in this thread too.
On 2016-02-05 21:24, Alexander Cherepanov wrote:
> 1. This rules out all modern hardening/debugging solutions like
> Valgrind, ASan, Intel MPX, CHERI (don't know if the latter is relevant
> for glibc).
I guess everybody here is familiar with ASan as used for debugging but
perhaps it's worth mentioning that there are at least two ongoing
projects working on full systems using ASan (and, for the second
one, UBSan) for hardening in production. The specific merits are yet to
be assessed but the interest is definitely there.