roguebantha

Yes I had considered it rather apparent I was referring to the page at the virtual address zero, but I've definitely referred to the CoW page used for private anonymous mappings as the "zero page" too, so I understand the confusion. I probably should have made it more clear! Sorry about that.

My understanding is that Rust is particularly lacking in the hardware interface area - a feature of incredible importance for kernels. In fact, that is the Kernel's primary function - to serve as an interface between user programs and hardware. Without excellent hardware interaction support, it's unlikely to be a good language to write a kernel in.

The real issue with this error is not the panic of course - it's the fact that during a panic, C doesn't provide a canonical way of unwinding whatever actions have been performed so far. Rust (or even C++) do provide a bit more robustness in regards to handling errors in an unwindable way, but Rust and C++ probably aren't tenable solutions for the kernel in this case. It's far easier to add an oops limit and kiss this technique goodbye (hopefully!).

To the contrary, I appreciate azakai's enthusiasm for seeking solutions, and also credit the fact that they came up with exactly the same solution we used to mitigate the issue.

The irony isn't lost on me that the one conceivable hotpath is this exploit technique...

It can be a lot slower too - but it's most dependent on how the kernel handles console logging. Serial consoles slow it down dramatically, which is why it's so much quicker on your typical GUI enabled setup.

Yes, there is now an oops limit, specifically because of this technique - see the conclusion paragraph.

Thankfully this isolated flaw was quite easy to fix. And yes this code isn't likely to be on any hot paths, and code can always stand to have bounds/sanity checks (and it always should). But unfortunately encapsulating all non-hot-paths in Linux kernel that might have these sorts of bugs in a memory-safe language is at best a very long term goal and at worst a pipe-dream. The real goal of the blog post was not to push for any sort of rewrite, but rather to note how even the simplest and most innocuous of bugs can lead to security-relevant primitives. And also to make sure kernel developers and bug fixers have strategies like this in mind when they evaluate other bugs in the future.

TLDR: However honorable the end-goal is, this blog post is not the ammo you need to push for a big rewrite of various kernel<->userland interfaces into memory safe languages.