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