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

Richard Smith richard at metafoo.co.uk
Tue Jun 9 19:33:10 PDT 2015

On Tue, Jun 9, 2015 at 7:30 PM, Peter Collingbourne <peter at pcc.me.uk> 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!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150609/65cc8340/attachment.html>

More information about the cfe-commits mailing list