> UBSan with recovery disabled still emits diagnostics, and if we wanted CFI to > have the same behaviour it would introduce a dependency on RTTI and a runtime > library, both things we would like to avoid in CFI in order to reduce binary > size overhead.
I don't follow why the dependence on RTTI is linked to whether you emit diagnostics, can you explain? I would think the diagnostic handler could gracefully degrade to not using the RTTI if it's unavailable. 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?). A CFI failure could show up during testing due to "normal" lifetime bugs, uninitialized variables, and the like, not just due to an attack being thwarted, and in either case I think it'd be good to have *some* indication that the bad thing happened, even if we can only print it to stderr by default. But, ultimately, I'm happy leaving the choice with you. 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. 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
