Technically yes, it would make it harder, but a house with unpickable locks isn’t impervious to entry. In my personal experience memory exploits aren’t the primary methods hackers use to gain access or run custom code. I think layers of protection are more effective at stopping actual damage from being done. Run custom code, but you’re still an unprivileged user. Elevate your access but you’re still in a sandbox. Break out of the sandbox but you breach memory allocation and the environment is destroyed and rebuilt. And all the while you should be tripping alerts.
The article actually covers that kind of defensive work a bit (although it’s all kernel internals):
“…if Rust disappeared tomorrow, we have cleaned up the C code in the kernel so much and taken in the ideas. We thank you, you’ve made Linux better with it just by existing.”
He described new C “guards” and scoped locks inspired by Rust …
And
Beyond language features, Kroah-Hartman tied Rust directly to a broader push around untrusted data and the idea that “all input is evil.”
…
He described ongoing work on an “untrusted” type wrapper and a validate method in Rust that forces explicit validation at the point where data crosses from untrusted to trusted.
Technically yes, it would make it harder, but a house with unpickable locks isn’t impervious to entry. In my personal experience memory exploits aren’t the primary methods hackers use to gain access or run custom code. I think layers of protection are more effective at stopping actual damage from being done. Run custom code, but you’re still an unprivileged user. Elevate your access but you’re still in a sandbox. Break out of the sandbox but you breach memory allocation and the environment is destroyed and rebuilt. And all the while you should be tripping alerts.
The article actually covers that kind of defensive work a bit (although it’s all kernel internals):
And