Message-ID: <CAH5fLgje088THfszy0LiE9u1b=XYme_Vo07azjiba=TJ85usvA@mail.gmail.com>
Date: Fri, 19 Jul 2024 18:46:53 +0200
From: Alice Ryhl <aliceryhl@...gle.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>, linux-doc@...r.kernel.org, 
	linux-kernel@...r.kernel.org, rust-for-linux@...r.kernel.org
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:
> > On 17 Jul 2024, at 19:12, Benno Lossin <benno.lossin@...ton.me> wrote:
> > +====================
> > +Rust Safety Standard
> > +====================
> > +
> > +Safe Rust code cannot have memory related bugs. This is a guarantee by the Rust compiler. Of course
> > +it is not without caveats: no compiler bugs, no bugs in the specification etc. But the possibly most
> > +important caveat is that of ``unsafe`` code. ``unsafe`` code needs to follow certain rules in order
> > +for safe code to enjoy the no-memory-bugs privilege. A simple example of such a rule is that
> > +references must be valid for the duration of their lifetime. If any rule is violated, it can lead
> > +to undefined behavior even in safe code! The term undefined behavior in Rust has a lot stricter
> > +meaning than in C or C++: UB in Rust is totally forbidden. In C one might rely on the compiler
> > +implementation to ensure correct code generation, but that is not the case for Rust. You can read
> > +more about UB in Rust
> > +`here <https://doc.rust-lang.org/reference/behavior-considered-undefined.html>`_.
> > +
> > +If ``unsafe`` code makes our life this difficult, one might ask the question "why do we even need
> > +it?" and the answer to that is that it gives users an escape hatch to do things that the compiler
> > +normally forbids. ``unsafe`` code is a tool that enables programmers to write more performant code,
> > +or code that interacts with hardware or C. These things are particularly important in kernel
> > +development.
> > +
> > +The most effective way to prevent issues in ``unsafe`` code is to just not write ``unsafe`` code in
> > +the first place. That is why minimizing the amount of ``unsafe`` code is very important. For
> > +example, drivers are not allowed to directly interface with the C side. Instead of directly
> > +communicating with C functions, they interact with Rust abstractions. This concentrates the usage
> > +of ``unsafe`` code, making it easy to fix issues, since only the abstraction needs to be fixed.
> > +Abstractions also allow taking advantage of other Rust language features. Read more in
> > +:ref:`rust-abstractions`.
>
> This is something that I think we should discuss at Kangrejos. I do not think
> that we should set in stone that the kernel crate is the only place where
> unsafe code is acceptable.
>
> I am in no way disagreeing with the use of safe abstractions, but I think we
> should have abstractions where they make sense. This is the case in the vast
> majority of times, but not in *all* of them.
>
> A simple example is a MMIO read or write. Should a driver be forbidden to call
> readX/writeX for an address it knows to be valid? How can you possibly write an
> abstraction for this, when the driver is the only one aware of the actual
> device addresses, and when the driver author is the person with actual access
> to the HW docs?
>
> If a driver is written partially in Rust, and partially in C, and it gets a
> pointer to some kcalloc’d memory in C, should It be forbidden to use unsafe
> in order to build a slice from that pointer? How can you possibly design a
> general abstraction for something that is, essentially, a driver-internal API?
>
> 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.

Perhaps it is worth having the document explicitly talk about middle
grounds between "directly access C apis" and "don't use unsafe code"?
My file abstractions [1] expose an unsafe function called
`assume_no_fdget_pos` and I intend for Rust Binder to have an unsafe
block calling that function. Using such an unsafe API is meaningfully
different from just directly calling `bindings::fget`, but both are
unsafe.

Though it doesn't seem like the document actually says "don't use
unsafe code in drivers". It just says "use abstractions".

Alice

[1]: https://lore.kernel.org/all/20240628-alice-file-v7-3-4d701f6335f3@google.com/

Powered by blists - more mailing lists