Re: Address Sanitizer local root

[Daniel Micay <danielmicay () gmail com>]

> As long as the aborts/faults happen at the earliest point where the
> wrong program behavior can be detected, I see no way they are "more
> painful to debug" than having ASan or similar introspectively print
> crash info. Attaching a debugger should get you equally useful
> information.

The aborts and faults tend to happen later than the ASan detection would
kick in though, other than the double-free case. For example, writes to
freed memory only get detected when the junk data is validated later on
(i.e. when an allocation is flushed from the FIFO quarantine), and it
can be quite hard to debug from there. Use of freed memory often crashes
right away with junk filling (pointer accesses) but it can end up
causing subtler issues or crashes far away from the source.

It's much easier to find the bugs than it would be without this, but if
your goal is implementing hardening features, it's not very fun to need
hundreds of fixes for use-after-frees across common software. It makes
sense to go at it with ASan or Valgrind first to clear out the obvious
problems and then worry about exploit mitigations. A surprising amount
of software has all kinds of memory corruption in the *common* code
paths.

Attachment: signature.asc
Description: This is a digitally signed message part