Quotes of the week

[Posted May 1, 2019 by corbet]

Remember, maintainer/reviewer time is scarce, engineer time is prolific, we optimize for reviewers, not the people writing the patches.

— Greg Kroah-Hartman

To phrase the argument in a bit more controversial form:

If the price of Linux using an insecure C runtime is to slow down system calls with immense PTI-alike runtime costs, then wouldn't it be the right technical decision to write the kernel in a language runtime that doesn't allow stack overflows and such?

I.e. if having Linux in C ends up being slower than having it in Java, then what's the performance argument in favor of using C to begin with?

— Ingo Molnar

Quotes of the week

Posted May 2, 2019 11:55 UTC (Thu) by roc (subscriber, #30627) [Link] (5 responses)

Molnar is right, but the chances of converting enough of Linux away from unsafe-C to be able to disable current and future C-insecurity mitigations are practically zero. (Though it still might make sense to write parts of the kernel in Rust ... writing drivers in Rust would reduce the bug exposure and make reviewing them easier.)

There's an opportunity for non-C kernels, or verified-C kernels, and/or microkernels, to disrupt Linux here.

Then again, maybe C-insecurity mitigations will be baked into increasingly bloated and complicated CPU cores so you'll be paying for them whether you use C or not.

Quotes of the week

Posted May 3, 2019 6:39 UTC (Fri) by mjthayer (guest, #39183) [Link] (4 responses)

To what extent is it feasible to write code which is valid C but more amenable to static correctness analysis?

Quotes of the week

Posted May 3, 2019 6:41 UTC (Fri) by mjthayer (guest, #39183) [Link] (1 responses)

Which I suppose is more or less what all the MISRA and other people are trying.

Quotes of the week

Posted May 3, 2019 23:23 UTC (Fri) by roc (subscriber, #30627) [Link]

MISRA disallows, among other things, dynamic memory allocation. MISRA and similar schemes are far too limited to use for the Linux kernel.

Quotes of the week

Posted May 3, 2019 23:30 UTC (Fri) by roc (subscriber, #30627) [Link] (1 responses)

Either you write in an incredibly restricted subset of C that is totally infeasible for something like the Linux kernel, or you write in a larger subset of C with annotations to help the static analyzer/verifier prove absence of classes of bugs. The problem with the latter approach is that even though a C compiler might compile your code, you're not really writing C anymore, you're writing a superset of a subset of C that everyone other than the C compiler needs to understand. And is twisting the syntax and semantics of your language so that a C compiler can compile it really worthwhile, or should you take the opportunity to fix some of the bad C decisions?

It's possible that creating your own language that's a bit like Rust but looks more like C unlocks some incrementality benefits for Linux (while having some pretty major costss). It's hard to tell without doing experiments.

Quotes of the week

Posted May 6, 2019 23:09 UTC (Mon) by logang (subscriber, #127618) [Link]

We already do the latter approach in the kernel to a small extent. We have a number of annotations[1] that are checked by sparse and also understandable by code reviewers.

I think it would be a great idea to do more annotated static analysis if people can come up with good cases where it will work.

Also, I feel like it would be of a significant value to add much of the same functionality that sparse is doing now to GCC and maybe eventually the C spec so that it's more widely available and developers can get the appropriate errors without needing to run a seperate tool, or wait for a build bot.

[1] https://elixir.bootlin.com/linux/latest/source/include/li...