These updates most definitely could've been handled better. I was having a busy week with exams and I get a call about around 10 machines not booting (this was before the announcement). Sure enough, last thing everyone reported was updating. I call the supplier and apparently they have reports of at least 2000 machines (at that moment) that had to be reimaged across the city (from what I could tell, all were older AMD PCs) because of this dumb update.
I was used to not being to able to trust software, but if I can't trust hardware now either, farming does suddenly appear much more appealing.
I lost many hours over this last week. The system was unable to boot and finally a thread on reddit came to the rescue ( <a href="https://www.reddit.com/r/techsupport/comments/7sbihd/howto_fix_inaccessible_boot_device_caused_by/" rel="nofollow">https://www.reddit.com/r/techsupport/comments/7sbihd/howto_f...</a> ).<p>This actually made the system boot but there are some leftovers being installed on first boot that I've been unable to disable that also causes the system to be unable to boot.<p>So now, the machine is running but as soon as it is restarted we have to re-image the disk, go through the process of manually removing patches, and then pray that we don't have a power shortage as we'd have to do everything yet again on next boot.<p>I'm not convinced that this patch will solve the issue either, because if this updates requires a reboot the fix won't be installed if we can't boot. I might try to install this update from the recovery console see if that works.<p>Quite frustrating.
In a related development, there are proposed patches to the Linux kernel (not yet merged) to blacklist the broken microcode updates: <a href="https://www.spinics.net/lists/kernel/msg2707159.html" rel="nofollow">https://www.spinics.net/lists/kernel/msg2707159.html</a><p>That patch disables the use by the kernel of the new IBPB/IBRS features provided by the updated microcode, when it's of a "known bad" revision. Since Linux prefers the "retpoline" mitigation instead of IBRS, and AFAIK so far the upstream kernel (and most of the backports to stable kernels) doesn't use IBPB yet, that might explain why Linux seems to have been less affected by the microcode update instabilities than Windows.<p>Also interesting: that patch has a link to an official Intel list of broken microcode versions.
>However, Intel does not appear too concerned that the incident will affect its bottom line - the company expects 2018 to be a record year in terms of revenue<p>There is an interesting paradox in our industry. If you pay enough attention (read: money) to security, you will be late to the market, your costs will be high and you lose profit. If you don't pay enough attention, you take the market, get your profits, but your product (be it hardware or software) and reputation will be screwed later. And worst of all: there's never enough attention to security.<p>So by simple logic, an optimal strategy is to forge your product quickly, take your profits within a [relatively] short period and vanish from the market. I guess we'll see this strategy executed from IoT vendors when market start to punish them for their bad sec.<p>For Intel, that "long period" just happened to be REALLY long.
"Here's a patch" - "Here's a patch to disable that other patch" - ...<p>What's next? Repeat? Sounds like this could turn into a maintainance nightmare quickly. Also because I've introduced things like that myself in the past, and that was for normal applications and not a kernel or OS. Somewhere, someday, there's usually this one exception for which none of your rules hold true and the thing blows up in your face.
Anyway, I'd love to see the actual code for this. Not a chance probably?
By my reading of the article, Microsoft is disabling some mitigations for Spectre due to instabilities that Intel's microcode update have been causing.<p>Intel certainly isn't making any friends these days...
It is not only Microsoft reverting this patch. HP, Dell or Red Hat are doing that as well.<p><a href="https://www.bleepingcomputer.com/news/microsoft/microsoft-issues-windows-out-of-band-update-that-disables-spectre-mitigations/" rel="nofollow">https://www.bleepingcomputer.com/news/microsoft/microsoft-is...</a>
I've not been impressed with my Windows 10 installations of late. All my machines that don't have the Long Term Servicing Branch have had wild instabilities and performance issues the past few months - crazy things, like the task manager taking minutes to launch, and the whole shell periodically crashing. The Fall Creators Update was so bad I had to wipe and start over on some boxes. It's not engendering a lot of confidence in their competence of late.
I never got them. The last update in my windows is from Dec 2017. My antivirus is compliant, the registry key correctly set up and yet it refuses to update.<p>I still haven't had the time to debug it, but I wonder how many people are out there with their OS silently refusing to update.
My brother was hit by a recent update to Windows 7 that prevented the machine from booting. He went to Microcenter to buy a hard drive. There were a lot of people doing the same thing for the same reason when he was there.
>Intel, AMD and Apple face class action lawsuits over the Spectre and Meltdown vulnerabilities.<p>I sure hope Intel will face a class action suit over this botched update. Many professionals have wasted countless hours dealing with this junk.
I mean, is this an unmitigated disaster on Intel's part? It's like a train wreck in slow motion.<p>A part of me feels this stories like this are going to keep getting worse until Spectre is finally used in the wild.
What a mess!<p>The day this blew up we rented our first physical server for the express purpose of running secure critical workloads in unpatched environments. Yes, I know that there is nothing secure, but not everything we do is running a chunk of logic uploaded by an attacker, so we will take our chances.
What does the Spectre bug mean for a person planning to buy a new windows computer? Should I buy an AMD CPU based computer instead of an Intel based computer?
A more accurate title would be that Microsoft disabled the specter mitigation’s due to a flawed Intel update, right? I thought this was all Microsoft’s fault until getting half way through the article.
Ugh, is this the cause of the weird bugchecks I've been having this week? Just gave myself 64gb page file and enabled full memory dumps so I could track it down in WinDbg. I always forget something on fresh installs...