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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 15 Sep 2014 19:28:14 +0400 From: Andrey Ryabinin <a.ryabinin@...sung.com> To: Randy Dunlap <rdunlap@...radead.org>, linux-kernel@...r.kernel.org 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>, Christoph Lameter <cl@...ux.com>, Joonsoo Kim <iamjoonsoo.kim@....com>, Andrew Morton <akpm@...ux-foundation.org>, 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, Michal Marek <mmarek@...e.cz>, Ingo Molnar <mingo@...hat.com>, Peter Zijlstra <peterz@...radead.org> Subject: Re: [RFC/PATCH v2 01/10] Add kernel address sanitizer infrastructure. On 09/14/2014 05:35 AM, Randy Dunlap wrote: > Following sentence is confusing. I'm not sure how to fix it. > Perhaps rephrase is like this: Do not use slub poisoning with KASan if user tracking enabled (iow slub_debug=PU). User tracking info (allocation/free stacktraces) are stored inside slub object's metadata. Slub poisoning overwrites slub object and it's metadata with poison value on freeing. So if KASan will detect use after free, allocation/free stacktraces will be overwritten and KASan won't be able to print them. >> +Please don't use slab poisoning with KASan (slub_debug=P), beacuse if KASan will > > drop: will > >> +detects use after free allocation and free stacktraces will be overwritten by > > maybe: use after free, > >> +poison bytes, and KASan won't be able to print this backtraces. > > backtrace. > >> + >> +Each shadow byte corresponds to 8 bytes of the main memory. We use the >> +following encoding for each shadow byte: 0 means that all 8 bytes of the >> +corresponding memory region are addressable; k (1 <= k <= 7) means that >> +the first k bytes are addressable, and other (8 - k) bytes are not; >> +any negative value indicates that the entire 8-byte word is unaddressable. >> +We use different negative values to distinguish between different kinds of >> +unaddressable memory (redzones, freed memory) (see mm/kasan/kasan.h). >> + > > Is there any need for something similar to k (1 <= k <= 7) but meaning that the > *last* k bytes are addressable instead of the first k bytes? > There is no need for that. Slub allocations are always 8 byte aligned (at least on 64bit systems). Now I realized that it could be a problem for 32bit systems. Anyway, the best way to deal with that would be align allocation to 8 bytes. >> +Poisoning or unpoisoning a byte in the main memory means writing some special >> +value into the corresponding shadow memory. This value indicates whether the >> +byte is addressable or not. >> + > -- 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