CHERI doesn't exist (Morello isn't available) and memory tagging is not a thing on most processors (especially not server or embedded which are where most Linux runs). Apple's MIE needs Asahi to reach M5 which won't happen for some years, and ARM servers are still quite new.
Meanwhile, Rust structurally enforces memory safety. It's simply a better option than C -- C needs closer scrutiny, more third-party static and dynamic analysis, conventions differ much more wildly, far more expertise is required, the bar to safe contribution is much higher, code review is more difficult, I could go on and on but they have reasons to prefer Rust and it's not just cargo culting. Memory safety is a huge reason to want Rust, but also the type system, monomorphized generics, traits, the great first-party package manager and build system, better developer experience, clearer semantics, ... I could go on.
That said, there are also downsides like hard reliance on LLVM, bad support for embedded or proprietary platforms, bad compile times, less flexibility in what is accepted by the borrow checker, more runtime checks and panics for safety, fragmented ecosystem, some basic things are "unstable", some semantics like pointer provenance still haven't been worked out after over a decade, semantics of borrowing are still in flux as well, etc.
These technologies are cool and good and useful but they do something different than Rust: they catch problems at runtime and mitigate the bad effects, rather than preventing them at compile time.
Automated transforms like this seem risky at best and dangerous at worst, due to one fundamental truth about computer software: garbage in, garbage out.
The transform can be perfectly correct, but any bugs in the input will be translated along with the rest.
Yet, I somehow doubt translation will be perfect, in that same way that translations among spoken languages have idioms that never quite carry across their full meaning.
So, yes, this can “reduce the risk”, but the nature of the tool seems to carry high inherent risk. I would hope no one tries to vibe this kind of transformation on a large legacy production code base without giving the results a line-by-line audit.
5 comments
[ 0.21 ms ] story [ 17.2 ms ] threadWhat about using CHERI or Memory Tagging? Rewriting an established and mature codebase seems like the wrong approach.
This seems less like "We want to prevent memory errors." and more like "We hate C, we want Rust."
Meanwhile, Rust structurally enforces memory safety. It's simply a better option than C -- C needs closer scrutiny, more third-party static and dynamic analysis, conventions differ much more wildly, far more expertise is required, the bar to safe contribution is much higher, code review is more difficult, I could go on and on but they have reasons to prefer Rust and it's not just cargo culting. Memory safety is a huge reason to want Rust, but also the type system, monomorphized generics, traits, the great first-party package manager and build system, better developer experience, clearer semantics, ... I could go on.
That said, there are also downsides like hard reliance on LLVM, bad support for embedded or proprietary platforms, bad compile times, less flexibility in what is accepted by the borrow checker, more runtime checks and panics for safety, fragmented ecosystem, some basic things are "unstable", some semantics like pointer provenance still haven't been worked out after over a decade, semantics of borrowing are still in flux as well, etc.
The transform can be perfectly correct, but any bugs in the input will be translated along with the rest.
Yet, I somehow doubt translation will be perfect, in that same way that translations among spoken languages have idioms that never quite carry across their full meaning.
So, yes, this can “reduce the risk”, but the nature of the tool seems to carry high inherent risk. I would hope no one tries to vibe this kind of transformation on a large legacy production code base without giving the results a line-by-line audit.