linux-kernel - Re: [PATCH v3 09/13] mm: slub: add kernel address sanitizer support for slub allocator

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]

Date:	Fri, 26 Sep 2014 09:22:54 -0500 (CDT)
From:	Christoph Lameter <cl@...ux.com>
To:	Dmitry Vyukov <dvyukov@...gle.com>
cc:	Andrey Ryabinin <a.ryabinin@...sung.com>,
	LKML <linux-kernel@...r.kernel.org>,
	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>,
	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>, Dave Jones <davej@...hat.com>,
	x86@...nel.org, linux-mm@...ck.org,
	Pekka Enberg <penberg@...nel.org>,
	David Rientjes <rientjes@...gle.com>
Subject: Re: [PATCH v3 09/13] mm: slub: add kernel address sanitizer support
 for slub allocator

On Thu, 25 Sep 2014, Dmitry Vyukov wrote:

> > +       depends on SLUB_DEBUG
>
>
> What does SLUB_DEBUG do? I think that generally we don't want any
> other *heavy* debug checks to be required for kasan.

SLUB_DEBUG includes the capabilties for debugging. It does not switch
debug on by default. SLUB_DEBUG_ON will results in a kernel that boots
with active debugging. Without SLUB_DEBUG_ON a kernel parameter activates
debugging.

> > +{
> > +       unsigned long size = cache->size;
> > +       unsigned long rounded_up_size = round_up(size, KASAN_SHADOW_SCALE_SIZE);
> > +
>
> Add a comment saying that SLAB_DESTROY_BY_RCU objects can be "legally"
> used after free.

Add "within the rcu period"

> >  static struct page *new_slab(struct kmem_cache *s, gfp_t flags, int node)
> > @@ -1416,8 +1426,10 @@ static struct page *new_slab(struct kmem_cache *s, gfp_t flags, int node)
> >                 setup_object(s, page, p);
> >                 if (likely(idx < page->objects))
> >                         set_freepointer(s, p, p + s->size);
>
> Sorry, I don't fully follow this code, so I will just ask some questions.
> Can we have some slab padding after last object in this case as well?

This is the free case. If poisoing is enabled then the object will be
overwritten on free. Padding is used depending on the need to align the
object and is optional. Redzoning will occur if requested. Are you asking
for redzoning?

> kasan_mark_slab_padding poisons only up to end of the page. Can there
> be multiple pages that we need to poison?

If there is a higher order page then only the end portion needs to be
poisoned. Objects may straddle order 0 boundaries then.

--
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/