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
| ||
|
Message-id: <53C53B77.3080000@samsung.com> Date: Tue, 15 Jul 2014 18:32:23 +0400 From: Andrey Ryabinin <a.ryabinin@...sung.com> To: Christoph Lameter <cl@...two.org>, Andrey Ryabinin <ryabinin.a.a@...il.com> Cc: "H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org, Dmitry Vyukov <dvyukov@...gle.com>, Konstantin Serebryany <kcc@...gle.com>, Alexey Preobrazhensky <preobr@...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>, Russell King <linux@....linux.org.uk>, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Pekka Enberg <penberg@...nel.org>, David Rientjes <rientjes@...gle.com>, Joonsoo Kim <iamjoonsoo.kim@....com>, Andrew Morton <akpm@...ux-foundation.org>, linux-kbuild@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, x86@...nel.org, linux-mm@...ck.org Subject: Re: [RFC/PATCH -next 00/21] Address sanitizer for kernel (kasan) - dynamic memory error detector. On 07/14/14 19:13, Christoph Lameter wrote: > On Sun, 13 Jul 2014, Andrey Ryabinin wrote: > >>> How does that work when memory is sparsely populated? >>> >> >> Sparsemem configurations currently may not work with kasan. >> I suppose I will have to move shadow area to vmalloc address space and >> make it (shadow) sparse too if needed. > > Well it seems to work with sparsemem / vmemmap? So non vmmemmapped configs > of sparsemem only. vmemmmap can also handle holes in memory. > > Not sure. This sparsemem/vmemmap thing is kinda new to me, so I need to dig some more to understand how it iтteracts with kasan. As far as I understand the main problem with sparsemem & kasan is shadow allocation: unsigned long lowmem_size = (unsigned long)high_memory - PAGE_OFFSET; shadow_size = lowmem_size >> KASAN_SHADOW_SCALE_SHIFT; shadow_phys_start = memblock_alloc(shadow_size, PAGE_SIZE); If we don't have one big enough physically contiguous block for shadow it will fail. -- 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