Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microsoft disables Spectre mitigations as Intel’s patches cause instability

securityweek.com

Post reply on HN
Print view View original

201–210 of 329 posts

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

#201

Post by tobyhinloopen »

tyfon wrote: post #200
ggregoire wrote: post #163

Earlier quoted context omitted.

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

I know in my company this has indeed resulted in a full stop in buying Intel and going AMD instead. There is also an active "project" to replace the Intel servers. I work in a bank and they are terrified of the possibility of user processes reading privileged memory. Not necessarily out of actual fear but out of the insane amount of paperwork this will require to satisfy the auditors that it is still safe. Anecdotall…

Wasn’t AMD also affected?

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

#202

Post by monkmartinez »

speedie wrote: post #182
ggregoire wrote: post #163

Earlier quoted context omitted.

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 .

Then ARM "folk" will find the equivalent of Spectre and Meltdown... then the cycle repeats, ad infinitum.

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

#203

Post by imglorp »

shultays wrote: post #49

Amount of fuck-up in this whole issue is mind blowing. I am getting more surprised with every new I get

I wonder how much all this cleanup will cost in hours, downstream, for all the installed users? Judging by all the grief on this thread it's substantial.

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

#204

Post by code_duck »

mehrdadn wrote: post #37
beagle3 wrote: post #32

Earlier quoted context omitted.

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…

> On Windows, once the file is open, it is that filename that is open; You can't rename or delete it; This is wrong... there's no clear-cut thing like the "file name" or "file stream" that you can specify as "in-use". It depends on the specifics of how the file is opened; often you can rename but not delete files that are open. Some (but AFAIK not all) in-use DLLs are like this. They can be renamed but not deleted. A…

In a case where one could get some sort of inconsistency because of different library versions, you restart the applications. That’s the point, that this can be handled by restarting the applications and not the entire operating system.

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

#205

Post by code_duck »

mehrdadn wrote: post #82
tialaramex wrote: post #52

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

Why would Linux need ‘defending’ for superior flexibility? The fact that files work like this is an advantage, not a disadvantage. I have never seen the flaw you’ve pointed out actually occurring in practice.

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

#206

Post by dimmuborgir »

megaman22 wrote: post #33

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

Creators Updates (1703 / 1709) are the culprits. LTSB (1607) has not been upgraded to Creators Update yet and it runs like butter.

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

#207

Post by evmar »

rlpb wrote: post #109
mehrdadn wrote: post #82

Earlier quoted context omitted.

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

> ...but it happens more often than I would like that I update Linux (Ubuntu) and, lo and behold, I can't really use any programs until I reboot... Ubuntu developer here. This doesn't happen to me in practice. Most updates don't cause system instability. I rarely reboot. Firefox is the most noticeable thing. After updating Firefox (usually it's a security update), Firefox often starts misbehaving until restarted. But…

For Chrome we had to go through a lot of extra effort to make updates not break us.

http://neugierig.org/software/chromium/notes/2011/08/zygote....

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

#208

Post by jschwartzi »

majewsky wrote: post #87
pjc50 wrote: post #55

Earlier quoted context omitted.

> What I expect it also means is that you'll get inconsistencies when doing inter-process communication, since they'll be using different libraries with potential mismatches. In theory, but Linux systems tend to do very little IPC other than X11, pipelines, and IP-based communication, where the protocols tend to support running with different versions. In practice you can achieve multi-year uptimes with systems until…

How can you ave a multi-year uptime unless you willfully ignore kernel security updates? In this day and age, year-long uptimes are an anti-pattern (if only because you cannot be sure whether your services are actually reboot-safe).

It's easy. You gather information about what the risks and hazards are for each vulnerability and then pragmatically decide whether there are any unacceptable risks after you mitigate with other layers of security.

It's a really common engineering task to do this and I'm not at all surprised that someone trying to maintain uptime would do so. Honestly it's more mature than updating every time because each change also introduces more potential for regression. If your goal is to run a stable system you want to avoid this unless the risk is outweighed.

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

#209

Post by CJefferson »

quietbritishjim wrote: post #136
beagle3 wrote: post #32

Earlier quoted context omitted.

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…

This doesn't fully explain why a reboot is not required on Linux. If a *nix operating system updates sysfile1.so and sysfile2.so in the way you describe, then there will be some time where the filename sysfile1.so refers to the new version of that file while sysfile2.so refers to the old version. A program that is started in this brief window will get mixed versions of these libraries. It is unlikely that all combina…

I had a program with a rarely reported bug that turned out to be lazy loading of .so files that was this bug. Switched to eager loading and it went away.

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

#210

Post by tyfon »

tobyhinloopen wrote: post #201
tyfon wrote: post #200

Earlier quoted context omitted.

I know in my company this has indeed resulted in a full stop in buying Intel and going AMD instead. There is also an active "project" to replace the Intel servers. I work in a bank and they are terrified of the possibility of user processes reading privileged memory. Not necessarily out of actual fear but out of the insane amount of paperwork this will require to satisfy the auditors that it is still safe. Anecdotall…

Wasn’t AMD also affected?

Not by Meltdown which enabled user processes to read kernel memory. And as we've seen in the aftermath, they have not nearly as much trouble with their patches for Spectre as Intel has had.
Post reply on HN