6 ms·

> Until that happens, it'll be hard to adopt Rust in a lot of C/C++ strongholds where C's ABI and dynamic linking are the thing that enables the software to get

by elteto 8mo ago

> Until that happens, it'll be hard to adopt Rust in a lot of C/C++ strongholds where C's ABI and dynamic linking are the thing that enables the software to get huge. Wait, Rust can already communicate using the C ABI. In fact, it offers exactly the same capabilities as C++ in this regard (dynamic linking).

pizlonator 8mo ago
That's an unsafe ABI.
- elteto 8mo ago
  As unsafe as C or C++. In fact, safer, because only the ABI surface is unsafe, the rust code behind it can be as safe or unsafe as you want it to be. I was addressing this portion of your comment: "C's ABI and dynamic linking are the thing that enables the software to get huge". If the C ABI is what enables software to get huge then Rust is already there. There is a second claim in your comment about a "safe ABI", but that is something that neither C or C++ offers right now.
  - pizlonator 8mo ago
    Here's the problem. If you told me that you rebuilt the Linux userland with Rust but you used C ABI at all of the boundaries, then I would be pretty convinced that you did not create a meaningful improvement to security because of how many dynamic linking boundaries there are. So many of the libraries involved are small, and big or small they expose ABIs that involve pointers to buffers and manual memory management. > There is a second claim in your comment about a "safe ABI", but that is something that neither C or C++ offers right now. Of course C and C++ are no safer in this regard. (Well, with Fil-C they are safer, but like whatever.) But that misses the point, which is that: - It would be a big deal if Rust did have a safe dynamic linking ABI. Someone should do it. That's the main point I'm making. I don't think deflecting by saying "but C is no safer" is super interesting. - So long as this problem isn't fixed, the upside of using Rust to replace a lot of the load bearing stuff in an OS is much lower than it should be to justify the effort. This point is debatable for sure, but your arguments don't address it.
    - kittiepryde 8mo ago
      Would a safe ABI work with sandboxing the C code? I'm a bit unsure how one would construct a safe C ABI from Rust's side,
    - duped 8mo ago
      How could a safe dynamic linking API ever work? I think you're moving the goalposts significantly here.
      - pizlonator 8mo ago
        > How could a safe dynamic linking API ever work? Fil-C solves it. I think Swift solves it, too. So it's solvable. No fundamental reason, that I know of, why Rust or any other safe language can't also have some kind of story here. > I think you're moving the goalposts significantly here. No. I'm describing a problem worth solving. Also, I think a major chasm for Rust to cross is how defensive the community gets. It's important to talk about problems so that the problems can be solved. That's how stuff gets better.
        merb 8mo ago
        Swift and fil-c are only pseudo safe. Once you deal with the actual world and need to pass around data from memory things are always unsafe since there is no safe way of sharing memory. At least not in our current operating systems. Swift and fil-c can at least guard to some extent the api.
      - ninkendo 8mo ago
        I don’t think GP is moving the goalposts at all, rather I think a lot of people are willfully misrepresenting GP’s point. Rust-to-rust code should be able to be dynamically linked with an ABI that has better safety guarantees than the C ABI. That’s the point. You can’t even express an Option<T> via the C ABI, let alone the myriad of other things rust has that are put together to make it a safe language. You can look to Swift for prior art on how this can be done: https://faultlore.com/blah/swift-abi/ https://faultlore.com/blah/swift-abi/ It would be very hard to accomplish. Apple was extremely motivated to make Swift have a resilient/stable ABI, because they wanted to author system frameworks in swift and have third parties use them in swift code (including globally updating said frameworks without any apps needing to recompile.) They wanted these frameworks to feel like idiomatic swift code too, not just be a bunch of pointers and manual allocation. There’s a good argument that (1) Rust doesn’t consider this an important enough feature and (2) they don’t have enough resources to accomplish it even if they did. But if you could wave a magic wand and make it “done”, it would be huge for rust adoption.
- andrewflnr 8mo ago
  A safe ABI would be cool, for sure, but in the market (specifically addressing your prediction) I don't know if it's really that big a priority for adoption. The market is obviously fine with an unsafe ABI, seeing how C/C++ is already dominant. Rust with an unsafe ABI might then not be as big an improvement as we would like, but it's still an improvement, and I feel like you're underestimating the benefits of safe Rust code as an application-level frontline of security, even linked to unsafe C code.
- MindSpunk 8mo ago
  What is a safe ABI? An ABI can't control whether one or both parties either end of the interface are honest. You can't have safe dynamic linking, dynamic linking requires you to trust the library you load with no ability to verify.
  - josefx 8mo ago
    > An ABI can't control whether one or both parties either end of the interface are honest. You are aware that Rust already fails that without dynamic linking? The wrapper around the C getenv functionality was originally considered safe, despite every bit of documentation on getenv calling out thread safety issues.
    - MindSpunk 8mo ago
      Yes? That's called a bug? The standard library incorrectly labelled something as safe, and then changed it. The root was an unsafe FFI call which was incorrectly marked as safe. It's no different than a bug in an unsafe pure Rust function. I'm choosing to ignore that libc is typically dynamically linked, but linking in foreign code and marking it safe is a choice to trust the code. Under dynamic linking anything could get linked in, unlike static linking. At least a static link only includes the code you (theoretically) audited and decided is safe.
- zozbot234 8mo ago
  A "safe" ABI is just a C ABI plus a "safe" Rust crate (the moral equivalent to a C/C++ header file) that wraps it to provide safety guarantees. All bare-metal "safe" FFI's are ultimately implemented on top of completely "unsafe" assembly, and Rust is not really any different.

by elteto 8mo ago

pizlonator 8mo ago

That's an unsafe ABI.

elteto 8mo ago
As unsafe as C or C++. In fact, safer, because only the ABI surface is unsafe, the rust code behind it can be as safe or unsafe as you want it to be. I was addressing this portion of your comment: "C's ABI and dynamic linking are the thing that enables the software to get huge". If the C ABI is what enables software to get huge then Rust is already there. There is a second claim in your comment about a "safe ABI", but that is something that neither C or C++ offers right now.
- pizlonator 8mo ago
  Here's the problem. If you told me that you rebuilt the Linux userland with Rust but you used C ABI at all of the boundaries, then I would be pretty convinced that you did not create a meaningful improvement to security because of how many dynamic linking boundaries there are. So many of the libraries involved are small, and big or small they expose ABIs that involve pointers to buffers and manual memory management. > There is a second claim in your comment about a "safe ABI", but that is something that neither C or C++ offers right now. Of course C and C++ are no safer in this regard. (Well, with Fil-C they are safer, but like whatever.) But that misses the point, which is that: - It would be a big deal if Rust did have a safe dynamic linking ABI. Someone should do it. That's the main point I'm making. I don't think deflecting by saying "but C is no safer" is super interesting. - So long as this problem isn't fixed, the upside of using Rust to replace a lot of the load bearing stuff in an OS is much lower than it should be to justify the effort. This point is debatable for sure, but your arguments don't address it.
  - kittiepryde 8mo ago
    Would a safe ABI work with sandboxing the C code? I'm a bit unsure how one would construct a safe C ABI from Rust's side,
  - duped 8mo ago
    How could a safe dynamic linking API ever work? I think you're moving the goalposts significantly here.
    - pizlonator 8mo ago
      > How could a safe dynamic linking API ever work? Fil-C solves it. I think Swift solves it, too. So it's solvable. No fundamental reason, that I know of, why Rust or any other safe language can't also have some kind of story here. > I think you're moving the goalposts significantly here. No. I'm describing a problem worth solving. Also, I think a major chasm for Rust to cross is how defensive the community gets. It's important to talk about problems so that the problems can be solved. That's how stuff gets better.
      - merb 8mo ago
        Swift and fil-c are only pseudo safe. Once you deal with the actual world and need to pass around data from memory things are always unsafe since there is no safe way of sharing memory. At least not in our current operating systems. Swift and fil-c can at least guard to some extent the api.
    - ninkendo 8mo ago
      I don’t think GP is moving the goalposts at all, rather I think a lot of people are willfully misrepresenting GP’s point. Rust-to-rust code should be able to be dynamically linked with an ABI that has better safety guarantees than the C ABI. That’s the point. You can’t even express an Option<T> via the C ABI, let alone the myriad of other things rust has that are put together to make it a safe language. You can look to Swift for prior art on how this can be done: https://faultlore.com/blah/swift-abi/ https://faultlore.com/blah/swift-abi/ It would be very hard to accomplish. Apple was extremely motivated to make Swift have a resilient/stable ABI, because they wanted to author system frameworks in swift and have third parties use them in swift code (including globally updating said frameworks without any apps needing to recompile.) They wanted these frameworks to feel like idiomatic swift code too, not just be a bunch of pointers and manual allocation. There’s a good argument that (1) Rust doesn’t consider this an important enough feature and (2) they don’t have enough resources to accomplish it even if they did. But if you could wave a magic wand and make it “done”, it would be huge for rust adoption.
andrewflnr 8mo ago
A safe ABI would be cool, for sure, but in the market (specifically addressing your prediction) I don't know if it's really that big a priority for adoption. The market is obviously fine with an unsafe ABI, seeing how C/C++ is already dominant. Rust with an unsafe ABI might then not be as big an improvement as we would like, but it's still an improvement, and I feel like you're underestimating the benefits of safe Rust code as an application-level frontline of security, even linked to unsafe C code.
MindSpunk 8mo ago
What is a safe ABI? An ABI can't control whether one or both parties either end of the interface are honest. You can't have safe dynamic linking, dynamic linking requires you to trust the library you load with no ability to verify.
- josefx 8mo ago
  > An ABI can't control whether one or both parties either end of the interface are honest. You are aware that Rust already fails that without dynamic linking? The wrapper around the C getenv functionality was originally considered safe, despite every bit of documentation on getenv calling out thread safety issues.
  - MindSpunk 8mo ago
    Yes? That's called a bug? The standard library incorrectly labelled something as safe, and then changed it. The root was an unsafe FFI call which was incorrectly marked as safe. It's no different than a bug in an unsafe pure Rust function. I'm choosing to ignore that libc is typically dynamically linked, but linking in foreign code and marking it safe is a choice to trust the code. Under dynamic linking anything could get linked in, unlike static linking. At least a static link only includes the code you (theoretically) audited and decided is safe.
zozbot234 8mo ago
A "safe" ABI is just a C ABI plus a "safe" Rust crate (the moral equivalent to a C/C++ header file) that wraps it to provide safety guarantees. All bare-metal "safe" FFI's are ultimately implemented on top of completely "unsafe" assembly, and Rust is not really any different.