<br><br><div class="gmail_quote">On Tue, Jan 24, 2012 at 9:53 AM, Duncan Sands <span dir="ltr"><<a href="mailto:baldrick@free.fr">baldrick@free.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Kostya,<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On Tue, Jan 24, 2012 at 1:23 AM, Duncan Sands <<a href="mailto:baldrick@free.fr" target="_blank">baldrick@free.fr</a><br></div><div class="im">
<mailto:<a href="mailto:baldrick@free.fr" target="_blank">baldrick@free.fr</a>>> wrote:<br>
<br>
Hi Kostya,<br>
<br>
> [resurrecting an old mail thread about AddressSanitizer false positive<br>
caused by<br>
> load widening]<br>
><br>
> Once the Attribute::AddressSafety is set by clang (a separate patch), fixing<br>
> this bug may look as simple as this:<br>
<br>
Hi Duncan,<br>
<br>
I don't get the point of an attribute. There's plenty of code out there<br>
that does wide loads like this directly (without them being created by the<br>
optimizers) since,<br>
<br>
<br>
You mean, the source code that e.g. loads 8 bytes, where up to 7 bytes might be<br>
out of array bounds?<br>
</div></blockquote>
<br>
yes.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Yes, we've seen quite a bit of such code.<br>
</blockquote>
<br></div>
I'm not surprised.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
First, such code often appears in libc, mostly in hand-written assembly (e.g.<br>
strlen), and valgrind/memcheck has a lot of trouble dealing with it<br>
(it basically has to intercept all such functions, which does not work when such<br>
functions are inlined, so valgrind does not properly work with O2-compiled<br>
binaries).<br>
asan does not care about it (yet) because it does not instrument libc.<br>
<br>
Second, we also seen such hacks in regular C/C++ code (usually, in codecs or<br>
compression code).<br>
Strictly speaking -- all these cases are bugs, according to either C or C++<br>
standard, and asan does not impose more restrictions than the standard.<br>
Note, that the hacks like these hurt not only address safety checkers like<br>
asan/memcheck/drmemory/<u></u>SAFEcode/etc, but also race detectors like<br>
tsan/helgrind/drd/etc.<br>
<br>
We still have lots of code with these intentional OOB accesses and we want to<br>
test it.<br>
In most cases I've met so far, the developers decided to actually fix the bugs<br>
according to the C++ standard and require the memory allocation to have up to 7<br>
extra bytes.<br>
</blockquote>
<br></div>
As far as I can see the C and C++ standards are not relevant. ASAN works on<br>
LLVM IR, not on C or C++. Lots of different languages have LLVM frontends. I<br>
personally turn Ada and Fortran into LLVM IR all the time for example. Clearly<br>
the C standard is not relevant to LLVM IR coming from such languages. What<br>
matters is how LLVM IR is defined. As far as I know this construct is perfectly<br>
valid in LLVM IR.</blockquote><div><br></div><div>Asan will not work for Fortran and Ada anyway (at least, out of the box). </div><div>I am not even sure that anything like asan is needed for Ada (it has bounds checking built-in, the dynamic memory allocation is much more restrictive).</div>
<div>The tool is rather specific to C/C++ (and ObjectiveC probably, although we have almost no tests for ObjectiveC, nor much knowledge in it). </div><div>Yes, the IR transformations are done on the LLVM level, but the asan run-time library heavily depends on the C/C++ semantics and even implementation,</div>
<div>and you can't really separate the asan instrumentation pass from the run-time. </div><div><br></div><div>--kcc </div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I do expect that sometimes this is impossible or undesirable.<br>
Then the solution would be to use __attribute__((address_safety)<u></u>) to avoid<br>
instrumenting the tricky pieces of code.<br>
</blockquote>
<br></div>
Unfortunately there is in general no way of attaching such attributes in many<br>
languages.<br>
<br>
Ciao, Duncan.<div class="HOEnZb"><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
--kcc<br>
<br>
<br>
just like the optimizers, they know it is safe and a win.<br>
The attribute won't help them. It looks like a way of just hiding the real<br>
problem, which seems to be that address sanitizer is overly strict.<br>
<br>
</blockquote>
<br>
</div></div></blockquote></div><br>