Looks like you are quoting from: http://arstechnica.com/security/2016/09/linux-kernel-securit...

While it's true that vendor drivers living in kernel space is horrible for security... that's somewhat offtopic here. This particular bug is in the memory management system, which is one of those things that kind of has to be in the kernel. A microkernel architecture seemingly would not have helped in this particular case.

> This particular bug is in the memory management system, which is one of those things that kind of has to be in the kernel.

Not really. L4 family (the post-Liedtke world) and Minix3 both have MM out of the kernel.

A privilege escalation in MM daemon would still allow you to write and read any user memory. Just not kernel memory or execute anything not covered by memory access capabilities. For nearly all intents and purposes, it is root.

Couple things here.

Firstly, as the MM daemon runs on its own process and is well-separated from other code, it is far easier to audit, debug and so on. Its interface is also entirely explicit. There's value in modular programming. It's far more reasonable to expect quality from such a MM daemon than the mess in a random monolith kernel.

Secondly, in seL4, physical pages are capabilities. There might be more than one MM daemon, owning separate sets of capabilities to physical pages. Security-critical memory might be managed by a MM daemon your vulnerable process has no capability to talk to.

Just my two cents.

seL4 does not have these kinds of errors. By shrinking the TCB, you make it possible to do hardcore verification. The challenge is in extending to larger systems and composition.

Worth noting that as of Genode's latest release, a lot of progress has been made in that regard.

Yeah not sure what happened. Somehow I ended up looking at wrong article.

I am not very good at theory of Operating Systems but since Memory Management is separated from kernel it would have been difficult for a memory bug to impact other subsystems.

Another argument is modularity which would have allowed better testing hence lesser chances of bugs.

Despite your erroneous reply, you still hit 4th most upvoted comment thanks to the pro-open source sentiment here.

Yep but my argument still holds true especially in the era of IoT risks are now becoming physical. Bugs earlier used to only impact people financially, emotionally but now risks are physical.

Why do you think it is erroneous?

While it is in part true, no amount of band-aid solutions will fix the issue of using C.

A small TCB will still be key, regardless of language.

10% small TCB size vs 100% of the complete code.

Which one will a security minded person pick?

Sorry, can you restate that question?

I'm not sure what you're asking.

A small TCB -> around 10% unsafe code.

C, due to arrays, strings, arithmetic operations and memory allocations requiring unsafe code leads to 100% unsafe code across the existing code.

A security minded person will pick those 10%.

> C, due to arrays, strings, arithmetic operations and memory allocations requiring unsafe code leads to 100% unsafe code across the existing code.

Imply is just slightly too harsh. Writing safe C code is very possible, as proven by projects such as seL4 or engineers such as djb.

Those projects had to constrained themselves to having 100% of the code available, no binary libraries and lock the compiler versions being used.

Since the early 90's I keep hearing that it is possible to write safe C code, yet outside in the real world, unless constrained by processes like MISRA-C and Frama-C, which isn't really C anymore, it never works.

The proof is the amount of CVE exploits, that get reported almost daily!

Just yesterday while reading some papers on Cyclone, I discovered this jewel:

"X El Capitan v10.11.6 and Security Update 2016-004" release notes

https://support.apple.com/en-us/HT206903

From 36 bug fixes, 31 are related C memory corruption issues!

OSX is pretty bad as they go.

MACH based hybrid kernel garbage.

A shame, considering Apple actually has the resources for doing a proper rebase of XNU on L4 and with actual pure microkernel multiserver architecture.

haha, that safety stuff is just training wheels. You can't delegate security. Even if you use some baby-proof "programming language", as a security engineer you still have to verify that the safety works in the condition(s) you're programming for.

Ahah, I was doing systems programming in Pascal dialects and Modula-2 before having to know C was a requirement.

Of course one always has to validate security, but with C each line of executable line of code is a possibility exploit, which grows exponentially with the amount of developer touching the code and their respective skills and UB knowledge.