5 ms·

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 a

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."

doctorpangloss 2y ago
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?
surajrmal 2y ago
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?
- brendangregg 2y ago
  Microsoft have been driving the work to make eBPF an IETF industry standard.
  - riskable 2y ago
    ...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 2y ago
      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 2y ago
        > 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 2y ago
      Embrace, extend, ...
      - jrockway 2y ago
        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.
- philistine 2y ago
  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.
  - Xunjin 2y ago
    > 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?
    - odo1242 2y ago
      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 2y ago
        > Some things (FUSE) are still annoying though. That should get much easier in macOS Sequoia with FSKit. https://developer.apple.com/documentation/fskit/ https://developer.apple.com/documentation/fskit/
    - Agingcoder 2y ago
      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.
  - nullindividual 2y ago
    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).
- numbsafari 2y ago
  > 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 2y ago
    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.
- wongarsu 2y ago
  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 https://en.wikipedia.org/wiki/Kernel_Patch_Protection
  - Analemma_ 2y ago
    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 2y ago
      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.

doctorpangloss 2y ago

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?

surajrmal 2y ago

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?

brendangregg 2y ago
Microsoft have been driving the work to make eBPF an IETF industry standard.
- riskable 2y ago
  ...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 2y ago
    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 2y ago
      > 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 2y ago
    Embrace, extend, ...
    - jrockway 2y ago
      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.
philistine 2y ago
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.
- Xunjin 2y ago
  > 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?
  - odo1242 2y ago
    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 2y ago
      > Some things (FUSE) are still annoying though. That should get much easier in macOS Sequoia with FSKit. https://developer.apple.com/documentation/fskit/ https://developer.apple.com/documentation/fskit/
  - Agingcoder 2y ago
    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.
- nullindividual 2y ago
  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).
numbsafari 2y ago
> 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 2y ago
  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.
wongarsu 2y ago
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 https://en.wikipedia.org/wiki/Kernel_Patch_Protection
- Analemma_ 2y ago
  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 2y ago
    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.