Hacker News Reader

Comment by CyberRabbi | Hacker News Reader

Does this RFC include all the requisite “safe” interfaces to enable writing a fully featured driver in Rust? If not, is it theoretically possible to create those safe interfaces within Linux’s API driver infrastructure? Or will some unsafe API usage always be necessary in Rust?

I remember there was an issue writing a rust-safe wayland compositor on top of wlroots because wlroot’s ownership model was simply not able to be cast in terms of interfaces that rust was able to prove were safe. [1] Is this not an issue in Linux?

[1] http://way-cooler.org/blog/2019/04/29/rewriting-way-cooler-i...

View on HN

I haven't done any Linux work (except for some stuff with device tree that I've mostly forgotten), but that post I made about Way Cooler may not be generalizable to all C APIs. It's also possible that I simply was not creative enough with my API design - since that blog post a few people have reached out with alternative designs that avoid some of the issues I ran into. I haven't dug into them however, since I'm no longer interested in working on Way Cooler.

It's not so much "Rust can't represent this ownership model" as "this ownership model is basically orthogonal to Rust's so you have to put much more effort in to write idiomatic Rust code compared to writing it in C". I would love for someone to come along and prove me wrong with a better wlroots wrapper.

Also, Wayland composites are much, much simpler than the Linux kernel, so that train of thought doesn't necessarily scale out.

From the link:

"The intention is to make these as safe as possible so that modules written in Rust require the smallest amount of `unsafe` code possible."

When writing a kernel, some unsafe somewhere is always required, on some level.

Yes I saw that but it wasn’t clear on whether it was possible or if there was a clear plan to make it 100% safe.

You’re saying some unsafe code is always necessary, why should that be the case? I think the big issue with wlroots was its callback-based API which is common with Linux-internal APIs as well. On a theoretical basis I’m not sure what this means for Rust. Is it simply not possible in the abstract to cast these types of APIs in a form that can be statically proven to be safe? Or is this a deficiency in the current design of Rust? Are all “callback-based” APIs inherently unsafe in Rust? Is it always theoretically possible to recast those APIs in a form that Rust can prove is safe? I would just want to understand exactly why it’s possible to write 100% safe Rust programs in user space and not in Linux kernel space.

These are the types of questions I would ask when evaluating whether or not it’s worth investing in and using Rust for my Linux driver.

because you have to interact directly with hardware at a low level at some point (poking registers, implementing syscalls, implementing process and memory address space isolation, context switching between rings, etc), that will always be inherently unsafe.

Userland Rust depends on these guarantees to provide safe code, something has to implement them.

If you're a driver, at some point you'll probably need to write bytes into a device register, mapped to a raw address in physical memory. That's a fundamentally unsafe thing to do: it relies on you as a programmer setting up the structure of the data in those registers correctly. Get it wrong and you can scribble over some arbitrary piece of memory, for example. The compiler can't check your working. It doesn't know the specification of every piece of hardware - that's what drivers are for.

It is impossible to make it 100% safe because in order to do that, Rust's language semantics would have to include the semantics of the underlying hardware APIs. Imagine I'm writing a text-mode VGA driver. To do this, I have to write at the memory starting at 0xB8000, because it's a memory-mapped device. The only way this would be safe is if Rust the language understood the VGA spec, because otherwise, it looks like you're accessing arbitrary memory. The only way to call the wfi instruction would be if Rust the language understood ARM semantics directly. Etc etc etc.

The callback thing is a red herring; it's not the fundamental issue here. Rust code can use callbacks just fine, in the general case. It also wasn't the fundamental issue with that API either.

Would svd2rust (or a project like it) be usable for that (assuming device manufacturers displayed some competency and emitted consumable descriptions of their HW APIs instead of reference manuals)?

Those projects generate code with unsafe inside (and sometimes outside). They are very useful for getting safe interfaces, but don't help remove the concept of unsafe entirely.

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.

> 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.

If an unsafe wrapper can be mis-used, it's not actually safe, and so the bug still lies inside the wrapper.

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.

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.

Reply on news.ycombinator.com