Keep It Simple Stupid has been the motto of many engineers, dating back to Kelly Johnson, who coined the KISS acronym at the Lockheed Skunk Works in the 1960s. It means that simpler designs are better. What we first create is usually complicated. Refactoring it makes it simpler and simpler. This is better because it is easier to understand, more likely to work reliably, and more maintainable — it does just enough to get the job done. While these are still valid reasons for KISS, a new emerging reason is security.
Layering ever-more-complex software on top of ever-more-complex hardware is not going to solve the cybersecurity problem — it just increases the attack surface. Today, software teams are hard-pressed to interpret massive, tersely-written hardware manuals, and then write code that works reliably. They cannot focus on writing secure code when they must struggle just to understand how the hardware works. New hardware architectures should be moving in the direction of making the programmer’s job easier, not harder, as is currently the case.
The objective of hardware architecture should be to achieve basic functionality as simply as possible. Complex operations should be left to software, except in cases where better performance is essential. Current hardware architectures have departed widely from this ideal. The same applies to protocol stacks and to other software components. Getting rid of seldom, if ever, used features and focusing on achieving basic requirements in simple ways would substantially reduce attack surfaces. What is needed is a just-enough design philosophy, not a pack-it-in-if-it-fits design philosophy. Security will remain elusive until vast simplifications are made.
A prime example of the escalation of hardware complexity is found in modern “RISC” processors. The RISC ARM ISA has 821 mnemonics vs. the CISC x86 ISA 981 mnemonics. So, what happened to the idea of reduced instruction sets? It seems to have gone out the window. IO controllers are as bad or worse. MCU manuals often devote hundreds or pages to describe a single IO controller. MCU manuals of 5,000 pages, or more, are not uncommon.
Chip vendors do provide hardware abstraction layers (HALs) to help with this IO complexity. However the HALs, themselves add yet another layer of complexity. For example, the STM32Cube HAL manual is 3,786 pages – a lot for a programming team to understand. The STMicro HAL, itself, contains hundreds of thousands of lines of code, if not over a million. I wonder, how all of that code can be written securely?
Complex features are best left to software. That way, they can be left out when not needed and thus do not complicate the programming task at hand. Otherwise programmers must figure out how to deal with unneeded hardware features. Resulting code to disable or work around such features is likely to leave holes for hackers to exploit, since it is not the main task at hand for programmers. Of course, if hardware implementation is essential for critical performance of a function, that is different, but even so it should be subject to the just-enough criterion.
We need to rethink how we achieve our goals. I suggest that we adopt a just enough design philosophy – just enough Silicon, just enough code, and no more. Much complexity is due to the desire for generality. Enabled by Moore’s Law, the pendulum has swung too far in that direction; hopefully, the pendulum is starting to swing back in the direction of simplicity for security. As pressure mounts for better device security, I think the pack-it-in era will come to an end and vendors that produce just-enough microcontroller and software functionality will find their businesses booming.
So, let’s KISS and give programmers a chance — Keep It Simple for Security!
Copyright © 2022 Micro Digital, Inc. All rights reserved.
Micro Digital Blog 