SOC security is not a job for general purpose CPUs

Life is full of convenience-security tradeoffs. Sometimes these are explicit, where you get to make an active choice about how secure or insecure you want things to be. Other times we are unaware of the choices we are making, and how risky they are for the convenience provided. If you leave your bike unlocked, you can expect it to be stolen. However, we all know the feeling of learning that our credit card number has been stolen – clueless as to how or why usually. The other thing we need to be wary of is that hackers and bad actors are always looking for new ways to exploit security flaws. This means that things we saw as safe choices can, overnight, become risky.

Remember back in the day when you could easily use a debugger to find the code that did a password check and bypass it? Now we have protected address spaces and better encryption. System exploits are often found by hackers wearing white hats and then provided to vendors for fixing, before the public even hears about them.

However, in the last year a serious new security flaw known as Spectre has come to light that should give everyone pause. Like most people you bought a general-purpose computer with a CISC instruction set to both play games and do your banking. Processor vendors have spent the last several decades dramatically improving the performance of the general-purpose processors that are used in them. Among them are the Intel, AMD and sometimes ARM processors.

With the clock ceiling of ~4GHz for processors, CPU designers looked for ways to improve performance. An area ripe for optimization was wait states for memory reads, which can block processing for hundreds of CPU cycles. The widely adopted solution is predictive branching, where the CPU used prior execution profiles to determine the likely outcome of a branch decision. The processor would save state and proceed to execute the most likely code path. If the prediction was wrong the processor state was returned to the saved state. And, execution would resume with the correct branch. This seems safe enough…

Unfortunately, even if memory and processor registers are restored, there is still a latent trace from the code that was executed based on the prediction – the memory cache may have been changed based on memory reads. Downstream, hackers can use this in a number of ways to ferret out the contents of memory that was believed to be secure. One example is where the predictive branch was a memory bounds check, but the training led the processor to expect that the test would pass, but in reality, contains illegal memory accesses. The predictive code would then pull protected memory into the cache, where it can be retrieved later by additional hacker code. In fact, there are numerous other ways to exploit cache modification by malicious code leveraging predictive branch execution. Some even work in the Java runtime environment in browsers.

Unlike software exploits, this one relies on fundamental behavior of general purpose processors. So, when this exploit became public there was no fix ready, and in fact we will have to live with it, perhaps with some mitigation, for some time. The most secure fix is to disable predictive code execution, using the LFENCE instruction, but this leads to huge slowdowns in CPU performance. One security researcher estimated that 24 million LFENCE instructions would need to be added to the Office Suite.

Now look at all the new applications where processors are used that have heightened security requirements. In the face of this, it is time to start using different types of processors for different types of tasks – secure processors for critical jobs, and higher performance processors for less critical tasks. The push for heterogonous processors has been underway for some time, largely driven by performance needs. However, there is a growing need for specifically designed secure processor families. These might for instance be RISC based and are less vulnerable to predictive execution exploits. They also can have their own direct connected memory and security IP and accelerators, that are not accessible to any other part of the system.

Rambus outlines one such solution in their white paper “The CryptoManager Root of Trust”. Starting with a 32 bit RISC-V processor that is dedicated to security functions, the entire ensemble includes a number of essential components and the proper architecture for ensuring security. As such it is specifically designed to securely run sensitive code. It comes with dedicated SRAM and ROM memories. Also, there is an AES, secure SHA-2 hash core and asymmetric public key engine.

The Rambus CryptoManager Root of Trust (CMRT) also includes a true random number generator, a key derivation core (KDC) for deriving ephemeral keys from root keys. To detect tampering it also has a canary core that can detect glitching and overclocking. The Rambus white paper goes into detail about its comprehensive attack resistance. Also, it discusses the techniques it uses to create silos for sensitive code that needs to run securely. In fact, multiple roots of trust can be created to keep resources, keys and security assets for different application separate from each other. The CMRT core can be added as a complete security solution to SOCs to address the needs of a number of vertical markets. These include IoT, Automotive, Networking/Connectivity, and Sensors.

Rambus also describes the development tools and their provisioning infrastructure that complete the core’s development kit and deliverables. The white paper, which goes into much more detail on the full set of features and capabilities is available on the Rambus website. It is worth noting that the RISC-V core is not considered to be at risk from the Spectre exploit. I highly recommend reading the white paper, and its notes and references.