Re:Ryzen Community Update #2
by tbrock on Thursday March 30, 2017 @01:31PM
(#13997263)
You are now aware we live in a world where even CPUs have microcode patches.
[ Parent
| on HN ]
Re:Ryzen Community Update #2
by JoachimSchipper on Thursday March 30, 2017 @01:39PM
(#13997336)
We've been living in that world for a while - what do you think is new here? E.g. http://www.anandtech.com/show/8376/intel-disables-tsx-instru... (and Intel is suspiciously tight-lipped about the (security?) impact of the TSX bug, while AMD's FMA3 bug seems to be a comparatively-harmless hang.)
Re:Ryzen Community Update #2
by nowaynohow on Friday March 31, 2017 @06:25AM
(#14002474)
What security impact of the Haswell/early-Broadwell TSX bug? The support for all TSX instructions where really disabled by the microcode update, and we know that for sure because it crashed the world instantly (in Linux).
Now, working TSX can have a security impact, yes. At least on TSX as implemented on later Broadwell/early Skylake, memory accesses done from inside an speculative region are allowed to bypass stuff they shouldn't. Is that what you meant?
Re:Ryzen Community Update #2
by RandomOpinion on Thursday March 30, 2017 @03:22PM
(#13998137)
Digging into the history briefly, patchable microcode seems to have existed in commercially released computers as far back as the 1960s.
"...CCROS [microcode] cards on the [IBM System/360] Model 30 could be replaced in the field. This made design modifications easier to accomplish, as well as providing for field diagnosis. ...
The later System/360 Model 25 and models of the later System/370 series were configured with at least one portion of the control store being read-write for loading microcode patches and microdiagnostics."
Re:Ryzen Community Update #2
by antisthenes on Thursday March 30, 2017 @02:47PM
(#13997878)
https://arstechnica.com/gadgets/2007/12/linux-patch-sheds-li...
Was this not the same thing? Some microcode update to patch a CPU flaw essentially?
That was almost a decade ago.