Internet crash today 19/7/24

[Nick]

So potentially an old fashioned buffer overflow or dangly pointer sort of problem.

My supposition is Yes.

Occasionally I was asked why I needed the budget to hire non-developer QA specialists to create test suites. I had a stock answer:

It's all about mindset.

• A Developer's entire mindset is all about MAKING things just do what they're supposed to. Developers usually create tests to prove they've met the specs/remit, i.e. "functional testing".
  
• A Tester's mindset is all about BREAKING things. Testers create tests whose sole purpose is to break things, i.e. non-functional testing. They approach code quality completely differently.
  

Sometimes developers are just too close to the actual code and can become "code blind" to oversights such as how to handle edge conditions. A first stage check on this is to "buddy" developers so that they check each other's code, but code reviews are before all the CI stuff I mentioned above. A lot of automated tools should be/are also used in static and dynamic code testing to pick up most of the common errors.

Developers and Testers are both devious little so-and-sos in their own ways, but coming at the same problem from completely opposing directions.

EDIT: All my comments re s/w product development & testing are highly simplified - there are many other types of testing that are used and many other stages & processes. There is also a HUGE range of opinions about the "best" way to develop products, or even a given product - these methodologies vary fundamentally in how projects are run, the tools & processes used, the time frame needed, the relative costs involved etc.

[ppppenguin]

You may also need fools for testing to destruction. "If you think you have made something foolproof, nature will evolve a better class of fool"

I'm not a software professional (barely even an amateur) but I've seen a lot of inked spilled on Rust. It's billed as a language that's as efficient as C for low level programming but inherently memory safe. If a lot of real world problems are caused by unsafe memory access, such as buffer overflow and bad pointers, then it seems like salvation. I'm pretty sure it's not.

[Mike Watterson]

Developer, "Why did you do that? It makes no sense."
Ordinary user, "I always have."

Application crashes (and if DOS maybe even wipes disk!).

Modula-2 and C++ can be as efficient as C, or even assembler, and used properly, don't have buffer overflows. But C++ (against wishes of Strustrupp) could use C libraries and C Strings. Many people use C++ compilers and are still writing traditional C programs.

Buffer overflow and other evils are possible in Modula-2 also, even though you can avoid C style strings, can't assign anonymous types that seem to match and even when writing Generic Functions etc, using magic types, you might forget to query the array size, or make a mistake accessing it, and BANG.

My conclusion is that the language chosen won't "fix" poor programmers, and the best programmers can use terrible languages safely.. Though languages with no compiler, no enforced types, auto type conversion and no checkers are bad. So are server side text web pages with mix of server side Java, client side javascript, SQL, HTML programatically/database generated, and PHP are a disaster to debug.

[Radio Fixer]

Thanks Nick and others. Sounds like the testing, as is often the case even with hardware, can take much more time and cost then the actual software code change.

Gary

[Mark Hennessy]

A good overview from a retired Microsoft dev:

https://www.youtube.com/watch?v=wAzEJxOo1ts

I always enjoy Dave's videos, and had been awaiting this one with interest.

[BusyBee]

A good overview from a retired Microsoft dev:

https://www.youtube.com/watch?v=wAzEJxOo1ts

I always enjoy Dave's videos, and had been awaiting this one with interest.

A good presentation.

From my limited scope I am filled with dread as to the possibilities though.

Tracy

[ppppenguin]

He reckons it's likely another old fashioned problem: failure to validate parameters sent to your software.

It's like the program expects a number between 1 and 6 but receives "33" or "chicken" and falls over rather than rejecting them safely. Even I, as barely a software amateur, understand this in the toytown software that I've written. Yes, I've committed the crime, but I'm aware I've done it and my software isn't ever doing anything sensitive.

[Mike Watterson]

It's like going into a bar and ordering Bicycle instead of regular stock, and the bar burns down.

[ppppenguin]

https://www.theregister.com/2024/07/24/c...nt_report/

History tells us that was a very bad assumption. It "resulted in an out-of-bounds memory read triggering an exception."
"This unexpected exception could not be gracefully handled, resulting in a Windows operating system crash."

A commonplace out of bounds memory access brings the world crashing down.

Interesting article on the subject: https://medium.com/coinmonks/anatomy-rus...a73c66396e

[Nick]

I rest my case! Being fair, it was a pretty predictable cause. I've written kernel drivers and a) they're very difficult to get 100% right, and b) when things don't go right, it's very difficult (in kernel mode) to catch and then sensibly handle the issue. As mentioned elsewhere, if you have a kernel exception, bizarre as it may seem, crashing the machine can be (for the user's data integrity) the safest thing to do.

EDIT: What I suspect happened was that a fairly tame change to a configuration file (which is all that was in the update that caused the issue) exposed a coding flaw in the kernel-level driver that CrowdStrike use and which is loaded early in the Windows boot process (in order to catch nasty viruses etc. - generally the earlier you can load, the better)
The flaw itself may have been there a long time and is probably something like a buffer overflow causing a stack corruption, or memory pointer being corrupted etc. I admit this is supposition, but a configuration file change which introduced a longer-than-previously-used string or similar and which in itself may seem harmless, could easily expose this type of flaw. It's a coding error, a bug, which was not caught in testing and which was not or could not be caught and handled safely by the driver in question, hence the BSOD and reboot.