There are plenty of tools designed to help you write parsers that compile down to C. Alternatively there is the microkernel approach. Either one (or both) would satisfy GP's implication that hand-written C parsers in ring 0 are bad.

Well, Android's Bluetooth stack is being rewritten in Rust so you probably can go pretty far in memory-safe languages (though of course Rust isn't a managed language, just a safe one).

Dumb question (not a kernel or C developer): can't you call into code compiled from a memory safe language, like in a shared object file?

Yeah, and we're slowly slowly moving towards that model. One barrier is that some safe languages, like Rust, support far fewer target platforms than the Linux kernel does. There are C compilers for everything, but only a few Rust backends.

Something similar to Wuffs[0] (posted on HN very recently), which compiles down to C, might be a good compromise between portability and safe languages. (There may be some contorted way to have Rust emit C, too.)

[0]: https://github.com/google/wuffs

Rust uses LLVM, which likely should have easier time being ported than an entire Rust compiler. Rust handles cross-compilation pretty well so you don't have to compile on an actual embedded device, or something.

I wonder if an LLVM backend that issues a very simple and predictable subset of C would be a viable way to support exotic old architectures which only have a C compiler. LLVM-cbe is a thing: https://github.com/JuliaComputing/llvm-cbe

Definitely, for example check how to make Go .so libraries.

https://medium.com/swlh/build-and-use-go-packages-as-c-libra...

Naturally the runtime also comes along, but that is another matter.

Do you know C.A.Hoare?

I advise you to read his Turing award speech from 1981.

Indeed! Hoare wrote about his self-reflection on the failures of his own software group.

There was also failure in prediction, in estimation of program size and speed, of effort required, in planning the coordination and interaction of programs, in providing an early warning that things were going wrong. There were faults in our control of program changes, documentation, liaison with other departments, with our management, and with our customers. We failed in giving clear and stable definitions of the responsibilities of individual programmers and project leaders,--Oh, need I go on?

What was amazing was that a large team of highly intelligent programmers could labor so hard and so long on such an unpromising project. You know, you shouldn't trust us intelligent programmers. We can think up such good arguments for convincing ourselves and each other of the utterly absurd. Especially don't believe us when we promise to repeat an earlier success, only bigger and better next time.

Apologies. Yeah, there's room for a lot of whataboutism as long as browsers and other user facing apps are also using unsafe languages for parsing untrusted code. But still that's not an excuse to do it IMO.

And indeed "the system is to blame" in that it's hard to get drivers using safe techniques into the Linux kernel, and Linus is famously anti-security. But I think for the individual programmer, they still end up choosing one of the above 3 mental models.

So I still think it would be interesting to know how people think about security when writing parsers in C in ring 0 for Linux drivers that exposed by default in billions in devices.

its called a microkernel