[brendangregg]

Yes, we know eBPF must attach to equivalent events to Linux, but given there are already many event sources and consumers in Windows, the work is to make eBPF another consumer -- not to invent instrumentation frameworks from scratch.

Just to use an analogy: Imagine people do their banking on JavaScript websites with Google Chrome, but if they use Microsoft Edge it says "JavaScript isn't supported, please download and run this .EXE". I'm not sure we'd be asking "if" Microsoft would support JavaScript (or eBPF), but "when."

[surajrmal]

This assumes eBPF becomes the standard. It's not clear Microsoft wants that. They could create something else which integrates with dot net and push for that instead.

Also this problem of too much software running in the kernel in an unbounded manner has long existed. Why should Microsoft suddenly invest in solving it on Windows?

[wongarsu]

Microsoft has invested in solving this for at least two decades, probably longer. They are just using a different (arguably worse) approach to this than the Unix world.

In Windows 9x anti-malware would just run arbitrary code in the kernel that hooked whatever it wanted. In Windows XP a lot of these things got proper interfaces (like the file system filter drivers to facilitate scanning files before they are accessed, later replaced by minifilters), and the 64 bit edition of XP introduced PatchGuard [1] to prevent drivers from modifying Microsoft's kernel code. Additionally Microsoft is requiring ever more static and dynamic analysis to allow drivers to be signed (and thus easily deployed).

This is a very leaky security barrier. Instead of a hardware-enforced barrier like the kernel-userspace barrier it's an effort to get software running at the same protection level to behave. PatchGuard is a cat-and-mouse game Microsoft is always loosing, and the analysis mostly helps against memory bugs but can't catch everything. But MS has invested a lot of work over the years in attempts to make this path work. So expecting future actions isn't unreasonable.

[1] https://en.wikipedia.org/wiki/Kernel_Patch_Protection

[Analemma_]

This is a weird reading of history. Microsoft has spent tons of effort getting as much code out of the kernel as possible: Windows drivers used to be almost all kernel-mode, now they're nearly all in userspace and you almost never need to write a kernel-mode Windows driver unless you're doing something with deep OS hooks (like CS was, although apparently even that wasn't actually necessary). The safeguards on kernel code are for the tiny sliver of use cases left that need it, it is not Microsoft patching individual holes on the leaky ship.

They haven't yet gone as far as Apple in banning third-party kernel-mode code entirely, but I wouldn't be surprised if it's coming.

[tptacek]

A thing I think a lot of people don't include in their premises about Crowdstrike is that they're probably the most significant aftermarket endpoint security product in the world (they are what Norton and McAfee were in 2000), which means they're more than large enough for malware to target their code directly, which creates interesting constraints for where their code can run.

I'm not saying I'd run it (I would not), just that I can see why they have a lot of kernel-resident code.

[jolux]

> I'm not saying I'd run it (I would not), just that I can see why they have a lot of kernel-resident code.

What would you run instead, or is there a different way of thinking about the problem it addresses that obviates the need?

[fsflover]

Not the parent, but security through compartmentalization seems like a more robust approach. See: Qubes OS.

[roenxi]

Microsoft made the reasonable point that locking 3rd parties out of the kernel might have resulted in legal challenges in the EU [0]. It is an interesting case where everyone is certain in hindsight that they would have been ok with MS blocking access, but it is less obvious that they would have taken that view if MS had pressured a bunch of security products out of the kernel with no obvious prompting.

[0] https://www.theregister.com/2024/07/22/windows_crowdstrike_k...

[Archelaos]

The 2009 agreement with the EU mentioned in the article seems to be the one about the integration of the Internet Explorer (IE) into MS Windows.[1] But it only applied to IE and the commitment was limited to 5 years.[2]

Or is the article referring to something else?

I see no reason why the EU should object to Microsoft's adoption of eBPF as long as MS Defender simply uses the same API that is available to all competitors.

[1] Here is the original text: https://ec.europa.eu/competition/antitrust/cases/dec_docs/39...

[2] See section 4, paragraph 20.

[philistine]

Apple took the lead on this front. It has closed easy access to the kernel by apps, and made a list of APIs to try and replace the lost functionality. Anyone maintaining a kernel module on macOS is stuck in the past.

Of course, the target area of macOS is much smaller than Windows, but it is absolutely possible to kick all code, malware and parasitic security services alike, from accessing the kernel.

The safest kernel is the one that cannot be touched at runtime.

[nullindividual]

I don't think Microsoft has a choice with regards to kernel access. Hell, individuals currently use undocumented NT APIs. I can't imagine what happens to backwards compat if kernel access is closed.

Apple's closed ecosystem is entirely different. They'll change architectures on a whim and users will go with the flow (myself included).

[becurious]

But Apple doesn’t have the industrial and commercial uses that Linux and Windows have. Where you can’t suddenly switch out to a new architecture without massive amounts of validation costs.

At my previous job they used to use Macs to control scientific instrumentation that needed a data acquisition card. Eventually most of the newer product lines moved over to Windows but one that was used in a validated FDA regulated environment stayed on the Mac. Over time supporting that got harder and harder: they managed through the PowerPC to Intel transition but eventually the Macs with PCIe slots went away. I think they looked at putting the PCIe card in a Thunderbolt enclosure. But the bigger problem is guaranteeing supply of a specific computer for a reasonable amount of time. Very difficult to do these days with Macs.

[nullindividual]

> validated FDA regulated environment stayed on the Mac

Given how long it takes to validate in a GxP environment, and the cost, this makes sense.

[adolph]

Sounds like they need a nice Hackintosh for that validated FDA regulation app-OS-HW combo.

[becurious]

Good luck getting that through a regulated company’s Quality Management System or their legal department. Way too much business risk and the last thing you want is a yellow or red flag to an inspector who can stop ship on your product until all the recall and remediation is done.

[philistine]

See Satya Nadella has recently said that Microsoft will now put security above any other value at Microsoft. He specifically even singled out backwards compatibility.

https://blogs.microsoft.com/blog/2024/05/03/prioritizing-sec...

Microsoft is a big boat. It takes a long time to turn if the captain orders it. But the captain has ordered it. I expect the sacrosanct nature of back compat to eventually die. Windows will never turn into the moving target that macOS is, but I expect a lot of old stuff to just stop working, when security concerns dictate they should be removed.

[Xunjin]

> The safest kernel is the one that cannot be touched at runtime.

Can you expand what you mean here? Because depending on the application you are running, you will need at least talk with some APIs to get privileged access?

[Agingcoder]

Being allowed to talk to the kernel to get info and running with the same privileges ( basically being able to read / write any memory ) is different.

[odo1242]

Yeah, Apple doesn’t allow any user code to run in kernel mode without significant hoops (the kernel is code signed) and tries to provide a user space API (e.g. DriverKit) as an alternative for the missing functionality.

Some things (FUSE) are still annoying though.

[duskwuff]

> Some things (FUSE) are still annoying though.

That should get much easier in macOS Sequoia with FSKit.

https://developer.apple.com/documentation/fskit/

[brendangregg]

Microsoft have been driving the work to make eBPF an IETF industry standard.

[riskable]

...just like they did with Kerberos! And just like with Kerberos they'll define a standard then refuse to follow it. Instead, they will implement subtle changes to the Windows implementation that make solutions that use Windows eBPF incompatible with anything else, making it much more difficult to write software that works with all platforms eBPF (or even just its output).

Everything's gotta be different in Windows land. Otherwise, migrating off of Windows land would be too easy!

In case you were wondering what Microsoft refused to implement with its Kerberos implementation it's the DNS records. Instead of following the standard (they wrote!) they decided that all Windows clients will use AD's Global Catalog to figure out which KDC to talk to (e.g. which one is "local" or closest to the client). Since nothing but Windows uses the Global Catalog they effectively locked out other platforms from being able to integrate with Windows Kerberos implementation as effectively (it'll still work, just extremely inefficiently as the clients won't know which KDC is local so you either have to hard-code them into the krb5.conf on every single device/server/endpoint and hope for the best or DNS-and-pray you don't get a Domain Controller/KDC that's on an ISDN line in some other country).

[xp84]

This to me ascribes way too much to mustache-twirling villainy at Microsoft, but to me fails to account for the fact that engineers surely make many of these implementation-detail decisions. These engineers aren’t incentivized to create lock-in. I think it’s more likely that sometimes for a feature to play well with other existing parts of the Windows ecosystem, compromises are made to the standards-compliance. Microsoft may have shipped those related interfaces before this standard had been hashed out, so they have a choice to break everything or to not perfectly follow the standard.

Note: I’m not a Windows dev so I can’t speak to specifics of anything like your Kerberos example. I just don’t believe MS is full of evil engineers, nor that Satya Nadella visits cubicles to promote lock-in practices.

[CRConrad]

> These engineers aren’t incentivized to create lock-in.

Ever heard of something called “money”?

> I think it’s more likely that sometimes for a feature to play well with other existing parts of the Windows ecosystem, compromises are made to the standards-compliance.

So you're basically saying that you're too young to remember the “good” old days of Embrace, Extend, Extinguish, right...?

[MawKKe]

Embrace, extend, ...

[jrockway]

This doesn't really seem like their strategy anymore. It's not like Edge directly interprets Typescript, for example. While they embraced and extended Javascript, any extinguishing seems to be on the technical merits rather than corporate will.

In the case of security scanners that run in the kernel, we learned this weekend that a market need exists. The mainstream media blamed Crowdstrike's bugs on "Windows". Microsoft would likely like to wash its hands of future events of this class. Linux-like eBPF is a path forward for them that allows people to run the software they want (work-slowers like Crowdstrike) while isolating their reputation from this software.

[chupasaurus]

Third step of the strategy mentioned by GP is enacted when market share allows it, and Edge is far below Chrome atm.

[numbsafari]

> Why should Microsoft suddenly invest in solving it on Windows?

If they can continue to avoid commercial repercussions for failing to provide a stable and secure system, then society should begin to hold them to account and force them to.

I’m not necessarily advocating for eBPF here, either. If they want to get there through some “proprietary” means, so be it. Apple is doing much the same on their end by locking down kexts and providing APIs for user mode system extensions instead. If MS wants to do this with some kind of .net-based solution (or some other fever dream out of MSR) then cool. The only caveat would seem to be that they are under a number of “consent decree” type agreements that would require that their own extensions be implemented on a level playing field.

So what. Windows Defender shouldn’t be in the kernel any more than CrowdStrike. Add an API. If that means being able to send eBPF type “programs” into kernel space, cool. If that means some user mode APIs, cool.

But lock it down already.

[safety1st]

Not necessarily disagreeing with you, but as far as 'avoiding commercial repercussions' goes... Windows' share of the desktop OS has market has been declining for almost 20 years at the rate of about 1% per year. And about 70% of the global installed base is still on Windows 10.

They have a long way to fall, but I'm not sure that if I'm a regulator I look at that and say there needs to be some kind of intervention by society apart from what market forces are gradually doing anyway.

[doctorpangloss]

Windows development on eBPF is slower than Linux development on eBPF, so it will never be supported. A source code user licensee could develop it faster, but who licenses Windows source and already has great eBPF experience?