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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <2bcf7cb500403cb26ad04934e664f34b0beafd18.camel@HansenPartnership.com>
Date: Wed, 19 Feb 2025 09:14:17 -0500
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: Dan Carpenter <dan.carpenter@...aro.org>, Christoph Hellwig
	 <hch@...radead.org>
Cc: 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

On Wed, 2025-02-19 at 11:05 +0300, Dan Carpenter wrote:
> On Tue, Feb 18, 2025 at 08:08:18AM -0800, Christoph Hellwig wrote:
> > But that also shows how core maintainers are put off by trivial
> > things like checking for integer overflows or compiler enforced
> > synchronization (as in the clang thread sanitizer).
> > How are we're going to bridge the gap between a part of the kernel
> > that is not even accepting relatively easy rules for improving
> > safety vs another one that enforces even strong rules.
> 
> Yeah.  It's an ironic thing...
> 
>         unsigned long total = nr * size;
> 
>         if (nr > ULONG_MAX / size)
>                 return -EINVAL;
> 
> In an ideal world, people who write code like that should receive a
> permanent ban from promoting Rust.

I look at most of the bugfixes flowing through subsystems I watch and a
lot of them are in error legs.  Usually around kfree cockups (either
forgetting or freeing to early).  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.

Regards,

James

[1] https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html#index-cleanup-variable-attribute
https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html#index-cleanup-variable-attribute