June 17, 2008
TCB size is measured in LOC, not kB
On a competitor's FAQ I found this little gem:
"In a secure processing environment it is important to keep the code size, and hence the 'attack surface' as small as possible."
At the surface, this looks like our TCB size matters argument (and small is beautiful in this case). But we tend to talk about the TCB size in terms of lines of code (LOC), while this quote talks about (executable) code size (in kB). Somehow this implies that the actual bytes of the executable code are the targets of an attack.
This notion would have merit if the attack was done against the physical storage medium with cosmic rays o or something the like. In the more likely scenario of attacks aiming to exploit bugs in the code, this line of argument is obviously complete nonsense.
Since attacks are against bugs, it's the complexity of the source code that matters. And how is that measured? To a first (very coarse) approximation in LOC.
If we look beyond the first-order effect of source-code size, other complexity effects become relevant. These include the underlying complexity of the task at hand—for hypervisors we can assume this to be the same for all implementations. But another important one is the implementation language: some languages are more error-prone than others. C (which is what we are using) isn't particularly great in this respect (type-safe languages are much better). But one language that is definitely massively worse is assembler. Which happens the implementation language of said competitor.
Since the competitor's implementation uses only assembly language, we can safely assume that their LOC count is higher than ours. Furthermore, the fault density is likely to be significantly higher than ours, for two reasons:
- assembler code is inherently more error-prone than C code (as C has at least some rules the compiler can check)
- C code can be analysed with static analysis tools. Such tools have gained significant power over the years, and are quite successful to find many classes of programming bugs. OK Labs uses a variety of static analysis tools (we'll talk about this in a future blog), and that's even before deploying formal verification. People who program in assembler can't use any of this.
So, which code would you trust for your security-critical applications?
Posted by Gernot Heiser on June 17 at 06:30 PM
About Gernot Heiser:
Gernot Heiser, Chief Technology Officer, never thought he would be in the business world. Prior to NICTA's creation in 2003, Dr Heiser was a full-time faculty member at the University of New South Wales. However, this die-hard academic couldn’t pass up the opportunity to see the commercialization of this research. Gernot still loves teaching, almost as much as he loves good wine and good food. And anyone will tell you that Gernot knows his wine.
Share this article