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

241–250 of 329 posts

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

#241

Post by prewett »

hishnash wrote: post #21
stinos wrote: post #9

"Here's a patch" - "Here's a patch to disable that other patch" - ... What's next? Repeat? Sounds like this could turn into a maintainance nightmare quickly. Also because I've introduced things like that myself in the past, and that was for normal applications and not a kernel or OS. Somewhere, someday, there's usually this one exception for which none of your rules hold true and the thing blows up in your face. Anyw…

Im really wanding they had more than 6months to do these patches and they did not bother testing on a good number of systems. Its not like MS + Intel dont have enough money to buy a few 1000 testing machines and get some testers on it.

Have you released a bugfix to a large application? I've had one line fixes break some use case I hadn't even heard of before, and it doesn't always show up right away, either. Intel's fix has to work on every application in every version of Windows, macOS, Linux, for multiple versions of processors with multiple different chipsets. And it has to be done yesterday. That's a nightmare scenario.

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

#242

Post by jerf »

cesarb wrote: post #178
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.

They are on the "tip" tree ( https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/... ), so they'll probably be sent to Linus as soon as the merge window opens (Linux 4.15 has just been released, so the merge window should open soon). I expect these patches to be on 4.16, and also to be backported to the stable releases (4.15.x and others). But yeah, upstream Linux kernel development is taking it slow. As far…

"But yeah, upstream Linux kernel development is taking it slow."

Taking it slow seems very appropriate to me. This seems to me to have been a case of everybody grossly overestimating the short-term portion of the catastrophe, and underestimating the long term.

In the short term, the only people who were going to be plausibly affected in the next three to six months are people on shared hosting of some sort where you may share a server with somebody else's untrusted code, where an accelerated fix is in order, but also something that can be centrally handled. I'm not that worried in the next three to six months that my personal desktop is somehow going to be compromised by either Meltdown or Spectre, and personally, if I see a noticeable performance issue I may well revert the fixes (I'm on Linux), because first you have to penetrate my defenses to deliver anything anyhow, then you have to be in a situation where you're not going to just use a root exploit, which probably means you're in a sandbox or something which means it's that much more difficult to figure out how to exploit this. For most users, uses, and systems, spectre and meltdown aren't that immediately pressing.

Meanwhile, in the long term this may require basically redesigning CPUs to a very significant degree; there is no software patch that can fix the underlying issues. It is difficult to overstate the long term impact of this class of bugs. IMHO the real problem from the jousting match with Linus and Intel last week isn't that Intel's patches today aren't quality code, but that it makes me concerned that they're just going to sweep this fundamental problem under the rug. As I said in another post on HN, I fully understand that remediating this is going to be years, and I don't expect Intel to have an answer overnight, or a full solution in their next "tock". But if they're not taking this seriously, we have a very large long-term problem. We're only going to see more leaks in the long term.

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

#243

Post by boznz »

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;

I am not sure about deletion, but one of my programs has been using the ability to rename itself to do updates for the last 15 years.

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

#244

Post by astrange »

KindOne wrote: post #185
zingmars wrote: post #168

These updates most definitely could've been handled better. I was having a busy week with exams and I get a call about around 10 machines not booting (this was before the announcement). Sure enough, last thing everyone reported was updating. I call the supplier and apparently they have reports of at least 2000 machines (at that moment) that had to be reimaged across the city (from what I could tell, all were older AM…

Become a goat farmer. https://www.reddit.com/r/sysadmin/comments/4l7kjd/found_a_te...

But if you look into their eyes, you can still see the progress bars…

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

#245

Post by michaelmrose »

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.

No lie. After all nothing is stopping you from updating once every tuesday and rebooting after updates. You just wont have to do it 8 times in succession or stop in the middle of doing useful work to do so.

I just don't update nvidia or my kernel automatically and magically I only have to reboot less than once a month and always on my schedule.

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

#246

Post by rkeene2 »

bri3d wrote: post #157
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).

Ksplice or KernelCare

Kernel Live Patching (KLP) has been in mainline since 4.4. I've used it to patch various flaws in my Linux distribution since rebooting the running cluster is more tedious.

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

#247

Post by ohiovr »

quiq wrote: post #132
ohiovr wrote: post #83

My brother was hit by a recent update to Windows 7 that prevented the machine from booting. He went to Microcenter to buy a hard drive. There were a lot of people doing the same thing for the same reason when he was there.

I don't use the windows side of my machine very often, but decided to update it last night. Booted fine (OS on SSD), but one of the HDDs with all of the windows files was corrupted. No go with ntfsfix, chkdsk, partition table destroyed. Reformatted it as ext4 and windows doesn't get to touch it anymore. Haven't tested it too much yet but seems to be working fine. Remember to use backups!

My brother did have major data loss. And no real backup strategy.

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

#248

Post by Mister_Snuggles »

jerf wrote: post #242
cesarb wrote: post #178

Earlier quoted context omitted.

They are on the "tip" tree ( https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/... ), so they'll probably be sent to Linus as soon as the merge window opens (Linux 4.15 has just been released, so the merge window should open soon). I expect these patches to be on 4.16, and also to be backported to the stable releases (4.15.x and others). But yeah, upstream Linux kernel development is taking it slow. As far…

"But yeah, upstream Linux kernel development is taking it slow." Taking it slow seems very appropriate to me. This seems to me to have been a case of everybody grossly overestimating the short-term portion of the catastrophe, and underestimating the long term. In the short term, the only people who were going to be plausibly affected in the next three to six months are people on shared hosting of some sort where you…

I read somewhere that people have developed POCs of these using JavaScript. At minimum, you'll want to keep your browser up to date as there are mitigations happening there too. Who knew that exposing high precision timers to untrusted JavaScript would be a bad idea?

Apart from browsers, it's fortunately pretty easy to avoid running code you don't trust on your devices.

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

#249

Post by noiv »

InvisibleCities wrote: post #215
zingmars wrote: post #168

These updates most definitely could've been handled better. I was having a busy week with exams and I get a call about around 10 machines not booting (this was before the announcement). Sure enough, last thing everyone reported was updating. I call the supplier and apparently they have reports of at least 2000 machines (at that moment) that had to be reimaged across the city (from what I could tell, all were older AM…

Trust me, if you don't like the idea of your entire livelihood hinging on weather or not a piece of equipment boots up, farming is NOT the career for you.

I like the idea of Internet Weather. Seems probability of rain is currently increasing. And so does anticipation of floods and surges.

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

#250

Post by avar »

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.

What you're describing is trivially done on any *nix system with a mature package manager, if it isn't doing this already:

1. Do the upgrade, this changes the files.

2. You have a log of what packages got upgraded.

3. Run the package system's introspection commands to see what files belonged to that package before & after

4. Run the package system's introspection commands to see what reverse depends on those packages, or use the lsof trick mentioned upthread.

5. For each of those things restart any running instance of the application / daemon.

Even if something didn't implement this already (most mature systems to) this is at most a rather trivial 30 line shellscript.

Post reply on HN