One interesting point that he makes is that we often sacrifice security in the pursuit of speed:
Using an interpreter to impose simple data-flow restrictions on the address-extraction code would make bugs in the code irrelevant to security—a huge benefit. However, most programmers will say “Interpreted code is too slow!” and won’t even try it....
Anyone attempting to improve programming languages, program architectures, system architectures, etc. has to overcome a similar hurdle. Surely some programmer who tries (or considers) the improvement will encounter (or imagine) some slowdown in some context, and will then accuse the improvement of being “too slow”—a marketing disaster.
I don’t like waiting for my computer. I really don’t like waiting for someone else’s computer. A large part of my research is devoted to improving system performance at various levels... But I find security much more important than speed. We need invulnerable software systems, and we need them today, even if they are ten times slower than our current systems. Tomorrow we can start working on making them faster.
I predict that, once we all have invulnerable software systems, we’ll see that security doesn’t actually need much CPU time. The bulk of CPU time is consumed by a tiny fraction of our programs, and by a tiny fraction of the code within those programs; time spent on security verification will be unnoticeable outside these “hot spots.”
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |