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: <Z7hulnJ4fwslRILy@pollux>
Date: Fri, 21 Feb 2025 13:16:22 +0100
From: Danilo Krummrich <dakr@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Christoph Hellwig <hch@...radead.org>,
	Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
	rust-for-linux <rust-for-linux@...r.kernel.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, Feb 20, 2025 at 04:39:58PM -0800, Linus Torvalds wrote:
> Honestly, what you have been doing is basically saying "as a DMA
> maintainer I control what the DMA code is used for".
> 
> And that is not how *any* of this works.
> 
> What's next? Saying that particular drivers can't do DMA, because you
> don't like that device, and as a DMA maintainer you control who can
> use the DMA code?

[...]

> So let me be very clear: if you as a maintainer feel that you control
> who or what can use your code, YOU ARE WRONG.

When I added you to the original thread [1], it was exactly to get some
clarification on this specific point.

In my perception, a lot (if not all) of the subsequent discussions evolved
around different aspects, while this specific one is not even limited to Rust in
the kernel.

Hence, I'm happy to see this clarified from your side; it was still a remaining
concern from my side, regardless of whether the PR in question will make it or
not.

However, I also want to clarify that I think that maintainers *do* have a veto
when it comes to how the API they maintain is used in the kernel. For instance,
when an API is abused for things it has not been designed for, which may hurt
the kernel as a whole.

But as mentioned previously, I do not think that this veto can be justified with
personal preference, etc.

- Danilo

[1] https://lore.kernel.org/lkml/Z5qeoqRZKjiR1YAD@pollux/