FYI in case we have any of these AMD microprocessors...
On 3/23/2016 11:15 AM, Henrique de Moraes Holschuh wrote:
> 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/
>
