Doesn't this actually validate Andrew Tannenbaum's argument[1] over 25 years ago when he said monolithic operating systems are inherently insecure and a rethink is required.
[1] https://groups.google.com/forum/m/?fromgroups#!topic/comp.os...
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.
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.
Not really. L4 family (the post-Liedtke world) and Minix3 both have MM out of the kernel.
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.
Which one will a security minded person pick?
I'm not sure what you're asking.
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%.
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.
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!
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.
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.