On Thu, Sep 17, 2020 at 11:35:40AM +0000, George Popescu wrote: > On Thu, Sep 17, 2020 at 08:37:07AM +0200, Marco Elver wrote: > > So, it seems that local-bounds can still catch some rare OOB accesses, > > where KASAN fails to catch it because the access might skip over the > > redzone. > > > > The other more interesting bit of history is that > > -fsanitize=local-bounds used to be -fbounds-checking, and meant for > > production use as a hardening feature: > > http://lists.llvm.org/pipermail/llvm-dev/2012-May/049972.html > > > > And local-bounds just does not behave like any other sanitizer as a > > result, it just traps. The fact that it's enabled via > > -fsanitize=local-bounds (or just bounds) but hasn't much changed in > > behaviour is a little unfortunate. > > > I suppose there are 3 options: > > > > 1. George implements trap handling somehow. Is this feasible? If not, > > why not? Maybe that should also have been explained in the commit > > message. > > > > 2. Only enable -fsanitize=local-bounds if UBSAN_TRAP was selected, at > > least for as long as Clang traps for local-bounds. I think this makes > > sense either way, because if we do not expect UBSAN to trap, it really > > should not trap! > > > > 3. Change the compiler. As always, this will take a while to implement > > and then to reach whoever should have that updated compiler. > > > > Preferences? > Considering of what you said above, I find option 2 the most elegant. > The first one doesn't sound doable for the moment, also the third. > I will edit this patch considering your comments and resend it to the > list. I have a slightly different suggestion that is very nearly #2 above: split local-bounds into a separate CONFIG that requires UBSAN_TRAP, and then carefully document both: - what does it catch that "bounds" doesn't - why it only operates in trap mode The rationale I have is that I don't like the coverage of some mitigation or detection to "silently" vary between builds. e.g. someone would build with/without UBSAN_TRAP and end up with unexpectedly different coverage. I'd rather there be a separate CONFIG that appears. -- Kees Cook
