<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 5/10/12 1:39 AM, Kostya Serebryany wrote:
<blockquote
cite="mid:CAN=P9pgV3Ep-08TA54_zRV9PABY1MN32sYMR7ADh-h0tXWc19Q@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
+Ott Tinn
<div><br>
</div>
<div>Some comments, mostly related to asan: </div>
<div><br>
</div>
<div>>> lscheck (void * ptr, int length)</div>
<div>length should be size_t</div>
</blockquote>
<br>
Correct. I had originally used uintptr_t, but that didn't typeset
very well. I decided to be less pedantic to improve readability.<br>
:)<br>
<br>
<blockquote
cite="mid:CAN=P9pgV3Ep-08TA54_zRV9PABY1MN32sYMR7ADh-h0tXWc19Q@mail.gmail.com"
type="cite">
<div>asan needs to distinguish between reads and writes. <br>
</div>
</blockquote>
<br>
Okay. We can then have a loadcheck() and a storecheck().<br>
<br>
Do you consider the atomic intrinsics (e.g., compare and swap) to be
stores, or do we need an lscheck() that checks operations that
perform a load and a store?<br>
<br>
<blockquote
cite="mid:CAN=P9pgV3Ep-08TA54_zRV9PABY1MN32sYMR7ADh-h0tXWc19Q@mail.gmail.com"
type="cite">
<div><br>
</div>
<div>>> pool register stack(void * p, int size)</div>
<div>asan needs more information for the stack than just pointer
and size. Currently, there is a extra constant string with frame
description.</div>
</blockquote>
<br>
First, there are separate instrumentation passes for adding
pool_register_stack(), pool_register_global(), and
pool_register_heap(). If a tool does not find one of these
functions useful, it can simply omit the pass that adds them.<br>
<br>
Second, regarding the extra parameters, my plan is to have each tool
run tool-specific passes to add parameters as needed. For example,
SAFECode would add a pool handle argument and, if used as a
debugging tool, source line and file name arguments. I assume ASan
can have a pass that adds the frame description argument. If that's
not possible, please let me know.<br>
<br>
Third, I am curious to know whether generic optimization of
registration calls could aid ASan. Optimizing away a pool_register
call basically means that all run-time checks on pointers to that
memory have either been proven safe or are performed using
fastlscheck/fastgepcheck. This can speed up SAFECode, but can it
also speed up ASan?<br>
<br>
<br>
<blockquote
cite="mid:CAN=P9pgV3Ep-08TA54_zRV9PABY1MN32sYMR7ADh-h0tXWc19Q@mail.gmail.com"
type="cite">
<div>Asan modifies the whole stack frame at once, not every single
alloca separately.</div>
<div>size must be size_t </div>
<div><br>
</div>
<div>>> pool register global(void * p, int size):</div>
<div>This is very slow for cases when we have millions of
globals. </div>
<div>asan uses a callback which takes an array of globals as a
parameter. </div>
<div>Also, asan modifies the global (adding a redzone at right). </div>
<div>size must be size_t <br>
</div>
</blockquote>
<br>
Good point; it would make more sense to have pool_register_global
take an array of globals and their size.<br>
<br>
For the redzones, adding them would be done by an ASan-specific
transform.<br>
<br>
<blockquote
cite="mid:CAN=P9pgV3Ep-08TA54_zRV9PABY1MN32sYMR7ADh-h0tXWc19Q@mail.gmail.com"
type="cite">
<div><br>
</div>
<div>>> pool unregister(void * p):</div>
<div>For performance, we will need separate unregister calls for
heap, stack and globals. <br>
</div>
</blockquote>
<br>
Okay, but just out of curiosity, what performance advantage do you
get by distinguishing between them?<br>
<br>
<blockquote
cite="mid:CAN=P9pgV3Ep-08TA54_zRV9PABY1MN32sYMR7ADh-h0tXWc19Q@mail.gmail.com"
type="cite">
<div><br>
</div>
<div><br>
</div>
<div>>> The Address Sanitizer (ASan)</div>
<div>s/Address Sanitizer/AddressSanitizer/ (no spaces) :)</div>
</blockquote>
<br>
Ah. Sorry about that.<br>
<br>
<blockquote
cite="mid:CAN=P9pgV3Ep-08TA54_zRV9PABY1MN32sYMR7ADh-h0tXWc19Q@mail.gmail.com"
type="cite">
<div><br>
</div>
<div>>> convert lscheck checks to fastlscheck</div>
<div>For asan this is useless (though harmless)</div>
</blockquote>
<br>
Actually, I'm not sure if that is true. If I understand correctly,
an lscheck in ASan will need to perform a load from shadow memory
and perform a comparison. A fastlscheck, on the other hand, does
two comparisons. If you suffer a cache miss in the shadow memory, I
think an lscheck could take longer than a fastlscheck.<br>
<br>
Also, fastlscheck is easier to optimize. Since you know the bounds
of the memory object to which the pointer belongs, you may be able
to optimize away one or both of the comparisons.<br>
<br>
-- John T.<br>
<br>
</body>
</html>