Rust only helps in a specifc use case of data races, when the memory belongs to the same process and is being access by threads.
Rust type system doesn't help when the data resides in a shared memory segment accessed by multiple processes.
Rust type system doesn't help when the data resides in a shared memory segment accessed by multiple processes.
Of course if you interact with foreign code (including code in other programs, but also code in the same program written in another language), you need unsafe. Or if you write a new synchronization primitive, etc. The unsafe is there to say "I manually checked and this is okay".
What's important is that with Rust, concurrent business logic - in a kernel, things like filesystems and drivers - shouldn't need any unsafe to synchronize correctly. You use unsafe for your lower level infrastructure, but the code that actually does things can be data race free (and thus is easier to modify and assure it's working correctly). And that's incredible.
Also the right way to implement filesystems and drivers in modern OSes should be in userspace drivers, which is the route being taken by Apple, Google and Microsoft across their OSes anyway.
This isn't quite true. You can provide a safe abstraction that involves cross-process locking APIs. https://github.com/elast0ny/shared_memory/blob/HEAD/examples... is an example using a mutex guard.
Rust's type system helps more in some cases than others, but you can get at least some help from it almost all of the time.