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.