Hacker News Reader

Comment by teruakohatu | Hacker News Reader

I struggle to understand MSFTs liability here. Can anyone explain to me how Microsoft would be liable for Delta’s outage?

View on HN

People are blaming Microsoft for signing a driver with bugs. Also something about not having an eBPF API.

This just sounds like shifting the blame to me. Nothing Microsoft did changed anything for the CS situation. Apparently it's Microsoft's fault that they don't have a great, secure, bugless API that everyone seems to want all of the sudden.

On the day the crashes started, Microsoft had a cloud services outage, and people assumed the two outages were related (they sort of were, in that some of the consultancies Microsoft hired also ran CrowdStrike so they couldn't get support for the cloud outages as easily). That seemed to have stuck around.

Not providing a way to inspect those data except from within kernel drivers (or whatever Windows calls them.) The huge HN thread about what happened weeks ago had some comments about Linux using eBPF to get the same kind of information Crowdstrike needs and Macs having another technology to do the same thing. In both cases the kernel won't crash and take down the machine. Of course it's possible to hog a machine from user space and make it unusable.

People also pointed out that bugs in Red Hat's and Debian's kernels caused CrowdStrike's non-buggy eBPF drivers to hang the system a few months prior (as they would for any code calling similar eBPF methods). Having the API is not enough, though in this case CrowdStrike couldn't really help it as none of their supported platforms were affected.

And in turn, Microsoft blames the EU for forcing them to allow an external vendor having kernel level access https://www.euronews.com/next/2024/07/22/microsoft-says-eu-t.... Lot of finger-pointing going around here.

Alot of people are blaming MSFT for approving this kernel driver and allow kernel drivers like this to crash the system.

Maybe as an operating system that Delta purchased, its kernel should not crash when a 3rd party software receives a faulty update?

They can’t do anything about a 3rd party software that runs in kernel space

I really dislike this line of thinking because it assumes that Microsoft is responsible for anything you run on your Windows machine.

I should be able to do whatever I want with a computer I buy, but that doesn't mean Microsoft should hold any liability for it. What am I missing here?

The difference is you are an individual and Delta is a public company. For enterprise purchases, you would have SLAs and contract terms to protect your company when something bad happens.

Fair, if this violates an SLA then Microsoft should pay up.

If Microsoft's SLAs are worded so that you're allowed to shove bits of third party code into the kernel without violating the SLA, though, they should fix that.

Reply on news.ycombinator.com