linux-kernel - Re: [uml-devel] [PATCH 5/6] slab: Annotate slab

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]

Message-ID: <alpine.DEB.1.00.0809030833050.15543@abydos.NerdBox.Net>
Date:	Wed, 3 Sep 2008 08:42:49 -0700 (PDT)
From:	Steve VanDeBogart <vandebo-lkml@...dBox.Net>
To:	Pekka Enberg <penberg@...helsinki.fi>
cc:	user-mode-linux-devel@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org,
	"Paul E. McKenney" <paulmck@...ibm.com>,
	Ingo Molnar <mingo@...e.hu>, dkegel@...gle.com,
	jiayingz@...gle.com
Subject: Re: [uml-devel] [PATCH 5/6] slab: Annotate slab

Hello Pekka,

On Wed, 3 Sep 2008, Pekka Enberg wrote:

> On Wed, Sep 3, 2008 at 8:08 AM, Steve VanDeBogart
> <vandebo-lkml@...dbox.net> wrote:
>> It is true that code above the allocator should not be touching free'd
>> slab objects.  However, it is also true that objects from slabs that
>> have a constructor should retain their per byte un/initialized state
>> through allocation and free cycles (just the semantic of slabs with
>> constructors AFAICT).
>
> Sorry for being unclear, sure, object should be marked as initialized
> when they're returned from kmem_cache_alloc(). However, what I
> disagree with is *where* you're marking them as initialized. Surely
> they're not semantically initialized when the slabs are allocated
> (although technically they are).

But which bits of a slab object should be marked as initialized at
kmem_cache_alloc() time?  We can't mark all of them as initialized
because the constructor may not initialize all of them (in fact, I've
programmatically confirmed that there are constructors that don't
initialize all the bytes of an object).  The only place to get the
information of interest is to mark all bytes uninitialized and then
run the constructor on the memory region.

>
> On Wed, Sep 3, 2008 at 8:08 AM, Steve VanDeBogart
> <vandebo-lkml@...dbox.net> wrote:
>> Ideally, we'd tell Valgrind that the bytes of a free'd slab object are
>> no longer accessible, but the initialized state should remain the same
>> until the object is made accessible again by the next allocation of
>> the object.  Unfortunately, the compression method for A & V bits in
>> Valgrind doesn't allow a region to be inaccessible and retain validness
>> bits.
>
> I don't see why you should mark them initialized all the time. Just
> mark them as uninitialized on kmem_cache_free() and again as
> initialized when they're about to be returned from kmem_cache_alloc()
> like we do in kmemcheck.

This question has the same answer as above.

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