linux-kernel - Re: Rust kernel policy

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250219153350.GG19203@1wt.eu>
Date: Wed, 19 Feb 2025 16:33:50 +0100
From: Willy Tarreau <w@....eu>
To: James Bottomley <James.Bottomley@...senPartnership.com>
Cc: "Martin K. Petersen" <martin.petersen@...cle.com>,
        Dan Carpenter <dan.carpenter@...aro.org>,
        Christoph Hellwig <hch@...radead.org>,
        Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
        rust-for-linux <rust-for-linux@...r.kernel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg KH <gregkh@...uxfoundation.org>, David Airlie <airlied@...il.com>,
        linux-kernel@...r.kernel.org, ksummit@...ts.linux.dev
Subject: Re: Rust kernel policy

Hi James,

On Wed, Feb 19, 2025 at 10:15:00AM -0500, James Bottomley wrote:
> On Wed, 2025-02-19 at 09:46 -0500, Martin K. Petersen wrote:
> > 
> > James,
> > 
> > > Could we possibly fix a lot of this by adopting the _cleanup_
> > > annotations[1]? I've been working in systemd code recently and they
> > > seem to make great use of this for error leg simplification.
> > 
> > We already have this:
> > 
> >   include/linux/cleanup.h
> > 
> > I like using cleanup attributes for some error handling. However, I'm
> > finding that in many cases I want to do a bit more than a simple
> > kfree(). And at that point things get syntactically messy in the
> > variable declarations and harder to read than just doing a classic
> > goto style unwind.
> 
> So the way systemd solves this is that they define a whole bunch of
> _cleanup_<type>_ annotations which encode the additional logic.  It
> does mean you need a globally defined function for each cleanup type,
> but judicious use of cleanup types seems to mean they only have a few
> dozen of these.

I may be missing something obvious, but this seems super dangerous to
me to perform lightly without reference counting, as it increases the
risks of use-after-free and double-free in case one of the allocated
objects in question can sometimes be returned. Users of such mechanisms
must be extremely cautious never to ever return a pointer derivated
from a variable tagged as such, or to properly NULL-assign the original
object for it not to double-free. So it might in the end require to be
careful about null-setting on return instead of explicitly freeing what
was explicitly allocated. I'm not sure about the overall benefit. Also
I suspect it encourages to multiply the return points, which makes it
even more difficult to possibly fix what needs to be fixed without
coming from a locally allocated variable (e.g. restore a state in a
parser etc). Maybe it's just me not seeing the whole picture, but as
a general case I prefer to forget a free() call (worst case: memory
leak) than forget a foo=NULL that may result in a double free, and the
description here makes me think the latter might more easily happen.

Regards,
Willy