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.