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

31–40 of 329 posts

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

#31

Post by gaius »

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?

To force a reinitialisation of all security contexts. Same reason that many websites make you log in again immediately after changing your password (which interestingly Windows doesn’t)

Historically (Windows 95 and earlier) reboots were required to reload DLLs and so on but that’s not really true anymore. Still a lot of installers and docs say to reboot when it’s not really necessary as a holdover from then

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

#32

Post by beagle3 »

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?

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 effectively reliable way to do that is reboot.

On Unix, once you have a handle=descriptor of the file, the name is irrelevant; You can delete or rename the file, The descriptor still refers to the file that was opened. Thus, you can just replace any system file; Existing programs will keep using the old one until they close/restart, new programs will get the new file.

What this means is, that even though you don't NEED to restart anything for most upgrades in Unix/Linux, you're still running the old version until you restart the program that uses it. Most upgrade procedures will restart relevant daemons or user programs, or notify that you should, (e.g. Debian and Ubuntu do).

You always need a reboot to upgrade a kernel (kernel-splice and friends not withstanding), but otherwise it is enough in Unixes to restart the affected programs.

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

#33

Post by megaman22 »

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 confidence in their competence of late.

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

#34

Post by icebraining »

mtgx wrote: post #13
nippples wrote: post #11

Gee, if only they had a Linus Torvalds type around to block irresponsible commits.

Didn't Torvalds already accept Intel's "garbage" Linux kernel patches?

I don't think so, they're still under discussion on LKML, including an alternative proposal by Ingo Molnar.

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

#35

Post by rocqua »

icebraining wrote: post #30
cm2187 wrote: post #16

Earlier quoted context omitted.

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

Nah, it was more than that: The patches do things like add the garbage MSR writes to the kernel entry/exit points. That's insane. That says "we're trying to protect the kernel". We already have retpoline there, with less overhead.

That was about patches to the linux kernel, not the microcode patches.

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

#36

Post by faragon »

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?

The main reason is that in Windows executable files and dynamic libraries (.exe and .dll) are locked while a process is using them, while in other systems, e.g. Linux, you can delete them from disk. The only absolute need for reboot should be an OS kernel update (there are cases where a kernel could be updated/patched without a reboot).

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

#37

Post by mehrdadn »

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…

> 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. And then there's FILE_SHARE_DELETE which allows deletion, but then the handle starts returning errors when the file is deleted (as opposed to keeping the file "alive").

To make it even more confusing, you can pretty much always even create hardlinks to files that are "in use", but once you do that the new name cannot be deleted unless the old name can also be deleted (i.e. they follow the same rules). This should also make it clear that it's not the "name" that's in use, but the "actual file" (whatever that means... on NTFS I'd suppose it corresponds to the "file record" in the MFT).

The rule that Windows always abides by is that everything that takes up space on the disk must be reachable via some path. So you can't delete in-use files entirely because then they would be allocated disk space but unreachable via any path.

> What this means is, that even though you don't NEED to restart anything for most upgrades in Unix/Linux, you're still running the old version until you restart the program that uses it.

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? Because it seems to me that the Windows method might be less flexible but is likely to be more stable, since there's a single coherent global view of the file system at any given time.

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

#39

Post by lucb1e »

gaius wrote: post #31
thanksgiving wrote: post #29

Earlier quoted context omitted.

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

To force a reinitialisation of all security contexts. Same reason that many websites make you log in again immediately after changing your password (which interestingly Windows doesn’t) Historically (Windows 95 and earlier) reboots were required to reload DLLs and so on but that’s not really true anymore. Still a lot of installers and docs say to reboot when it’s not really necessary as a holdover from then

I was under the impression that the reason is what u/beagle3 mentions (in a sibling comment to yours): open system files. I'm curious to see your comment on what he describes, as what you mention (reloading some security context) does not seem to be the whole truth. That websites make one log in again after changing your password has nothing to do with this.

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

#40

Post by pjc50 »

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?

Windows executables are opened with mandatory exclusive locking. So you can't overwrite a program or its DLLs while any instances of it are running. If a DLL is widely used, that makes it essentially impossible to update while the system is in use.

There is a registry key which allows an update to schedule a set of rename operations on boot to drop in replacement file(s). https://blogs.technet.microsoft.com/brad_rutkowski/2007/06/2...

Post reply on HN