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: <200801181114.33513.vlobanov@speakeasy.net>
Date:	Fri, 18 Jan 2008 11:14:33 -0800
From:	Vadim Lobanov <vlobanov@...akeasy.net>
To:	Andy Lutomirski <luto@...ealbox.com>
Cc:	linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	David Schwartz <davids@...master.com>,
	Johannes Weiner <hannes@...urebad.de>, clameter@....com,
	penberg@...helsinki.fi
Subject: Re: Why is the kfree() argument const?

On Friday 18 January 2008 05:54:12 am Andy Lutomirski wrote:
> It almost sounds like the compiler is free to change:
>
> void foo(const int *x);
> foo(x);
> printf("%d", x);
>
> to:
>
> void foo(const int *x);
> printf("%d", x);
> foo(x);
>
> especially if it can prove that the pointer to x doesn't otherwise
> escape or that foo doesn't call anything that could see the pointer (and
> given that gcc has special magical markings for malloc, one way this
> could be "proven" is to have x be some freshly malloced object.

That's absolutely not true.

Let's unravel the code, by fixing usage of 'x' (which seems to vary at will 
between value and pointer in the above example), and by replacing printf with 
another opaque function. Our decls:
	void foo(const int *ptr);
	void bar(int val);
You're saying that this:
	foo(&x);
	bar(x);
can be reordered into this:
	bar(x);
	foo(&x);

No way. First, the way that const is currently defined, the compiler cannot 
assume that the value of x did not change while foo was executing. So, it 
will not only be forced to leave the two functions in that order, it will 
even reload the value of x before passing it into bar. Go figure.

Second, even if const did have stronger semantics that forbade the value of x 
from being modified during execution of foo, the compiler still could not 
reorder the two function calls, before it cannot assume that the two 
functions (in their internal implementations) do not touch some other, 
unknown to this code, global variable.

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