Live data from Hacker News

Microsoft disables Spectre mitigations as Intel’s patches cause instability

securityweek.com

181–190 of 329 posts

Re: Microsoft disables Spectre mitigations as Intel’s patches cause instability

#182

I'm amazed on how Intel's stock price still keeps going UP, despite all these problems... just WOW.

Do you know someone who is going to stop buying Intel's CPUs?

Well , Linus already said perhaps linux should look at the arm folk . Should that happen , well guess what ? From my very small knowledge , 90+% of internet infrastructure runs on linux .

Re: Microsoft disables Spectre mitigations as Intel’s patches cause instability

#183
post #133
post #61

In a related development, there are proposed patches to the Linux kernel (not yet merged) to blacklist the broken microcode updates: https://www.spinics.net/lists/kernel/msg2707159.html 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 upstr…

> In a related development, there are proposed patches to the Linux kernel (not yet merged) to blacklist the broken microcode updates Linus probably won't pull it until it's truly known to be stable, because of his attitude towards having decent quality code and not causing needless system instability. Without Linus... who knows what would have happened by now.

Everyone would have politely installed their "fixes" . This situation shows why linus was swearing .

Re: Microsoft disables Spectre mitigations as Intel’s patches cause instability

#184

Earlier quoted context omitted.

Yes, in principle what you've said about the Unix approach here is correct, if you upgrade one half of a system and not the other half and now they're talking different protocols, that might not work. But keep in mind that if your system can't cope with this what you've done there is engineer in unreliability, you've made a system that's deliberately not very robust, unless it's very, very tightly integrated (e.g. tw…

Aaaaaand here comes the Linux defending! OK... > But keep in mind that if your system can't cope with this what you've done there is engineer in unreliability It's weird that you're blaming my operating system's problems on me . "My system" is something a ton of other people wrote, and this is the case for pretty much every user of every OS. I'm not engineering anything into (or out of) my system so I don't get the "…

It's weird that you're blaming my operating system's problems on me.

No one is blaming you specifically, it is a common way of saying, “if you write operating systems, and you do $THING, you will get $RESULT.” Common, but wrong, which is why your high school English teacher will ding you for phrasing something that way.

Re: Microsoft disables Spectre mitigations as Intel’s patches cause instability

#185

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 AM…

Become a goat farmer. https://www.reddit.com/r/sysadmin/comments/4l7kjd/found_a_te...

Re: Microsoft disables Spectre mitigations as Intel’s patches cause instability

#186
post #32

Earlier quoted context omitted.

Speaking of which, why do so many things require reboot to update on Windows?

There is a very fundamental difference between how Unix and Windows view open files: On Windows, once the file is open, it is that filename that is open; You can't rename or delete it; Therefore, if you want to replace a DLL (or any other file) that is in use, you have to kill any program that uses it before you can do that; And if it's a fundamental library everything uses (USER32.DLL COMCTL.DLL etc), the only effec…

Maybe this is also why 'rm -rf /' is so effective in destroying your system, isn't it?

Re: Microsoft disables Spectre mitigations as Intel’s patches cause instability

#187
What a mess!

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.

Re: Microsoft disables Spectre mitigations as Intel’s patches cause instability

#188
post #46
post #27

Earlier quoted context omitted.

Just in case you, like me, missed the memo where Microsoft said they'd stop supplying security updates if you have no AV / AV incompatible with the patches installed. The fix to the former is creating the registry entry manually. https://support.microsoft.com/en-us/help/4072699/january-3-2...

Bizarre. Customers without Antivirus In cases where customers can’t install or run antivirus software, Microsoft recommends manually setting the registry key as described below in order to receive the January 2018 security updates.

Do I read this correctly ? M$ gave us the registry key with which we can convince winblows that we are runing AV , when infact , we uninstalled it ?

Re: Microsoft disables Spectre mitigations as Intel’s patches cause instability

#189
post #149

Earlier quoted context omitted.

And then another developer kindly explained why he's wrong. It's fun to listen to Linus' rants, sure, but he's not always correct.

And then yet another developer showed there are way better fixes than what intel proposed [1]. So he was correct after all. [1] https://lkml.org/lkml/2018/1/23/25

It's almost as if software development isn't an exact science and there are multiple approaches to any given problem.

Re: Microsoft disables Spectre mitigations as Intel’s patches cause instability

#190
post #71

Earlier quoted context omitted.

FYI - The “dude” from Amazon worked for Intel for 8 years before joining Amazon UK just over a year ago.

The “dude” is also probably working under an insane amount of pressure and being made to feel like he is somehow responsible or at fault for the whole situation. Best not to make it personal from the peanut gallery.

So the person supposedly single-handedly working on this fix doesn't even work for Intel? That strikes me as... Odd?
Post reply on HN