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

61–70 of 329 posts

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

#61

Post by cesarb »

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

Also interesting: that patch has a link to an official Intel list of broken microcode versions.

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

#62

Post by sundvor »

morsch wrote: post #46
thg wrote: 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.

It makes sense though. Only AV programs that comply may set the setting. Without a compliant AV program, there's nothing to do that set - unless you do it manually.

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

#63

Post by vetinari »

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…

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

While this is true, I've never seen this to be a problem. If two programs use IPC, they usually use either stable, or compatible protocol.

To make things even more complicated, you can have two programs, either each in it's own container, or statically linked, or with their private bundles of libraries, doing IPC and then they are free to have different versions of the underlying libraries, while the users still expect them to work fine.

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

#64

Post by cesarb »

Santosh83 wrote: post #48
thg wrote: 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...

Microsoft won't supply updates even if you have no AV installed, including builtin Defender disabled?? I thought stopping updates was only for the case of unpatched AVs that did not set the registry key...

If you have no patched AV, who's going to set the registry key?

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

#65

Post by T-N-T »

Santosh83 wrote: post #48
thg wrote: 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...

Microsoft won't supply updates even if you have no AV installed, including builtin Defender disabled?? I thought stopping updates was only for the case of unpatched AVs that did not set the registry key...

Microsoft does not have any way of knowing whether you have an antivirus or not and because the Spectre patch causes a bluescreen on boot if you have an antivirus that's not updated, they require the antivirus set the registry key to say "hey, it's safe to update". Absence of AV means that registry key doesn't get set.

MS doesn't provide an easy, GUI way of disabling built-in Defender by the way. If you 'disable' defender by using the control panel on windows 10, it only stops its activity temporarily and it can reactivate itself after 24 hours or something like that. You can permanently disable it through registry keys but it's not an officially supported, accepted method to edit the registry by yourself. There's a group policy for 10 Pro and other corp editions though.

For a normal home user, Defender is never fully disabled. It will deactivate itself if you install a third party antivirus, and reenable itself when you uninstall them. Bottom line, the average user is not supposed to be AV-less.

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

#66

Post by postingatwork »

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…

> 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. Is this correct?

At the first glance this is true, but you can guard against this in several ways. If your process only forks children then it already inherits the loaded libraries from the parent as part of the forked address space. Alternatively you can pass open file descriptors between processes. Another option is to use file-system snapshots, at least if the filesystem supports them.

Yet another option is to not replace individual files but complete directories and swap them out via RENAME_EXCHANGE (an atomic swap, available since kernel 3.15). As long as the process keeps a handle on its original working directory it can keep working with the old version even if it has been replaced with a new one.

Some of those approaches are tricky, but if you want to guard against such inconsistencies at least it is possible. And if your IPC interfaces provide a stable API it shouldn't be necessary.

> And then there's FILE_SHARE_DELETE which allows deletion

That has some issues when the file is mmaped. If I recall correctly you can't replace it as long as a mapping is open.

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

#67

Post by vetinari »

thanksgiving wrote: post #29
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…

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

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

We are getting there on Linux too - with atomic or image based updates of the underlying system. On servers you will (or already) have A/B partitions (or ostrees), on mobiles and IoT too, some desktops (looking at Fedora) also prefer reboot-update-reboot cycle, to prevent things like killing X while doing your update and leaving your machine in inconsistent state.

macOS also does system updates with reboot, for the same reasons.

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

#69

Post by Thimothy »

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.

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.

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

#70

Post by watwut »

dotdi wrote: post #50
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

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.

Those were not delivered fixes, that was work in progress that is still work in progress. And the dude who was "called out" works for Amazon.
Post reply on HN