| |
| ▲ | pizlonator 6 hours ago | parent [-] | | 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. | | |
| ▲ | staticassertion 4 hours ago | parent | next [-] | | > - 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. I think we all agree that it would be a huge deal. > - 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. As you point out, this is the debatable part, and I'm not sure I get your justification here. | | |
| ▲ | pizlonator 3 hours ago | parent [-] | | This might end up being the forcing function (quoting myself from another reply in this discussion): > It can't be that replacing 20 C/C++ shared objects with 20 Rust shared objects results in 20 copies of the Rust standard library and other dependencies that those Rust libraries pull in. But, today, that is what happens. For some situations, this is too much of a memory usage regression to be tolerable. If memory was cheap, then maybe you could say, "who cares". Unfortunately memory isn't cheap these days | | |
| ▲ | staticassertion 2 hours ago | parent [-] | | How much overhead is that? Also, why would that have much overhead? Things deduplicate in memory. | | |
| ▲ | rlpb 2 hours ago | parent [-] | | Your apt update would still be huge though. When the dependency changes (eg. a security update) you’d be downloading rebuilds of 20 apps. For the update of a key library, you’d be downloading your entire distribution again. Every time. | | |
| ▲ | staticassertion 2 hours ago | parent [-] | | Oh, well yeah, statically linked binaries have that downside. I guess I don't think that's a big deal, but I could maybe imagine on some devices that are heavily constrained that it could be? IDK. Compression is insanely effective. |
|
|
|
| |
| ▲ | yxhuvud 5 hours ago | parent | prev | next [-] | | What you are asking for is to make a library definition replacement to .h-files that contain sufficient information to make rust safe. That is a big, big step and would be fantastic not only for rust but for any other language trying to break out of the C tar pit. | |
| ▲ | adgjlsfhk1 6 hours ago | parent | prev | next [-] | | The argument for unsafe ABI not being that big of a deal is that ABI boundaries often reflect organizational boundaries as well. E.g. the kernel wouldn't really benefit from a "safe ABI" because users calling into the kernel need to be considered malicious by default. | |
| ▲ | kittiepryde 6 hours ago | parent | prev | next [-] | | 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, | |
| ▲ | wang_li 6 hours ago | parent | prev | next [-] | | So you're calling for dynamic linking for rust native code? Because rust's safety doesn't come from runtime, it comes from the compiler and the generated code. An object file generated from a bit of rust source isn't some "safe" object file, it's just generated in a safe set of patterns. That safety can cross the C ABI perfectly fine if both things on either side came from rust to begin with. Which means rust dynamic linking. | |
| ▲ | 4 hours ago | parent | prev | next [-] | | [deleted] | |
| ▲ | duped 6 hours ago | parent | prev [-] | | How could a safe dynamic linking API ever work? I think you're moving the goalposts significantly here. | | |
| ▲ | ninkendo 6 hours ago | parent | next [-] | | 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/ 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. | | |
| ▲ | pizlonator 5 hours ago | parent [-] | | > I don’t think GP is moving the goalposts at all Thank you :-) > It would be very hard to accomplish. Yeah it's a super hard problem especially when you provide safety using the type system! The work the Swift team did here is hella impressive. > But if you could wave a magic wand and make it “done”, it would be huge for rust adoption. Yeah! |
| |
| ▲ | pizlonator 6 hours ago | parent | prev [-] | | > 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. |
|
|
|
| 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. |
