3 ms·
> I agree the solution is not perfect and ideally I would nuke the language out of orbit. > But that approach will never win the hearts of UNIXy kernel devs I
by vmchale 8y ago
> I agree the solution is not perfect and ideally I would nuke the language out of orbit.
> But that approach will never win the hearts of UNIXy kernel devs
I don't think this is fair. The Linux kernel contains (as of writing) 17913052 lines of C. If you have a plan to rewrite 18 million lines of code and patch every single dependency, fine. But until then such concerns will dominate.
It's also worth noting that the Rust many people write is not the low-level stuff that C programmers and systems programmers write. See https://www.cl.cam.ac.uk/~srk31/research/papers/kell17some-preprint.pdf https://www.cl.cam.ac.uk/~srk31/research/papers/kell17some-p... for a better explanation of that.
- pjmlp 8y agoI don't have such plan, but Linux kernel devs have some mitigation plans. Not to rewrite C into something else, but to get out of the current escalation of kernel exploits, now that Linux is a commodity OS, it gets targeted as such https://events.linuxfoundation.org/events/linux-security-summit-europe-2018/program/schedule/ https://events.linuxfoundation.org/events/linux-security-sum... Hence Kernel Self Preservation Project, removing VLAs from kernel code, adding all possible ways of mitigation, and hopping that eventually tagged pointers like SPARC and ARM have become common across all supported hardware. The charts shown by Google employees regarding exploits are quite telling.