Re: gdb not catching out-of-bounds pointer

On Dec 15, 6:30 pm, Ben Bacarisse <ben.use...@xxxxxxxxx> wrote:

I think the C definition is more helpful here.  Using C's terms, buf1
and buf2 are distinct objects and a bounds checker can detect access
outside of either.  Indeed mudflap does just that.

I don't see how it could without the possibility of false positives.
You can't introduce padding between the two objects because that would
break ABI compatibility. You can't assume that a person can't access
one object through a pointer to the other, because it is perfectly
legal to add and subtracts offsets to pointers.

I understand that here you may simply be explaining why valgrind
misses this error, but seems that you might be making a stringer point
here:

Yes, valgrind misses the error because the way the language is
normally implemented means it's not an error. You could have
calculated the offset between the two objects and added that offset to
the pointer of the object that appears first.

To put it another way, it's not necessarily out of bounds to access
one object in a way that can be reasonably guaranteed to validly
access another object.

Because they are always allocated as a pair and one cannot be
allocated without the other, a runtime bounds checker cannot detect
accidental overflow from one into the other.

A bounds checker is permitted to detect this.

Sure, it's permitted to detect *every* access and complain that it
*might* be out-of-bounds. But that would not be a useful bounds
checker.

More important is that they are adjacent.  Had there been some padding
between them, a theoretical bounds checker could detect access to that
region.

Not likely, since that would be a perfectly valid way to access the
padding.

Not in standard C.  Accessing any gap between automatic objects (in
the C sense) is undefined behaviour.  It is this UB that permits a
conforming bounds-checked C implementation.

Right, but real-world UNIX implementations aren't standard C. They
guarantee specific memory layouts for structures, for example, because
otherwise it would incredibly hard to pass them between modules
compiled separately.

DS
.

Relevant Pages

  • Re: gdb not catching out-of-bounds pointer
    ... and buf2 are distinct objects and a bounds checker can detect access ... one object through a pointer to the other, ... and might therefore make an optimisation based on that ... it does, in fact, forbid such optimisations or if it relaxes the rules ...
    (comp.unix.programmer)
  • Re: gdb not catching out-of-bounds pointer
    ... and buf2 are distinct objects and a bounds checker can detect access ... one object through a pointer to the other, ... and might therefore make an optimisation based on that ... it does, in fact, forbid such optimisations or if it relaxes the rules ...
    (comp.unix.programmer)