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

291–300 of 329 posts

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

#291

Post by nullymcnull »

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

It's simple for any application to open a file in Windows such that it will allow a rename or delete while open - set the FILE_SHARE_DELETE bit on the dwShareMode arg of the win32 CreateFile() function. In .NET, the same behaviour is exposed by File.Open / FileShare.Delete.

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

#292

Post by morganvachon »

shiven wrote: post #108
morganvachon wrote: post #101

Earlier quoted context omitted.

CPUs from AMD are not vulnerable to Meltdown, but are vulnerable to both versions of Spectre. https://www.amd.com/en/corporate/speculative-execution

Damn! So, practically, no modern processor (or consumer laptop, or enterprise server) is safe from Spectre? Time to go off the beaten path.

The earliest Intel Atom chips (Nxxx series) are supposedly safe, but they were only ever used in woefully underpowered netbooks and nettops, and they had perhaps half the performance of a similarly clocked (much older) Pentium M. That performance metric is documented, and I've felt it myself when I owned a Pentium M laptop and Atom N450 netbook at the same time a few years ago.

A few ARM SoCs -- including the entire line used in Raspberry Pi boards -- are safe, but the vast majority of recent ARM devices are affected by one or more of the attack vectors. This means virtually any flagship and most if not all midrange smartphones and tablets, even iPhones and iPads, are vulnerable.

This is the most complete list of affected CPUs and SoCs I've found, and they appear to be keeping it updated:

https://www.techarp.com/guides/complete-meltdown-spectre-cpu...

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

#293

Post by ShroudedNight »

avtar wrote: post #218
mosselman wrote: post #112

So what can I do for my next self-built pc? Get some AMD equipment, or is that not enough?

I'm eyeing Threadripper for my next build but beyond that I'm going to choose a motherboard vendor based on the level of support they offer in this scenario. Some observations that I'm making: * How promptly did they address the issue via official channels, i.e. did they leave users in the dark as they appealed to vendors in their forums (hint: most of them seem to have gone down this route) or did they share updates…

For those in the market for an X399/TR4 motherboard, have you come to any conclusions?

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

#294

Post by avtar »

ShroudedNight wrote: post #293
avtar wrote: post #218

Earlier quoted context omitted.

I'm eyeing Threadripper for my next build but beyond that I'm going to choose a motherboard vendor based on the level of support they offer in this scenario. Some observations that I'm making: * How promptly did they address the issue via official channels, i.e. did they leave users in the dark as they appealed to vendors in their forums (hint: most of them seem to have gone down this route) or did they share updates…

For those in the market for an X399/TR4 motherboard, have you come to any conclusions?

MSI seems [1] to be fairly proactive right now with patches going back to several X99 motherboards. Asus for example has so far only committed to provide updates for two X99 motherboards.

[1] https://www.msi.com/news/detail/7yJ7XCklfBXt8mFhG8nkfSurJUz3...

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

#295

Post by tluyben2 »

peterwwillis wrote: post #281
StudentStuff wrote: post #276

Earlier quoted context omitted.

Maybe its time to consider an OS with better maintainers, like Debian. I've had less issues on unstable/sid over the past few years than I had on the last Ubuntu LTS release (which was what spurred me to Debian). On my other machine, Debian Stretch (and Jessie prior to upgrading) have treated me well, there just isn't breakage when upgrading to the latest stable release or when applying security patches.

I chose Ubuntu because it was more widely supported by 3rd party software vendors and support companies than Debian. But this doesn't matter, because I still ran into hardware and software compatibility issues, and Ubuntu is more up to date than Debian, meaning Debian would have been even more broken by default. I don't know of a single Linux distro that works out of the box with my laptops. Maybe if I bought a $2,00…

Depends what you need ofcourse; a lot of people buy the newest and fastest but do not need it. Most (90%+) of my dev work works fine on an X220 which I can pick up for $80, has stellar linux support and still really good (14+ hour) battery life. Depends on the use case ofcourse, but when I see what most people around me do on their 2k+ laptops, they could have saved most of that. Also, Ubuntu Unity is just not very good; but Ubuntu or Debian with i3 are perfect. Cannot imagine a better desktop.

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

#296

Post by ams6110 »

jschwartzi wrote: post #208
majewsky wrote: post #87

Earlier quoted context omitted.

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…

But with "yum check-update" or the equivalent apt-get incantation saying you have dozens of security updates every week or two, reading the release notes for all of them and deciding which ones can be skipped safely in your environment is too much work. Far easier to just apply all updates every two weeks or monthly or whatever your schedule is, and then reboot.

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

#297

Post by da_chicken »

code_duck wrote: post #205
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 "…

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.

Well, it's not always an advantage. It's just the consequences of a different locking philosophy.

Windows patches are a much bigger pain in the ass to deal with on a month-to-month basis, but Linux patches can really bite you.

Example 1:

Say I have an application 1 that uses shared library X, and a application 2 that spawns an external process every 5 minutes that uses library X and communicates in some way with application 1. Now let's say that library X v2.0 and v2.1 are incompatible, and I need to apply an update.

On Windows, if I update this program, it will keep running until the system is rebooted. Updates, although they take significant time due to restarts, are essentially atomic. The update either applies to the entire system or none of the system. The system will continue to function in the unpatched state until after it reboots.

On Linux, it's possible for application 1 to continue to run with v2.0 of the shared library, while application 2 will load v2.1, and suddenly your applications stop working. You have to know that your security update is going to cause this breaking change and you need to deal with it immediately after applying the update.

Example 2:

A patch is released which, unbeknownst to you, causes your system to be configured in a non-bootable state.

On Windows, you'll find out immediately that your patch broke the system. It's likely (but not certain) to reboot again, roll back the patch, and return to the pre-patched state. In any event, you will know that the breaking patch is one that was in the most recently applied batch.

On Linux, you may not reboot for months. There may be dozens or hundreds of updates applied before you reboot your system and find that it's not in a bootable state, and you'll have no idea which patch has caused your issue. If you want your system in a known-working state, you'll have to restore it prior to the last system reboot. And God help you if you made any configuration changes or updates to applications that are not in your distro's repository.

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

#298

Post by tluyben2 »

jschwartzi wrote: post #208
majewsky wrote: post #87

Earlier quoted context omitted.

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…

Fully agree here; a lot (most?) of patches and updates are simply not exploitable in the respective server use case, so why should I incur risk of downtime to apply it?

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

#299

Post by darpa_escapee »

peterwwillis wrote: post #281
StudentStuff wrote: post #276

Earlier quoted context omitted.

Maybe its time to consider an OS with better maintainers, like Debian. I've had less issues on unstable/sid over the past few years than I had on the last Ubuntu LTS release (which was what spurred me to Debian). On my other machine, Debian Stretch (and Jessie prior to upgrading) have treated me well, there just isn't breakage when upgrading to the latest stable release or when applying security patches.

I chose Ubuntu because it was more widely supported by 3rd party software vendors and support companies than Debian. But this doesn't matter, because I still ran into hardware and software compatibility issues, and Ubuntu is more up to date than Debian, meaning Debian would have been even more broken by default. I don't know of a single Linux distro that works out of the box with my laptops. Maybe if I bought a $2,00…

> I kind of hate Linux as a desktop now

This is unfortunate. I've been using Linux and suffered, for the lack of a better word, with its warts since 2002.

There was a period between 2013-2016 where Linux was great as my main operating system. It was more stable than OS X and was much better for development.

Is hardware support your main issue with desktop Linux?

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

#300

Post by asveikau »

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…

Here is the simplest way I can put it: When you delete a file in NT, any NtCreateFile() on its name will fail with STATUS_DELETE_PENDING until the last handle is closed.[1] Unix will remove the name for this case and the name is re-usable for any number of unrelated future files.

[1] Note that is not the same as your "must be reachable via some path". It is literally inaccessible by name after delete. Try to access by name and you get STATUS_DELETE_PENDING. This is unrelated to the other misfeature of being able to block deletes by not including FILE_SHARE_DELETE.

Post reply on HN