Having gotten back in the door...
mikeymike wrote:
I don't know much about processor architecture or software workarounds for issues, but I imagine the workaround for this is going to be much the same as with previous processor bugs, such as the Pentium F00F bug...
See, this isn't even 'bug.' It's a design decision. (Where have we heard that before? No, but seriously...) AMD did what seemed like a very 'sane' thing, and didn't obfuscate the procedure at all. However, since they
are in the middle of nullifying a whole other class of exploitable 'design decision,' if this gets documented readily enough, and someone comes up with a useful way to exploit it (presently, how many normal users are running XP with Admin privs?)... it could be moderately-large T Trouble, with the value of T increasing proportional with the popularity of K8 vs. Intel.
The value of the vulnerability (and the potential to somehow crash a moderately large subset of boxes is, of course, the definition of 'vulnerability') is blunted by the need to have 'root' priveleges by other means, but as the article notes, it opens the door to some sneaky tricks -- mostly more subtle versions of hacks known today (turning what was previously a NOP into something useful, suddenly activating and privelege-escalating a payload quiescent in a widely-distributed DLL), or more usefully destructive versions of same (you can fry anyone's hardware already by sending vCore through the roof, but that only works mainboard by mainboard; an attack that works across a whole class of CPU -- and yes, this does hinge on whether the microcode is actually capable of doing anything so terrible -- is much more usefully kid-accessible if wanton destruction is the goal).
The obvious solution is to not run potentially-hostile or potentially-exploitable (in other ways) software under Ring 0, AKA 'Administrator' or 'root.' Fairly straightforward (certain 'alternative' OSes have, of course, encouraged this practice for years), but not innately as simple as patching against F00F.
A secondary level of protection would involve scanning for the signature of a microcode patcher, with the same overhead as any other form of 'virus' scanning takes today. (Too much, really.)
Or, point taken, the kernel itself could lock out all attempts to write to that MSR, but that poses a chicken-and-egg every time there's a good reason for the kernel vendor to apply an update that the BIOS vendor/distributor didn't. -- Rare now, but becoming less rare as complexity grows, and I can only assume Microsoft is a major distribution channel for 'necessary' (for the 'stable' function of Windows) updates, absent the guarantee of every BIOS shipper's cooperation in every product ever made. If the kernel will load the proverbial trustedupdate.rom before enabling protections each boot, then, at least for the unlikely but severe-if-possible hardware-frying case, it's 'worth' an attacker's trouble to figure out how to modify said blocks on disk.
Not the end of the world, but one more confounding annoyance in it. In the worst (hopefully impossible) case, a "Click here to run this file purporting to be a screensaver that actually manages to do permanent damage to your CPU" worm -- helpfully propagated by 'immune' users of alternate product, of course -- would be an expensive counter to the advance in security these chips otherwise provide. ["We're too smart for that!," sure, so instead let's slip it into a supply-side hack on something popular... like, say, an adware-removal util that naturally needs such priveleges to do its work.]
