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

141–150 of 329 posts

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

#141

Post by rleigh »

mehrdadn wrote: post #98
rleigh wrote: post #91

Earlier quoted context omitted.

That's D-BUS being a terribly specified and poorly implemented mess. Everything underneath should be solid.

I mean, OK, but if Windows's GUI (or PowerShell, or whatever) crashed or misbehaved upon update, would you be satisfied with "that's win32k/DWM/whatever being a poorly implemented mess; everything underneath should be solid"?

No. D-BUS is a travesty and blight upon the Linux desktop, and with systemd, every Linux system. It's the most fragile and nasty IPC system I've encountered. There are several better alternatives implemented by competent people, so there's really no excuse for its many defects.

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

#142

Post by sundarurfriend »

cm2187 wrote: post #16
mm-vorticesoft wrote: post #5

Linus was right

I thought he was angry about the mitigation being disabled by default, not being unstable.

His overall point was a bewilderment at the incompetent and non-sensical patches that were being given as "fixes" in this issue. Linus was pointing out a particular instance of that, but this news and other behaviour from Intel seems to indicate this is part of an endemic, cultural, administrative issue inside the company.

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

#143

Post by gnfurlong »

mehrdadn wrote: post #58
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…

X11 (or other window-related tooling) was exactly what I was thinking of actually, because every time I do a major Linux (Ubuntu) update I can't really launch programs and use my computer normally until I reboot. It always gets finicky and IPC mismatch is the best explanation I can think of.

Are you sure this isn't more the Desktop Environment/Display Manager than X11? Or otherwise something to to with your use case?

I've primarily been using AwesomeWM for the last few years and occasionally XFCE (both on ArchLinux) and I cant recall ever experiencing what you describe.

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

#144

Post by beagle3 »

mehrdadn wrote: post #127
tzahola wrote: post #123

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. That's why you should restart those programs that were using the library. You can find this out via `lsof`.

Really? Somehow procure a list of all libraries that were updated in a system update, go through each one, find out which program was using it, and kill that program? Every single time I update? You can't be serious.

Apt does this automatically for you on uphrade

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

#145

Post by ptero »

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 principle, yes, IPC can fail between different versions of the same software. However, the chances that communication will fail between new version and some other utility are IMO much higher. A surprise comm failure between two copies of the same software (even different revisions) usually makes developers look pretty bad.

Some versions are known to be incompatible and most Linux distributions do a very good job of recommending and doing a restart of affected services in a way transparent to users. I have been running Linux and home and at work for years, almost never restart those workstations and, as far as I can tell, never had problems from piecemeal upgrades. My 2c.

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

#146

Post by dhimes »

chli wrote: post #97
tjoff wrote: post #18

I lost many hours over this last week. The system was unable to boot and finally a thread on reddit came to the rescue ( https://www.reddit.com/r/techsupport/comments/7sbihd/howto_f... ). 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. So now, the machine is running but as soon as it is res…

Same thing happened to me this week-end and we are not alone [1]. The worst is that it's actually the second time on this computer (Kaby Lake i3 on a MB with Intel B250 Chipset). I had the same issue in December last year (exact same behaviour with probably an earlier version of that hotfix). I'm running with Windows Update service disabled till this is fixed for good ! [1] https://answers.microsoft.com/en-us/windows…

I have not been able to disable the update service. I'm supposed to be able to, but damn if I don't open my computer in the morning and see everything closed (and lock files all over the place) and all kinds of annoying shit like this.

I actually like Win 10, but it's shit like this that keeps me from becoming a true convert. Oh, for $X00 I can get enterprise update, but IMO that's just Win 10 home being used as ransomware. /rant

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

#147

Post by postingatwork »

Valmar wrote: post #126
rlpb wrote: post #109

Earlier quoted context omitted.

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

Here, on Arch, Firefox updates don't cause me any grief. Only time I've ever need to reboot is after a kernel or DKMS module update. For systemd updates, I can just reload it. For the likes of core components like bash, and major DE updates, I can just lazily use loginctl to terminate all of my sessions, and start fresh. I'm not sure why Firefox would be causing instability until you restart (reboot?), though.

Firefox with e10s enabled (all current releases) detects version differences between parent process and and a child process started at a later point in time. Until recently it aborted the entire browser when that happened. I think now they have some logic that tries to keep running with the already open processes and abandoning the incompatible child.

Ideally they'd just prefork a template process for children and open fds for everything they need, that way such a detection wouldn't be necessary.

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

#148

Post by epicide »

_asummers wrote: post #111
zolthrowaway wrote: post #100

Earlier quoted context omitted.

Vote with your wallet. That's really the only thing that you can do. Intel is too comfortable in their position as market leader. Until they start to feel some pressure, they have shown they don't really care. I know AMD is not a perfect company either, but I elected to buy a Ryzen processor for my upcoming build. People need to at least consider the competition without defaulting to "I need a processor, I buy the la…

I understand your point, and agree with the spirit of it, but a few consumers buying Ryzen chips isn't going to make one bit of difference. A couple data centers buying dozens of racks of them, however, would be more measurable. Hit em in the B2B not the B2C.

Yep, nobody gets fired for picking Intel, so to speak.

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

#149

Post by kabes »

DominikD wrote: post #94
dotdi wrote: post #50

Earlier quoted context omitted.

Intel has been called out by Linus Torvalds several days ago for the crappy fixes they delivered for GNU/Linux. I would be very surprised if Intel actually shipped proper fixes for Windows. It's a shame, really.

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

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

#150

Post by GirlsCanCode »

beagle3 wrote: post #32
thanksgiving wrote: post #29

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…

This is completely untrue. How much does Tim pay you to spread these lies?
Post reply on HN