4 ms·
Why does this point to a hardware-level protection rather than simply removing the dependency on C? I mean wouldn't moving to rust mitigate most of these vulner
by monadic2 6y ago
Why does this point to a hardware-level protection rather than simply removing the dependency on C? I mean wouldn't moving to rust mitigate most of these vulnerabilities? I can't help but think that if hardware protection from vulnerabilities were useful we would have enabled them 30-40 years ago.
I just don't see any value of this to the end-user: the result (a crash) is the same.
If they can get it to work it might be beneficial, but it would also validate the idea that C is broken as a system language because it can't know at compile-time whether or not an fault will occur on memory access, which has been proven to be the correct way to reason about memory.
- pjmlp 6y agoBecause it still won't protect against unsafe code in Rust. // very contrived example fn main() { let mut data = vec!(1, 3, 4); unsafe { let ptr = data.as_mut_ptr(); *(ptr.offset(1024)) = 1; } } At some level there is some unsafe code, even if in pure Assembly. There problem with C is that it taints everything due to strings, arrays and UB. By the way, Android is also taking steps to introduce Rust on its codebase, hence the talks started by Google at Linux Plumbers conference. As much as I love to rant on C, as long as POSIX based software is relevant, if WG 14 isn't willing to improve its security, hardware solutions are the only way.
- monadic2 6y agoAlright I guess I see what you’re saying, and this does seem like natural progress from address sanitization.