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

Date:   Mon, 12 Dec 2016 11:12:05 +0000
From:   Vaneet Narang <v.narang@...sung.com>
To:     Dmitry Vyukov <dvyukov@...gle.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

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. 

Regards,
Vaneet Narang