linux-kernel - RE: Why is the kfree() argument const?

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.LFD.1.00.0801180754050.2957@woody.linux-foundation.org>
Date:	Fri, 18 Jan 2008 08:10:29 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	David Schwartz <davids@...master.com>
cc:	Johannes Weiner <hannes@...urebad.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	clameter@....com, penberg@...helsinki.fi
Subject: RE: Why is the kfree() argument const?

On Thu, 17 Jan 2008, David Schwartz wrote:
> 
> Nonsense. The 'kfree' function *destroys* the object pointer to by the
> pointer. How can you describe that as not doing anything to the object?

Here's an idea. Think it through. 

Why don't we need write permissions to a file to unlink it?

Here's a hint: because unlinking doesn't *write* to it. In fact, it 
doesn't read from it either. It doesn't do any access at all to that 
object, it just *removes* it.

Is the file gone after you unlink it? Yes (modulo refcounting for aliasing 
"pointers" aka filenames, but that's the same for any memory manager - 
malloc/free just doesn't have any, so you could think of it as a 
non-hardlinking filesystem).

So you're the one who are speaking nonsense. Making something "not exist" 
is not at all the same thing as accessing it for a write (or a read). It 
is a metadata operation that doesn't conceptually change the data in any 
way, shape or form - it just makes it go away.

And btw, exactly as with kfree(), a unlink() may well do something like 
"disk scrubbing" for security purposes, or cancel pending writes to the 
backing store. But even though it may write (or, by undoing a pending 
write, effectively "change the state") to the disk sectors that used to 
contain the file data, ONLY AN IDIOT would call it "writing to the file". 
Because "the file" is gone. Writing to the place where the file used to be 
is a different thing.

So give it up. You're wrong. Freeing a memory area is not "writing to it" 
or accessing it in *any* manner, it's an operation on another level 
entirely.

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