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] [day] [month] [year] [list]

Date:	Fri, 18 Jan 2008 16:20:43 +0100
From:	"Giacomo A. Catenazzi" <cate@...eee.net>
To:	ecolbus@...la.fr
CC:	linux-kernel@...r.kernel.org
Subject: Re: Why is the kfree() argument const?

ecolbus@...la.fr wrote:
> Giacomo Catenazzi wrote:
> 
>> const No writes through this lvalue. In the absence of this qualifier, writes may occur
>> through this lvalue.
>>
>> volatile No cacheing through this lvalue: each operation in the abstract semantics must
>> be performed (that is, no cacheing assumptions may be made, since the location
>> is not guaranteed to contain any previous value). In the absence of this qualifier,
>> the contents of the designated location may be assumed to be unchanged except
>> for possible aliasing.
> 
> Well, I'm still wondering if there is not something dangerous or weird about
> declaring the argument of kfree() to be const... 

It should be only cosmetic thing (and few warnings in some
not yet identified cases).

> Since the content of the referenced object is unlikely to be declared volatile, the
> compiler should be allowed to assume that its content was not changed, except
> for possible aliasing. But what happens if the compiler can also prove there is 
> no aliasing? In that case, he should be allowed to assume that the content
> pointed to was not modified at all, right?

I doesn't follow it. Anyway C has the "as-if" rule, which it mean:
the compiler could optimize as far the result doesn't change
(time are not issues, and result could change if a valid compiler
could give the same results).  So a very smart compiler (which
should compile all units at the same time) could do good things
without need of explicit register, static (with some exceptions),
const, volatile (if it very smart it know about system, signals,
and it can set "volatile" on need), restrict, ...

> Fortunately, kmalloc is not declared with attribute malloc in the kernel,
> so there should be no problem, but if it were (and, actually, I've not found
> why it wasn't), the compiler would be able to tell that *s1 *cannot* 
> be aliased, and therefore decide to move val = s1->i *after* having
> called kfree(). In that case, we would clearly have a bug...

IIRC kmalloc(0) return an alias (but not so relevant in this
discussion).

Hmm. C is used not to do much optimization. One thing to remember
is that function could have a lot of side effects, so compiler
will/should never optimize in your way (but if compiler know exactly
how kfree work internally).

C "const" is a lot weaker to C++ "const".

BTW, I doesn't like const in kfree, but I was talking about
weak "const" in C.

> So, although this should currently work, code which breaks if you do
> a legitimate modification somewere else looks quite dangerous to me.

for sure!  But C is anal in: "users know better than compiler on what
they want to do", so compiler cannot do big optimizations C, without
breaking C rules, and used can do nasty things playing with hidden
pointers.

ciao
	cate

PS: use lkml rule: "do CC: to all relevant people!"

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