https://x.com/Perpetualmaniac/status/1814376668095754753
Posted on 07/20/2024 8:10:34 AM PDT by ransomnote
https://x.com/Perpetualmaniac/status/1814376668095754753
you nailed it ...
It’s not normally encountered in languages where you don’t have pointers. In COBOL terms, it’s like a divide by 0.
The newer coders won't be able to elicit the proper requirements from the clients or know how best to implement the poor requirements they got. But hey, that's why we have beta testers.
Doesn’t this explain what a complete crap-show our supposed awesome technology is? 1 security update from a single company can take down so much stuff around the globe. Horrible.
I never said that. Try actually READING.
This is Geek to me. 🫤
Nope. That’s binary. DEI loves non-binary. They apparently fly use hexadecimal. They forgot to carry the 16.
Because that is all you have when you are working with kernel-mode and boot-time drivers in Windows.
BTW, you can make the exact same class of error in other program languages too.
Automated code inspection tools improve the odds of catching errors, but they are not foolproof.
Automated unit testing improves the odds of catching errors, but it is not foolproof either.
The big failure was not testing this update with a variety of Windows systems, and not rolling out a sample population of the user base before a general distribution.
“whose entire professional career has been in C#”
Doesn’t c# run slower? Also I’d say that anytime you use new or malloc, you’d better check for a null result.
This is amateur hour. For something so critical as a kernel module/driver, it would mean that code reviews failed, static analysis tools weren’t used, their DevOps pipeline and test suite failed to catch this, nobody ran any manual tests, etc..
So, at what point do you wonder about sabotage? If it isn’t, then it’s a very sorry state of affairs at MS. For a KERNEL MODULE!
Given the scale of this, I believe an investigation is warranted. I’d put money on sabotage.
Unfortunately, I got caught up in it - I had a two-week business trip with a flight home yesterday, I woke to the news of this issue and the problems banks & airlines were having. Typical! Of course my flight was delayed, then delayed, then delayed, with me finally getting home at 3:30am.
Sigh.
It’s legacy, just like Linux there’s few options for kernel programming. For Linux, it’s straight C...with Rust becoming a recent option, nothing else.
IT is not magic.
At the end of the day human error (or active or passive sabotage) can make it crash and burn.
Passive sabotage is when somebody sees that something is wrong and decides to keep their mouths shut and do nothing about it.
It is highly effective and almost impossible to catch.
Do today’s programmers even desk-test their own code? In the early days, the programmer was expected to have a stub app on his machine wherein he crafted the code with all the requisite inputs and outputs including all headers and library linkage (to eliminate naming collisions), compiled, linked and TESTED (bounds checks, min/max parameters, unterminated strings, etc.) before submitting it to the dogfood repository. There it was given the evil eye by several highly-paid (and super-stressed) mercenaries, then compiled and linked into the dogfood testbox where it was given a fairly thorough hands-on BEFORE it was even NOMINATED for the production build. It would have to pass a couple of code reviews AND a functionality review before being piped into production. Each line of code had about ten sets of eyes on it before a customer was allowed to test it. But that was then (the 1990’s), and this is now.
Not necessarily. The C# Just-in-time translation is remarkably efficient.
Yes, I have done timing tests on some complex algorithms that were implemented in both C# and C++. They ran at approximately the same rate.
I would say one had better check for a null pointer anytime a class pointer gets passed along to another method. Then provide some reasonable error message and a suitable fallback that does not cause a crash.
That is pretty hard to do and even harder to test and see if it works. That is why it is seldom done.
Csgent must be some service running in kernel..
Dividing by zero works!
This was not a problem from Microsoft. It was a problem from the Crowd Strike company.
This was an organizational and management problem, not sabotage. They released an insufficiently tested version of their computer security product on their entire customer base at the same time. You never do that.
They won't do that again. Most likely they will go out of business and cannot do that again.
sye, sti termxyeel imoptrnta
ok, sure Crowd Strike, not MS.
That said, it’s so amateurish I have to question that it could be sabotage. We don’t know it wasn’t.
I’m a software architect and manager responsible for safety critical software systems, I’m well aware of release tools and processes.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.