Handle assembly in sanitizer tools

[ramosian-glider]

Originally reported on Google Code with ID 192

Sanitizer tools need to handle assembly (inline and not). For ASan and TSan that will
improve tool coverage, for MSan - help avoid false positives.

ATM it seems like the best chance to do that is through some kind of MC pass in LLVM.
AFAIK, those things (MC passes) do not exist yet. Making that happen would require
significant infrastructure work.

Reported by eugenis@google.com on 2013-06-06 07:59:40

[ramosian-glider]

Can we reason about some side effects of inline assembly pieces by looking at their
constraints?

Reported by ramosian.glider on 2013-06-06 09:00:17

[ramosian-glider]

More or less. But this does not apply to .S assembly.

We already understand constraints line "r" or "q", but if there is a pointer to memory
the best we can do in MSan is unpoison the entire allocator chunk it points to. The
latter is not implemented yet, and it will not work for .S assembly anyway.

Reported by eugenis@google.com on 2013-06-06 09:02:48

[ramosian-glider]

Issue 290 has been merged into this issue.

Reported by konstantin.s.serebryany on 2014-05-07 08:58:57

[ramosian-glider]

BTW wouldn't it make more sense to decompile .S into LLVM and then sanitize result?

Reported by tetra2005 on 2014-05-07 17:31:18

[ramosian-glider]

By handling inline assembly, we get .S for free - they all go through the same AsmParser.
.S -> .ll decompilation would be a very nice thing to have, but it sounds like a very
complex task and I'm not aware of any reasonably good implementations. It would make
even more sense to apply it to .o (to handle yasm/nasm/fortran/whatever-else-generated
objects) and maybe even to .so (to handle system libraries, binary OpenGL blobs, etc).

.so adds yet another level of complexity.

Reported by eugenis@google.com on 2014-05-08 07:39:20

[ramosian-glider]

> By handling inline assembly, we get .S for free -
> they all go through the same AsmParser.

I disagree here - dependencies and memory sizes in inline asm are explicit in asm constraints
whereas in AsmParser you'll have to somehow devise them yourself.

> it sounds like a very complex task

Well, not much more complex as analyzing assembly and tracking data/control dependencies
in AsmParser...

Reported by tetra2005 on 2014-05-08 09:01:18

[ramosian-glider]

Asm constraints are not enough. We want to capture arbitrary memory accesses in asm
(i.e. "memory" in the clobber list).

Reported by eugenis@google.com on 2014-05-08 09:11:54

[ramosian-glider]

> We want to capture arbitrary memory accesses in asm
> (i.e. "memory" in the clobber list).

Interesting. Do you have some publicly available use-case?

Reported by tetra2005 on 2014-05-08 12:20:40

[ramosian-glider]

Sure, /usr/include/bits/select.h:

# define __FD_ZERO(fdsp) \
  do {                                                                        \
    int __d0, __d1;                                                           \
    __asm__ __volatile__ ("cld; rep; " __FD_ZERO_STOS                         \
                          : "=c" (__d0), "=D" (__d1)                          \
                          : "a" (0), "0" (sizeof (fd_set)                     \
                                          / sizeof (__fd_mask)),              \
                            "1" (&__FDS_BITS (fdsp)[0])                       \
                          : "memory");                                        \
  } while (0)

This is causing false positives in MSan.

Reported by eugenis@google.com on 2014-05-08 12:25:42

[ramosian-glider]

Reported by ramosian.glider on 2015-07-30 09:05:31

• Labels added: ProjectAddressSanitizer