On Tue, Jun 9, 2015 at 7:30 PM, Peter Collingbourne <[email protected]> wrote:
> > I don't follow why the dependence on RTTI is linked to whether you emit > diagnostics, can you explain? > > > The CFI mechanism is designed not to depend on RTTI; see > http://clang.llvm.org/docs/ControlFlowIntegrityDesign.html 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. > > > I would think the diagnostic handler could gracefully degrade to not > using the RTTI if it's unavailable. > > > Perhaps, but without a class name its usefulness is limited. 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.) > 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?). > > > 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. > > > 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. > > > Sounds good then, I'll work on that approach. OK, thanks!
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
