On Fri, Jul 19, 2024 at 6:24 PM Daniel Almeida <daniel.almeida@xxxxxxxxxxxxx> wrote: > > On 17 Jul 2024, at 19:12, Benno Lossin <benno.lossin@xxxxxxxxx> 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@xxxxxxxxxx/
