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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 12 Dec 2016 11:49:16 +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 11:29 AM, 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?


>> 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.


>> disabling reads, right?
>> Disabling both certainly does not make sense.