alilleybrinker

It’s in the book. That’s the entire point of the book.

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!

Did you read the article? The author makes exactly that point.

Wired should retract this homophobic article.

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.

I am appalled that Wired published this.

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.

[1] https://www.alilleybrinker.com/mini/rusts-culture-of-semanti...

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.

There's also the Common Weakness Enumeration (CWE), a long-running taxonomy of software weaknesses (meaning types of bugs).

https://cwe.mitre.org/

The project maintainers had to both:

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]

[1] https://www.alilleybrinker.com/blog/cpp-must-become-safer/

[2] https://security.googleblog.com/2024/09/eliminating-memory-s...

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.

[1] https://www.cnn.com/2023/01/06/business/walgreens-shopliftin...

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.

[1] https://lwn.net/ml/all/2024092614-fossil-bagful-1d59@gregkh/

Mickos is quoted:

"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!

Very interested in exploring how this will compare to Diesel [1] and SeaORM [2], the other two options in this space today. Joshua Mo at Shuttle did a comparison between Diesel and SeaORM in January of this year that was really interesting [3].

[1] https://diesel.rs/

[2] https://www.sea-ql.org/SeaORM/

[3] https://www.shuttle.dev/blog/2024/01/16/best-orm-rust

In part two, the author explains trait objects in a way that is, I think, a little misleading.

They're right that trait objects are dynamically sized types, which means they can't be passed by value to functions, but wrong that they need to be boxed; they can instead be put behind a reference. Both of the following are valid types.

  type DynFutureBox = Pin<Box<dyn Future<Output = ()>>>;
  type DynFutureRef<'f> = Pin<&'f dyn Future<Output = ()>>;

Code patterns are social! What is strange to one is normal to another.

The kind of pattern used here with the `||` might seem weird to some JavaScript developers, but it's pretty normal in shell scripts, and it's pretty normal in Ruby with `unless`!

There is no such thing as universally self-documenting code, because self-documentation relies on an assumption of an audience — what that audience knows, what patterns are comfortable for them — that does not exist in general.

Self-documenting code can work in a single team, particularly a small team with strong norms and shared knowledge. Over time as that team drifts, the shared knowledge will weaken, and the "self-documenting" code will no longer be self-documenting to the new team members.

You are mistaken. The work described here is based on this paper, currently published as a preprint: https://www.medrxiv.org/content/10.1101/2024.08.15.24312078v...

This preprint is the first link in the article.

Yeah, I think you're conflating the arguments of "Weapons of Math Destruction" and "The Unaccountability Machine" here.

"The Unaccountability Machine," based on Mandy's summary in the OP, argues that organizations can become "accountability sinks" which make it impossible for anyone to be held accountable for problems those organizations cause. Put another way (from the perspective of their customers), they eliminate any recourse for problems arising from the organization which ought to in theory be able to address, but can't because of the form and function of the organization.

"Weapons of Math Destruction" argues that the scale of algorithmic systems often means that when harms arise, those harms happen to a lot of people. Cathy argues this scale itself necessitates treating these algorithmic systems differently because of their disproportionate possibility for harm.

Together, you can get big harmful algorithmic systems, able to operate at scale which would be impossible without technology, which exist in organizations that act as accountability sinks. So you get mass harm with no recourse to address it.

This is what I meant by the two pieces being complementary to each other.

Cathy O'Neil's "Weapons of Math Destruction" (2016, Penguin Random House) is a good companion to this concept, covering the "accountability sink" from the other side of those constructing or overseeing systems.

Cathy argues that the use of algorithm in some contexts permits a new scale of harmful and unaccountable systems that ought to be reigned in.

https://www.penguinrandomhouse.com/books/241363/weapons-of-m...

Steel seems alright: https://github.com/mattwparas/steel

There are other Lisps too (https://github.com/alilleybrinker/langs-in-rust) though I think they’re less actively maintained.

Orin Kerr's analysis of this new ruling, which is linked from the Tech Crunch article, helps break down where the specific splits with other courts lie. This is useful even if you don't agree with Kerr's analysis of the validity of any specific courts' decisions: https://reason.com/volokh/2024/08/13/fifth-circuit-shuts-dow...

Since they actually make a product using their patented technology, they would definitionally not be a patent troll. Even if they’re litigious, that’s exactly how the system is supposed to work when you’ve invented a valuable technology which you sell to recoup the costs of R&D plus the profit of your invention.