4 ms·

quiche may be great - I haven't tried it - but it definitely isn't memory safe. It uses unsafe constructs liberally.

by zik 3y ago

mcronce 3y ago
That doesn't mean it's not memory safe - it means that those constructs need to be thoroughly scrutinized for memory safety, which is significantly better than the entire codebase needing to be thoroughly scrutinized for memory safety
- zik 3y ago
  By that reasoning C is also memory safe.
  - mcronce 3y ago
    No? Your entire C codebase needs to be thoroughly scruitinized, whereas in Rust, you can build a small portion with unsafe code, thoroughly audit that, and build a sound abstraction on top.
josephg 3y ago
What does “liberally” mean here? Because without even looking at the code, I bet less than 5% of the code in quiche is unsafe. It’s probably about 2% or something. And remember, unsafe rust is still borrow checked and often run through Miri as well - which is crazy strict. Miri rejects a lot of correct programs. There is no comparison with C, where trivial programs exhibit UB and memory unsafety all the time, and the standard library is covered in foot guns. I really dislike the puritan wing of the rust community who see the unsafe keyword as some sort of blight to be excised. Unsafe is a necessary and important part of the language. It is needed for lots of reasons - like how you can’t make high performance container types in purely safe rust. Or to interact with code written in other languages. Unsafe is not a devils mark. It’s a good and useful tool. Get over it.
- nine_k 3y ago
  It often suffices to find one remotely triggerable unsafe memory write in a huge executable to achieve RCE. Memory safe would be 0% unsafe.
  - minitech 3y ago
    “n% unsafe” here refers to `unsafe` blocks that can’t be automatically guaranteed safe by the Rust compiler, not to actual concrete instances of memory unsafety.
    - josephg 3y ago
      Right. And even if you only work in “safe rust”, a massive part of the software stack you rely on still isn’t formally verified like that. LLVM and rustc aren’t formally verified - and they likely have bugs. The kernel is all “unsafe” code. And the rust standard library is full of unsafe code. And so on. Moving heaven and earth to excise the last 2% of unsafe code in random rust libraries just doesn’t make engineering sense. Especially when doing so comes with a significant performance cost. If reliability is what you’re after, that time is almost certainly better spent adding more tests, fuzz testing and validating your code with Miri and friends.
rapsey 3y ago
Examples, tests and interfacing with C are almost all the instances of unsafe.
- zamalek 3y ago
  I assumed the FFI would be the unsafe bit, you can't interact with an unsafe language from a safe context - the mere act of dereferencing a pointer that originates from unsafeland is fraught with UB.

quiche may be great - I haven't tried it - but it definitely isn't memory safe. It uses unsafe constructs liberally.

by zik 3y ago

quiche may be great - I haven't tried it - but it definitely isn't memory safe. It uses unsafe constructs liberally.

That doesn't mean it's not memory safe - it means that those constructs need to be thoroughly scrutinized for memory safety, which is significantly better than the entire codebase needing to be thoroughly scrutinized for memory safety

zik 3y ago
By that reasoning C is also memory safe.
- mcronce 3y ago
  No? Your entire C codebase needs to be thoroughly scruitinized, whereas in Rust, you can build a small portion with unsafe code, thoroughly audit that, and build a sound abstraction on top.

josephg 3y ago

What does “liberally” mean here? Because without even looking at the code, I bet less than 5% of the code in quiche is unsafe. It’s probably about 2% or something. And remember, unsafe rust is still borrow checked and often run through Miri as well - which is crazy strict. Miri rejects a lot of correct programs. There is no comparison with C, where trivial programs exhibit UB and memory unsafety all the time, and the standard library is covered in foot guns. I really dislike the puritan wing of the rust community who see the unsafe keyword as some sort of blight to be excised. Unsafe is a necessary and important part of the language. It is needed for lots of reasons - like how you can’t make high performance container types in purely safe rust. Or to interact with code written in other languages. Unsafe is not a devils mark. It’s a good and useful tool. Get over it.

nine_k 3y ago
It often suffices to find one remotely triggerable unsafe memory write in a huge executable to achieve RCE. Memory safe would be 0% unsafe.
- minitech 3y ago
  “n% unsafe” here refers to `unsafe` blocks that can’t be automatically guaranteed safe by the Rust compiler, not to actual concrete instances of memory unsafety.
  - josephg 3y ago
    Right. And even if you only work in “safe rust”, a massive part of the software stack you rely on still isn’t formally verified like that. LLVM and rustc aren’t formally verified - and they likely have bugs. The kernel is all “unsafe” code. And the rust standard library is full of unsafe code. And so on. Moving heaven and earth to excise the last 2% of unsafe code in random rust libraries just doesn’t make engineering sense. Especially when doing so comes with a significant performance cost. If reliability is what you’re after, that time is almost certainly better spent adding more tests, fuzz testing and validating your code with Miri and friends.

rapsey 3y ago

Examples, tests and interfacing with C are almost all the instances of unsafe.

zamalek 3y ago
I assumed the FFI would be the unsafe bit, you can't interact with an unsafe language from a safe context - the mere act of dereferencing a pointer that originates from unsafeland is fraught with UB.