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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACT4Y+YmZ_G6B4mAx0+K-chcDpNzVtR9mA=b5vam0tXD02-CQA@mail.gmail.com>
Date:	Fri, 26 Sep 2014 08:55:55 -0700
From:	Dmitry Vyukov <dvyukov@...gle.com>
To:	Christoph Lameter <cl@...ux.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 Fri, Sep 26, 2014 at 7:22 AM, Christoph Lameter <cl@...ux.com> wrote:
> 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.

Ack
thanks for explanation


>> > +{
>> > +       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?

I am not asking for redzoning yet.


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