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

Message-ID: <19722657.437421200683429036.JavaMail.www@wwinf4614>
Date:	Fri, 18 Jan 2008 20:10:29 +0100 (CET)
From:	ecolbus@...la.fr
To:	linux-kernel@...r.kernel.org
Cc:	"Giacomo A. Catenazzi" <cate@...eee.net>
Subject: Re: Why is the kfree() argument const?

Olivier Galibert wrote:
> On Fri, Jan 18, 2008 at 05:45:49PM +0100, ecolbus@...xxxxx wrote:
> > The malloc attribute is exactly about this : giving the compiler the
> > indication that no other pointer aliases this object, allowing for
> > better optimizations.
> 
> If you put a malloc attribute on the allocator and no free attribute
> on the deallocator, you can get bugs indeed. GIGO.
> 
> 
> > Yes. Bad things start to happen when users add wrong indications to
> > the compiler. By adding the "const" indication to kfree(), the programmer
> > wrongly tells that it can optimize reading the values pointed to before or
> > after calling the function (if it is also sure that they cannot be
> > read/written otherwise). Current gcc implementations seem quite
> > conservative in this regard, and don't optimize that much, but what about
> > the future?
> 
> The future should be quite nice because:
> 
> - the compiler can not know that kmalloc does not have an alias to
> the pointer tucked somewhere accessible by other non-inline functions
> (as kfree is), especially since it does have aliases in practice, so
> it cannot prove to "not read/written otherwise" part without the
> malloc attribute
> 
> - if you add the (non-standard C) malloc attribute to kmalloc, then
> you also add the free attribute to kfree which tells the compiler
> that the pointer is invalid after the call, which ensures no
> accesses will be moved after it
> 
> OG.

I completely agree with you here. But, unless this page : 

http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html

is not up-to-date anymore, there is no free attribute. Which
is quite logical, actually, as such an attribute would be
equivalent to simply marking the parameter of the function
non-const.

That's what I was alluding to, when speaking of a legitimate
change (adding attribute malloc to kmalloc()) which would break
another part of the kernel. Of course, we can also assume that
nobody would make the error of letting kfree() taking a 
const void* after that, but experience shows that programmers
are very likely to fall into such traps.

(No flame intended on anybody : in my case, I'm actually able
to fall even when there is no trap at all. That's the reason for
spotting such a weird one makes me anxious. Especially since
having kfree() take a non-const argument comes at no runtime
cost.)

Cheers,

Emmanuel

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