[LLVMdev] load widening conflicts with AddressSanitizer

[Kostya Serebryany]

On Tue, Jan 24, 2012 at 1:23 AM, Duncan Sands <baldrick at free.fr> wrote:

> Hi Kostya,
>
> > [resurrecting an old mail thread about AddressSanitizer false positive
> caused by
> > load widening]
> >
> > Once the Attribute::AddressSafety is set by clang (a separate patch),
> fixing
> > this bug may look as simple as this:
>
> Hi Duncan,


> I don't get the point of an attribute.  There's plenty of code out there
> that does wide loads like this directly (without them being created by the
> optimizers) since,


You mean, the source code that e.g. loads 8 bytes, where up to 7 bytes
might be out of array bounds?
Yes, we've seen quite a bit of such code.

First, such code often appears in libc, mostly in hand-written assembly
(e.g. strlen), and valgrind/memcheck has a lot of trouble dealing with it
(it basically has to intercept all such functions, which does not work when
such functions are inlined, so valgrind does not properly work with
O2-compiled binaries).
asan does not care about it (yet) because it does not instrument libc.

Second, we also seen such hacks in regular C/C++ code (usually, in codecs
or compression code).
Strictly speaking -- all these cases are bugs, according to either C or C++
standard, and asan does not impose more restrictions than the standard.
Note, that the hacks like these hurt not only address safety checkers like
asan/memcheck/drmemory/SAFEcode/etc, but also race detectors like
tsan/helgrind/drd/etc.

We still have lots of code with these intentional OOB accesses and we want
to test it.
In most cases I've met so far, the developers decided to actually fix the
bugs according to the C++ standard and require the memory allocation to
have up to 7 extra bytes.
I do expect that sometimes this is impossible or undesirable.
Then the solution would be to use __attribute__((address_safety)) to avoid
instrumenting the tricky pieces of code.

--kcc


just like the optimizers, they know it is safe and a win.
> The attribute won't help them.  It looks like a way of just hiding the real
> problem, which seems to be that address sanitizer is overly strict.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120124/40f6fbc5/attachment.html>