As someone who helps write an operating system, some areas of kernel code can be less subject to the usual C memory safety issues than most user code. This isn’t because kernel programmers are special, but because the kind of code that gets written is different. I rarely find myself allocating memory at all in kernel code, and if I don’t allocate memory, I’m less likely to overrun a buffer.
In other areas of kernel code, buffers common, but the data is completely opaque. You won’t find kernel code parsing a buffer written to a filesystem because there is nothing to parse. The buffer is literally just a pointer and a length.
That being said, I would love something like Rust for lifetime management and thread safety and for the occasional data structure.
(Large sections of Linux are indeed quite scary from a memory safety perspective. Anything related to /proc or /sys comes to mind.)
I don't find either of the Kernels you mention to be particularly unsafe, despite being written in "unsafe" languages. Can you point to better kernels written in Rust?
That being said, a kernel is a huge undertaking. There is nothing else with the scope of Linux. And substantial parts of writing a kernel involve dealing with architecture nastiness, and, in the absence of formal architecture models, no language will help much here. The Linux x86 low level code is a terrifying mess, and it’s also the best and most capable implementation I’m aware of. (I’m obviously biased.) A language like Rust would help only a tiny bit.
(Something like NMI handling on x86 is fundamentally memory unsafe. If you get nested NMIs, your stack gets clobbered. Thanks AMD. Linux has code, mostly in assembly, that detects and recovers. Good luck writing it in any memory safe language.)
I once skimmed seL4, and I would not use its x86 code for serious work in its current form.
