Sort of. The point is less primitive and more verifiable. A lot of the security kernels of the past were a decent size. So was Dijkstra&#x27;s THE OS which pioneered the robust, construction processes. Hamilton&#x27;s team&#x27;s flawless code for Apollo certainly wasn&#x27;t small either:<p><a href="https:&#x2F;&#x2F;upload.wikimedia.org&#x2F;wikipedia&#x2F;commons&#x2F;thumb&#x2F;2&#x2F;2e&#x2F;Margaret_Hamilton.gif&#x2F;220px-Margaret_Hamilton.gif" rel="nofollow">https:&#x2F;&#x2F;upload.wikimedia.org&#x2F;wikipedia&#x2F;commons&#x2F;thumb&#x2F;2&#x2F;2e&#x2F;Ma...</a><p>We tend to keep the TCB small as less code = less bugs. We simplify it because simpler code = easier verification. Usually... More important is you know what states or execution effects each component can have in a way that can be abstracted into analyzing those above it. So, the thing can be 4Kloc or 100Kloc, but it should be easily analyzed and composed modules.<p>One problem I noticed, though, is that systems without needed functionality get continuous, ad-hoc versions of that functionality from their developers. C and UNIX were perfect examples with all kinds of extensions there was a mess trying to cover stuff that came by default in prior languages and platforms. So, there was less safety &amp; consistency anyway despite underlying tool being primitive.<p>This led me to shift from &quot;simple &amp; tiny as possible&quot; to the simplest version of tools that make it as easy as possible to do right. Bernstein et al&#x27;s Ethos &amp; NaCl projects are perfect examples where internally they&#x27;re a bit complex but interface is simple to use &amp; securely. Just got to find the right balance.<p>A lot of good wisdom on such things is from Karger et al in the link below on high assurance virtualization. See &quot;layered design&quot; especially for verbal and visual explanation:<p><a href="http:&#x2F;&#x2F;www.cse.psu.edu&#x2F;~trj1&#x2F;cse543-f06&#x2F;papers&#x2F;vax_vmm.pdf" rel="nofollow">http:&#x2F;&#x2F;www.cse.psu.edu&#x2F;~trj1&#x2F;cse543-f06&#x2F;papers&#x2F;vax_vmm.pdf</a>