Also surprised an async completion was writing to the stack. You should normally pass a heap buffer to these functions and keep it alive e.g for the lifetime of the object being watched.

It's not an async completion. The call is synchronous.

Windows allows some synchronous calls to be interrupted by another thread to run an APC if the called thread is in an "alertable wait" state. The interrupted thread then returns to the blocking call, so the pointers in the call are expected to be valid.

Edit 2: I should clarify that the thread returns to the blocking call, which then exits with WAIT_IO_COMPLETION status. So you have to retry it again. but the stack context is expected to be safe.

APC is an "Asynchronous procedure call", which is asynchronous to the calling thread in that it may or may not get run. Edit: May or may not run a future time.

(https://learn.microsoft.com/en-us/windows/win32/sync/asynchr...)

There are very limited things you are supposed to do in an APC, but these are poorly documented and need one to think carefully about what is happening when a thread is executing in a stack frame and you interrupt it with this horrorshow.

Win32 API is a plethora of footguns. For the uninitiated it can be like playing Minesweeper with code. Or like that scene in Galaxy Quest where the hammers are coming at you at random times as you try to cross a hallway.

A lot of it was designed by people who, I think, would call one stupid for holding it wrong.

I suppose it's a relic of the late 80s and 90s when you crawled on broken glass because there was no other way to get to the other side.

You learn a lot of the underlying systems this way, but these days people need to get shit done and move on with their lives.

Us olds are left behind staring at nostalgically at our mangled feet while we yell at people to get off our lawns.

> There are very limited things you are supposed to do in an APC, but these are poorly documented and need one to think carefully about what is happening when a thread is executing in a stack frame and you interrupt it with this horrorshow.

One must not throw a C++ exception across stack frames that don't participate in C++ stack unwinding, whether it's a Win32 APC, another Win32 callback, a POSIX signal or `qsort` (for the people that believe qsort still has a place in this decade). How the Win32 API is designed is absolutely irrelevant for the bug in this code.

I was talking about APCs and win32 api in general not this bug.

select() (written in C, a language without exceptions) is synchronous, its authors just (reasonably) did not expect an exception to be thrown in the middle of it invoking a blocking syscall. The algorithm was correct in the absence of a language feature C simply does not have and that is relatively surprising (you don't expect syscalls to throw in C++ either).

I think they went even further and 3d printed their thumbprint and unlocked their phone with it, if I remember correctly.

Just change your thumbprint after a leak, no problem.

A dedicated criminal wouldn’t have fingerprints.

Lol, author's thought process mirrored mine as I read the article, as I was reading I was thinking, 'doesn't kqueue support that?... and then a section on kqueue. Then I was thinking to myself, so how does the Linux implementation do it then?... was just about to start trawling the source code when 'A parenthesis..'

Great article. Sorry to say though, Windows does manage all this in a more consistent way - but I guess they had the benefit of a clean slate.

signalfd / process descriptiors are the Windows style mechanism... what is missing are a few things like 'spawn' that returns a fd directly (eliminating races...)

there is no race from the parent

the pid will not be reused until you either handle sigchld or wait

This is the best response so far. Session churn creates lots of db activity but lots of it is of low business value. Better to offload to a separate process.

Also session data is often Blobs which db's don't process as efficiently as columnar data.

Oh Man, I think I have a candidate for the Apology Homepage.

Ah Tom Baker, also a gem.

Was also interested to hear one of the background clips mentioning how the greenhouse effect was 'really starting to bite', and this was in 1990.

At last an explanation that makes a bit of sense to me.

>Hopefully they own up to this, and explain what they're going to do to prevent another global-impact process failure

They probably needn't bother, every competent sysadmin from Greenland to New Zealand is probably disabling the autoupdate feature right now, firewalling it off and hatching a plan to get the product off their server estate ASAP.

Marketing budgets for competing product are going to get a bump this quarter probably.

>Crowdstrike runs on MacOS and Linux workstations too.

This is what chills me to the bone, there's loads of these installations worldwide on heterogeneous OSs but with very little oversight of the code. Companies have basically rolled over and stated, 'OK, we trust you'

I'm not usually a fan of strident calls to open source everything, but the source code at least for the channel file parser on all OSs should now be made public so that we can have an oversight of what so many have placed their trust in.

Perfect timing for this article after Putin's Russia just forced Apple to drop as many VPNs as possible from the App store in ru.

The aim obviously being to have an easier time surveilling the populace whilst also denying them access to any information not spewed by the Party.

It can't be long now until Moscow has a big sign that reads 'War is Love' plastered on some nameless building.

edit:typo.

>"they have no reason to surveil boring ordinary individuals."

Tell that to Parsons, Winston Smith's loyal to the Party neighbour who's betrayed by his own child. If surveillance is allowed to become pervasive enough, nobody is safe.