5 ms·

I think what GP is saying that you'll have problems in logic or other typical programming problems and that it isn't a lack of language features/safety but rath

I think what GP is saying that you'll have problems in logic or other typical programming problems and that it isn't a lack of language features/safety but rather time/money being thrown at these libraries I imagine the top two reasons unsafe memory access happen is: 1) other complicated logic seeped into the memory sensitive area or causes programmer fatigue 2) memory management is hard Rust helps with #2 but let's not kid ourselves, what percentage of a library like glibc would be spent in unsafe blocks? Drawing attention to an unsafe area can help though. As you can see, I'm running around in circles. Just like every discussion about this does. Until an avid Rust user puts their money where their mouth is, we're all just playing Armchair Programmer.

pcwalton 11y ago
I don't understand the difference between #1 and #2, or why Rust helps with one and not the other. If memory safety is enforced, it's enforced. > Rust helps with #2 but let's not kid ourselves, what percentage of a library like glibc would be spent in unsafe blocks? string.h is not as interesting as, say, the DNS resolver. Nothing about the DNS resolver needs to be unsafe.
- bluejekyll 11y ago
  It's true. In my DNS code I have zero unsafe code. Though I did need to add some new unsafe code to the Rust OpenSSL library, but that's really because of the FFI to C. That too would be unnecessary if OpenSSL was rewritten in Rust.
  - sgrove 11y ago
    What about binding to the OCaml implementation at https://nqsb.io/ https://nqsb.io/ ?
    - nostrademons 11y ago
      Wouldn't that require pulling in the OCaml garbage collector? Much of the reason people use glibc or other low-level libraries rather than a managed runtime is so they don't need to link in a managed runtime.
      - sgrove 11y ago
        Good point, I think it would indeed mean pulling in all of OCaml's runtime model.
  - jononor 11y ago
    Does the OpenSSL library allow/plan for an Rust reimplementation (possibly side-by-side for a while) of the C bits? Seems that would be best practice - assuming the goal is make everything safe Rust.
    - bluejekyll 11y ago
      In theory that's just copying the Rust bridge code and using that as the frontend API for a rewrite. So yes it's possible, you "just" need to rewrite the rust-openssl-sys library. I think the hesitation there is that everyone has gotten it beaten into your head that writing new crypto libraries is dangerous. It's probably safer to use a library that has tons of eyes on it, but at some point we should do it.
      - jononor 11y ago
        Problem is that if this is not considered beforehand, one might create APIs which are very hard/tedious to replicate without the old/legacy implementation. But maybe for openssl staying close to the original API is useful, then one could maybe put a C API on top and use it also outside Rust.
unscaled 11y ago
OP article was specifically talking about Rustbelt as one tool you would be able to use in the future to mitigate the risks posed by the unsafe code you do have. But in general, I think that entire idea is that as more code moves to memory-safe languages, the less need we have for unsafe sections. Ideally, once the kernel itself can be written in a memory safe language, everything running on top of that wouldn't need much unsafe blocks. To be honest, this goal is probably decades away, but we should definitely be considering memory-safe languages for systems programming.
- panic 11y ago
  It's not decades away! Check out https://sel4.systems https://sel4.systems.
  - cmrx64 11y ago
    And, relatedly, https://robigalia.org/ https://robigalia.org/
  - deleted 11y ago
    [deleted]
tatterdemalion 11y ago
> what percentage of a library like glibc would be spent in unsafe blocks? Probably less than you think. What I think the limit is is that there are functions in glibc that present inherently unsafe interfaces. I'm not sure how many but it might be enough that writing libc in Rust is not that helpful.
- andrewprock 11y ago
  Once you admit unsafe blocks, you admit that Rust is unsafe. The value of porting from one unsafe language to another is probably only marginal.
bluejekyll 11y ago
> an avid Rust user puts their money where their mouth is There are lots of people doing this. Look at crates.io. I decided to write a new fully compliant DNS server and client, trust-dns. I work on it in my spare time (it's time not money), which is hard with two kids. I've learned a few things. It's hard to get it done. There's a lot to learn from the rfc's. Just because it's Rust, doesn't mean it's easy. There are all the same borrow rules, and I know I have a bunch of TODOs in the code to go fix things like extra clones. The IDEs, while good, are not on par with other languages yet. Basically it's a lot of work. And I commend the individuals who've paved the way for me with the std library in Rust, but we still have so much more work to do until there is a full OS env like GNU.
- rubiquity 11y ago
  Your entire post reinforces the idea that in my list of challenges to writing safe software that #1 is far more the issue than #2.
  - bluejekyll 11y ago
    Yes. I'm agreeing that it's hard and takes a lot of energy. But people are doing it.
dikaiosune 11y ago
Re: amount of low level code needing unsafe blocks, its worth checking out this series that documents creating a bare metal kernel in rust that has lots of type safety and uses shockingly little assembly or unsafe: http://os.phil-opp.com/ http://os.phil-opp.com/
- pjmlp 11y ago
  C created this wrong perception that you need lots unsafe code, due to how it does strings and vectors. In all safe alternatives to C, just like Rust sure you need unsafe at the Assembly FFI level and hardware integration like IO ports and interrupt handling. But everything else can be just plain safe code.
nitrogen 11y ago
If someone wants to pay me to rewrite glibc in Rust, I'd gladly do it, as I'm sure lots of other devs would. It's actually something I've thought about doing as a hobby, but there are a million other hobbies above it on the list.
- XorNot 11y ago
  What we need is a way to coordinate the effort I suspect. Given we have glibc as a standard interface, a site which matched up function tests with implementations and made it obvious where to jump in could build a decent community.

pcwalton 11y ago

I don't understand the difference between #1 and #2, or why Rust helps with one and not the other. If memory safety is enforced, it's enforced. > Rust helps with #2 but let's not kid ourselves, what percentage of a library like glibc would be spent in unsafe blocks? string.h is not as interesting as, say, the DNS resolver. Nothing about the DNS resolver needs to be unsafe.

bluejekyll 11y ago
It's true. In my DNS code I have zero unsafe code. Though I did need to add some new unsafe code to the Rust OpenSSL library, but that's really because of the FFI to C. That too would be unnecessary if OpenSSL was rewritten in Rust.
- sgrove 11y ago
  What about binding to the OCaml implementation at https://nqsb.io/ https://nqsb.io/ ?
  - nostrademons 11y ago
    Wouldn't that require pulling in the OCaml garbage collector? Much of the reason people use glibc or other low-level libraries rather than a managed runtime is so they don't need to link in a managed runtime.
    - sgrove 11y ago
      Good point, I think it would indeed mean pulling in all of OCaml's runtime model.
- jononor 11y ago
  Does the OpenSSL library allow/plan for an Rust reimplementation (possibly side-by-side for a while) of the C bits? Seems that would be best practice - assuming the goal is make everything safe Rust.
  - bluejekyll 11y ago
    In theory that's just copying the Rust bridge code and using that as the frontend API for a rewrite. So yes it's possible, you "just" need to rewrite the rust-openssl-sys library. I think the hesitation there is that everyone has gotten it beaten into your head that writing new crypto libraries is dangerous. It's probably safer to use a library that has tons of eyes on it, but at some point we should do it.
    - jononor 11y ago
      Problem is that if this is not considered beforehand, one might create APIs which are very hard/tedious to replicate without the old/legacy implementation. But maybe for openssl staying close to the original API is useful, then one could maybe put a C API on top and use it also outside Rust.

unscaled 11y ago

OP article was specifically talking about Rustbelt as one tool you would be able to use in the future to mitigate the risks posed by the unsafe code you do have. But in general, I think that entire idea is that as more code moves to memory-safe languages, the less need we have for unsafe sections. Ideally, once the kernel itself can be written in a memory safe language, everything running on top of that wouldn't need much unsafe blocks. To be honest, this goal is probably decades away, but we should definitely be considering memory-safe languages for systems programming.

panic 11y ago
It's not decades away! Check out https://sel4.systems https://sel4.systems.
- cmrx64 11y ago
  And, relatedly, https://robigalia.org/ https://robigalia.org/
- deleted 11y ago
  [deleted]

tatterdemalion 11y ago

> what percentage of a library like glibc would be spent in unsafe blocks? Probably less than you think. What I think the limit is is that there are functions in glibc that present inherently unsafe interfaces. I'm not sure how many but it might be enough that writing libc in Rust is not that helpful.

andrewprock 11y ago
Once you admit unsafe blocks, you admit that Rust is unsafe. The value of porting from one unsafe language to another is probably only marginal.

bluejekyll 11y ago

> an avid Rust user puts their money where their mouth is There are lots of people doing this. Look at crates.io. I decided to write a new fully compliant DNS server and client, trust-dns. I work on it in my spare time (it's time not money), which is hard with two kids. I've learned a few things. It's hard to get it done. There's a lot to learn from the rfc's. Just because it's Rust, doesn't mean it's easy. There are all the same borrow rules, and I know I have a bunch of TODOs in the code to go fix things like extra clones. The IDEs, while good, are not on par with other languages yet. Basically it's a lot of work. And I commend the individuals who've paved the way for me with the std library in Rust, but we still have so much more work to do until there is a full OS env like GNU.

rubiquity 11y ago
Your entire post reinforces the idea that in my list of challenges to writing safe software that #1 is far more the issue than #2.
- bluejekyll 11y ago
  Yes. I'm agreeing that it's hard and takes a lot of energy. But people are doing it.

dikaiosune 11y ago

Re: amount of low level code needing unsafe blocks, its worth checking out this series that documents creating a bare metal kernel in rust that has lots of type safety and uses shockingly little assembly or unsafe: http://os.phil-opp.com/ http://os.phil-opp.com/

pjmlp 11y ago
C created this wrong perception that you need lots unsafe code, due to how it does strings and vectors. In all safe alternatives to C, just like Rust sure you need unsafe at the Assembly FFI level and hardware integration like IO ports and interrupt handling. But everything else can be just plain safe code.

nitrogen 11y ago

If someone wants to pay me to rewrite glibc in Rust, I'd gladly do it, as I'm sure lots of other devs would. It's actually something I've thought about doing as a hobby, but there are a million other hobbies above it on the list.

XorNot 11y ago
What we need is a way to coordinate the effort I suspect. Given we have glibc as a standard interface, a site which matched up function tests with implementations and made it obvious where to jump in could build a decent community.