This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Undefined behavior in glibc

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?


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[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] [5]

Alexander Cherepanov

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]