Re: [patch 1/7] slab: introduce kzfree()

[Johannes Weiner]

On Thu, Feb 19, 2009 at 06:28:55PM +0000, Hugh Dickins wrote:
> On Thu, 19 Feb 2009, Matt Mackall wrote:
> > On Thu, 2009-02-19 at 16:34 +0000, Hugh Dickins wrote:
> > > On Thu, 19 Feb 2009, Pekka Enberg wrote:
> > > > On Thu, 2009-02-19 at 10:22 +0900, KOSAKI Motohiro wrote:
> > > > > 
> > > > > poisonig is transparent feature from caller.
> > > > > but the caller of kzfree() know to fill memory and it should know.
> > > > 
> > > > Debatable, sure, but doesn't seem like a big enough reason to make
> > > > kzfree() differ from kfree().
> > > 
> > > There may be more important things for us to worry about,
> > > but I do strongly agree with KOSAKI-san on this.
> > > 
> > > kzfree() already differs from kfree() by a "z": that "z" says please
> > > zero the buffer pointed to; "const" says it won't modify the buffer
> > > pointed to.  What sense does kzfree(const void *) make?  Why is
> > > keeping the declarations the same apart from the "z" desirable?
> > > 
> > > By all means refuse to add kzfree(), but please don't add it with const.
> > > 
> > > I can see that the "const" in kfree(const void *) is debatable
> > > [looks to see how userspace free() is defined: without a const],
> > > I can see that it might be nice to have some "goesaway" attribute
> > > for such pointers instead; but I don't see how you can argue for
> > > kzalloc(const void *).
>     ^^^^^^^^^^^^^^^^^^^^^
> (Of course I meant to say "kzfree(const void *)" there.)
> 
> > 
> > This is what Linus said last time this came up:
> > 
> > http://lkml.org/lkml/2008/1/16/227
> 
> Thanks for that, I remember it now.
> 
> Okay, that's some justification for kfree(const void *).
> 
> But I fail to see it as a justification for kzfree(const void *):
> if someone has "const char *string = kmalloc(size)" and then
> wants that string zeroed before it is freed, then I think it's
> quite right to cast out the const when calling kzfree().

You could argue that the pointer passed to kzfree() points to an
abstract slab object and kzfree() uses this to find the memory of that
object which it then zeroes.  The translation of course is a no-op as
the object pointer and the memory pointer coincide.

It depends on how transparent you want to make kzfree() for the
caller.  Is it 'zero out and then free the object' or is it 'free the
object, but note that it contains security-sensitive data, so make
sure that it never gets into the hands of somebody else'?

No strong opinion from me, though, I can not say which one feels
better.  I made it intuitively const, so I guess I would lean to the
more opaque version of the function.

> Hugh

	Hannes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/