This is something I’ve always wanted from a type system, or a way to make it if you can easily make custom types. Especially for strings, bags of bytes are easier. Seems like it could help in a lot of circumstances with security issues.
Writing a web app? All user input is untrusted until you process it. And if Untrusted<String> can’t be converted to String accidentally then it forces the programmer to think about it.
Unfortunately in Java (my everyday language) this isn’t feasible. I’d want to be able to join or process Untrusted<String> the same as normal. Really it would need to be built into the stars library.
Back to the article it sounds like this could work really well for the kernel. I hope this kind of idea catches on outside of that.
bjackman 141 days ago [-]
It's worth noting that in the kernel there's more to "user data" than just the fact that its content might be crafted maliciously:
- it might get swapped out or migrated, meaning your thread goes to sleep if you touch it.
- it can always change concurrently.
- the pointer is only valid within the current context (coz it's a pointer into the user address space).
- I've actually never thought about this before but also the user could free it concurrently I think?
So there's actually already C APIs in the kernel that force you to be aware of this, at least for strings (stuff where the user passes a pointer to their memory). There's also fancy compiler stuff for marking struct fields as pointing to user data, which IIUC can be used to detect if you're forgetting to use the right conversion APIs.
This isn't the case for values passed in registers though so I think Trusted<u64> would be totally new.
ANYWAY, overall: this is cool and good but it's actually one of the lower-impact things from Rust in the kernel IMO. I don't think the bugs that this prevents are actually all that common in practice. TOCTOU would be the biggest one by far but they are rare compared to the daily deluge of incredibly basic UAF bugs that Rust also prevents.
tux3 141 days ago [-]
>I've actually never thought about this before but also the user could free it concurrently I think?
Yup. But if you only send it back to the malloc heap, the kernel doesn't notice, it will happily read data that has been freed.
Unless the data is unmapped, then the kernel is going to get a page fault while trying to read your input. What goes up must come down, so that gets translated to SIGSEGV, and the program stops.
cyphar 141 days ago [-]
The kernel doesn't give you SIGSEGV in that case -- you will usually just get -EFAULT. All user pointer accesses are scoped with user_access_begin() and user_access_end() (or something equivalent) which stops the block of data from being unmapped by another thread -- of course, if this mechanism didn't exist then you would get a kernel oops if there was a concurrent munmap(2).
cyphar 140 days ago [-]
I looked at it again and the story is more complicated -- user_access_begin() is actually just a memory barrier on x86 and so doesn't take mmap_sem like I thought. It looks like each get_user() independently checks that the pointer is valid and access_ok() is actually just a fast path. You will still get -EFAULT in the unmapped case though.
bjackman 141 days ago [-]
But the question mark was coz I was wondering if there's some process global lock that would prevent it.
I think I was thinking of the mmap lock. But this was a dumb question mark, this lock isn't just randomly taken when threads enter syscalls. So yeah this is indeed another reason why copy_from_user etc is needed.
lock1 141 days ago [-]
Why is that not feasible? You could define `Untrusted<T>` container and `.map()` in Java just fine.
lmm 141 days ago [-]
Java lacks higher-kinded types, so there is no library of helpful functions that work on anything with a .map() method. E.g. if you want to do a tree traversal you'll have to implement it by hand.
taktoa 141 days ago [-]
Rust and C++ implement generics with monomorphization rather than boxing, so there is a potential performance hit associated with a type like this in Java that is guaranteed not to exist in Rust.
In practice, the JVM may still monomorphize it, but it is not guaranteed to, and this would be a good reason to avoid unnecessary uses of generics in a high performance codebase like a kernel, if you chose to write one in Java.
lock1 141 days ago [-]
Sure, I guess that's worth mentioning in the context of the original post. It's true that Java implementation of parametric polymorphism has a performance drawback compared to Rust or C++. And it's certainly a bad idea to use Java generics without considering the drawback in hot code paths.
But GP described something they wanted from a type system and basically said container with `Functor`-like behavior is not possible to do in Java. It's possible, albeit with a performance drawback and a bit more clunky to work with compared to Rust, Haskell, or a language with native HKT support.
wavemode 141 days ago [-]
the parent commenter states that Java is their everyday language, so in this context I don't think we're talking about performance, nor about the needs of the kernel.
menaerus 141 days ago [-]
Yes, it can be implemented basically in any language that can hide the data members so I also see nothing special about it.
surajrmal 141 days ago [-]
It's only special when you are coming from C. Kernels implemented in c++ have done this sort of thing for a long time.
kimixa 141 days ago [-]
There's plenty of C string libraries with opaque types. No reason why a similar thing can't be done there.
menaerus 141 days ago [-]
Opaque types cannot be stack- or statically allocated.
kimixa 141 days ago [-]
No, but many languages already have limitations like "strings live on the heap", even many discussed in this thread.
Dynamically sized objects on the stack has always been difficult. You could argue that C special casing fixed length strings to allow that is the odd one out.
ViewTrick1002 141 days ago [-]
Not really. Hiding the data is the easy part.
What makes Rust special is that you need to acknowledge the potential errors when unwrapping the type. With a standard library and culture built on exposing the edge cases at compile time.
That is where the guarantees and feeling of certainty comes from.
jeroenhd 141 days ago [-]
That's not a language feature as much as it is a culture and standard library feature.
For instance, Java could do the same, but in practice conversion methods throw runtime exceptions that you won't be warned about and your code will randomly crash if conversions fail, except in some cases when it doesn't. For casting between numeric types the language does have some legacy cruft, but for web applications nothing is stopping you from doing this. Java's explicit exception system is great at forcing developers to deal with potential failures, but in practice Java developers chose not to deal with exceptions so often that exceptions now get hidden.
Rust does this stuff in the standard library and that gives you the advantage that you don't need to explain the concept and convince every developer that this is a good idea. The same way Java has optional nullability annotations that are rarely used in practice because not every developer feels like adding them, unlike languages where nullability is part of the type system.
The concept is not exclusive to Rust, but I also haven't found it very popular outside of Rust developer circles.
baq 141 days ago [-]
I'm happily using this pattern in TS to wrap DB ids to avoid mistakenly passing e.g. user id to a function accepting a thing id or vice versa. Works very well and prevented a few close calls. I'd call it a type system feature, especially if you pack the id in a nominal type.
cleartext412 140 days ago [-]
> Java's explicit exception system is great at forcing developers to deal with potential failures, but in practice Java developers chose not to deal with exceptions so often that exceptions now get hidden.
Every time I see someone bringing up the idea of adding checked exceptions to a language (usually in these endless exceptions vs returning errors debates), it is met with "it won't work, look at Java", and it feels like a real shame. I'm sure complications of additional syntax would pay off just as fast as it does for regular type annotations.
lock1 141 days ago [-]
Visibility modifier as a native language feature is not the easy part.
It's more like "comptime safety feeling" => "language w/ visibility modifier" but the converse is not necessarily true. Without language support, it's back to C convention or workaround again.
menaerus 141 days ago [-]
Show me an example. I don't understand this marketing lingo.
ViewTrick1002 141 days ago [-]
Take for example working with file names and paths. In for example Linux paths are a collection and bytes and does not need to be valide unicode. Which some programming languages hides from you and subtly introduces errors. Or even worse, accepting that strings may contain invalid unicode poisoning the entire language with uncertainty.
If you are iterating over the files in a directory the Rust standard library gives you paths. Not strings.
To convert a path that to a regular string type which is valid unicode you need to acknowledge that the path may be invalid. Either unwrapping and panicking or handling the error.
To do this the standard library gives two options:
/// Yields a [`&str`] slice if the `Path` is valid unicode.
///
/// This conversion may entail doing a check for UTF-8 validity.
/// Note that validation is performed because non-UTF-8 strings are
/// perfectly valid for some OS.
pub fn to_str(&self) -> Option<&str>
/// Converts a Path to a Cow<str>.
///
/// Any non-UTF-8 sequences are replaced with U+FFFD REPLACEMENT CHARACTER.
pub fn to_string_lossy(&self) -> Cow<'_, str>
You get to make a choice, and panicking/erroring is perfectly valid if you only expect valid unicode paths.
As the world and your software changes if you suddenly encounter a non-unicode path then you will immediately know where the error comes from and can fix the issue. Instead of trying to pinpoint the root source of an error far exposing itself far down stream.
menaerus 141 days ago [-]
You said
> With a standard library and culture built on exposing the edge cases at compile time.
So, how exactly is "you need to acknowledge that the path may be invalid" from your example a compile-time trait? That's certainly not something you know during the compile-time, and if so, then you should be treating all the files like that, so, I see no difference here wrt other languages.
ViewTrick1002 141 days ago [-]
Take the function signature:
pub fn to_str(&self) -> Option<&str>
An option is an enum (tagged union)
pub enum Option<T> {
None,
Some(T),
}
To get the data out of the Some variant you need to match on it. If you don't cover the the None variant with a choice it will not compile.
let my_valid_string = match path.to_str() {
Some(path) => path,
None => todo!("Cover invalid unicode case"),
}
You can see this in the playground here were I deliberately did not cover the None path leading to the compiler telling me I need to make a choice.
We can't know if a generic path is valid at compile time. But we can at compile time ensure that we must acknowledge and make a choice for the invalid case.
This now (in)famous blogpost on Go is what happens when you just pretend that everything works:
> We can't know if a generic path is valid at compile time. But we can at compile time ensure that we must acknowledge and make a choice for the invalid case.
While a pragmatic choice, in reality it isn't very practical IMO. Most of the times you really don't know what to do with the error so you end up turning the condition either into an exception, because it really is an exceptional case, and/or assert on it as an invariant that is broken and which you believe is a programming (usage) error. In any case, you don't really know how to handle it well, and this is I believe often the case for kernel design too - they will try to eliminate as much as possible such cases with testing because they can't afford to panick during the runtime because that would actually be detrimental for QoS.
Even in C++ you have something not quite the same but similar with [[nodiscard]] qualifier but in practice I haven't really seen it being used much but when I did it was mostly annoying to deal with. It's like a hot potato that is being thrown across the API boundaries but nobody wants to deal with it.
johnisgood 141 days ago [-]
OCaml, Haskell, Kotlin, and Swift has this, too...
scns 141 days ago [-]
There are at least some unikernels written in OCaml IIRC, don't know about kernells written in Haskell.
Long story short: rust is buggy because it cannot handle paths that are not unicode ? :)
MBCook 141 days ago [-]
Since I do web apps Strings are my bread and butter.
If you make UntrustedString a subclass of String (trusted) then you lose type safety. So TrustedString has to be the subclass. Easy enough.
But now string literals are “untrusted”. So you have to do new String(“this is trusted content”) everywhere you need it, which is a pain.
And you can’t add trusted strings. The operator will return a normal String (untrusted) so you have to cast it. Same with any function you call like substring.
So you have to live with that, or make overrides for every single string function that fix the types where necessary.
It’s just really non-ergonomic. I think having it built in would likely make it far better.
lock1 141 days ago [-]
> But now string literals are “untrusted”. So you have to do new String(“this is trusted content”) everywhere you need it, which is a pain.
Eh? Isn't that the main point of doing all of this? Being explicit on the boundaries but still providing a way to manipulate them like a String?
I don't see anything wrong with `new Validated("literal")` (or functional friendly `Validated.of("literal")`). If you intend to create a `Validated`, then create it via constructor / static factory method that enforces necessary validations to create `Validated`.
> So you have to live with that, or make overrides for every single string function that fix the types where necessary.
Like `Optional<T>` and `Stream<T>`, you could define `Validated::map(Function<? super String,String>)` if you want. With `map()`, you could operate `Validated` with anything that accepts `String` like usual.
With that said, I don't recommend using `Validated` in your actual Spring project though, use (OOP) value objects instead. I used value objects quite a lot on my legacy Spring project. It plays nicely with functional-style, cover "validation" stuff, and avoiding primitive obsession. Putting `String` on `UserId` will result in a loud compiler error.
blibble 141 days ago [-]
of all languages, perl supported this as a first class feature, "tainting"
k_bx 141 days ago [-]
After jumping from no-embedded-knowledge to a forced situation where I needed to produce something working, I've played a bit with Rust-for-Embedded, and it has exactly this approach when working with various ports and devices (UART, clocks etc.). And oh by is this approach practical! While still very possible, it does make a large move towards compiler not letting you shoot in the foot.
lock1 141 days ago [-]
Interesting.
Though it reminds me of Alexis's "Parse, don't validate", isn't `syscall :: u8 -> Untrusted<u8>` considered as "validate"?
I hope kernel codes that consume it will transform it to appropriate type as well `Untrusted<u8> -> T`.
vlovich123 141 days ago [-]
The kernel is different because it’s not safe to access Untrusted until you copy it locally. Only then can you start parsing. Otherwise you run the risk of TOCTOU security vulnerabilities parsing user space input which then changes the next time you try to access it.
Untrusted doesn’t validate - it just ensures you don’t accidentally access the data until you’ve ingested data that could be potentially attacking you.
pjmlp 141 days ago [-]
You can do this kind of type oriented programming in C++, unfortunely as many people only use it as a better C, this knowledge is seldom widespread, and even when demoing, it needs a lot of advocacy alongside compiler explorer to actually make the point across.
And then the audience will nod yes, accept the message of what is possible, and go back to whatever approach they were doing already.
ultimaweapon 141 days ago [-]
Rust give more ergonomic to this. In C++ it need a lot of typing for creating a new type compared to Rust.
jeroenhd 141 days ago [-]
You need to add a lot of text, but the text contains about the same semantic meaning. It's a lot of typing but that's a matter of density rather than ease of use.
At least in modern c++. Then again, modern C++ seems to play the same role as modern Java, in that some places use it but most of them are stuck at the version they picked when they started developing on a piece of software decades ago.
pjmlp 141 days ago [-]
To be fair to modern C++, or lack thereof, I would assert most places being stuck with specific versions applies to any programming language that traces back to the 20th century.
Turns out updating software versions in most companies is really hard, and updating humans atittude to specific programming practices even harder, unless their job is on the line.
vlovich123 141 days ago [-]
Rust has solved the problem of upgrading at the language level - you can mix’n’match modules targeting different revisions of the language just fine and you can mix’n’match multiple versions of the same library within a single binary. It makes the whole thing possible to do piecemeal.
pjmlp 141 days ago [-]
Only if there are no incompatible changes on the standard library, public interface or observable semantic behaviours.
And even so, it doesn't matter if IT says no, or the customer doesn't pay for consulting services to upgrade existing projects.
vlovich123 141 days ago [-]
I’ve never seen IT be involved in a decision about the language edition being selected by a development team or even which dependency to pick. As for consulting, that’s a different type of world that’s not the best example of good software development practices.
As for incompatible changes, there aren’t any in Rust by design. That limits some of the changes they can make even in an edition but in practice it works ok. Even over a longer time span, I think the Rust community will figure out a way to trim irrelevant cruft away.
pjmlp 141 days ago [-]
It happens all the time, in many companies IT decides the images used on the build servers, or cloud instances for developers.
I am not so optimistic when Rust achieves a similar market share and historical baggage, as C and C++ have today, growing since the 1970's.
It is of course better designed, and with better tooling, that doesn't spare it from market forces and companies sponsoring the foundation.
See where Linux foundation is today for a comparable example.
pjmlp 141 days ago [-]
Depends pretty much on the type, if using templates or not, if being anti-macros or not.
It isn't the typing, rather the culture.
tialaramex 141 days ago [-]
Rust's type system is a technology, but technology can be used by a culture to support its goals. The technology alone will not get you there, so the culture is more important, but we do need both for success.
tialaramex 141 days ago [-]
Also Rust's borrowck means you can often design an API where it's really easy to fall into our old friend the pit of success with these wrapper types.
Both Rust's OwnedFd and Rust's Mutex<T> have analogous C++ which are used, but lacking a borrowck C++ can't express the idea "Maximum of one person can have this"
What happens if I keep a mutable reference to the Goose despite unlocking the protective mutex? In C++ the answer is you lose mutual exclusion, in Rust that doesn't compile. C++ people will say "Don't do that" but "not doing that" does not scale whereas it doesn't compile scales just fine.
pjmlp 141 days ago [-]
While you are right if we are using the languages on their own, like clippy is common usage on Rust land culture, it is a matter of how much similar tooling gets used on C++, which is sadly a matter of culture, or lack thereof.
vlovich123 141 days ago [-]
I’ve never seen static analysis c++ tooling that has precise errors, have you? It’s always a littered mess of useful and useless things and I’m not even so sure it would warn about holding on to an interior reference into a lock-protected data structure.
Static analysis in c++ is akin to clippy but without a --fix option and many more false positives. Also clippy is more about stylistic consistency within the ecosystem and completely optional, not about safety which isn’t optional.
pjmlp 141 days ago [-]
Depends on which tools, clang tidy can be customised, Apple just did a talk at C++ Now about their custom checks for Webkit "Safe C++".
Commercial tools like PVS and Coventry, or those used in high integrity computing, also allow for rule customisation.
However the first step is to use anything at all, a challenge since lint was born in 1979.
William_BB 141 days ago [-]
Out of curiosity, how would one go about implementing this in C++?
Writing a web app? All user input is untrusted until you process it. And if Untrusted<String> can’t be converted to String accidentally then it forces the programmer to think about it.
Unfortunately in Java (my everyday language) this isn’t feasible. I’d want to be able to join or process Untrusted<String> the same as normal. Really it would need to be built into the stars library.
Back to the article it sounds like this could work really well for the kernel. I hope this kind of idea catches on outside of that.
- it might get swapped out or migrated, meaning your thread goes to sleep if you touch it.
- it can always change concurrently.
- the pointer is only valid within the current context (coz it's a pointer into the user address space).
- I've actually never thought about this before but also the user could free it concurrently I think?
So there's actually already C APIs in the kernel that force you to be aware of this, at least for strings (stuff where the user passes a pointer to their memory). There's also fancy compiler stuff for marking struct fields as pointing to user data, which IIUC can be used to detect if you're forgetting to use the right conversion APIs.
This isn't the case for values passed in registers though so I think Trusted<u64> would be totally new.
ANYWAY, overall: this is cool and good but it's actually one of the lower-impact things from Rust in the kernel IMO. I don't think the bugs that this prevents are actually all that common in practice. TOCTOU would be the biggest one by far but they are rare compared to the daily deluge of incredibly basic UAF bugs that Rust also prevents.
Yup. But if you only send it back to the malloc heap, the kernel doesn't notice, it will happily read data that has been freed.
Unless the data is unmapped, then the kernel is going to get a page fault while trying to read your input. What goes up must come down, so that gets translated to SIGSEGV, and the program stops.
I think I was thinking of the mmap lock. But this was a dumb question mark, this lock isn't just randomly taken when threads enter syscalls. So yeah this is indeed another reason why copy_from_user etc is needed.
In practice, the JVM may still monomorphize it, but it is not guaranteed to, and this would be a good reason to avoid unnecessary uses of generics in a high performance codebase like a kernel, if you chose to write one in Java.
But GP described something they wanted from a type system and basically said container with `Functor`-like behavior is not possible to do in Java. It's possible, albeit with a performance drawback and a bit more clunky to work with compared to Rust, Haskell, or a language with native HKT support.
Dynamically sized objects on the stack has always been difficult. You could argue that C special casing fixed length strings to allow that is the odd one out.
What makes Rust special is that you need to acknowledge the potential errors when unwrapping the type. With a standard library and culture built on exposing the edge cases at compile time.
That is where the guarantees and feeling of certainty comes from.
For instance, Java could do the same, but in practice conversion methods throw runtime exceptions that you won't be warned about and your code will randomly crash if conversions fail, except in some cases when it doesn't. For casting between numeric types the language does have some legacy cruft, but for web applications nothing is stopping you from doing this. Java's explicit exception system is great at forcing developers to deal with potential failures, but in practice Java developers chose not to deal with exceptions so often that exceptions now get hidden.
Rust does this stuff in the standard library and that gives you the advantage that you don't need to explain the concept and convince every developer that this is a good idea. The same way Java has optional nullability annotations that are rarely used in practice because not every developer feels like adding them, unlike languages where nullability is part of the type system.
The concept is not exclusive to Rust, but I also haven't found it very popular outside of Rust developer circles.
Every time I see someone bringing up the idea of adding checked exceptions to a language (usually in these endless exceptions vs returning errors debates), it is met with "it won't work, look at Java", and it feels like a real shame. I'm sure complications of additional syntax would pay off just as fast as it does for regular type annotations.
It's more like "comptime safety feeling" => "language w/ visibility modifier" but the converse is not necessarily true. Without language support, it's back to C convention or workaround again.
If you are iterating over the files in a directory the Rust standard library gives you paths. Not strings.
To convert a path that to a regular string type which is valid unicode you need to acknowledge that the path may be invalid. Either unwrapping and panicking or handling the error.
To do this the standard library gives two options:
https://doc.rust-lang.org/std/path/struct.PathBuf.html#metho...Or accept that the conversion may be lossy:
https://doc.rust-lang.org/std/path/struct.PathBuf.html#metho...You get to make a choice, and panicking/erroring is perfectly valid if you only expect valid unicode paths.
As the world and your software changes if you suddenly encounter a non-unicode path then you will immediately know where the error comes from and can fix the issue. Instead of trying to pinpoint the root source of an error far exposing itself far down stream.
> With a standard library and culture built on exposing the edge cases at compile time.
So, how exactly is "you need to acknowledge that the path may be invalid" from your example a compile-time trait? That's certainly not something you know during the compile-time, and if so, then you should be treating all the files like that, so, I see no difference here wrt other languages.
https://play.rust-lang.org/?version=stable&mode=debug&editio...
We can't know if a generic path is valid at compile time. But we can at compile time ensure that we must acknowledge and make a choice for the invalid case.
This now (in)famous blogpost on Go is what happens when you just pretend that everything works:
https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-...
While a pragmatic choice, in reality it isn't very practical IMO. Most of the times you really don't know what to do with the error so you end up turning the condition either into an exception, because it really is an exceptional case, and/or assert on it as an invariant that is broken and which you believe is a programming (usage) error. In any case, you don't really know how to handle it well, and this is I believe often the case for kernel design too - they will try to eliminate as much as possible such cases with testing because they can't afford to panick during the runtime because that would actually be detrimental for QoS.
Even in C++ you have something not quite the same but similar with [[nodiscard]] qualifier but in practice I haven't really seen it being used much but when I did it was mostly annoying to deal with. It's like a hot potato that is being thrown across the API boundaries but nobody wants to deal with it.
https://mirage.io
If you make UntrustedString a subclass of String (trusted) then you lose type safety. So TrustedString has to be the subclass. Easy enough.
But now string literals are “untrusted”. So you have to do new String(“this is trusted content”) everywhere you need it, which is a pain.
And you can’t add trusted strings. The operator will return a normal String (untrusted) so you have to cast it. Same with any function you call like substring.
So you have to live with that, or make overrides for every single string function that fix the types where necessary.
It’s just really non-ergonomic. I think having it built in would likely make it far better.
I don't see anything wrong with `new Validated("literal")` (or functional friendly `Validated.of("literal")`). If you intend to create a `Validated`, then create it via constructor / static factory method that enforces necessary validations to create `Validated`.
Like `Optional<T>` and `Stream<T>`, you could define `Validated::map(Function<? super String,String>)` if you want. With `map()`, you could operate `Validated` with anything that accepts `String` like usual.With that said, I don't recommend using `Validated` in your actual Spring project though, use (OOP) value objects instead. I used value objects quite a lot on my legacy Spring project. It plays nicely with functional-style, cover "validation" stuff, and avoiding primitive obsession. Putting `String` on `UserId` will result in a loud compiler error.
Though it reminds me of Alexis's "Parse, don't validate", isn't `syscall :: u8 -> Untrusted<u8>` considered as "validate"?
I hope kernel codes that consume it will transform it to appropriate type as well `Untrusted<u8> -> T`.
Untrusted doesn’t validate - it just ensures you don’t accidentally access the data until you’ve ingested data that could be potentially attacking you.
And then the audience will nod yes, accept the message of what is possible, and go back to whatever approach they were doing already.
At least in modern c++. Then again, modern C++ seems to play the same role as modern Java, in that some places use it but most of them are stuck at the version they picked when they started developing on a piece of software decades ago.
Turns out updating software versions in most companies is really hard, and updating humans atittude to specific programming practices even harder, unless their job is on the line.
And even so, it doesn't matter if IT says no, or the customer doesn't pay for consulting services to upgrade existing projects.
As for incompatible changes, there aren’t any in Rust by design. That limits some of the changes they can make even in an edition but in practice it works ok. Even over a longer time span, I think the Rust community will figure out a way to trim irrelevant cruft away.
I am not so optimistic when Rust achieves a similar market share and historical baggage, as C and C++ have today, growing since the 1970's.
It is of course better designed, and with better tooling, that doesn't spare it from market forces and companies sponsoring the foundation.
See where Linux foundation is today for a comparable example.
It isn't the typing, rather the culture.
Both Rust's OwnedFd and Rust's Mutex<T> have analogous C++ which are used, but lacking a borrowck C++ can't express the idea "Maximum of one person can have this"
What happens if I keep a mutable reference to the Goose despite unlocking the protective mutex? In C++ the answer is you lose mutual exclusion, in Rust that doesn't compile. C++ people will say "Don't do that" but "not doing that" does not scale whereas it doesn't compile scales just fine.
Static analysis in c++ is akin to clippy but without a --fix option and many more false positives. Also clippy is more about stylistic consistency within the ecosystem and completely optional, not about safety which isn’t optional.
Commercial tools like PVS and Coventry, or those used in high integrity computing, also allow for rule customisation.
However the first step is to use anything at all, a challenge since lint was born in 1979.