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
