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]

Date:	Tue, 2 Sep 2008 22:08:48 -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, John Reiser <jreiser@...Wagon.com>
Subject: Re: [uml-devel] [PATCH 5/6] slab: Annotate slab

On Sat, 30 Aug 2008, Pekka Enberg wrote:

> Hi Steve,
>
> On Sat, Aug 30, 2008 at 2:17 AM, Steve VanDeBogart
> <vandebo-lkml@...dbox.net> wrote:
>> Valgrind annotations for the slab allocator:  Malloc-like and free-like
>> for cache_alloc and free.  Telling Valgrind a region is free-like clears
>> all the valid bits, so slabs with constructors need different treatment;
>> tell Valgrind about slab objects when first constructed and free them
>> when the slab is destroyed.
>
> OK, I'm biased (I'm one of the kmemcheck developers) but these hooks
> to SLAB are too ugly to live with. My preferred solution is that you
> reuse the kmemcheck annotations
> kmemcheck_slab_alloc()/kmemcheck_slab_free() we have:
>
> http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-tip.git;a=commitdiff;h=30532cb3c49a2a9fed94127aab26003c52398a51

Thank you for pointing out the location of the kmemcheck code.  I looked
around briefly but didn't find the latest version.  It does seem that
kmemcheck and Valgrind annotations want to live in the same places so it
makes perfect sense to combine them where possible.  I'm not exactly sure
what you find so ugly about the Valgrind annotations, please elaborate.

>> @@ -3578,6 +3595,9 @@
>>  {
>>        struct array_cache *ac = cpu_cache_get(cachep);
>>
>> +       if (!cachep->ctor)
>> +               VALGRIND_FREELIKE_BLOCK(objp, 0);
>> +
>>        check_irq_off();
>>        objp = cache_free_debugcheck(cachep, objp,
>> __builtin_return_address(0));
>
> I'm not sure why you want to treat caches with constructor
> differently. Sure, the memory regions *are* initialized but from
> programmer's point of view you're not supposed to be touching the
> memory unless you got it from kmalloc() or kmem_cache_alloc(). Same
> goes for kfree() and kmem_cache_free() -- no touchy touchy after you
> pass a pointer to either of the functions (unless you're RCU, of
> course).

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).

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.

The best we can do without spending extra space or extra cycles it to
leave the memory accessible while it is free in a slab.

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