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.