> 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. > 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. http://reviews.llvm.org/D10268 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
