On Thu, Sep 18, 2014 at 4:09 AM, Yury Gribov <y.gri...@samsung.com> wrote:
> Hi all,
>
> Current semantics of memory constraints in GCC inline asm (i.e. "m", "v",
> etc.) is somewhat loosy in that it tells GCC that asm code _may_ access
> given amount of bytes but is not guaranteed to do so. This is (ab)used by
> e.g. glibc (and also some pieces of kernel):
> __STRING_INLINE void *
> __rawmemchr (const void *__s, int __c)
> {
> ...
> __asm__ __volatile__
> ("cld\n\t"
> "repne; scasb\n\t"
> ...
> "m" ( *(struct { char __x[0xfffffff]; } *)__s)
>
> Imprecise size specification prevents code analysis tools from understanding
> semantics of inline asm (without parsing inline asm instructions which e.g.
> Asan in Clang tries to do). In particular we can't automatically instrument
> inline asm in kernel with Kasan because we can not determine exact access
> size (see e.g. discussion in
> https://gcc.gnu.org/ml/gcc-patches/2014-05/msg02530.html).
>
> Would it make sense to add another constraint modifier (like "=", "&", etc.)
> that would tell compiler/tool that memory access in asm is _guaranteed_ to
> have the specified size?
Hi,
What is the number of cases it will fix for kasan?
It won't fix the memchr function because the size is indeed not known
statically. So it's a bad example.
My impression was that kernel has relatively small amount of assembly,
out of which:
1. memchr/strcpy need special handling anyway.
2. putuser/getuser must not be instrumented.
3. atomic operations need special handling for ktsan, so kasan can
just reuse the same manual instrumentation.
And the rest is just not interesting enough. Am I missing something?
