linux-kernel - Re: [PATCH v2] kasan: Support for r/w instrumentation control

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CACT4Y+Z7zUW=0XEYsPFHTJUY5aFc-noBEcixNJGijj989JogMg@mail.gmail.com>
Date:   Fri, 16 Dec 2016 11:46:18 +0100
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Vaneet narang <v.narang@...sung.com>
Cc:     Andrey Ryabinin <aryabinin@...tuozzo.com>,
        Maninder Singh <maninder1.s@...sung.com>,
        Alexander Potapenko <glider@...gle.com>,
        Jonathan Corbet <corbet@....net>,
        Michal Marek <mmarek@...e.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        kasan-dev <kasan-dev@...glegroups.com>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        "open list:KERNEL BUILD + fi..." <linux-kbuild@...r.kernel.org>,
        PANKAJ MISHRA <pankaj.m@...sung.com>,
        Ajeet Kumar Yadav <ajeet.y@...sung.com>
Subject: Re: [PATCH v2] kasan: Support for r/w instrumentation control

On Fri, Dec 16, 2016 at 11:29 AM, Vaneet Narang <v.narang@...sung.com> wrote:
>
> Hi Andrey,
>
>
> There are times when requirement is only to find write issues so user should have flexibility to
> skip read instrumentation for better performance with KASAN enabled build to find realtime
> issues as well.
>
> >> crashes of false positives). CONFIG_KASAN_READS/WRITES is intended for
> >> situations when one wants to disable instrumentation wholesale.
> >>
> >
> >I'm talking about UBSAN_SANITIZE_ALL/KCOV_INSTRUMENT_ALL/GCOV_PROFILE_ALL
> >KASAN doesn't have something similar. I didn't add this because IMO it's not very useful for KASAN.
> >One may have a bug in instrumented code, but it can be easily missed if access is done in generic
> >code. Very simple example is passing invalid pointer in strcpy()
>
>
> Old toolchains already add asan hooks before strcpy, strcmp. Please check assembly generated
> for module with below code using gcc 4.9.
>
> static noinline void __init test_kasan_module(void) {
>         strcpy(test, "testing strcpy");
> }
>
> 0000000000001108 <test_kasan_module>:
>     1108:       a9bd7bfd        stp     x29, x30, [sp,#-48]!
>     110c:       d28001e1        mov     x1, #0xf                        // #15
>     1110:       910003fd        mov     x29, sp
>     1114:       a90153f3        stp     x19, x20, [sp,#16]
>     1118:       58000253        ldr     x19, 1160 <test_kasan_module+0x58>
>     111c:       f90013f5        str     x21, [sp,#32]
>     1120:       aa1303e0        mov     x0, x19
>     1124:       94000000        bl      0 <__asan_loadN>              // Instrumented Read of size 15
>     1128:       58000215        ldr     x21, 1168 <test_kasan_module+0x60>
>     112c:       d28001e1        mov     x1, #0xf                        // #15
>     1130:       910042b4        add     x20, x21, #0x10
>     1134:       aa1403e0        mov     x0, x20
>     1138:       94000000        bl      0 <__asan_storeN>          // Instrumented Write of size 15
>     113c:       f9400260        ldr     x0, [x19]
>     1140:       f9000aa0        str     x0, [x21,#16]
>     1144:       f8407260        ldr     x0, [x19,#7]
>     1148:       f80172a0        str     x0, [x21,#23]
>     114c:       a94153f3        ldp     x19, x20, [sp,#16]
>
>
>
> Similar behaviour for strcmp, memset, memcpy ... but  with latest compiler 6.2,
> this implementation is removed from compiler in this case we can define wrappers
> in kasan.c for these function like we are already doing for memcpy, memmove, memset
>
>


One option would be to simply compile kernel as:
$ make CC="gcc --param asan-instrument-reads=0"