<br><br><div class="gmail_quote">On Tue, Jan 24, 2012 at 1:53 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><div class="gmail_quote">On Tue, Jan 24, 2012 at 1:36 PM, Kostya Serebryany <span dir="ltr"><<a href="mailto:kcc@google.com" target="_blank">kcc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>ASAN *can* be modified this way (it will actually make instrumentation ~10% cheaper). </div><div>But this mode will miss some bugs that the current mode finds. </div><div>I've seen at least a couple of such *real* bugs.</div>


<div><br></div><div>And these bugs are not only about exploitability, but also about correctness. </div><div>If a program reads garbage, there is no simple way to statically prove that this garbage does not affect the program's behavior. </div>

</blockquote></div><br></div><div>We could go back to my original proposed fix -- come up with a specific way to model a "read past the end" in the LLVM IR. Essentially capture the act of load widening in the IR. I'm imagining 'load i8* %ptr as i64'. This is a load that reads an i64 value from memory, but only fills the low 8 bits with a value, the high bits are undef.</div>
</blockquote><div><br></div><div>I don't *feel* the LLVM IR too well yet, but I would expect such change to be a very disruptive revolution. </div><div>Every transformation will have to learn about the new instruction (or instruction attribute, whatever) -- all for a relatively little value. </div>
<div><br></div><div>--kcc </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><br></div><div>Then the analysis knows that the program cannot rely on the value in the high bits, and does not flag an error. The code generator knows that the high bits can be undef, and can emit the widened load to memory as appropriate. We can teach the optimizers to *try* to transform C code forming these patterns into such a load for canonicalization, and we can provide a __builtin_....(...) syntax for explicitly performing such a load.</div>

<div><br></div><div>PS: The syntax might equally well be "load i64* %ptr as i8'; it all depends on what the most natural way to form this pattern in IR is -- produce an i8 value or an i64 with undef high bits? require the pointer to be the wide type or the narrow type? i'd have to look at how these would play out in IR to tell what the best pattern is...</div>

</blockquote></div><br>