Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

eBPF on Windows

github.com

Post reply on HN
Print view View original

111–120 of 169 posts

Re: eBPF on Windows

#111

Post by sanxiyn »

muststopmyths wrote: post #82
hs86 wrote: post #54

Here is a recent comment from Dropbox engineers about the state of tracing tooling on Linux compared to Windows: https://dropbox.tech/infrastructure/boosting-dropbox-upload-... Is their assessment correct? If so, how comes that we got DTrace in 2019 and now eBPF ported to Windows? Are they trying to consolidate all tooling into one platform?

ETW (What netsh trace in the post uses underneath) has been around for 20+ years in Windows and is extremely powerful. However, Microsoft has always neglected the usability side of it. It's a bitch to set up and hard to interpret. Documentation is there, but scattered and hard to find easily. Most people here have probably seen Bruce Dawson's performance analysis and debugging posts. WPA/WPR are probably the only use…

ETW is the topic of the post titled "The Worst API Ever Made" and the title is well deserved. If ETW tooling is lacking, it's because API is so terrible nobody wants to write tooling.

https://caseymuratori.com/blog_0025

Re: eBPF on Windows

#112

Post by dblohm7 »

srcmap wrote: post #98
brendangregg wrote: post #97

Great news, I'm looking forward to analyzing performance on Windows with BPF! Given that PerfView and WPA also got flame graphs it'll start to feel like home. :-)

From the architecture diagram, it looks like just network ebpf only. Does anyone know if it can profile file/disk io type activities?

They make it pretty clear from the post that its support is currently limited, and that they plan on adding more hooks in the future.

Re: eBPF on Windows

#113

Post by cmeacham98 »

salawat wrote: post #104
tptacek wrote: post #48

A fun detail of this work is that it uses a formal-methods-based verifier (designed outside of Microsoft) that accepts a wider range of programs than does the Linux verifier, which is itself kind of nightmare fuel. https://vbpf.github.io/assets/prevail-paper.pdf The verifier in this paper also has some biting limitations; for instance, you can't resize a packet in it, because they don't account for pointer invalidati…

>Additionally, the PREVAIL paper explicitly doesn't verify program termination, which is kind of a dealbreaker for kernel BPF. I'd be more alarmed if someone had solved the Halting Problem and I hadn't heard about it, to be honest.

From my understanding eBPF is sufficiently constrained to where the halting problem is solvable for all representable programs (in eBPF).

Re: eBPF on Windows

#114

Post by dthaler »

tptacek wrote: post #48

A fun detail of this work is that it uses a formal-methods-based verifier (designed outside of Microsoft) that accepts a wider range of programs than does the Linux verifier, which is itself kind of nightmare fuel. https://vbpf.github.io/assets/prevail-paper.pdf The verifier in this paper also has some biting limitations; for instance, you can't resize a packet in it, because they don't account for pointer invalidati…

The ebpf-for-windows maintainers have been working with the PREVAIL verifier maintainers for some time now on improving the implementation for everyone, since we agree that addressing such limitations is critical. For example, the PREVAIL maintainers added program termination verification back in January 2021. Check it out at https://github.com/vbpf/ebpf-verifier

Re: eBPF on Windows

#115

Post by 1970-01-01 »

jaywalk wrote: post #19
1970-01-01 wrote: post #16

See https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis... Step 1: Getting SQL and a few other things running in Linux. That was in 2016. Step 2: WSL and WSL 2 eBPF puts them at something like step 2.2.5

This seems like the exact opposite of EEE. Care to explain your thinking?

Linux is cited as an example in the link: https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...

Re: eBPF on Windows

#116

Post by voidfunc »

pjmlp wrote: post #56
EvanAnderson wrote: post #34

Earlier quoted context omitted.

You missed a lot of tedious reboots by starting your experience with the Windows NT family w/ Windows 2000. Windows NT 4.0 was a breath of fresh air, as far as the UI went, compared to NT 3.51, but Windows NT didn't really come into its own, in my opinion, until Windows 2000. The tedious "re-apply the service pack and reboot" or "you thought about changing a setting, so therefore reboot" scenarios were nearly removed…

I do mostly Windows, and given the option would rather keep doing so, however you just reminded me of the "fun" of writing ISAPI extensions on Windows 2000. For those unaware of it, IIS used to execute fully on kernel level, so ISAPI extensions were comparable to device drivers, which meant any programming error would just kill the kernel, thus requiring a reboot. So tracking down memory corruption issues on ISAPI ex…

Goodness, who decided that was a good idea?!

Re: eBPF on Windows

#117

Post by pctammela »

dthaler wrote: post #114
tptacek wrote: post #48

A fun detail of this work is that it uses a formal-methods-based verifier (designed outside of Microsoft) that accepts a wider range of programs than does the Linux verifier, which is itself kind of nightmare fuel. https://vbpf.github.io/assets/prevail-paper.pdf The verifier in this paper also has some biting limitations; for instance, you can't resize a packet in it, because they don't account for pointer invalidati…

The ebpf-for-windows maintainers have been working with the PREVAIL verifier maintainers for some time now on improving the implementation for everyone, since we agree that addressing such limitations is critical. For example, the PREVAIL maintainers added program termination verification back in January 2021. Check it out at https://github.com/vbpf/ebpf-verifier

the PREVAIL implementation seems to be more robust then Linux's verifier, are there any plans to port it to Linux?

From the counter examples directory, this implementation seems very promising.

Re: eBPF on Windows

#118

Post by jhomedall »

encryptluks2 wrote: post #81
jhomedall wrote: post #76

Earlier quoted context omitted.

They do in WSL2, as I understand it.

Try it out... install Ubuntu using WSL2. Install docker using apt-get. See that it doesn't work without the Docker Desktop install for Windows and a special integration. Try running podman or other container-based solutions and see that they don't work.

Having followed the instructions from https://docs.docker.com/engine/install/ubuntu/, I was able to get this working fine. This is without Docker Desktop installed. It probably would have also worked with the version from distro repository.

  zed@ZED-PC:~$ sudo service docker start
   * Starting Docker: docker                      [ OK ]
  zed@ZED-PC:~$ sudo docker run hello-world
  Unable to find image 'hello-world:latest' locally
  latest: Pulling from library/hello-world
  b8dfde127a29: Pull complete
  Digest: sha256:f2266cbfc127c960fd30e76b7c792dc23b588c0db76233517e1891a4e357d519
  Status: Downloaded newer image for hello-world:latest
  
  Hello from Docker!
  This message shows that your installation appears to be working correctly.
The full output for 'docker run' was much longer, so I've snipped it down to size

Re: eBPF on Windows

#119

Post by malkia »

sanxiyn wrote: post #111
muststopmyths wrote: post #82

Earlier quoted context omitted.

ETW (What netsh trace in the post uses underneath) has been around for 20+ years in Windows and is extremely powerful. However, Microsoft has always neglected the usability side of it. It's a bitch to set up and hard to interpret. Documentation is there, but scattered and hard to find easily. Most people here have probably seen Bruce Dawson's performance analysis and debugging posts. WPA/WPR are probably the only use…

ETW is the topic of the post titled "The Worst API Ever Made" and the title is well deserved. If ETW tooling is lacking, it's because API is so terrible nobody wants to write tooling. https://caseymuratori.com/blog_0025

There are some good articles in here (recently added) - https://devblogs.microsoft.com/performance-diagnostics/ - but @randomascii's stuff was priceless (I'm still using UIforETW as it's friendliest little ui to setup xperf). I'm still struggling with WPA though (from loading/waiting to load symbols, to sometimes getting right there lost - but often it's helpful).

Visual Studio's own Performance Profiler (Alt+F2, Ctrl+Alt+F2) also uses ETW - just more streamlined, better UI - but once it collects a bit too much data, it just can't handle it.

Re: eBPF on Windows

#120

Post by EvanAnderson »

voidfunc wrote: post #116
pjmlp wrote: post #56

Earlier quoted context omitted.

I do mostly Windows, and given the option would rather keep doing so, however you just reminded me of the "fun" of writing ISAPI extensions on Windows 2000. For those unaware of it, IIS used to execute fully on kernel level, so ISAPI extensions were comparable to device drivers, which meant any programming error would just kill the kernel, thus requiring a reboot. So tracking down memory corruption issues on ISAPI ex…

Goodness, who decided that was a good idea?!

Thr ISAPI modules don't run in kernel mode, but they're in-process with IIS (back in W2K) and it's a bit fraught.

I assumed that kernel-mode HTTP service was an answer by Microsoft to the "Tux" web server: https://en.m.wikipedia.org/wiki/TUX_web_server

Post reply on HN