[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ANNOUNCEMENT: AMD processor microcode security update

FYI in case we have any of these AMD microprocessors...

On 3/23/2016 11:15 AM, Henrique de Moraes Holschuh wrote:
> 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/

Reply to: