[nullfrigid]

Microsoft has a very solid point here. MS has wanted to kick AV vendors out of kernel space for a long time because it isn't necessary, and can lead to the type of incident we are talking about here.

MS provides a userspace interface[0] for AV vendors to do what they need to do, but they can't be forced to use it.

So yes, due to EU regulations, AV vendors can still play in kernel space, and can bring much of the world to a halt when they make a mistake as a result.

[0] https://learn.microsoft.com/en-us/windows/win32/amsi/antimal...

[tpm]

No they don't have a point. They:

- could have kicked AV vendors out of kernel space, including themselves, ensuring level playing field (which is the point of EU regulations). But then they couldn't sell their product that's "isn't necessary".

- could have created other, less critical APIs to use for everyone

- could have enabled anything mandated by the EU only for the EU market

[piva00]

If they provide a userspace interface but use their own set of kernel accesses for Windows Defender then they are not competing fairly, don't you think? They just need to make Windows Defender use those userspace interfaces as well and all is good :)

[fargle]

or, the users could kick CS and McAfee out of the kernel space themselves - by not using those products or features that require these dodgy kernel modules.

the CTOs and engineering staff are the ones in control of their machines, not M$. or at least they should be. problem is that they thought they were solving a problem by installing this kind of software, but instead were simply handing over their responsibility to a 3rd party that was totally irresponsible - and certainly doesn't accept it. they took a compliance short-cut with "box checking" software. that's where the problem lies - lack of responsibility and engineering rigor in the IT orgs.

[LightHugger]

If microsoft is content with being out of kernel space why don't they just do that and compete with their own AV on the same API? Oh, they want kernel level access with their AV and want nobody else to have it? Oh. Maybe no, they don't have a solid point.

[trueismywork]

The real cause of mistake was a single point of failure where there was no A/B testing, no gradual deployment nothing. To say that banning AV from kernel would prevent this is not just hilarious but disingenuous and shows complete lack of knowledge of operations and deployment. There's no golden rule which says that Windows cannot make these errors.

[cdumler]

That is a solution, but not the cause. The cause is not having a culture that evaluates failure scenarios. From what I have read:

  * Updates are not vetted or sanity checked.
  * Updates are not slow-rolled to production.
  * Updates are not signed to prevent corruption or alteration.
  * Updater does not sanitize or validate inputs.
  * Updater does not have a reversion process to previously known good position on faulty boot.
  * Updater should mark itself as Unnecessary For Boot on faulty boot at some point.

Finally, its high adoption means it creates a mono-culture. There should be another version built independently where one is running on a machine and another sits in a ready state. If there is a fault in one, it becomes disabled and the second takes over. Good ol' NASA style redundancy.

[hilbert42]

"Updater should mark itself as Unnecessary For Boot on faulty boot at some point."

Precisely the point I made in my comment. If Windows can initiate a BSOD then it can also initiate a reboot without said patch.

What Microsoft's PR department said is personified bullshit and needs debunking ASAP.

[trueismywork]

Agree