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
| ||
|
Date: Wed, 14 Jun 2017 09:12:03 +0900 From: Joonsoo Kim <js1304@...il.com> To: Andrey Ryabinin <aryabinin@...tuozzo.com> Cc: Dmitry Vyukov <dvyukov@...gle.com>, 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 Tue, Jun 13, 2017 at 07:49:47PM +0300, Andrey Ryabinin wrote: > 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. I understand your decision. Thanks for looking this. Thanks.
Powered by blists - more mailing lists