linux-kernel - Re: [PATCH v6 00/11] Kernel address sanitizer

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]

Message-Id: <20141118125843.434c216540def495d50f3a45@linux-foundation.org>
Date:	Tue, 18 Nov 2014 12:58:43 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Andrey Ryabinin <a.ryabinin@...sung.com>
Cc:	Dmitry Vyukov <dvyukov@...gle.com>,
	Konstantin Serebryany <kcc@...gle.com>,
	Dmitry Chernenkov <dmitryc@...gle.com>,
	Andrey Konovalov <adech.fo@...il.com>,
	Yuri Gribov <tetra2005@...il.com>,
	Konstantin Khlebnikov <koct9i@...il.com>,
	Sasha Levin <sasha.levin@...cle.com>,
	Michal Marek <mmarek@...e.cz>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	Christoph Lameter <cl@...ux.com>,
	Pekka Enberg <penberg@...nel.org>,
	David Rientjes <rientjes@...gle.com>,
	Joonsoo Kim <iamjoonsoo.kim@....com>,
	Dave Hansen <dave.hansen@...el.com>,
	Andi Kleen <andi@...stfloor.org>,
	Vegard Nossum <vegard.nossum@...il.com>,
	"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
	linux-mm@...ck.org, Randy Dunlap <rdunlap@...radead.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Dave Jones <davej@...hat.com>,
	Jonathan Corbet <corbet@....net>,
	Joe Perches <joe@...ches.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 00/11] Kernel address sanitizer - runtime memory
 debugger.

On Tue, 11 Nov 2014 10:21:42 +0300 Andrey Ryabinin <a.ryabinin@...sung.com> wrote:

> Hi Andrew,
> 
> Now we have stable GCC(4.9.2) which supports kasan and from my point of view patchset is ready for merging.
> I could have sent v7 (it's just rebased v6), but I see no point in doing that and bothering people,
> unless you are ready to take it.

It's a huge pile of tricky code we'll need to maintain.  To justify its
inclusion I think we need to be confident that kasan will find a
significant number of significant bugs that
kmemcheck/debug_pagealloc/slub_debug failed to detect.

How do we get that confidence?  I've seen a small number of
minorish-looking kasan-detected bug reports go past, maybe six or so. 
That's in a 20-year-old code base, so one new minor bug discovered per
three years?  Not worth it!

Presumably more bugs will be exposed as more people use kasan on
different kernel configs, but will their number and seriousness justify
the maintenance effort?

If kasan will permit us to remove kmemcheck/debug_pagealloc/slub_debug
then that tips the balance a little.  What's the feasibility of that?


Sorry to play the hardass here, but someone has to ;)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/