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

191–200 of 329 posts

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

#191

Post by Valmar »

speedie wrote: post #183
Valmar wrote: post #133

Earlier quoted context omitted.

> 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 .

Exactly. He's very intelligent about how he manages the kernel, which is precisely why it is preferred by a majority of businesses throughout the world, and is the absolute #1 in the supercomputer world, for the top 500:

https://www.top500.org/statistics/details/osfam/1

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

#193

Post by speedie »

Valmar wrote: post #191
speedie wrote: post #183

Earlier quoted context omitted.

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

Exactly. He's very intelligent about how he manages the kernel, which is precisely why it is preferred by a majority of businesses throughout the world, and is the absolute #1 in the supercomputer world, for the top 500: https://www.top500.org/statistics/details/osfam/1

I was just pointing out why politeness gets you nowhere when dealing with eejits . Linus improved that Capone's saying about kind word and a gun .

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

#194

Post by cat199 »

tialaramex wrote: post #52
mehrdadn wrote: post #37

Earlier quoted context omitted.

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

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…

> Now, the "you can't delete things because then the disk space is unreachable" argument makes plenty of sense for, say, FAT, a filesystem from the 1980s.

Unix semantics were IIRC in place as far back as v7 (1979), possibly earlier - granted, a PDP disk from that time was bigger (~10-100MB) than the corresponding PC disk from a few years later (~1-10MB), but an appeal to technological progress in this particular example case is a moot point.

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

#195

Post by cat199 »

CuriousCosmic wrote: post #57
mehrdadn wrote: post #37

Earlier quoted context omitted.

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

*nixes have a system for handing off to the newer version such as kpatch and kgraft. kgraft for example swaps off each syscall for a process while it is not being used. This lets the OS slowly transfer to the new kernel as it is running. kpatch does it all in one go but locks up the system for a few milliseconds. The version that is currently merged into 4.0+ kernels is a hybrid of the two developed by the authors of…

Runtime kernel patching is a new thing. "*nixes" do not generally have these systems. Some proprietary technologies exist which enable specific platforms to use runtime kernel patching exist.

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

#196

Post by cat199 »

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).

you willfully ignore kernel security updates.

If my system is closed to the public world, has a tiny amount of external services, and I am aware of the specific bug delta since system release and what mitigations may or may not be required, I can leave it running as long as I choose to accept the risk. Cute phrases like 'pattern' and 'anti-pattern' are rules of thumb, not absolute truths.

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

#197

Post by xigency »

collinmanderson wrote: post #161
PerusingAround wrote: post #151

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

I have a feeling there's going to be a lot of demand for future Intel hardware that's immune to spectre and meltdown. I think it might cause _more_ sales of Intel chips in the future, not fewer.

Regardless of sales, I would think damage to their image would be a concern. Maybe it's not a concern to investors because their "PR nightmare" turned out to be softball for them, and it's been hard to pin anything on Intel when they keep pointing fingers in all directions.

I think it's our responsibility as technology literate folks and decision makers to explicitly highlight their failures so that mistakes and poor handling like this are not normalized.

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

#198

Post by cat199 »

anfilt wrote: post #10
mm-vorticesoft wrote: post #5

Linus was right

Well he is known for calling a spade a spade. No matter how blunt that may be.

except for when he is wrong.

Why he gets a pass for being the 'nice guy' and DeRaadt gets the bad rep is still a mystery to me

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

#199

Post by [deleted] »

hishnash wrote: post #169
tallanvor wrote: post #38

By my reading of the article, Microsoft is disabling some mitigations for Spectre due to instabilities that Intel's microcode update have been causing. Intel certainly isn't making any friends these days...

I would love to see the message log between MS Apple and Intel on this.

[deleted]

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

#200

Post by tyfon »

ggregoire wrote: post #163
PerusingAround wrote: post #151

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?

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.

Anecdotally, but you asked for "someone" and here is someone :)

Post reply on HN