feature article
Subscribe Now

Morpheus Processor Foils Attackers

Research CPU is Designed to be Self-Vaccinating

Moving targets are always harder to hit. That’s the underlying premise behind Morpheus, a CPU designed to stop malware dead in its tracks. It’s not a commercial product, but a university research project created specifically to take on a DARPA challenge for secure processors. And so far, it looks like it works, deflecting every attack thrown its way. 

Morpheus implements malware protection entirely in hardware. The processor itself thwarts malware attacks, above and beyond any software-based countermeasures you might deploy. Its creators won’t say that it’s totally 100% impervious to attack, only that “it’s super hard to hack.” 

It works by combining some existing techniques with a new dimension: the element of time. Morpheus encrypts and obfuscates code and data, then does it again, and again, and again, continually moving things around so that attackers have no time to figure out what’s going on. Taken individually, Morpheus’s countermeasures may be familiar, but in combination they form a tough shield. 

According to Todd Austin, one of the University of Michigan grad students on the Morpheus team, all programs have both “defined semantics” and “undefined semantics.” In other words, there are some things you explicitly define in your source code (the length of a buffer, for example), and some things that are just assumed, like the CPU’s native word size or the preferred alignment of objects in memory. Most malware, he says, takes advantage of the undefined stuff. Side-channel attacks, for instance, will sniff out changes in power consumption, RF emissions, or calculation times in order to glean information about what’s going on inside the chip. The current location of the stack pointer is determined at runtime, not in the code. All of these things (and many others) are undefined semantics; they’re not specified anywhere in the program’s source code but are natural side effects of running real code on real hardware. 

You can stymie side-channel attacks by adding some randomization to your chip’s behavior. This is like sending out chaff to muddy a radar signal and decrease the signal-to-noise ratio. But a dedicated attacker (the kind DARPA is most worried about) will eventually see through these countermeasures, and code analysis can predict the runtime position of a stack pointer. All it takes is time. And that’s where Morpheus comes in. 

Morpheus randomizes memory addresses and pointers, and it encrypts data and code. But then it repeats the process every 50 milliseconds, completely wiping out any progress the attackers might have made in decoding the encryption. The bad guys have just 50ms to do their worst before having to start all over again. That’s what makes Morpheus so resilient. 

“I don’t generally say that [it’s unhackable] myself, because I think it is hackable,” says Austin in an IEEE Spectrum interview. “But it’s super hard to hack. It may be hackable, but not by software.”

“This actually stops any attack that relies on pointers and code. It only stops low-level attacks. It doesn’t stop things like SQL injection and real high-level stuff that happens on your web server. The Morpheus machine we built for the DARPA challenge is really built to stop what’s called a remote code execution, or RCE, attack.”  

Morpheus’s protection works on two fronts: randomization and encryption. First, all memory addresses are randomized by adding an offset to blocks of memory. The offset is added to all write cycles and subtracted for all read cycles. To make things tougher, code references use one random offset while data references use a different random offset. The two independent offsets also prevent code and data from accidentally interfering with each other. (For performance reasons, the last four bits of the displacement are always zero so that objects stay word aligned.) Memory addresses wrap around the address space so that large offsets don’t create unworkable addresses. 

The program code never sees any of this. As far as it knows, everything is right where it should be. That’s an example of Austin’s “undefined semantics.” It’s not too different from the way x86 processors use memory segmentation to shift the apparent start and end of code segments, data segments, and stack segments. In fact, any CPU with an MMU does much the same thing. The difference with Morpheus is that the offsets are randomly generated, and they change every 50ms. 

Second, Morpheus encrypts the contents of code and data segments, in addition to moving them around. The encryption keys are also randomized, and they also change every 50ms. This has the obvious benefit of obfuscating your code, which is often the first point of attack for malware. To exploit a buffer-overflow bug, for example, you first have to know where the buggy code resides. Malware can either start at a known program location or it can hunt for a known code snippet. Morpheus frustrates both modes of attack. 

The encryption and decryption take place outside of the processor’s L1 cache but before its L2 cache (and any subsequent caches). That makes it invisible to the processor, including low-level kernel code, but not invisible to external DRAM. Even cache flushes will export only encrypted data. Everything outside the chip is encrypted; everything inside is in cleartext. If an evildoer somehow managed to locate an area of interest despite the address randomization, the data itself would be encrypted with a key that’s good for only 50ms. 

On-the-fly code encryption isn’t a new idea. IBM’s CodePack for PowerPC was doing this back in the 1990s, though in IBM’s case the goal was code compression, and the encryption was just a side effect. Both Morpheus and PowerPC pipeline the encryption alongside address generation in such a way that it has minimal effect on performance. 

Randomizing address offsets isn’t new, either. Address space layout randomization (ASLR) has been around for a while, and mainstream operating systems like Windows, iOS, and Android all use it. But ASLR is a one-time offset added when a program is first loaded. Morpheus takes that concept and repeats it at frequent intervals, denying attackers the time needed to figure out the random offset. 

The 50-millisecond re-randomization period – the Morpheus team calls it “churn” – isn’t cast in concrete. They arrived at that number after testing and simulation. Shorter periods make hacking even tougher, but the overhead adversely affected performance. As it is, the team estimates Morpheus takes a 5–10% performance hit due to all the extra work. 

Austin points out that extremely short churn periods (on the order of 10ms) would force attackers to be physically adjacent to the hardware under attack. The turnaround time through a couple of typical network routers would eat up most of the churn period, leaving almost no time for the hackers to commit their despicable deeds. 

As an added safeguard, Morpheus can initiate an immediate churn if it detects that an attack is underway. So even the 50ms delay is worst-case. 

Morpheus is based on RISC-V, mostly because it’s an open-source CPU specification that encourages experimentation. “It could go well beyond RISC V, well beyond a CPU. The concepts themselves are independent of the underlying implementation,” says Austin. 

Sadly, security measures are becoming a mandatory part of our designs, from silicon layout on up. That adds an unwanted layer of complexity, and it’s wasted effort if it doesn’t work perfectly. Morpheus’s techniques seem singularly effective, and they’re applicable to just about any CPU, DSP, or GPU, according to its designers. If their research pans out, maybe Morpheus will become a standard part of new hardware designs, and one less thing to worry about.

Leave a Reply

featured blogs
Jul 24, 2021
Many modern humans have 2% Neanderthal DNA in our genomes. The combination of these DNA snippets is like having the ghost of a Neanderthal in our midst....
Jul 23, 2021
The Team RF "μWaveRiders" blog series is a showcase for Cadence AWR RF products. Monthly topics will vary between Cadence AWR Design Environment release highlights, feature videos, Cadence... [[ Click on the title to access the full blog on the Cadence Community...
Jul 23, 2021
Synopsys co-CEO Aart de Geus explains how AI has become an important chip design tool as semiconductor companies continue to innovate in the SysMoore Era. The post Entering the SysMoore Era: Synopsys Co-CEO Aart de Geus on the Need for AI-Designed Chips appeared first on Fro...
Jul 9, 2021
Do you have questions about using the Linux OS with FPGAs? Intel is holding another 'Ask an Expert' session and the topic is 'Using Linux with Intel® SoC FPGAs.' Come and ask our experts about the various Linux OS options available to use with the integrated Arm Cortex proc...

featured video

Design Success with Foundation IP & Fusion Compiler

Sponsored by Synopsys

When is 1+1 greater than 2? When using DesignWare Foundation IP & Fusion Compiler! Join Raymond and Yung in their discussion of a customer that benefited from the combination of Fusion Compiler’s machine learning and Foundation IP cells and macros.

More information about DesignWare Foundation IP: Embedded Memories, Logic Libraries, GPIO & PVT Sensors

featured paper

Configure the charge and discharge current separately in a reversible buck/boost regulator

Sponsored by Maxim Integrated

The design of a front-end converter can be made less complicated when minimal extra current overhead is required for charging the supercapacitor. This application note explains how to configure the reversible buck/boost converter to achieve a lighter impact on the system during the charging phase. Setting the charge current requirement to the minimum amount keeps the discharge current availability intact.

Click to read more

featured chalk talk

Multi-Protocol Wireless in Embedded Applications

Sponsored by Mouser Electronics and STMicroelectronics

As our devices get smarter, our communication needs get more complex. In this episode of Chalk Talk, Amelia Dalton chats with Marc Hervieu from STMicroelectronics joins me to discuss the various topologies present in today’s wireless connectivity, and how the innovative architecture and flexible use of resources of the STMicroelectronics STM32WB microcontroller can help you with your wireless connectivity concerns in your next embedded design.

Click here for more information about STMicroelectronics Wireless Connectivity Solutions