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

301–310 of 329 posts

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

#301

Post by mehrdadn »

asveikau wrote: post #300
mehrdadn wrote: post #37

Earlier quoted context omitted.

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

"Reachable" doesn't mean "openable". Reachable just means there is a path that the system identifies the file with. There are files you cannot open but which are nevertheless reachable by path. Lots of reasons can exist for this and a pending delete is just one of them. Others can include having wrong permissions or being special files (e.g. hiberfil.sys or even $MFTMirr).

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

#302

Post by asveikau »

mehrdadn wrote: post #301
asveikau wrote: post #300

Earlier quoted context omitted.

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

"Reachable" doesn't mean "openable". Reachable just means there is a path that the system identifies the file with. There are files you cannot open but which are nevertheless reachable by path. Lots of reasons can exist for this and a pending delete is just one of them. Others can include having wrong permissions or being special files (e.g. hiberfil.sys or even $MFTMirr).

I would be kind of surprised if "the system" cares much about the name of a delete pending file. NT philosophy is to discard the name as soon as possible and work with handles. I was under the impression that ntfs.sys only has this behavior because older filesystems led everybody to expect it.

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

#303

Post by tfigment »

asveikau wrote: post #300
mehrdadn wrote: post #37

Earlier quoted context omitted.

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

this has led to some interesting observations for me in linux when I've had really large log files that were still in use and were "deleted" but the file was still in use. (I think cat /dev/nul > file will do this). Tools like du now cannot find where the disk usage actually is. Only on restart of the app does usage show correctly again. Kinda hard to troubleshoot if you were not aware this was what happened.

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

#304

Post by mehrdadn »

asveikau wrote: post #302
mehrdadn wrote: post #301

Earlier quoted context omitted.

"Reachable" doesn't mean "openable". Reachable just means there is a path that the system identifies the file with. There are files you cannot open but which are nevertheless reachable by path. Lots of reasons can exist for this and a pending delete is just one of them. Others can include having wrong permissions or being special files (e.g. hiberfil.sys or even $MFTMirr).

I would be kind of surprised if "the system" cares much about the name of a delete pending file. NT philosophy is to discard the name as soon as possible and work with handles. I was under the impression that ntfs.sys only has this behavior because older filesystems led everybody to expect it.

Well if you look at the scenario you described, I don't believe the parent folder can be deleted while the child is pending deletion. And if the system crashes, I'd expect the file to be there (but haven't tested). So the path components do have to be kept around somewhere...

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

#305

Post by asveikau »

mehrdadn wrote: post #304
asveikau wrote: post #302

Earlier quoted context omitted.

I would be kind of surprised if "the system" cares much about the name of a delete pending file. NT philosophy is to discard the name as soon as possible and work with handles. I was under the impression that ntfs.sys only has this behavior because older filesystems led everybody to expect it.

Well if you look at the scenario you described, I don't believe the parent folder can be deleted while the child is pending deletion. And if the system crashes, I'd expect the file to be there (but haven't tested). So the path components do have to be kept around somewhere...

It's true that NT won't let you remove a directory if a child has a handle open. But I suspect you are getting the reasoning backwards. The directory is not empty as long as that delete pending file is there. Remove this ill-conceived implementation detail (and it is that) then this and other problems go away.

There is also an API that retrieves a filename from a handle. I don't think it guarantees the name be usable though.

It's easy to imagine a system that works the way I would have it, because it exists: Unix. You can unlink and keep descriptors open. NT is very close to being there too, except for these goofy quirks which are kind of artificial.

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

#306

Post by asveikau »

tfigment wrote: post #303
asveikau wrote: post #300

Earlier quoted context omitted.

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

this has led to some interesting observations for me in linux when I've had really large log files that were still in use and were "deleted" but the file was still in use. (I think cat /dev/nul > file will do this). Tools like du now cannot find where the disk usage actually is. Only on restart of the app does usage show correctly again. Kinda hard to troubleshoot if you were not aware this was what happened.

I agree that this is a drawback or a common gotcha for the Unix behavior which would be more user visible with the NT behavior, but to anyone advocating the Windows way I would ask: is it worth getting this fringe detail "right" by making every unlink(x); open(x, O_CREAT ...); into a risky behavior that may randomly fail depending on what another process is doing to x? On Windows, I have seen this type of pattern, a common one because most people aren't aware of this corner case, be the cause of seemingly random failures that would be rather inexplicable to most programmers. (Often the program holding x open is an AV product scanning it for viruses, meaning that any given user system might have a flurry of race condition causing filesystem activities that may or may not conflict with your process.)

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

#307

Post by mygo »

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.

Holy wow. This is prose. This is poetry.

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

#308

Post by krinchan »

mehrdadn wrote: post #263
peterwwillis wrote: post #167

Earlier quoted context omitted.

> I update Linux (Ubuntu) and, lo and behold, I can't really use any programs until I reboot Which is almost true. In fact, you were unable to use programs that changed runtime dependencies or conflicted with current user sessions, init processes or kernel modules. You can often use other programs, but not ones that in any way touched the ones you upgraded, for one reason or another. If you have to upgrade, say, a co…

> If you have to upgrade a GUI app, or a tool that depends on some bastardized unholy subsystem designed to "secure desktop sessions", that may very well require relinquishing the session and restarting it. If you have to upgrade a tool used by your desktop (and if you have a complex desktop, that is literally thousands of programs), it's the same story, though you may even need to restart your desktop session manage…

I've long since abandoned "bare metal" Linux in favor of VirtualBox and Windows for my home machine and VirtualBox and macOS on my laptop.

Monday's I merge last week's snapshot, take a new one, and run all my updates. Then I do my dev work in my VM. Before I head out on trips, I just ship the entire machine over the network to my MacBook Pro.

This is mostly because have you literally ever tried to install any Linux on laptops? It's always a Russian roulette with those $+#&ing Broadcom wireless chipsets. >.So you're not hallucinating. Linux as a desktop/laptop had a sweet spot from like...2012-ish till 2016. Then 802.11ac went mainstream so Broadcom released new chipsets and graphics cards had a whole thing with new drivers and Ubuntu's packagers (the people) lost their mind or something.

Nothing feels right, at least in Ubuntu/Arch land right now.

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

#309

Post by otempomores »

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…

We anticipated that and brought thrustworthy hard and software into your future farming equipment.

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

#310

Post by nurettin »

mygo wrote: post #307
InvisibleCities wrote: post #215

Earlier quoted context omitted.

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.

Holy wow. This is prose. This is poetry.

Looks like a field ripe for AI to introduce random auto-correct induced typos into paragraphs where a change of word order could be perceived as poetic.
Post reply on HN