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: Thu, 20 Nov 2014 15:35:22 +0300 From: Andrey Ryabinin <a.ryabinin@...sung.com> To: Ingo Molnar <mingo@...nel.org> Cc: Andrey Ryabinin <ryabinin.a.a@...il.com>, Andrew Morton <akpm@...ux-foundation.org>, 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" <x86@...nel.org>, "linux-mm@...ck.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>, LKML <linux-kernel@...r.kernel.org>, Linus Torvalds <torvalds@...ux-foundation.org> Subject: Re: [PATCH v6 00/11] Kernel address sanitizer - runtime memory debugger. On 11/20/2014 12:03 PM, Ingo Molnar wrote: > > * Andrey Ryabinin <ryabinin.a.a@...il.com> wrote: > >> I've counted 16: >> >> aab515d (fib_trie: remove potential out of bound access) >> 984f173 ([SCSI] sd: Fix potential out-of-bounds access) >> 5e9ae2e (aio: fix use-after-free in aio_migratepage) >> 2811eba (ipv6: udp packets following an UFO enqueued packet need also >> be handled by UFO) >> 057db84 (tracing: Fix potential out-of-bounds in trace_get_user()) >> 9709674 (ipv4: fix a race in ip4_datagram_release_cb()) >> 4e8d213 (ext4: fix use-after-free in ext4_mb_new_blocks) >> 624483f (mm: rmap: fix use-after-free in __put_anon_vma) >> 93b7aca (lib/idr.c: fix out-of-bounds pointer dereference) >> b4903d6 (mm: debugfs: move rounddown_pow_of_two() out from do_fault path) >> 40eea80 (net: sendmsg: fix NULL pointer dereference) >> 10ec947 (ipv4: fix buffer overflow in ip_options_compile()) >> dbf20cb2 (f2fs: avoid use invalid mapping of node_inode when evict meta inode) >> d6d86c0 (mm/balloon_compaction: redesign ballooned pages management) >> >> + 2 recently found, seems minor: >> http://lkml.kernel.org/r/1415372020-1871-1-git-send-email-a.ryabinin@samsung.com >> (sched/numa: Fix out of bounds read in sched_init_numa()) >> >> http://lkml.kernel.org/r/1415458085-12485-1-git-send-email-ryabinin.a.a@gmail.com >> (security: smack: fix out-of-bounds access in smk_parse_smack()) >> >> Note that some functionality is not yet implemented in this >> patch set. Kasan has possibility to detect out-of-bounds >> accesses on global/stack variables. Neither >> kmemcheck/debug_pagealloc or slub_debug could do that. >> >>> 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? >>> >> >> Yes, AFAIK there are only few users of kasan now, and I guess that >> only small part of kernel code >> was covered by it. >> IMO kasan shouldn't take a lot maintenance efforts, most part of code >> is isolated and it doesn't >> have some complex dependencies on in-kernel API. >> And you could always just poke me, I'd be happy to sort out any issues. >> >>> 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? >>> >> >> I think kasan could replace kmemcheck at some point. > > So that angle sounds interesting, because kmemcheck is > essentially unmaintained right now: in the last 3 years since > v3.0 arch/x86/mm/kmemcheck/ has not seen a single kmemcheck > specific change, only 4 incidental changes. > > kmemcheck is also very architecture bound and somewhat fragile > due to having to decode instructions, so if generic, compiler > driven instrumentation can replace it, that would be a plus. > GCC already supports address sanitizer on x86_32/x86_64/arm/arm64/rs6000, and adding compiler's support for any other architecture is trivial. Per-arch work on kernel-side maybe is not trivial, but there is nothing complex either. It's much more simpler then kmemcheck. -- 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/
Powered by blists - more mailing lists