linux-kernel - Re: Re: [PATCH 1/1] 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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Mon, 12 Dec 2016 14:44:40 +0100
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Vaneet narang <v.narang@...sung.com>
Cc:     Maninder Singh <maninder1.s@...sung.com>,
        Michal Marek <mmarek@...e.com>,
        Andrey Ryabinin <aryabinin@...tuozzo.com>,
        Alexander Potapenko <glider@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        LKML <linux-kernel@...r.kernel.org>,
        "open list:KERNEL BUILD + fi..." <linux-kbuild@...r.kernel.org>,
        kasan-dev <kasan-dev@...glegroups.com>,
        PANKAJ MISHRA <pankaj.m@...sung.com>,
        Ajeet Kumar Yadav <ajeet.y@...sung.com>
Subject: Re: Re: [PATCH 1/1] kasan: Support for r/w instrumentation control

On Mon, Dec 12, 2016 at 2:43 PM, Dmitry Vyukov <dvyukov@...gle.com> wrote:
>
> On Mon, Dec 12, 2016 at 12:12 PM, Vaneet Narang <v.narang@...sung.com> wrote:
>>
>> Hi,
>>
>> >>> Do you actually hit an issue with image size? In what context?
>> >>> Do you use inline/outline instrumentation? Does switching to the other
>> >>> option help?
>> >>
>> >> Memory access with KASAN enabled Image has overhead in terms of cpu execution.
>> >> Sometimes we are not able to reproduce race condition issues with these overhead in
>> >> place. So user should have control atleast over read instrumentation.
>> >
>> >Don't you want to disable KASAN entirely in such case?
>>
>> hmmm, but we need KASAN to detect corruption issues so overhead can be
>> reduced by switching OFF read instrumentation. Generally Reads are much more frequent
>> than writes as latest arm64 kernel has 224000 reads and 62300 writes
>> which is almost 3.5 times. So i think this control is required.
>>
>>
>> >>> Does it make sense to ever disable writes? I assume that you are
>> >>
>> >> Write instrumentation control is majorly kept to be inline with ASAN for user space
>> >> applications.
>> >> Also write is sometimes useful when uImage is already sanitized and some corruption
>> >> is done by kernel modules by doing some direct memory access then both read / write sanity of uImage
>> >> can be avoided.
>> >
>> >But then you don't need KASAN at all.
>>
>> KASAN support is required in this case to detect module issues.
>> KASAN provides asan_load / asan_store definition as these functions
>> are added by compiler in modules before every memory access.
>> These are the functions which will do address sanity and detect errors.
>

[resending as plain text]

Ah, OK, I see. So you want to e.g. not instrument kernel (for both
reads and writes), but instrument a single module. That makes sense.
Please extend the Usage section of KASAN docs:
https://kernel.org/doc/html/latest/dev-tools/kasan.html#usage
mention not instrumenting writes for whole kernel, and instrumenting a
single module.