A BOINC Distributed Computing Project is Needed to Find
(Intel & AMD) x86 State Machine "microcode attack vectors"
found in
Microsoft, Linux & Apple operating systems






Abstract
A distributed cryptography project is needed to find x86 State Machine "microcode attack vectors" Intel's & AMD's x86 (& all x86-64) CPUs.

These x86 CPUs contain rogue microcode that is currently being used to create or modify x86 state machine instructions that make possible "Privilege Level Escalation" (PLE) to achieve access to the Superuser privilege level.

With PLE, all data on an x86 computer is accessible for indexing (and or retransmission) onward to multiple security intelligence agencies.

This x86 microcode attack vector  has essentially completely eliminated the x86 state machine's ability to handle secrets of any kind.

Other current x86 security issues

Some recently published scientific research has determined that CPU (or GPU, or FPU or Vector Unit) hardware based random number generators can be completely compromised by changing the "p" or "n" doping of wires within the random number generation logic gates of any CPU.
This distributed computing project should also look for the new instructions (or modified existing instructions) within the code fragments of existing operating system code on Microsoft Windows & Apple Computer systems.

Other CPUs of the x86 type from other US or UK companies should be subject to the same level of analysis.

In the long run, each and every x86 CPU ever made with microcode capability must be disassembled layer by layer and the arrangement of the logic gates recovered (including the "p" and "n" doping state of all of the gates), much like what has been done with the Commodore 64 CPU 6502 (CMOS).




What is Microcode?

Microcode is a layer of hardware-level instructions or data structures involved in the implementation of higher level machine code instructions in central processing units, and in the implementation of the internal logic of many channel controllers, disk controllers, network interface controllers, network processors, graphics processing units, and other hardware. Microcode resides in special high-speed memory and translates machine instructions into sequences of detailed circuit-level operations.

Microcode helps separate the machine instructions from the underlying electronics so that instructions can be designed and altered more freely. It also makes it feasible to build complex multi-step instructions while still reducing the complexity of the electronic circuitry compared to other methods. Writing microcode is often called microprogramming and the microcode in a particular processor implementation is sometimes called a microprogram.

Modern microcode is normally written by an engineer during the processor design phase and stored in a ROM (read-only memory) or PLA (programmable logic array) structure, or a combination of both. However, machines also exist which have some (or all) microcode stored in SRAM or flash memory.

Microcode stored outside the CPU is traditionally denoted a "writable control store" in the context of computers.

Complex digital processors may also employ more than one (possibly microcode based) control unit in order to delegate sub-tasks which must be performed (more or less) asynchronously in parallel. Microcode is generally not visible or changeable by a normal programmer, not even by an assembly programmer. Unlike machine code which often retains some compatibility among different processors in a family, microcode only runs on the exact electronic circuitry for which it is designed, as it constitutes an inherent part of the particular processor design itself.



An x86 "Known Feature" and Problem

Modern x86 microprocessors from Intel and AMD contain a feature known as "microcode update", or as the vendors prefer to call it, "BIOS update". Essentially the processor can reconfigure parts of its own hardware to fix bugs ("errata") in the silicon that would normally require a recall.

This is done by loading a block of "patch data" created by the CPU vendor into the processor using special control registers. Microcode updates essentially override hardware features with sequences of the internal RISC-like micro-ops (uops) actually executed by the processor. They can also replace the implementations of microcoded instructions already handled by hard-wired sequences in an on-die microcode ROM.

AMD's US Patent 6438664 ("Microcode patch device and method for patching microcode using match registers and patch routines") goes into substantial detail on this.

Typically microcode update blocks are stored in the BIOS flash ROM and loaded into the processor as the system boots. They can also be loaded by the operating system; for instance, Linux contains a microcode device driver for Intel chips.

AMD recently released a "BIOS fix" to motherboard makers to address Errata 109, in which REP MOVS instructions caused subsequent instructions to be skipped under specific pipeline conditions.

Previously it was not clear if and how AMD even supported microcode updates in the K8 family until this announcement. After analyzing a number of BIOS images, it appears that AMD has secretly used the microcode update facility on several occasions over the past few years, but obviously avoided publicly disclosing that it actually had bugs patchable in this manner.

Early K7 (Athlon) cores initially supported microcode updates as well, until ironically the microcode update mechanism itself was found to be broken and subsequently listed as an erratum.


AMD vs Intel : Intel's Microcode Formats "seem more secure"

Surprisingly, AMD microcode itself is in no way encrypted as it is in Intel microcode updates; the raw data loaded into the microcode patch array is directly exposed. The repetitive structure of the data, bit patterns and fields characteristic of microcode indicate that apparently no encryption was performed.

US Patent 6438664 describes the most probable structure of this data; the bit patterns in the update blocks show the outline of the uop triads and control fields known to exist in K8 microcode. Further analysis of the microcode format is in progress.

Even more surprising is the total lack of strong authentication that the update block has not been damaged or altered. The processor's sole means of validating an update is to take the sum of all 32-bit words in the 896 byte update block and compare it to the 32-bit checksum at offset 12; this verification is done by microcode already stored in the microcode ROM.

Modifying random bits within the update block was tested, regenerating a correct checksum, and loading the block into the processor. In many cases the processor accepts the block with no visible effects; other cases cause a spontaneous reboot.

Most alarming is the way in which certain bit modifications cause the processor to perform very bizarrely, for instance raising segfaults and performing incorrect computations on certain microcoded instructions.

The processor also apparently does not check the header to see if the loaded update matches its exact model and stepping; it is possible to load updates intended for an Opteron onto an Athlon 64 CPU, although this will crash the machine or cause bizarre behavior.

Depending on which data block bits are modified, loading an invalid update apparently causes an internal fault and the CPU spontaneously reboots.

The ability to fundamentally alter instruction decoding and execution on AMD K8 processors is sure to interest hardware hackers everywhere.

Unfortunately, it is by not means clear if these kinds of alterations have much practical use. The updates are structured to patch specific microcode lines, and there are a very limited number of patch slots available (around 64 if the patented technique was actually implemented as described). Adding useful new instructions to the ISA is therefore unlikely; at best we could enable a previously undefined opcode to execute a few lines of uops and return. The primary purpose of microcode patching is to modify or disable defective functionality, rather than add new features.

Interestingly, this does have serious implications for system security. If one is able to get root access on a machine even once, it is hypothetically possible to install a microcode update specifically to help compromise security from userspace at a later time. Such an update could be flashed into the BIOS to make it persistent across reboots.

For instance, by patching the appropriate microcode lines, it may be possible to catch an opcode that would normally be illegal, and instead handle it by tricking the TLB into thinking we're in kernel mode when in fact the attacker has only compromised a userspace process. From there, the attacker could control the entire machine, all without altering a single bit of "software".

There may also be a hidden danger to altering K8 microcode without complete information. It is possible (though very unlikely) that the microcode could electrically reconfigure signal routing in a fashion similar to FPGAs, for instance to cut off defective logic and reroute signals to redundant arrays. This approach has been used in the past and the AMD patents even suggest it.

If this were the case, there is a very remote chance the CPU itself could be permanently damaged, for instance, by tri-stating pass transistors into a high current draw state or adjusting the K8's voltage and frequency scaling controls out of spec. This is not meant to discourage potential hackers.

Nonetheless, it is suspected that with sufficient analysis or maybe a bit of inside information, one could do some interesting things with microcode hacking.

At the very least, the information here should be useful for adding AMD support to the Linux microcode update driver, which already supports Intel's update mechanism.


Currently available solutions to cope with the x86 and x86-64 attack vector


Timeframes

Today (realistically within the next three months)

Legal

Trade

IT Deployment

Post Espionage Indecent "Evidence Recovery"

Other related systems that must be banned : The Digital Rights Management CPU, its presence is not detectable by the x86 CPUID instruction.

 
The Motorola 68000's metallic traces ...
Motorola 68000 chip


In "about 6 months time"

Multiple options are available in this time frame

Long Term Solutions (after 6 months)

Essentially any long term solution has to be severe

Who will not help

Who can or might help

What technologies can help

Nations that have taken solutions to mitigate the x86 risk factor

Russian news outlet Kommersant has reported that the nation's government wants to ditch Intel and AMD processors in favor of a locally-developed ARM effort.

The outlet's report suggests three state-owned Russian companies are banding together to develop to be called “Baikal” that will use ARM's 64-bit kernel Cortex A-57 as its base design, offer at least eight cores, be built with a 28nm process and run at 2GHz or more in PCs or servers. The report also says “It is assumed that Baikal will be delivered to the authorities and state-owned companies.”

Russia's ”central state information agency” ITR-TASS, picked up on Kommersant's report and in its own effort writes that Baikal “will be installed on computers of government bodies and in state-run firms, which purchase some 700,000 personal computers annually worth $500 million and 300,000 servers worth $800 million.”

While both ITR-TASS and Kommersant say Baikal will find its home in computers run by state-owned entities, neither suggests there's a national security angle behind the decision. That's not stopped Phoronix from declaring that “For strict security enthusiasts believing AMD and Intel have been compromised by the NSA or other US agencies, it's time to celebrate.”

Setting aside that kind of thinking, a move to 64-bit ARM by entities that collectively acquire a million devices a year would be significant because of boost it would give ARM-based servers and PCs.

Such devices are, at present, largely hypothetical. But with Amazon Web Services, Google and Facebook all reported to be considering their own ARM designs to keep their servers' operating costs down, interest in the idea is considerable. Startups are having a go, too: at Computex The Reg met Cavium, a purveyor of 48-core chip it is aiming at the server market.

Cavium's staff includes folks from failed ARM server chipmaker Calxeda, who told us they feel that effort flopped because not enough enterprise software runs on ARM. That's no longer quite such a problem. If Russia follows this path, and the rules of open source, the problem could disappear entirely.



The distributed computing solution

ADD CONTENT RELATING TO DISTRIBUTED HASHSUM COLLISION TESTING






Newsworthy items that are evolving, in relation to the Intel x86 CPU attack vectors


References

Microcode

Security Intelligence Agencies

Nations Affected, internal security completely compromised

Related Documents (microcode)

Related websites

Notable agencies and entities using attack vectors, some x86

Co-authors (if applicable) [TBA] : None


Initial Idea

Created

Last Revised

Version

Last Change

Revision State


25 May 2013

28 August 2013

27 July 2014

0.84dd

Add content links

Revisable