Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.security > #4646 > unrolled thread

ANNOUNCEMENT: AMD processor microcode security update

Back to article view | Back to linux.debian.security

Contents

  ANNOUNCEMENT: AMD processor microcode security update Henrique de Moraes Holschuh <hmh@debian.org> - 2016-03-23 19:20 +0100
    Re: ANNOUNCEMENT: AMD processor microcode security update "Kalnozols, Andris" <andris@hpl.hp.com> - 2016-03-23 20:10 +0100
      Re: ANNOUNCEMENT: AMD processor microcode security update "Kalnozols, Andris" <andris@hpl.hp.com> - 2016-03-23 20:20 +0100
      Re: ANNOUNCEMENT: AMD processor microcode security update Jason Fergus <leech@thefnords.org> - 2016-03-24 23:40 +0100

#4646 — ANNOUNCEMENT: AMD processor microcode security update

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 <hmh@debian.org>

[toc] | [next] | [standalone]

#4648

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/
> 

[toc] | [prev] | [next] | [standalone]

#4649

Profuse apologies for the group reply; more proof that
multi-tasking is overrated...


On 3/23/2016 11:52 AM, Kalnozols, Andris wrote:
> FYI in case we have any of these AMD microprocessors...
> 

[toc] | [prev] | [next] | [standalone]

#4653

That's very interesting.  Hopefully that's not the reason my AMD system
would randomly crash on me, I thought I had fixed it with some better
cooling, and one of my DIMMs had gone bad.  I no longer have the system
though.

On Wed, 2016-03-23 at 11:52 -0700, Kalnozols, Andris wrote:
> 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.ht
> > ml 
> > 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_vu
> > lnerability_from_unprivileged/
> > 

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.security

csiph-web