Intel Itanium and Secure64 SourceT are NOT vulnerable to either Spectre or Meltdown.
While the media paints these vulnerabilities as ‘inbuilt’ and difficult to protect against, below we explain how both vulnerabilities work, and why Itanium and SourceT are immune.
Figure: SourceT takes advantage of the security features of the Itanium chip to eliminate all paths to malware injection and execution, and includes protection against high-volume DDoS attacks in the network stack.
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 shockwaves through the open-source and enterprise communities.
Rather than just a simple software flaw, these vulnerabilities are at the heart of almost every computing system in the world today: the CPU.
Both Spectre and Meltdown exploit flaws in the way internal hardware is implemented.
They create 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 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 CPUs 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 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.
What this means for your end user is this: Spectre can trick software that’s secure in and of itself — and following best security practises — into sharing private information without them knowing.
This is obviously a huge problem for end users and businesses alike.
Spectre attacks are effective against x86 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 1960s, when Rob Tomasulo — the author of the ingenious Tomasulo’s Algorithm (which enabled out-of-order execution processors) developed an algorithm to dynamically re-schedule instruction execution.
This allows 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.
This makes it unsafe to work with sensitive information on the machine.
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.
What most people remember, though, is the Watergate investigations, culminating with the August 8th resignation of Richard Nixon.
What you 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 731 million. 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.
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: specialised instructions (e.g., MMX, AES, etc.) and 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 can be forgiven 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 21st 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 it must be built in from the ground up. In this case, that’s the CPU.
EPIC and Itanium
Bill Worley, the chief architect of Itanium 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, 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.
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 generalised 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 an 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 defence-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 hyper threads; 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.
The information is based on an original Blog on 9 January 2018 at Secure64.com. Accessed 9 February 2018.
C-COR is the authorised systems integrator and accredited Southern Hemisphere support centre for Secure64.
For more information, visit https://www.c-cor.com.au/portfolio/secure-dns/