THIS ANNOUNCEMENT IS ONLY RELEVANT TO SYSTEMS THAT HAVE AMD PILEDRIVER
MICROPROCESSORS (AMD-FX, and AMD Opteron 3300 / 4300 / 6300).
AMD has released a microcode update that fixes a severe fault (also
known as "erratum") on AMD Piledriver processors. This erratum can
cause dangerous system instability, and it is also a grave security
risk. Both server and desktop processors are affected by this erratum.
Without this fix, these processors may misbehave in an extremely
dangerous way when they receive an NMI (non-maskable interrupt),
resulting in unpredictable system behavior. Robert Święcki discovered
that the incorrect behavior can be exploited by an unprivileged user in
an unprivileged VM to directly attack the host (hypervisor) kernel.
It is trivial to trigger the erratum using the "perf" tool.
The affected processors identify themselves (in /proc/cpuinfo) as:
vendor_id : AuthenticAMD
cpu family : 21
model : 2
stepping : 0
We believe those AMD processors to be:
* AMD-FX 32nm family (codename "Vishera")
* AMD Opteron 3300 family
* AMD Opteron 4300 family
* AMD Opteron 6300 family
The above listing might be incomplete.
On a Debian system, the erratum can be fixed by installing updated
amd64-microcode packages from "non-free" and rebooting. The processor
will be updated during boot (by the "initramfs") with the fixed
microcode. After the system reboots, the "microcode" field in
/proc/cpuinfo should read "microcode: 0x0600084f" (on the above
mentioned processors). This indicates that the fixed microcode is
active.
Note: the microcode update is not permanently installed to the
processor: it is reapplied at every boot. You should check with your
motherboard vendor for the availability of a new BIOS/UEFI update with
the fixed microcode.
The updated amd64-microcode packages are already available: users of
unstable, testing ("Strech"), and wheezy-backports need only update
their systems.
Users of stable ("Jessie") and oldstable ("Wheezy") should enable the
"stable-proposed-updates" archive ("oldstable-proposed-updates" for
oldstable) to receive this update now, or wait for the next Debian
stable/oldstable point release (scheduled for 2016-04-02).
Please refer to https://www.debian.org/releases/proposed-updates.html
for details on stable and oldstable early updates.
All packages can also be downloaded directly from:
http://httpredir.debian.org/debian/pool/non-free/a/amd64-microcode/
Version key:
oldstable: 1.20160316.1
oldstable-backports: 2.20160316.1~bpo70+1
stable: 2.20160316.1~deb8u1
testing: 2.20160316.1
unstable: 2.20160316.1
== What is a processor microcode update? ==
Microcode is a control sequence/program that implements several internal
functions of the system processor (CPU). A microcode update can fix
many classes of processor defects. It can also update the control
parameters of on-die processor subsystems, such as: power management, IO
buses, embedded GPU interconnect, embedded cache and memory controllers,
performance monitoring unit, etc.
The Linux kernel can send a microcode update to the processor when one
is supplied by the operating system (Debian + non-free).
The microcode update has to be applied every time the processor is reset
or powered off: it doesn't "stick". Therefore, Debian has to install
this microcode update to the initramfs, so as to apply it every time the
computer boots.
== What is known about this AMD microcode update? ==
Robert Święcki, while fuzzing the kernel using the syzkaller tool,
uncovered very strange behavior on an AMD FX-8320. This strange
behavior was later reproduced on other AMD Piledriver model 2, stepping
0 processors including the Opteron 6300.
He contacted AMD, which attributed the behavior to a microcode fault,
introduced by microcode revisions 0x600832 and 0x600836. Unfortunately,
using an earlier revision of the microcode leaves other critical errata
unfixed (on Opteron 6300, for example, it would be expose users to
another dangerous critical erratum, #815, which these microcode
revisions did fix).
Robert discovered, using his proof-of-concept exploit code, that the
incorrect behavior allows an unprivileged attacker on an unprivileged VM
to corrupt the return stack of the host kernel's NMI handler. At best,
this results in unpredictable host behavior. At worst, it allows for an
unprivileged user on unprivileged VM to carry a successful host-kernel
ring 0 code injection attack.
The erratum is timing-dependent, and easily triggered by workloads that
cause a high number of NMIs, such as running the "perf" tool.
More details:
http://seclists.org/oss-sec/2016/q1/450
http://www.theregister.co.uk/2016/03/06/amd_microcode_6000836_fix/
https://www.reddit.com/r/linux/comments/47s8a8/new_amd_microcode_vulnerability_from_unprivileged/
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique de Moraes Holschuh <h...@debian.org>
