linux-kernel - Re: [RFC PATCH 1/5] doc: rust: create safety standard

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: <CANiq72mxh-7sSj9kTVGENWbcJtbrbzSfksYhKPOap2UrvgZ47A@mail.gmail.com>
Date: Fri, 19 Jul 2024 19:56:56 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Daniel Almeida <daniel.almeida@...labora.com>
Cc: Benno Lossin <benno.lossin@...ton.me>, Jonathan Corbet <corbet@....net>, 
	Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>, 
	Wedson Almeida Filho <wedsonaf@...il.com>, Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>, 
	Björn Roy Baron <bjorn3_gh@...tonmail.com>, 
	Andreas Hindborg <a.hindborg@...sung.com>, Alice Ryhl <aliceryhl@...gle.com>, linux-doc@...r.kernel.org, 
	linux-kernel@...r.kernel.org, rust-for-linux@...r.kernel.org, 
	Chapot Clément (M.) <clement.chapot@...ytechnique.edu>, 
	Baptiste Lepers <baptiste.lepers@...il.com>
Subject: Re: [RFC PATCH 1/5] doc: rust: create safety standard

On Fri, Jul 19, 2024 at 6:24 PM Daniel Almeida
<daniel.almeida@...labora.com> wrote:
>
> For these corner cases, a simple safety comment should suffice. By all means,
> let's strive to push as much of the unsafe bits into the kernel crate. But,
> IMHO, we shouldn’t treat Rust drivers as some unprivileged entity, they’re
> also kernel code, after all.

The intention has never been to forbid unsafe blocks, but rather to
minimize the amount of unsafe code as much as possible.

That is why mixing Rust and C in ways that make the amount of unsafe
blocks increase a lot may not be the best approaches. Sometimes it may
be needed nevertheless, i.e. there is no hard rule here.

Relatedly, on the topic of drivers being "unprivileged" entities:
anything we can do to make any code as "unprivileged" as possible (in
"number of unsafe blocks" or other ways) is likely a good thing, as
long as it does not detract from what actually needs to be done and is
not too onerous.

In other words, part of the idea of using Rust has always been trying
to see how much we could tight things up while still making things
work in practice.

For instance, other ways to tight things up would be disallowing to
call certain APIs/subsystems/... (i.e. visibility, which we will add),
marking certain crates as `#![deny(unsafe_code)]` or other lints, or
verification of certain properties (there are researchers looking into
this).

But, yeah, I agree it will be one of the interesting discussions at
Kangrejos... :)

Cheers,
Miguel