4 ms·
> The symptoms are changed, but no less dangerous. Potentially even more dangerous. Having the program segfault immediately is much preferable to, say, Heartbl
by zrm 8y ago
> The symptoms are changed, but no less dangerous.
Potentially even more dangerous. Having the program segfault immediately is much preferable to, say, Heartbleed.
- barrkel 8y agoIf only we could guarantee immediate segfaults.
- kibwen 8y agoThat's literally what Rust compiler errors are doing. :P
- zrm 8y ago> If only we could guarantee immediate segfaults. It should be possible to create a malloc implementation that does that by making the minimum allocation size a page and then not reusing virtual addresses for new allocations. Then once an allocation is freed, any access to it is permanently a segfault. That may not be practical on existing architectures with 48-bit virtual addressing though, since you could plausibly exhaust the address space. The full 64 bits might be sufficient for most things at least. You could also get most of the benefit by not reusing virtual addresses until you run out.
- steveklabnik 8y agoIt's not, because that relies on actually doing the de-reference. Thanks to UB, that may never actually happen, the code may get removed entirely.
- zrm 8y agoIf the code is removed entirely then what memory is being improperly accessed?
- steveklabnik 8y agoIt's impossible to tell, as that can cause other issues. See the link I posted about time travel elsewhere in the thread.
- zrm 8y agoThe day will come when the compilers that do things like that will be righteously categorized as malware.
- the_why_of_y 8y agoThe day will come when language specifications that allow compilers to do things like that will be righteously categorized as archaic.
- kibwen 8y agoAny situation where C would segfault immediately, Rust would also segfault immediately. The only difference is that Rust references are an alternative to C pointers that provide stronger safety guarantees at the cost of restricting what is possible (in other words, the same tradeoff that all static analyses make, including every type system). You can also use C-style pointers in Rust, but you can get away with just using references the vast majority of the time, which gives you better memory safety guarantees at no runtime cost since references are just pointers at runtime (and they're often automatically marked as restrict pointers at that). You're not going to get Heartbleed in Rust by using references.
- kbwt 8y ago> Any situation where C would segfault immediately, Rust would also segfault immediately. For equivalent code, yes. The borrow checker can however compel you to write code that would not immediately panic in Rust, when the C code you would have written has at least a chance of segfaulting immediately or being detected with valgrind.
- kibwen 8y agoI'm afraid I don't follow. Can you give me an example of the borrow checker compelling one to write such a piece of code? I admit I can't think of an example of Rust code that would fail to panic when the equivalent C code would tend to segfault.
- zrm 8y agoThe issue isn't the equivalent of Rust code in C, it's C code without an equivalent in Rust. Rust should prevent the typical UAF bug in C, but if the programmer unwisely insists on using the same pattern in which they fail to track object lifetimes correctly, they can still implement it by using array indexes instead of pointers. Which can also be done in C (as was the case in Heartbleed), but it isn't as common, and is potentially worse than the usual C UAF because it produces a consistent successful out of bounds access rather than at least the possibility for a segfault. It's possible to prevent someone from doing something bad and have that cause them to do something worse. "Nothing is foolproof to a sufficiently talented fool" etc. Safer tools are not a replacement for competence.