I see. When writing the VGA driver, writing to memory space between 0xB8000 and the upper bound is technically safe because we know nothing else is mapped there. So you could wrap writes to that region in a “SafeVideoMemoryWrite”function call, and designate that function as safe to call. I believe this is done in the standard library of Rust for efficiency purposes. Is there no way to designate user-level safe interfaces built on top of unsafe? Put another way, is there a way for a user to extend rust’s notion of safety?
But honestly at that point, using Rust doesn’t seem to be very much different than using C in terms of safety guarantees. It still requires a programmer capable of competently ensuring required runtime properties.
You would do it conceptually in that way, yes; you'd provide a safe API, and then use unsafe inside of it to implement it. The standard library is just regular old Rust code, you can do the exact same thing. And in fact, you'd want to, in order to isolate the unsafety as much as you can.
> But honestly at that point, using Rust doesn’t seem to be very much different than using C in terms of safety guarantees.
The difference is that it's limited in scope, and auditable. Even in a kernel, if you do it right, unsafe is the vast, vast minority of code. Let's be extremely generous and put it at 10% (Redox, an OS in Rust, had about 2% unsafe last I checked). That means that you still have a much, much significantly smaller space in to look for these bugs.
In a few words, when dealing with kernel modules and drivers (and I guess every low-level implementation), ensuring that the upper (Rust) layers are safe is still the job of a person: a person, with a great understanding of both worlds, writing the unsafe functions that glue safe-land and the rest of the kernel together.
> The difference is that it's limited in scope, and auditable. Even in a kernel, if you do it right, unsafe is the vast, vast minority of code.
That’s true but it’s also slightly misleading. Any code that uses the unsafe wrappers technically must be checked and all code that uses that code must checked in turn, ad Infinitum. Misuse of the Unsafe wrapper can occur at any level. For instance, if you misuse a DMA command that corrupts memory, it’s not simply the DMA command wrapper that must be checked, the entire sequence of logic that led to the bad command being executed must also be checked.
> Any code that uses the unsafe wrappers technically must be checked
If that is the case, then your unsafe wrappers are unsound.
Safe functions need to be impossible to use in an unsafe way or else they should marked as unsafe.
That could take the form of a runtime check that the function's invariants are maintained or a proof that the function's invariants are always maintained.
That’s true, so now I see where the issue of unavoidable unsafe usage comes in. It’s not always possible to create a safe and general wrapper for all driver functionality, though in special cases maybe. I agree now that using Rust still offers something even if it can’t be guaranteed that the code is 100%. Thanks for explaining.
But honestly at that point, using Rust doesn’t seem to be very much different than using C in terms of safety guarantees. It still requires a programmer capable of competently ensuring required runtime properties.