Mostly Rust has been used for drivers so far. Here's the first Rust driver I found:
https://github.com/torvalds/linux/blob/2137cb863b80187103151...
It has one trivial use of `unsafe` - to support Send & Sync for a type - and that is apparently temporary. Everything else uses safe APIs.
Functions like that can and should be marked unsafe in rust. The unsafe keyword in rust is used both to say “I want this block to have access to unsafe rust’s power” and to mark a function as being only callable from an unsafe context. This sounds like a perfect use for the latter.
That's not how it works. You don't mark them unsafe unless it's actually required for some reason. And even then, you can limit that scope to a line or two in majority of cases. You mark blocks unsafe if you have to access raw memory and there's no way around it.
The general rule of thumb is that safe code must not be able to invoke UB.
- Hardware access is unsafe - Kernel interface is unsafe
How much remains in the layer in-between that's actually safe?
I ported a C skip list implementation to rust a few years ago. Skip lists are like linked lists, but where instead of a single "next" pointer, each node contains an array of them. As you can imagine, the C code is packed full of fiddly pointer manipulation.
The rust port certainly makes use of a fair bit of unsafe code. But the unsafe blocks still make up a surprisingly small minority of the code.
Porting this package was one of my first experiences working with rust, and it was a big "aha!" moment for me. Debugging the C implementation was a nightmare, because a lot of bugs caused obscure memory corruption problems. They're always a headache to track down. When I first ported the C code to rust, one of my tests segfaulted. At first I was confused - rust doesn't segfault! Then I realised it could only segfault from a bug in an unsafe block. There were only two unsafe functions it could be, and one obvious candidate. I had a read of the code, and spotted the error nearly immediately. The same bug would probably have taken me hours to fix in C because it could have been anywhere. But in rust I found and fixed the problem in a few minutes.
Another thing you can do from rust without "unsafe": output some buggy source code that invokes UB in a language like C to a file, then shell out to the compiler to compile that file and run it.
I'm just pointing out that "your program manipulates the external system in such a way that UB is caused" is outside the scope of Rust's guarantees, and kernel development doesn't fundamentally change that (even though it might make it easier to trigger). Rust's guarantees are only about what the Rust code does; anything else would be hard or impossible to guarantee and Rust doesn't try to do so.
unsafe {
// this is normal Rust code, you can write as much of it as you like!
// (and you can bend some crucial safety rules)
// but try to limit and document what you put inside an unsafe block.
// then wrap it in a safe interface so no one has to look at it again
}(but as others pointed out, unsafe should only be used at the 'edges', the vast majority should never need to use unsafe)