Intel Itanium and Secure64 Source T are NOT vulnerable to either Spectre or Meltdown and below are explanations of how both vulnerabilities work, and why Itanium and SourceT are immune.

by John Worley, Director of Engineering, Secure64

The newly announced vulnerabilities (CVE-2017-5715, CVE-2017-5753, CVE-2017-5754) code named Spectre and Meltdown have sent shivers and shockwaves through the open-source and enterprise communities. Rather than just a simple software flaw, the vulnerabilities are at the heart of almost every computing system in the world today: the CPU.

Both Spectre and Meltdown exploit flaws in the implementation of the tremendously complex internal hardware working to provide the appearance of a continuous stream of parallel instruction execution.

SPECTRE

Spectre, as the name suggests, exploits speculative execution. This hardware technique detects when a program decision may be blocked on data from slow memory (RAM or lower levels of cache). Rather than wait, the hardware creates multiple speculative machine states based on the possible outcomes of the decision. It appears possible from the discussion that there can be several such “forks”, which can continue until some earlier decision is available, or no further “forks” can be created. Eventually, one of the speculative states becomes THE machine state and normal (non-speculative) computation resumes; the other states never become architecturally visible and simply “disappear”.

In CPU’s with small register sets (x86, MIPS, ARM, etc.) and deep internal pipelines (x86), it’s much more likely that a variable will not be “live” in a register, so this technique can pay off handsomely in those cases.

The flaw exploited by Spectre (whose meme really should be Blofeld’s cat) is that some side effects of the speculative execution don’t actually disappear, specifically, speculative values loaded into cache. This allows the attacker, using ROP or other techniques, to induce the victim into loading information into the cache without actually using it, to be harvested later.

According to the authors, Spectre attacks are effective against x86 (what isn’t, really?) as well as the RISC-based ARM and MIPS architecture.

MELTDOWN

Meltdown, so called because it “melts down” the normal address space protections, exploits a different type of execution speed-up: out-of-order execution. This technique dates back to the 1960’s, when Rob Tomasulo developed an algorithm to dynamically re-schedule instruction execution to allow otherwise-blocked instructions to proceed if they didn’t depend on the stalled instruction. An extended approach, out-of-order superscalar, goes even further and allows multiple, independent instruction streams to be executed in parallel when resources allow.

Of course, when machine exceptions occur (page faults, system calls, etc.), the architectural state of the machine must be made consistent with the logical state at the time of the exception, meaning that multiple instructions following the exception are “discarded”. Like Spectre, Meltdown harvests information from visible state, e.g., caches, that are not properly cleaned up.

An additional component of the attack is a memory region, virtual or physical, that maps all (Linux) or most (Windows) of physical memory at a different set of addresses than the user space. Interestingly, the authors were unable to affect some attacks on ARM and MIPS architectures, but similar, simpler attacks, also work.

1974

The Year 1974 was notable for many important events. The first recorded surviving sextuplets were born in Cape Town. People Magazine was first published (Mia Farrow on the cover), while the Brady Bunch and Lucille Ball both made their final appearances on TV. ABBA wins the Eurovision song contest with “Waterloo”, and Queen releases their second album (Queen II). What most people remember, thought, is the on-going Watergate investigations, culminating with the August 8^th resignation of Richard Nixon.

What most people SHOULD remember, though, is that 1974 is the birth year of the x86 computer line. An amazing variety of bells and whistles have been added over the years, but the basics of the architecture remain unchanged. The 8080 was implemented in approximately 6000 transistors, compared to the Nehalem at 731M. Over 120,000 times as many transistors, but the programmer (remember – everything runs in assembly!) is still stuck with small register sets, two-operand opcodes, and variable-length multi-cycle instructions (although see below …)

So, what did Intel do with all those transistors? On-board caches are there (up to 24MB shared LLC), but the bulk of the real estate goes into two functions: compatibility (Intel’s bread and butter) and performance. Performance comes from two sources: specialized instructions (e.g., MMX, AES, etc.) and – you guessed it – speculative, out-of-order, deeply pipelined instruction execution.

When 30%-40% of your chip area is already burned on supporting and speeding up legacy code and dusty decks, the Intel engineers may be given some forgiveness for not taking the time and additional chip area to properly clean up the instruction execution.

This raises the question: can we really meet the needs of 21^st century computer security with a 44-year old architecture? The answer has been repeatedly found to be “no” – Spectre and Meltdown are just the latest in a long line of goofs, oopses, and oversights.

Enhancing computer security is like changing a building design to be taller. You don’t make a building taller by simply adding another floor. You have to think of lifting the existing building and
inserting a new foundation (including mechanicals, environmentals, etc.) to support it. Computer security isn’t frosting you put on the top (or, as Bruce Schneier says “magic fairy dust”) – it must be built in from the ground up – and ground, in this case, is the CPU.

EPIC and Itanium

Bill Worley, the chief architect of Itanuim and co-founder of Secure64, was obsessed with computer security. He intrinsically knew this foundational principle, and understood complexity is the enemy
of security. As an early contributor to IBM’s RISC projects, and as the chief architect of HP’s PA RISC family, he also knew a few things about what does and doesn’t pay off in the chip area. He looked at the vast chip areas devoted to out-of-order and speculative execution and knew this was a possible area for attacks. He also knew this could be much better applied to additional caches and execution units, leaving the task of figuring out parallelism to compilers and software tools, explicitly specifying this to the hardware. Thus was born the EPIC architecture: explicitly parallel instruction computing.

But parallelism wasn’t enough – the architecture had to allow for better security than before. After all, this was to be the new foundation. So, numerous features, some new, some old, were melded into a unique, flexible, powerful memory architecture. Additionally, the internal pipelines had to properly clean up after themselves.

After Bill retired from HP in 2002, it was natural for him to think of this architecture, now released as Itanium from Intel, when approached on how to build a secure webserver. The rest is the story of Secure64.

Itanium vs. Spectre and Meltdown

The Itanium platform is naturally immune to both Spectre and Meltdown precisely because the complex, expensive methods used to speed up a 44-year old architecture are completely absent in Itanium.

Itanium execution is explicitly parallel. It is the job of the compiler or coder to lay out the instructions and tell the hardware what can be done in parallel. Linus once quipped that he’d like to see an out-of-order Itanium (probably something he regrets saying, now), showing himself clueless about what EPIC and Itanium were about.

Without out-of-order execution, there is no way for the Meltdown attack to work.

Likewise, there is no speculative execution in Itanium. Instead, the architecture provides powerful branch prediction and predication, a concept generalized from ARM (sadly, abandoned in AArch64) to avoid branching altogether.

Moreover, the vast IA-64 register set dramatically reduces the chances that a data item would be loaded from memory at the time it’s needed. Let’s consider the first Spectre example:

if (x < array1_size) {
y = array[array1[x] * 256];
}

In Itanium, if array1_size is known to be unchanged in the function, it would be loaded early and maintained in a register, as would the addresses of array1 and array2, so the Itanium coding for the expression would be:

cmp.ltu   p6, p7 = r13, r14
shladd    r8 = r13, 2, r15 ;;

(p6) ld4 r8 = [ r8 ] ;;

(p6) shl r8 = r8, 8 ;;

(p6) add r8 = r8, 8 ;;

(p6) ld4 r8 = [ r8 ]

Notice there’s no branching; further, the architecture definition ensures that no results of predicated operations are architecturally visible, even in the case of loads, stores, or exceptions.

There is a Itanium feature called speculative loads, but it is an entirely different mechanism, explicitly controlled by software. It is rarely generated by compilers and almost never appears in hand assembly. This means the attacker would have to rewrite the victim code, but then why bother with the subterfuge if you can do that?

SourceT® vs. Spectre and Meltdown

Like its underlying CPU, SourceT is naturally immune to both Spectre and Meltdown, but adds extra defense-in-depth.

The first and largest hurdle a Spectre or Meltdown attacker must overcome is injecting the attacking code into a running system. And this, quite simply, cannot be done:

(1) The boot image is cryptographically authenticated, so “trojan” images will not boot.

(2) Once loaded, all executable pages are locked-down and accessible as data, read or

write; there is no mechanism to add new code pages.

Even if an attacker can add code (he can’t), there is no way for it to do anything to the victim:

(1) Unlike x86, ARM, MIPS, etc., all program control information is stored in a separate

backing store. The address is unique per thread, not programmatically available outside

the thread –  not even within the thread, really, and stored in high-privilege
memory, as well.

(2) SourceT does not run with hyperthreads; there is no share  branch target table for the

attacker to manipulate.

(3) Each thread’s private memory is also protected with a 24-bit protection key. So, even if

the attacker knew the address(es) it wanted, it couldn’t read or write them.

Meltdown would have a “meltdown” because, even failing all other impossibilities, there is no space or spaces, privileged or otherwise, that map all of physical memory for reading and/or writing. And, as with any load/store architecture, indirect branch prediction/speculation is not an issue; Itanium goes further and requires indirect branches to use a special set of registers which can only be set from integer registers, never stored or loaded directly.

—