My safe language doesn't have "null", more or less.
What it has is Option<T>, and I cannot turn that into a T without handling the failure case: there is literally no way to construct the code otherwise¹. One must handle the failure path. (That might be way of explicit panic/abort/oops, but it's then right there in the code: that branch will panic … and safely.)
¹(this example is using safe Rust. There's unsafe Rust too and there I can chase the null pointer all I want with that, but the parent's point is that we should be sticking to safe interfaces for stuff like this. And I'm using Rust as an example, but Option is hardly unique to Rust, heck, Rust stole the idea from its predecessors.)
OK, and what does your kernel actually do when a kernel thread panics? It "stops execution", sure, so it will... oops? Causing exactly the problem given in the article?
It shouldn’t be a question that tedunangst should even have to ask, given that he has had a chip on his shoulder about Rust and its safety guarantees for years and thus should have learned that much about it by now.
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!).
One of the missing pieces IMO is that your language needs the right kind of shorthand to make it easy to say "I'm calling things that return Options or Results, I myself return an Option or Result, any time I unwrap let's pipeline any null values or failures into returning a failure immediately."
The whole idea is that there should never be a way to call unwrap() if you as the caller cannot handle it gracefully. And if you do this at every step up until the UI layer, which can handle any failure as an error to be displayed in the UI, then the job is complete!
Yep, and monads without syntactic support are a pain to work with in practice! For instance, the best possible way in a language like Python is to break down what would otherwise be a set of imperative statements into a whole bunch of lambda functions: https://returns.readthedocs.io/en/latest/#id1
In a C++ code base I work on, we use a macro that is essentially Rust’s ?. It’s obviously less convenient than ?, but it’s not bad (even without syntax support). In the past in systems C code, I’ve manually written every error check and return.
That's the explicit handling of the None case I mentioned in the comment: it causes an explicit, and safe, abort. By "explicit", I mean the .unwrap() call will be right there, in the method that needs to turn an Option<T> into a T, and visible to a code reviewer. In the larger context here of kernel code, it should raise the eyebrow on the reviewer: "wait, this function shouldn't abort, it needs to handle the edge cases!".
(But for some userland app, aborting might be acceptable. The kernel is in a bit of a bind, since an abort — a kernel panic — means the user loses computer until they reboot, and the work along with it.)
Vs. a C pointer … all uses are more or less equally suspect; any given use, you hope the code has done it's homework for ensuring they're not NULL, and if they are, the consequence is UB. (And in Rust, and in the languages Rust steals the idea of Option from, you're only using/passing Options where "None"/null/nil is a possibility. If it's not, or you've verified or handled that at some outer stack frame, then you just pass a reference to a T, which is statically guaranteed to point to a valid object¹.)
¹again, barring buggy code using unsafe Rust, in the example of Rust, or calling into C code that fails to maintain its invariants, etc.
Take the example in the article, where the code does,
priv->mm->mmap->vm_start
while trying to generate the output for smaps_rollup. That's compilable, but buggy, C, because mmap can be null, but we failed to check for it.
Vs., if mmap were an Option<T>, where T is whatever type that pointer points to. Let's say our coder attempts to write,
priv->mm->mmap->vm_start
(In some imaginary language, because C doesn't have Option, AFAIK.) The compiler would say, no, you can't "->vm_start", because "mmap" could be None (whatever you call the "nothing here" value/variant; I'm going to call it None, to distinguish it from the null pointer).
In the case of unwrap, the coder could do something like (this is psuedo-code)
(priv->mm->mmap).unwrap().vm_start
It would then be obvious there is an abort there. Their reviewer would not be pleased with that, I suspect: we don't want kernel panics or oops or aborts while generating a file in /proc. And likely our imaginary coder would know this too, and when the compiler errored the first time, saying, "hey, mmap is an Option", they'd raise an eyebrow, say something like, "wait, it is? When would mmap be None?" and then proceed to properly handle that case. (E.g., by treating it as if it where the empty list.)
The root cause of the bug isn't the kernel dereferencing a NULL and causing UB. It's the kernel doing error handling and attempting to kill the oopsing task and continue. If the semantics of Rust panics also did a kernel oops, unwrap() would trigger the exact same bug described in the blog post with regards to reference count rollover (if Rust in the kernel doesn't do stack unwinding)
There are two bugs discussed in the article. One is the one this thread started with, which was the kernel deref'ing a NULL.
You're right that this is separate from the handling of the oops, which is the main exploitability that TFA is getting at, and certainly fixing one deref leading to an oops (the proc file chasing NULL) doesn't fix the other bug of "any oops can be further exploited".
But the context of this subthread is the implication that you must have some null, and some thing must happen when it is chased. That assumption is wrong, that's what the core of the comment I'm making is getting at: you can't follow a null if you don't have the possibility of them in the first place. (Or where you must have an Option<T>, you can build safe interfaces for handling that fact.)
> unwrap() would trigger the exact same bug described in the blog post with regards to reference count rollover
If we consider this instead as "an unwrap occurring during the oops handling", maybe, but it's not guaranteed that that is the case. Other aspects of Rust could similarly prevent that bug. I haven't fully grokked the latter half of the article, but I didn't think it would be necessary for the comment, as, a. the chain was about "Printing /proc/$pid/smaps is not on any conceivable performance-critical hot path." and b. followed by the question about null.
Ref-counting in Rust is often dealt with via RAII, and is safe through that, both in that RAII means the refcount is managed correctly and without input from the coder, but also Rc (and I presume Arc) will abort on overflow. I don't know if that would fully translate to kernel code, given that we might be taking refs due to the actions of userland, and that might be happening near the userland/kernel boundary and be reasonably subject to unsafe code that could very well fall prey to the same problems.
Yes, but fundamentally the kernel's inability to handle exceptional cases is all in deference to performance. Non-performance-critical sections, which in a fair analysis would be 99.9% of the kernel at least, should be written in a language and style that provides structured unwinding, not just jumping to the error case and whoops I accidentally jumped beyond all the unlocks and reference count decrements and deallocations. That's the issue.
You wouldn't allow code that aborts without cleanup in these areas of the kernel, or in the kernel at all.
You can't make a similar rule against null dereferences, because those happen by accident. (Unless you wrap every single pointer dereference, which is not happening.)
If you don't allow aborting, then the compiler makes you write an error-handling path that returns, and the cleanup code will not be skipped.
These juvenile and facile retorts do not elevate the discourse, nor are they a good look. As a long-time OpenBSD developer you have a lot of smart things to say about technical subjects, including kernels specifically, and I wish you would leave the dumb snarky comments unwritten.
If an abort function still triggers cleanup, then yes it is better. C doesn't have such a thing, so your sarcasm about 'telling them' is unwarranted.
If an abort function doesn't trigger cleanup, then you can block it at compile time to prevent this kind of bug. But before you can even think about doing that, you need to split pointers into nullable and non-nullable. And the kernel devs already know about that idea, and how hard it is to implement in C.
Nobody is naively suggesting "hey kernel devs do this thing!" as if there isn't decades of momentum behind the current codebase. It's just a look at how C is bad at this particular kind of bug.
Ideally it has a iterator construct built in so it views an empty linked list chain truly as an empty list without derefencing the first (null) item preemptively.
In order to have the safe language I believe you would need to decompose the code shown here in show_smaps_rollup(). If the null deref occurred in the unsafe portion it would likely still do an oops. If the null deref occurred in the safe portion it would likely exit safely and cause the syscall to return some errno that describes a kernel fault.
