Re: Bad response from Crowdstrike
But low-level code basically doesn't. If you're writing in assembler or in C, a lot of important things do not raise exceptions for every invalid situation. With more clarity, C doesn't have exceptions. Some libraries have their own things that look kind of like exceptions, but they all work a little differently from each other and a lot of code you work with will not have those either. Good functions, including kernel ones, do check for and report errors, but you have to check that manually. If you don't, execution will proceed. You can't do a global check either. For instance, if you try to allocate memory and there isn't memory available, you have to check that right after trying and if you don't, your code will continue to execute until it tries to use that memory that never got allocated.
That's just talking about organized system calls which return errors in a way other than exceptions. There are lots of other things where you don't even have that. If you're dealing with locations in memory and you refer to a location that doesn't exist, isn't yours*, or doesn't contain what you intended it to contain, that's not an exception situation. You will get, respectively, a crash that can't be recovered from, a crash that can't be recovered from, and the wrong data which will probably lead to more bad pointer arithmetic somewhere which will, hopefully soon enough, give you a crash that can't be recovered from instead of a bunch of shredded data and then a crash that can't be recovered from. The only way to do this is to put more effort into not messing up and assuming that you still have, so trying to find out where before the users run the code. CroudStrike did not test their file in the way they needed to. It was a QA problem, and one I have a feeling they've fixed now, but they needed to learn that configuration files that get executed are code and can break things just as badly as the code that looks more familiar.
* When you run as the kernel, basically all of RAM is yours. While a program running in a user account, even root, will only crash itself** when trying to access memory used by another program, the kernel can stomp on memory used by any process. This is one of the reasons why you can't recover from an invalid memory use in the kernel. By the time you know you've had one, the chances are high that several other things are hideously damaged and you don't know what and where they are. Continuing to run is likely to cause more problems than not, so it requires a restart.
** Most of the time. There are some ways to access RAM that is not yours, and predictably, bad things happen when that goes wrong.