2 ms·
That’s very easily mitigated - write the security software so it can’t crash. Like, you know, drivers should be written. Malware can’t crash a well-written or
by gjsman-1000 2y ago
That’s very easily mitigated - write the security software so it can’t crash. Like, you know, drivers should be written.
Malware can’t crash a well-written or memory-safe driver, so it will never be unloaded. Problem solved.
- deleted 2y ago[deleted]
- echoangle 2y agoWriting the driver so it can’t crash is the hard part, I think the developers knew that this was the goal.
- jayd16 2y agoJust don't make mistakes is not actionable feedback.
- stubish 2y agoWith modern developer tooling, it kind of is. Pick the right language for the right job. You can catch the vast majority of crashes in your code at compile time, to the point where the potential of 'making a mistake' is a statistical improbability. But so many companies just stick with C, and even ignore compiler and static code analysis warnings, because the machismo of their devs protects them much better. Software by companies failing basic risk analysis.
- jayd16 2y agoWhy are we talking about language safety when it was a malformed config? It shouldn't boot with a malformed config, by design. The issues seem to be operational not technical.
- stubish 2y agoWhen parsing the config, the code crashed causing a BSOD. It wasn't even known it was malformed at that stage. A safer language would not let you crash when attempting to parse or validate malformed config. Unsafe languages require remembering and bothering to run extra steps to check your code is safe