Earlier quoted context omitted.
> A rewrite would clean up the code, sure, but then you're left in the same situation, only with brand new bugs that nobody has time to fix. The entire point is that you're not in the same situation regarding memory safety problems/vulnerabilities.
Memory safety problems are the low-hanging fruit of vulnerabilities. A re-write by unskilled programmers will not guarantee the code is safe, because they will introduce many other kinds of vulnerabilities.
Rewrite Everything in Rust
51–60 of 242 posts
Re: Rewrite Everything in Rust
#52Earlier quoted context omitted.
Isn't that just what a compiler is, where the target language is machine code?
I realize something like glibc would be the LAST set of source code to run through a transpiler, but how hard do folks think it would be to make a C -> Rust transpiler? I'd think you'd go about it by making Rust a target backend for LLVM. This way you let LLVM deal with the all C stuff (macros, etc), and just focus on the internal representation to Rust conversion. In theory, you'd get C++ to Rust as well. Chances is…
Why do you want to do that? The only way to make it work short of doing years and years of static analysis research to automatically translate ad-hoc memory management disciplines into those of Rust (that I think will not succeed anyway) would be to compile to unsafe code. And if you compiled to unsafe Rust code, there would be no gain.
Re: Rewrite Everything in Rust
#53Is there a "glibrust" or equivalent standard library for Rust, yet?
Rust of course has a standard library[0] and it includes a libc, but (I might be wrong here) I think the libc portion is FFI into glibc or similar. I think the stuff written in rust is considerably more high-level, focusing more on data structures, concurrency, string manipulation, etc. [0]: https://doc.rust-lang.org/std/
Re: Rewrite Everything in Rust
#54Earlier quoted context omitted.
> A rewrite would clean up the code, sure, but then you're left in the same situation, only with brand new bugs that nobody has time to fix. The entire point is that you're not in the same situation regarding memory safety problems/vulnerabilities.
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…
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.
Re: Rewrite Everything in Rust
#55Re: Rewrite Everything in Rust
#56Earlier quoted context omitted.
> A rewrite would clean up the code, sure, but then you're left in the same situation, only with brand new bugs that nobody has time to fix. The entire point is that you're not in the same situation regarding memory safety problems/vulnerabilities.
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…
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.
Re: Rewrite Everything in Rust
#57Earlier quoted context omitted.
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…
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…
Re: Rewrite Everything in Rust
#58Earlier quoted context omitted.
Isn't that just what a compiler is, where the target language is machine code?
I realize something like glibc would be the LAST set of source code to run through a transpiler, but how hard do folks think it would be to make a C -> Rust transpiler? I'd think you'd go about it by making Rust a target backend for LLVM. This way you let LLVM deal with the all C stuff (macros, etc), and just focus on the internal representation to Rust conversion. In theory, you'd get C++ to Rust as well. Chances is…
Re: Rewrite Everything in Rust
#59Earlier quoted context omitted.
Have you even looked at the source code to glibc? It's stuffed full of macros and #ifdef hell. Not to mention symbol versioning, the use of gcc-specific compiler extensions, and ancient-UNIX-beard performance hacks. You'd have more success teaching a chimpanzee to play the violin, than automatically translating glibc into anything.
I've seen a lot of weird preprocessor (ab)use in GNU code. The coreutils true/false (of all programs to invoke clever preprocessor tricks...) has this gem: in true.c (all told, an 80-line file): /* Act like "true" by default; false.c overrides this. */ #ifndef EXIT_STATUS # define EXIT_STATUS EXIT_SUCCESS #endif false.c, of course, contains only: #define EXIT_STATUS EXIT_FAILURE #include "true.c" On my current system…
Re: Rewrite Everything in Rust
#60Earlier quoted context omitted.
> A rewrite would clean up the code, sure, but then you're left in the same situation, only with brand new bugs that nobody has time to fix. The entire point is that you're not in the same situation regarding memory safety problems/vulnerabilities.
Yeah, I'm not saying that a rewrite is necessarily a bad idea or that it wouldn't improve things (though writing a drop-in replacement for something like glibc in Rust sounds pretty challenging to me). The situation I'm talking about is the one where no one has an incentive to improve the software day-to-day. If we really want to fix the problem, we should also look at how it got that way.