linux-kernel - Re: SLUB: Return ZERO_SIZE

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:	Mon, 4 Jun 2007 18:20:25 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Pekka Enberg <penberg@...helsinki.fi>,
	Christoph Lameter <clameter@....com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, jeremy@...p.org
Subject: Re: SLUB: Return ZERO_SIZE_PTR for kmalloc(0)

> The thing is, why *should* we care about comparing addresses? We'll give 

Because people use it to tell objects apart. All over the kernel we do
things like

	if (inode1 == inode2)

to figure out if they are the same inode. Now inodes are not zero sized
so we are safe there

> the right result (you got many perfectly separate allocations, they're 
> just zero bytes apart, exactly like you asked for!). The fact that C++ has 
> some semantics for it is not a good argument 

Its the usual semantic in languages that use a pointer as an object
handle. C is actually the oddity here, the other languages use it to
avoid aliasing of object handles and the resulting confusion.

Clearly we do need an option to make the kernel explode when misusing
such pointers for debugging whatever the default for other behaviour is.
And on a 64bit box we probably have enough address space to hand out a
few million unique faulting pointers.
-
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/