linux-kernel - Re: [PATCH v1 00/11] mm/kasan: support per-page shadow memory to reduce memory consumption

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:   Tue, 13 Jun 2017 19:49:47 +0300
From:   Andrey Ryabinin <aryabinin@...tuozzo.com>
To:     Joonsoo Kim <js1304@...il.com>, Dmitry Vyukov <dvyukov@...gle.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Alexander Potapenko <glider@...gle.com>,
        kasan-dev <kasan-dev@...glegroups.com>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H . Peter Anvin" <hpa@...or.com>, kernel-team@....com
Subject: Re: [PATCH v1 00/11] mm/kasan: support per-page shadow memory to
 reduce memory consumption

On 06/08/2017 05:40 AM, Joonsoo Kim wrote:
>>>
>>> I don't understand why we trying to invent some hacky/complex schemes when we already have
>>> a simple one - scaling shadow to 1/32. It's easy to implement and should be more performant comparing
>>> to suggested schemes.
>>
>>
>> If 32-bits work with the current approach, then I would also prefer to
>> keep things simpler.
>> FWIW clang supports settings shadow scale via a command line flag
>> (-asan-mapping-scale).
> 
> Hello,
> 
> To confirm the final consensus, I did a quick comparison of scaling
> approach and mine. Note that scaling approach can be co-exist with
> mine. And, there is an assumption that we can disable quarantine and
> other optional feature of KASAN.
> 
> Scaling vs Mine
> 
> Memory usage: 1/32 of total memory. vs can be far less than 1/32.
> Slab object layout: should be changed. vs none.
> Usability: hard. vs simple. (Updating compiler is not required)
> Implementation complexity: simple. vs complex.
> Porting to other ARCH: simple. vs hard (But, not mandatory)


My main concern is a huge amount of complex and fragile code that comes with this patchset.
Basically you are building a completely new algorithm on the fundamentals that were designed
for the current algorithm. Hence you have to do these hacks with black shadow, tlb flushing, etc.

Yes, it does consume less memory, but I'm not convinced that such aggressive memory saving
are mandatory. I guess that for the most of the users (if not all) that currently unsatisfied with 1/8 shadow
1/32 will be good enough.
FWIW I did run sanitized kernel (1/8 shadow) on the smart TVs with 1Gb of ram.

> So, do both you disagree to merge my per-page shadow? If so, I will
> not submit v2. Please let me know your decision.
> 

Sorry, but it's a nack from me.

> Thanks.
>