Microsoft's EU agreement means it will be hard to avoid CrowdStrike-like calamities in the future

EU Flag
(Image credit: Shutterstock)

CrowdStrike's buggy software update and its kernel-level access to Windows lethally combined to cause the massive outage last week. One of the ways that Microsoft could avoid this type of unfortunate event in the future is to restrict kernel access to third-party developers. However, the company cannot legally do this because of an understanding it struck with the EU in 2009. Thus, this type of outage that affected 8.5 million Windows devices could happen again, especially if it involves widely-used enterprise security software.

The Microsoft-EU agreement states that the former must make the Windows Client and Server operating system APIs that its security software, like Microsoft Defender for Endpoint uses, available to other developers. Neowin also said that the company must document the APIs it deploys on the Microsoft Developer Network unless they create security risks.

Microsoft made this move after a complaint was filed against it in Europe, and it allowed other vendors to create products that affect Windows at the kernel level. This agreement with the European Commission resulted in a freer market for security products and prevented Microsoft from gaining a monopoly on antivirus and other security suites.  

However, it also paved the way for the global CrowdStrike disaster that affected the world last week. Any error at the kernel level could potentially disable any operating system, that’s why Apple locked macOS and stopped giving developers access to its kernels. This move inherently hardens macOS from third-party software-induced crashes, as no one else but Apple can make changes to its kernel. However, it also meant that security providers had to revamp their apps to ensure they would continuously protect their clients, even without access to the kernel level of Macs, MacBooks, and iMacs.

Apple and Google still do not have an agreement with the European Commission regarding kernel-level access to their operating systems. Nevertheless, this could change at any moment, especially as Europe has been wary about and making moves against big tech.

We cannot directly blame Microsoft or the EU for the CrowdStrike crash, especially as neither was at fault for the event. In the end, the event last week lies solely on the shoulders of CrowdStrike for releasing an unstable update without testing it first. As Microsoft said in its press release, "It's also a reminder of how important it is for all of us across the tech ecosystem to prioritize operating with safe deployment and disaster recovery using the mechanisms that exist."

TOPICS
Jowi Morales
Contributing Writer

Jowi Morales is a tech enthusiast with years of experience working in the industry. He’s been writing with several tech publications since 2021, where he’s been interested in tech hardware and consumer electronics.

  • kyzarvs
    It's the EU's fault? That's your headline? Wow...

    You can blame a non-rigorous testing process by MS (your kernel, you should be testing / approving what hooks into it imo, especially from large vendors). You can blame a non-rigorous testing process by Crowdstrike. You can't blame a monopoly-busting set of directives.
    Reply
  • setx
    That's not just nonsense, it's intentional spreading of misleading and harmful information.

    If MS wouldn't allow any non-MS kernel-level security software that would never happen? EU is at fault for preventing monopolies?
    Reply
  • ezst036
    Admin said:
    Last week's CrowdStrike crash was caused by the app's kernel level access to Windows. However, Microsoft cannot legally stop companies from that level of access because of an agreement it made with the European Commission in 2009.

    Microsoft's EU agreement means it will be hard to avoid CrowdStrike-like calamities in the future : Read more

    It's not entirely surprising at all to learn that a bunch of know-nothing bureaucrats is actually behind this monstrosity. Microsoft should never have been forced to give out software-related access to its kernels in this manner.

    Microsoft should do whatever it can to back out of this bad EU agreement. It hurts the customers.

    Documentation only should be the red line.
    Reply
  • das_stig
    ezst036 said:
    It's not entirely surprising at all to learn that a bunch of know-nothing bureaucrats is actually behind this monstrosity. Microsoft should never have been forced to give out software-related access to its kernels in this manner.

    Microsoft should do whatever it can to back out of this bad EU agreement. It hurts the customers.

    Documentation only should be the red line.
    What a load of tosh, fault lies squarely with Crowdstrike for not going through QA, they not only hit Windows but Linux has had issues too, same when Microsoft bork monthly patches, same as any other software company that don't follow best software development practices. Suggest you read rather going on an anti-regulator rant, for once I'm backing the EU for blocking Microsoft anti-competitive monopolistic endeavours!
    Reply
  • edzieba
    kyzarvs said:
    It's the EU's fault? That's your headline? Wow...

    You can blame a non-rigorous testing process by MS (your kernel, you should be testing / approving what hooks into it imo, especially from large vendors). You can blame a non-rigorous testing process by Crowdstrike. You can't blame a monopoly-busting set of directives.
    That's not how kernel-level drivers work. If they have kernel access, they can mess with the kernel. That's pretty much the definition of a kernel level driver.

    If your concern is buggy 3rd party kernel-level drivers taking down your OS then DO NOT INSTALL THEM. Big Bad EU is not sneaking onto your box and magicking a Crowdstrike install onto it, you made that choice yourself, entirely of your own volition. A legal mandate leaving open the option of installing kernel-level drivers means you equally have the option to not install them.
    Reply
  • vanadiel007
    It's an interesting conundrum. Should an OS vendor provide access to the kernel, so other "security" software can patch into it?

    I have banned software from MacAfee, Norton, Kapersky and a host of others from ever residing on my machines, as they provide nothing but a bunch of advertisement for services and upgrades that affect overall machine performance. That is just my opinion and your mileage may vary.
    Reply
  • ezst036
    das_stig said:
    What a load of tosh, fault lies squarely with Crowdstrike for not going through QA, they not only hit Windows but Linux has had issues too, same when Microsoft bork monthly patches, same as any other software company that don't follow best software development practices. Suggest you read rather going on an anti-regulator rant, for once I'm backing the EU for blocking Microsoft anti-competitive monopolistic endeavours!

    MacOS was not hit.

    The EU does not force Apple to open up the kernel against their will.
    Reply
  • -Fran-
    I've been reading on this specific issue and I appreciate the level of detail that has been floating around from people "in the know" and, Microsoft is trying their best to deflect with the most pathetic of deflections I've seen in ages.

    Talk about missing the whole bloody point of the regulation, haha.

    Kernel-mode drivers and how you expose kernel functions is entirely up to MS and the idea behind this regulation is to allow all potential security providers to compete, one to one, with Microsoft. The fact the only way Microsoft has* envisioned to allow said competition is ring-0 operation (non-user space) is pretty darn stupid. If they would just secure the kernel properly and expose only what is relevant, they would not have had these problems.

    Also, CrowdStrike is still at fault here. Even with MS'es stupid decisions, CS is the one that effectively broke everything and not MS. This is just stupid from MS'es side. They may as well just stayed silent and no one would've picked up the magnifier glass into their DDK and Kernel practices. Stupid, stupid, stupid.

    Regards.
    Reply
  • bluvg
    -Fran- said:
    Kernel-mode drivers and how you expose kernel functions is entirely up to MS and the idea behind this regulation is to allow all potential security providers to compete, one to one, with Microsoft. The fact the only way Microsoft has* envisioned to allow said competition is ring-0 operation (non-user space) is pretty darn stupid. If they would just secure the kernel properly and expose only what is relevant, they would not have had these problems.
    These and other comments about kernel access are not fully accurate; even though it is a kernel-level driver, it is not uncontrolled read/write access--it serves primarily as a notification mechanism. See PatchGuard; to work around this limitation, Microsoft provided AV vendors kernel callback notifications to get the kind of telemetry they were getting previously by modifying the descriptor tables. They register their drivers to receive these notifications, but it's critical that they process these notifications correctly. The driver in this case triggered a read of memory location 0, which is an access violation. The kernel then immediately--and correctly--bug checks.
    Reply
  • cd_reader_eater
    kyzarvs said:
    It's the EU's fault? That's your headline? Wow...

    You can blame a non-rigorous testing process by MS (your kernel, you should be testing / approving what hooks into it imo, especially from large vendors). You can blame a non-rigorous testing process by Crowdstrike. You can't blame a monopoly-busting set of directives.
    One of the worst articles on tomshardware, like was this hit piece written by an A.I or a toddler?

    Absolute bonkers.

    Anyone recommend a different tech news site?
    Reply