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.
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.