It’s a proprietary config file. I think it’s a list of rules to forbid certain behaviours on the system. Presumably it’s downloaded by some userland service, but it has to be parsed by the kernel driver. I think the files get loaded ok but the driver crashes when iterating over an array of pointers. Possibly these are the rules and some have uninitialised pointers but this is speculation based on some kernel dumps on twitter. So the bug probably existed in the kernel driver for quite a while, but they pushed a (somehow) malformed config file that triggered the crash.
For this Channel File, yes. I don’t know what the failure rate is - this article mentions 40-70%, but there could well be a lot of variance between different companies’ machines.
The driver has presumably had this bug for some time, but they’ve never had a channel file trigger it before. I can’t find any good information on how they deploy these channel files other than that they push several changes per day. One would hope these are always run by a diverse set of test machines to validate there’s no impact to functionality but only they know the procedure there. It might vary based on how urgent a mitigation is or how invasive it’ll be - though they could just be winging it. It’d be interesting to find out exactly how this all went down.
It’s a proprietary enterprise security product so I think it’ll be difficult to get information until they give a proper post-mortem (if they do so). Here’s hoping someone can put it all together though.
From what we have from CrowdStrike so far, the Channel File 291 update was to combat some use of Named Pipes in Windows malware.
This seems to have triggered a null pointer exception in the Falcon kernel driver as it loaded this Channel File. CrowdStrike say this is not related to the large null sections of one of the files but haven’t really explained what did trigger it.
Regardless, the kernel driver ought to have been statically analysed to detect this kind of memory hazard, or written in a language that prevents this class of bugs altogether. This is a priority of the US government right now, but CrowdStrike doesn’t seem to have got the memo.
wouldn’t changing it just end up performative
Exactly. Sidereal time does get rid of time zones and leap years, but it’s still referenced to a single physical object and relies on a arbitrary choice of start point. So it doesn’t create some perfect cosmic time standard.
The international date line doesn’t help since that’s just 180° offset from Greenwich itself.
The point of standards is that they can be followed by everyone. The AD/BC epoch is fine. The Greenwich meridian is fine. UTC is fine. Changing them would cause so much disruption that it cannot be worth it.
Daylight savings can go die in a ditch though.
I would encourage you not to split things up too finely. A single repo for your environment would allow you to see all related changes with git. E.g. if you set up a new VM it might need a playbook to set something up, a script to automate a task, and a DNS entry. With a well put together commit message explaining why you’re making those changes there’s not much need for external documentation.
Maybe if you want some more info organised in a wiki, point to the initial commit where you introduced some set up. That way you can see how something was structured. Or if you have a issue tracker you can comment with research on something and then close the issue when you commit a resolution.
Try not to have info spread out too much or maintaining all the pieces will become a chore. Make it simple and easy to keep up.
Godbolt to the rescue! So gcc 13.2 certainly does produce the same code, though a lot of other versions and compilers do it slightly differently. Surprisingly, clang doesn’t optimise this and uses idiv
for the modulo version.
For sure. It’d be nice to have the units in a separate namespace but at least Numbat won’t let you override identifiers already defined in the system of measure. I use Pint on Python - I usually keep the units in an identifier named u
so they can’t get accidentally overridden. That means either using u.km
for single units or u('g/cm^3')
for composite units. It’d be great if the language could separate units e.g. as [km]
or `` but getting a compact syntax to distinguish the units namespace without colliding with other language features would be tricky. I remember F# having a good syntax but didn’t dive that deep since it’s not used widely in my field.
Core utils has this AI built in: yes
“abbabba” doesn’t match the original regex but “abbaabba” does