[PATCH] Implement diagnostic mode for -fsanitize=cfi*, -fsanitize=cfi-diag.

Peter Collingbourne peter at pcc.me.uk
Tue Jun 9 19:30:04 PDT 2015


> 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/






More information about the cfe-commits mailing list