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: <4e1abc9c1ab07aeecc157a366c0b5eb91a177f2a.camel@kernel.org>
Date: Thu, 20 Feb 2025 10:16:10 +0200
From: Jarkko Sakkinen <jarkko@...nel.org>
To: Bart Van Assche <bvanassche@....org>, Steven Rostedt
 <rostedt@...dmis.org>,  Jason Gunthorpe	 <jgg@...dia.com>
Cc: Kees Cook <kees@...nel.org>, Miguel Ojeda
 <miguel.ojeda.sandonis@...il.com>,  Christoph Hellwig	 <hch@...radead.org>,
 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 Thu, 2025-02-20 at 10:13 +0200, Jarkko Sakkinen wrote:
> On Wed, 2025-02-19 at 12:52 -0800, Bart Van Assche wrote:
> > On 2/19/25 12:46 PM, Steven Rostedt wrote:
> > > I do feel that new drivers written in Rust would help with the
> > > vulnerabilities that new drivers usually add to the kernel.
> > 
> > For driver developers it is easier to learn C than to learn Rust.
> > I'm
> > not sure that all driver developers, especially the "drive by"
> > developers, have the skills to learn Rust.
> 
> IMHO, Rust is not that difficult to learn but it is difficult to
> run.
> 
> One point of difficulty for me still is the QA part, not really the
> code. QuickStart discusses on how to install all the shenanigans
> with distribution package managers.
> 
> The reality of actual kernel development is that you almost never
> compile/run host-to-host, rendering that part of the documentation
> in the battlefield next to useless.
> 
> Instead it should have instructions for BuildRoot, Yocto and
> perhaps NixOS (via podman). It should really explain this instead
> of dnf/apt-get etc.

If I got a Rust patch for review cycle, I would not have any idea
what to do with it. And I'm talking about writing a single line of
code but how to put that patch into a QA cycle (personally using
BR for this, which is somewhat popular choice among kernel
maintainers).

So I would put "NAK because cannot test this".

BR, Jarkko