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: <Pine.LNX.4.64.0902231429360.28573@blonde.anvils>
Date:	Mon, 23 Feb 2009 14:51:05 +0000 (GMT)
From:	Hugh Dickins <hugh@...itas.com>
To:	Nick Piggin <nickpiggin@...oo.com.au>
cc:	Pekka Enberg <penberg@...helsinki.fi>,
	Matt Mackall <mpm@...enic.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	David Vrabel <david.vrabel@....com>,
	Johannes Weiner <hannes@...xchg.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Chas Williams <chas@....nrl.navy.mil>,
	Evgeniy Polyakov <johnpol@....mipt.ru>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org,
	Christoph Lameter <cl@...ux-foundation.org>,
	Nick Piggin <npiggin@...e.de>
Subject: Re: [patch 1/7] slab: introduce kzfree()

On Tue, 24 Feb 2009, Nick Piggin wrote:
> 
> Well, the buffer is only non-modified in the case of one of the
> allocators (SLAB). All others overwrite some of the data region
> with their own metadata.
> 
> I think it is OK to use const, though. Because k(z)free has the
> knowledge that the data will not be touched by the caller any
> longer.

Sorry, you're not adding anything new to the thread here.

Yes, the caller is surrendering the buffer, so we can get
away with calling the argument const; and Linus argues that's
helpful in the case of kfree (to allow passing a const pointer
without having to cast it).

My contention is that kzfree(const void *ptr) is nonsensical
because it says please zero this buffer without modifying it.

But the change has gone in, I seem to be the only one still
bothered by it, and I've conceded that the "z" might stand
for zap rather than zero.

So it may be saying please hide the contents of this buffer,
rather than please zero it.  And then it can be argued that
the modification is an implementation detail which happens
(like other housekeeping internal to the sl?b allocator)
only after the original buffer has been freed.

Philosophy.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ