3 ms·

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 thos

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-in-c.html http://way-cooler.org/blog/2019/04/29/rewriting-way-cooler-i...

steveklabnik 6y ago
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.
- CyberRabbi 6y ago
  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.
  - throwaway2048 6y ago
    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.
  - randalluk 6y ago
    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.
    - deleted 6y ago
      [deleted]
  - steveklabnik 6y ago
    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.
    - CyberRabbi 6y ago
      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.
      - steveklabnik 6y ago
        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.
timidger 6y ago
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.

steveklabnik 6y ago

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.

CyberRabbi 6y ago
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.
- throwaway2048 6y ago
  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.
- randalluk 6y ago
  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.
  - deleted 6y ago
    [deleted]
- steveklabnik 6y ago
  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.
  - CyberRabbi 6y ago
    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.
    - steveklabnik 6y ago
      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.

timidger 6y ago

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.