On Thu, Sep 18, 2014 at 10:42 PM, Yury Gribov <y.gri...@samsung.com> wrote:
> On 09/18/2014 09:33 PM, Dmitry Vyukov wrote:
>>
>> What is the number of cases it will fix for kasan?
>
>
> Re-added kernel people again.
>
> AFAIR silly instrumentation that assumed all memory accesses in inline asm
> are must-accesses (instead of may-accesses) resulted in only one false
> positive. We haven't performed an extensive testing though.
>
>> It won't fix the memchr function because the size is indeed not known
>> statically. So it's a bad example.
>
>
> Sure, we will _not_ be able to instrument memchr. But being able to identify
> "safe" inline asms would allow us to instrument those (and my gut feeling is
> that they are a vast majority).
>
>> My impression was that kernel has relatively small amount of assembly,
>
>
> Well,
> $ grep -r '"[=+]\?[moVv<>]" *(' ~/src/linux-stable/ | wc -l
> 1133
>
> And also
> $ grep -r '"[=+]\?[moVv<>]" *(' ~/src/ffmpeg-2.2.2/ | wc -l
> 211
>
>> And the rest is just not interesting enough.
>
> Now that may be the case. But how do we know without trying?
Well, we can look at some instances at least before committing new code to gcc.
Here are results of your grep with removed "prefetch" and removed
archs except x86:
2 ./arch/x86/boot/bitops.h:
12 ./arch/x86/boot/boot.h:
1 ./arch/x86/boot/compressed/eboot.c:
1 ./arch/x86/boot/cpuflags.c:
3 ./arch/x86/boot/pm.c:
2 ./arch/x86/include/asm/apic.h:
8 ./arch/x86/include/asm/atomic.h:
8 ./arch/x86/include/asm/atomic64_64.h:
1 ./arch/x86/include/asm/bitops.h:
2 ./arch/x86/include/asm/bitops.h:#define
13 ./arch/x86/include/asm/cmpxchg.h:
3 ./arch/x86/include/asm/cmpxchg_32.h:
4 ./arch/x86/include/asm/desc.h:
3 ./arch/x86/include/asm/desc.h:#define
1 ./arch/x86/include/asm/edac.h:
20 ./arch/x86/include/asm/fpu-internal.h:
2 ./arch/x86/include/asm/futex.h:
1 ./arch/x86/include/asm/io.h:"m"
1 ./arch/x86/include/asm/io.h::"m"
26 ./arch/x86/include/asm/kexec.h:
9 ./arch/x86/include/asm/linkage.h:
5 ./arch/x86/include/asm/local.h:
2 ./arch/x86/include/asm/mutex_64.h:
38 ./arch/x86/include/asm/percpu.h:
8 ./arch/x86/include/asm/percpu.h:#define
1 ./arch/x86/include/asm/perf_event.h:
2 ./arch/x86/include/asm/rmwcc.h:
8 ./arch/x86/include/asm/rwsem.h:
3 ./arch/x86/include/asm/signal.h:
11 ./arch/x86/include/asm/special_insns.h:
2 ./arch/x86/include/asm/spinlock.h:
7 ./arch/x86/include/asm/switch_to.h:
6 ./arch/x86/include/asm/sync_bitops.h:
8 ./arch/x86/include/asm/uaccess.h:
1 ./arch/x86/include/asm/word-at-a-time.h:
18 ./arch/x86/include/asm/xor_avx.h:
3 ./arch/x86/include/asm/xsave.h:
2 ./arch/x86/kernel/cpu/bugs.c:
2 ./arch/x86/kernel/i387.c:
2 ./arch/x86/kernel/machine_kexec_64.c:
1 ./arch/x86/kernel/reboot.c:
1 ./arch/x86/kernel/vm86_32.c:
50 ./arch/x86/kvm/emulate.c:
3 ./arch/x86/kvm/vmx.c:
1 ./arch/x86/lib/csum-partial_64.c:
6 ./arch/x86/math-emu/fpu_trig.c:
1 ./arch/x86/mm/init_32.c:
2 ./arch/x86/pci/pcbios.c:
5 ./arch/x86/power/cpu.c:
1 ./drivers/char/hw_random/via-rng.c:
8 ./drivers/char/mwave/smapi.c:
2 ./drivers/hv/hv.c:
1 ./drivers/input/misc/wistron_btns.c:
1 ./drivers/lguest/x86/core.c:
1 ./drivers/pci/hotplug/cpqphp_nvram.c:
2 ./drivers/s390/block/dasd_diag.c:
8 ./drivers/s390/cio/ioasm.h:
2 ./drivers/s390/crypto/ap_bus.c:
2 ./drivers/scsi/ultrastor.c:
1 ./drivers/video/fbdev/platinumfb.c:
28 ./lib/raid6/avx2.c:
14 ./lib/raid6/mmx.c:
47 ./lib/raid6/recov_avx2.c:
49 ./lib/raid6/recov_ssse3.c:
15 ./lib/raid6/sse1.c:
28 ./lib/raid6/sse2.c:
1 ./lib/sha1.c:
2 ./net/iucv/iucv.c:
It seems that it is mostly synchronization primitives and raid6
driver. Boot and s390 drivers are probably not very interesting.
Synchronization primitives are definitely interesting for asan
(because of racy use-after-free's). The rest looks very mildly
interesting.
I do not see a very strong need for doing this for asan. There can be
other reasons, of course.
