[PATCH] Implement diagnostic mode for -fsanitize=cfi*, -fsanitize=cfi-diag.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-commits