The section on how to do software assurance of unsafe code in Rust is excellent.
A lot of prior guidance I've seen tends to stop at the level of running Miri, but (as the article says) there are things Miri won't catch. The model-based tests with a known-good oracle and the use of fault injection (especially panic-related behavior) are really good.
Safety in the face of panics in Rust can be hard to reason about, and the standard library itself has made errors with those semantics in the past.
Great work Rain and Oxide for building something so useful and assuring it so robustly!
It takes an issue of people in power abusing that power, and ties it to their sexuality, as if the men abuse their power because they’re gay, or as if straight men never do similarly.
Identifying abusive power structures is good, but writing about it in a way that centers the sexuality of the participants has the effect of demonizing a whole group of people unfairly.
In situations like this I appreciate that Rust has a culture of semantic precision [1] and while this kind of API-clarification is painful in the short-term, I think it will be worth it for Linux.
For the disjoint field issues raised, it’s not that the borrow checker can’t “reason across functions,” it’s that the field borrows are done through getter functions which themselves borrow the whole struct mutably. This could be avoided by making the fields public so they can be referenced directly, or if the fields needs to be passed to other functions, just pass the the field references rather than passing the whole struct.
There are open ideas for how to handle “view types” that express that you’re only borrowing specific fields of a struct, including Self, but they’re an ergonomic improvement, not a semantic power improvement.
1) Decide to use the highly risky `pull_request_target` Actions trigger instead of the much safer `pull_request` trigger, 2) include in their Actions a script, executing in an environment with write access to the repo and access to repository secrets, which executes untrusted input (the branch name).
The repository maintainers are running actions for PRs with the `pull_request_target` trigger, which gives full access to target repository secrets with write permissions. It's very explicitly documented as dangerous to do this. To mitigate the risk, `pull_request_target` actions run on the state of the target branch, not the source branch, but in this case because the target branch has this script which executes code influenced by an untrusted data source (the branch name), you get this vulnerability.
There’s likely some amount of code which would not be rewritten into Rust but which would be rewritten into safe C++. Migrating to a whole new language is a much bigger lift than updating the compiler you’re already using and then modifying code to use things the newer compiler supports. Projects do the latter all the time.
Alternatively, Rust's cell types are proof that you usually don't need mutable aliasing, and you can have it at hand when you need it while reaping the benefits of stronger static guarantees without it most of the time.
Not everything will be rewritten in Rust. I've broken down the arguments for why this is, and why it's a good thing, elsewhere [1].
Google's recent analysis on their own experiences transitioning toward memory safety provide even more evidence that you don't need to fully transition to get strong safety benefits. They incentivized moving new code to memory safe languages, and continued working to actively assure the existing memory unsafe code they had. In practice, they found that vulnerability density in a stable codebase decays exponentially as you continue to fix bugs. So you can reap the benefits of built-in memory safety for new code while driving down latent memory unsafety in existing code to great effect. [2]
The article makes the particularly good point that you generally can’t effectively add new inferences without constraining optionality in code somehow. Put another way, you can’t draw new conclusions without new available assumptions.
In Sean’s “Safe C++” proposal, he extends C++ to enable new code to embed new assumptions, then subsets that extension to permit drawing new conclusions for safety by eliminating code that would violate the path to those safety conclusions.
It ought to be easier to get a blank slate of a small device with some compute power and a screen, like the Kindle here, without having to jailbreak something.
Nice to see they identified Rust as a common language across many of the categories they surveyed! They specifically call out tooling, even for other languages, being written in Rust. As someone who myself builds a lot of CLIs in Rust, I think it’s great for that use case and hope it continues to grow!
Here’s an article [1] quoting Walgreens’ CFO who, on an earnings call in early 2023, offered that Walgreens had in prior quarters likely overblown the level of shrink they were experiencing and expected to experience (“shrink” is the industry term for lost revenue due to theft and other causes).
Obviously this is more than a year ago, so it’s possible the facts on the ground have changed. However, this is reasonable evidence that at least as of a year ago, their shrink numbers were enough to be downplayed on an earnings call with investors.
Right. A huge part of the value proposition of enterprise kernels is the stability, which you pay a cost for in the form of backporting and maintenance. That’s the thing that makes it valuable as a product!
It really can’t be the policy of the upstream to restrain enhancements because they might make backports harder. Companies get paid, and paid well, to do those backports! Let them be responsible for that burden.
Greg KH's comment about not letting yourself be limited today by the needs of commercial users of old kernels is a good one [1]. That would be a tail wagging the dog situation, where newer APIs can't improve beyond the support that's available in old kernels. If that were the constraint, then improvements which rely on available toolchains would have to wait years for those toolchains to read wide enough distribution to users with slow adoption schedules for new kernels before you could even think of building on those toolchains.
"The power of open source is not that we agree and get stuff done; it is that we disagree and get stuff done. That’s the true power when you have a governance model that allows people who have nothing in common to produce something in common."
Which is a nice sentiment; but open source is not a governance model!
Open source is a licensing model, and can support any governance
model alongside it. Open source projects can be consensus-based,
authoritarian (Benevolent Dictator for Life), democratic, corporate,
and more!
Maybe he meant "collaboration model," but again open source does
not have to be collaborative. There are successful open source
projects which do not accept contributions, like SQLite, for
example.
I definitely agree on the mission alignment and strong ethical orientation of non-profit work being a big motivator. I've worked for MITRE, a non-profit that runs Federally Funded Research & Development Centers (you might remember us from such projects as the CVE system and the ATT&CK framework) for more than 9 years, and I'm still happy to be here!
It's a different environment from most non-profits with MITRE, in part because we're big and funded directly by the federal government under the unique FFRDC arrangement (which functions differently from things like federal grants). But the idea of being mission-oriented and getting to solve problems to make people's lives better is still a big component!