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
- Linux : The current Linux random number generator [callable by
random(), in C] in use is
an Intel binary that is not open source in origin. All
Linux branches using the Intel random number generator are
compromised.
- Intel & AMD x86 cryptography instructions are also
completely compromised. The use of these instructions, even for bulk
encryption with ongoing re-keying is null and void.
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.
- The x86 random number generator has been totally compromised :
CPUs produced outside the US have modified random number generator
masks.
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
- Intel's and AMD's CEOs can be charged with High Treason (and Theft
of State Secrets, as well as Compromising State Secrets) today. This
action is perfectly within the reasonable legal limits of most
European and Asian nations do this today.
- China, Russia and India (as well as other affected nations like
India) can charge these CEOs with High Treason and provide about 1000m
of paper evidence demonstrating the microcode and other attacks.
- The internal laws for High Treason and Compromising State Secrets
are clearly enough written in most nations so as to permit this
without any constitutional or complexities within the law courts of
these nations.
Trade
- Ban Intel and AMD x86 computers with the capability of having their
microcode patched from government use at any level.
- Ban Intel and AMD x86 computers with the capability of having their
microcode patched from being imported or exported.
IT Deployment
- Start an ongoing desktop compute replacement cycle using alternate
[non x86] desktop computing architectures.
- For the European Economic Community (or nations like China or
Japan) replacing the Windows & Mac x86 desktop may be an easier
task than for smaller nations.
- Allow currently deployed x86 CPUs to be assessed for risk and
decommissioned from governmental and quasi-governmental use. National
Universities can be a help here, as there are many technology students
that could benefit from this kind of IT training.
- There are x86 Windows utilities than can be designed to make this
management task easier, every PC should run them.
- Require Microsoft and Apple to provide a "Control Panel" utility on
all their products showing clearly that the product is subject to this
attack vector.
- If Apple, AMD, Intel or Microsoft do not comply in 3 months time --
seize all of the company's assets and charge the CEOs with High
Treason.
Post Espionage Indecent "Evidence Recovery"
- The silicon of not only the early x86 CPUs (when the microcode
feature was introduced) but the current x86 CPUs will have to be
dissected at the gate level by removing layer after layer of etched
silicon, as was done for the Visual
6502 Project. Care and attention will have to be paid to the
"dopant state" of each and every gate. This is delicate and
mind-numbing work on a large scale, and currently only China can
afford to do this.
- The x86 state machine will have to be decomposed on each CPU that is
dissected -- to its lowest level of complexity -- so that the CPU can
be run in simulation. There are some YouTube lectures on how this was
done with the 6502, but the 68000 was only discussed as a possibility
for future work.
- Lecture
1, Lecture
2, Lecture
3, Lecture
4.
- Also see : http://www.youtube.com/results?visual+6502
Other related systems that must be banned :
The Digital Rights Management CPU, its presence is not detectable by the
x86 CPUID instruction.
- According to leaked internal documents from the German Federal
Office for Security in Information Technology (BSI) that Die Zeit
obtained, IT experts figured out that Windows 8, the touch-screen
enabled, super-duper, but sales-challenged Microsoft operating system
is outright dangerous for data security. Windows 8 allows Microsoft to
control the computer remotely through a built-in backdoor. Keys to
that backdoor are likely accessible to the NSA – and in an unintended
ironic twist, perhaps even to the Chinese (but this has not been fully
verified).
- The backdoor is called “Trusted Computing,” developed and promoted
by the Trusted Computing Group, founded a decade ago by the
all-American tech companies AMD, Cisco, Hewlett-Packard, IBM, Intel,
Microsoft, and Wave Systems.
- Its core element is a chip, the Trusted Platform Module (TPM), and
an operating system designed for it, such as Windows 8. Trusted
Computing Group has developed the specifications of how the chip and
operating systems work together.
- Its purpose is Digital Rights Management and computer security. The
system decides what software had been legally obtained and would be
allowed to run on the computer, and what software, such as illegal
copies or viruses and Trojans, should be disabled. The whole process
would be governed by Windows, and through remote access, by Microsoft.
- Now there is a new set of specifications out, creatively dubbed
TPM 2.0. While TPM allowed users to opt in and out, TPM 2.0 is
activated by default when the computer boots up. The user cannot
turn it off. Microsoft decides what software can run on the
computer, and the user cannot influence it in any way.
- Windows governs TPM 2.0. And what Microsoft does remotely is not
visible to the user. In short, users of Windows 8 with TPM 2.0
surrender control over their machines the moment they turn it on for
the first time.
- It would be easy for Microsoft or chip manufacturers to pass the
backdoor keys to the NSA and allow it to control those computers.
NO, Microsoft would never do that, we protest.
- Alas, Microsoft, as we have learned from the constant flow of
revelations, informs the US government of security holes in its
products well before it issues fixes so that government agencies can
take advantage of the holes and get what they’re looking for.
- Experts at the BSI, the Ministry of Economic Affairs, and the
Federal Administration warned unequivocally against using computers
with Windows 8 and TPM 2.0.
- One of the documents from early 2012 lamented, “Due to the loss of
full sovereignty over the information technology, the security
objectives of ‘confidentiality’ and ‘integrity’ can no longer be
guaranteed.”
- Elsewhere, the document warns, “This can have significant
consequences on the IT security of the Federal Administration.” And
it concludes, “The use of ‘Trusted Computing’ technology in this
form ... is unacceptable for the Federal Administration and for
operators of critical infrastructure.”
- Another document claims that Windows 8 with TPM 2.0 is “already”
no longer usable. But Windows 7 can “be operated safely until 2020.”
After that other solutions would have to be found for the IT systems
of the Administration.
- Note : Apple phased out the surveillance chips in 2009, so far the
TPM risks do not seem to apply to Apple hardware.
- Note : Linux (and other related operating systems) do not comply
with the TPM standard. Linux machines cannot use the technology.
- Hardware manufactures could build machines with the chips
deactivated, Microsoft said. If you want to have control over your
computer, that’s what you’d have to buy.
- Linux machines are about the only easy operating system
replacement solution. The city government of Munich started its
Linux move has started 10 years ago and had completed the move by
Winter 2013. Replacement times may vary from organization to
organization.
The Motorola 68000's metallic traces ...
In "about 6 months time"
Multiple options are available in this time
frame
- Forbid the import of Intel or AMD x86 & x86-64 CPUs for all
time.
- Ban Intel and AMD x86 computers with the capability of having their
microcode patched from the Private Sector.
- Create a national monitoring framework that would make possible a
permanent ban Intel & AMD : glue chips, controller chips etc ...
Long Term Solutions (after
6 months)
Essentially any long term solution has to
be severe
- Permanently Forbid the import (and domestic use) of Intel and AMD
CPUs and microcontrollers, glue chips etc... This will require the
hiring a small security intelligence agency workforce to enforce this,
but this action (and workforce) must be phased into the national
police systems within 5 years.
- Refuse to enforce any and all "patents" and "intellectual property"
these companies within national borders.
- Intel & AMD's time as corporations being permitted to operate in
Europe and Asia are finished. The termination (and seizure of all of
the corporation's assets, investments and facilities (plant &
equipment) must take place.
- It can take up to 5 years to create a working framework for the
banning of Intel & AMD controller chips.
Who will not help
- Intel & AMD, and all of their subsidiaries. Intel will probably be
the least helpful. AMD has merely hidden the internal state machine
structure of its microcode.
- MOSSAD, as Intel has a research facility in Israel. MOSSAD already
knows everything about the Intel and AMD microcode subsystems, as most
Intel staff in Israel already work for (or are interviewed by MOSSAD) at
regular intervals.
- Intel was forced to set up a research facility in Israel to save its
executives from being assassinated by MOSSAD. This known "security
compromise" is common knowledge in the security intelligence sector
globally, so this is not a secret and never was a secret. The extremism
of the actions of all the parties involved is ultimately a tragedy for
China, as it has been most taken advantage of here.
- MaAfee is an anti-virus and malware package for x86 windows systems,
but it is owned by Intel. Expect no cooperation from this company.
- Microsoft also has a research facility is Israel, so the security risk
possibilities from this must be taken into account.
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
|
|