Undefined behavior in glibc

[Alexander Cherepanov]

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
> pointer types.

Not sure this plays well with other principles. AIUI (from [1], [2], [2] 
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, 
whole array?

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41630#c8
[2] https://gcc.gnu.org/ml/gcc/2001-10/msg00820.html
[3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54136#c5

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:
 >
 > https://sourceware.org/bugzilla/show_bug.cgi?id=19411
 > https://sourceware.org/bugzilla/show_bug.cgi?id=19412
 > https://sourceware.org/bugzilla/show_bug.cgi?id=19413

I should have included in the list the bug report by Pascal Cuoq:

https://sourceware.org/bugzilla/show_bug.cgi?id=19391

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[1][2] 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.

[4] 
https://blog.hboeck.de/archives/879-Safer-use-of-C-code-running-Gentoo-with-Address-Sanitizer.html
[5] 
http://balintreczey.hu/blog/proposing-amd64-hardened-architecture-for-debian/

-- 
Alexander Cherepanov