<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jun 9, 2015 at 7:30 PM, Peter Collingbourne <span dir="ltr"><<a href="mailto:peter@pcc.me.uk" target="_blank">peter@pcc.me.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> I don't follow why the dependence on RTTI is linked to whether you emit diagnostics, can you explain?<br>
<br>
<br>
</span>The CFI mechanism is designed not to depend on RTTI; see <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__clang.llvm.org_docs_ControlFlowIntegrityDesign.html&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=BSqEv9KvKMW_Ob8SyngJ70KdZISM_ASROnREeq0cCxk&m=bVzzX-jFk5GJ_r6kpvBsRwxOpWfDBvZrkQB1QZW4OuA&s=R68M8YSOOw5ZsOiDLfviO-pWUTCdHCH5a_LXtSx3wV4&e=" target="_blank">http://clang.llvm.org/docs/ControlFlowIntegrityDesign.html</a> for details on how it works. However if diagnostics are enabled we will need RTTI, as that is the mechanism we use to get the name of the class that failed the check.<br>
<span class=""><br>
> I would think the diagnostic handler could gracefully degrade to not using the RTTI if it's unavailable.<br>
<br>
<br>
</span>Perhaps, but without a class name its usefulness is limited.</blockquote><div><br></div><div>A diagnostic saying that the CFI check had failed and printing out the problematic pointer value and a backtrace would still be preferable to the program mysteriously hitting a ud2, I think. There's no fundamental reason to require RTTI for diagnostics here. (IIRC, UBSan has other checks that will print the type name only if it's known.)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> As for the library dependence, I would think it's preferable to produce *some* kind of diagnostic by default on the way out rather than just silently terminating, unless there are security implications to doing so (are you worried about an attacker overwriting the sanitizer runtime's callback function?).<br>
<br>
<br>
</span>I believe that the default behavior ought to be that which is recommended for binaries shipped to end users. A diagnostic is no more actionable to a user than a crash, and even the function call to emit the diagnostic has a small file size cost. As for security implications, the runtime library (as with any code linked into the program) forms part of an attack surface which we should seek to minimize.<br>
<span class=""><br>
> If you think that we should trap silently by default, then I have no objection to adding a -fsanitize-trap= mechanism, and turning it on by default for CFI.<br>
<br>
<br>
</span>Sounds good then, I'll work on that approach.</blockquote><div><br></div><div>OK, thanks! </div></div></div></div>