2 ms·
> Rust isn't going to help you with that. As I noted elsewhere in this thread ( https://news.ycombinator.com/item?id=14753692 https://news.ycombinator.com/item
by ekidd 9y ago
> Rust isn't going to help you with that.
As I noted elsewhere in this thread ( https://news.ycombinator.com/item?id=14753692 https://news.ycombinator.com/item?id=14753692 ), I've actually been working on a low-level media decoder in Rust. Compared to my earlier work in C (the xmlrpc-c library, for example), my Rust code has stood up very well to heavy fuzzing. My xmlrpc-c code, on the other hand, was written with ridiculous levels of paranoia, and it has been the subject of multiple CVEs thanks to a third-party XML parser I used.
So in terms of practical engineering reality, Rust seems to make a big difference. And even more importantly, it means I can trust other people's libraries a bit more.
Rust's practical advantages seem to be:
1. Runtime bounds checks! I wouldn't have thought that this was the most important thing, but when fuzzing, it's the last line of defense against quite a few potential exploits.
2. Debug-mode checks for integer overflow. Rust defines integer overflow as an error, and debug builds will actually check for it. This turns out to work really well with fuzzers.
3. The borrow checker. In my experience, this is actually less useful than (1) and (2) above in terms of preventing security bugs. But it does help.
So as somebody who's written parsers for untrusted data in both C and Rust, I definitely found that Rust helped me a lot. Of course, Rust can't help with some forms of stupidity, such as writing a bad custom memory allocator and using it to handle key material. OpenSSL's problems go well beyond the ordinary hazards of C.
- pjmlp 9y ago> 1. Runtime bounds checks! I wouldn't have thought that this was the most important thing, but when fuzzing, it's the last line of defense against quite a few potential exploits. C.A.R Hoare talking in 1981 about how their Algol compiler customers reacted to the proposal of turning off bounds checking. "Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law." The mainstream adoption of UNIX and with it, C, made many without the knowledge of how computing outside AT&T walls since the dawn of computing looked it, to cargo cult ideas that were proven wrong elsewhere. But given that victorious get to re-write history and UNIX got adopted by the enterprise, those OSes written in safer systems programming languages get forgotten. The recent example was to learn about PL/8 and how IBM used it, in a compiler framework similar to LLVM, to do the research that lead to RISC. http://rsim.cs.illinois.edu/arch/qual_papers/compilers/auslander82.pdf http://rsim.cs.illinois.edu/arch/qual_papers/compilers/ausla... Imagine that! The RISC computer was designed using an OS written in a system programming language using Algol safety checks, including bounds checking, in the 70's. EDIT: Added a link to the PL/8 research paper.