Re: Auxiliary header and macros for sanitizers in userland programs

[Valery Ushakov <uwe%stderr.spb.ru@localhost>]

On Wed, Jun 06, 2018 at 09:09:17 +0200, Kamil Rytarowski wrote:

> >>> So the issue is that libc is compiled without sanitizer and
> >>> allocations done inside libc are not known to a sanitizer?  For libc
> >>> functions that return allocated memory I guess you mark it in the
> >>> sanitizer's interposed wrapper ("interceptor"?), but in the case of
> >>> callbacks there is no interceptor between libc and the callback to do
> >>> that.  Is that about right?
> >>
> > [...]
> >> but in general the sanitizers have no
> >> information what happens inside libc, treating it as a blackbox.
> >>
> > [...]
> >>
> >> Interceptos mostly have rules of type PreRead/PostRead and
> >> PreWrite/PostWrite arguments passed to functions in libc (pthread, ..).
> >> In the MSan case during PreWrite there is a check whether arguments
> >> passed to a function are properly initialized, and in PostRead phase
> >> mark the buffers as initialized.
> >>
> >> In the fts_open(3) case there is no stage between the time of being
> >> aware about initialzed (not just allocated) FTSENT buffers and executing
> >> callback function that already needs this information. In this case,
> >> there is need to help to Memory Sanitizer with explicit __msan_unpoison().
> > 
> > It sounds like sanitizers must use run-time generated closures or
> > compile-time generated auxiliary functions to wrap libc callbacks.
> > I.e. when code calls fts_open(..., compare); the sanitizer must
> > generate code to call fts_open(..., sanitize_compare); where
> > sanitize_compare does the pre/post checks around a call to the real
> > compare.
> 
> Generating runtime wrapper code for compare isn't that simple, and doing
> it in a portable across CPUs in C/asm is difficult (if possible).

It doesn't have to be run-time.  Since sanitizer is part of the
compiler, it can generate a new instance for every callback.

It's like they are not even trying...

-uwe