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

101–110 of 169 posts

Re: eBPF on Windows

#101

Post by GordonS »

Someone1234 wrote: post #85
GordonS wrote: post #49

Wow, I'm really stoked to see this! This could be a game-changer for the infosec community in particular - now, if you want to get into internals, such as tracing file system and registry calls, you've got to write drivers. And drivers are very tricky to write, and it's very easy to miss corner cases - which can result in the dreaded BSOD. Plus, drivers need to go through a verification and signing process by Microso…

Everything you described is already available on Windows in userland via filters (FileSystemWatcher/ReadDirectoryChangesW, RegNotifyChangeKeyValue, et al). Obviously you can only monitor whatever lives in your security context. eBPF looks cool since it is a VM, that could have access to more kernel structures (network?), but solving the issues you described is largely a solved problem on the platform.

Nope, with FileSystemWatcher (and the Windows APIs it uses under the hood) you get minimal information - only using a driver can you get contextual information, such as the handle of the thread, process and user that made the call.

And RegNotifyChangeKeyValue is only useful for watching a single, specific value - if you monitor a tree, it doesn't even tell you what changed, only that something matching the filter did. And as with file system changes, if you want to know which thread/process/user made the change, you need to use a driver.

Re: eBPF on Windows

#102

Post by rasputnik6502 »

Agingcoder wrote: post #77
agumonkey wrote: post #63

Earlier quoted context omitted.

were powershell designers from the unix world ? I didn't know that I don't mind bash warts, history is what it is, I don't sell powershell .. but someone saying powershell is confusing has serious jaws. powershell is really nice and only if you fancy sed/grep everything then you'll consider bash* superior

I don't think I want to compare them - I dislike them both! One is too basic and cryptic, the other one is overly complex for a shell, and in the end, I want to use neither. I'm not sure what the ideal shell would look like though. Maybe an actual (simple and expressive) programming language with a way to 'lift' statements ?

The situation gets worse every year with multitude new commanline utilities and scripts being created as part of new frameworks, languages and tools. And then everything gets mixed together to form some unstable, ever changing, inconsistent programming language.

Re: eBPF on Windows

#103

Post by lunfard00 »

majkinetor wrote: post #55
agumonkey wrote: post #44

Earlier quoted context omitted.

> Powershell is apparently pretty modern and well designed, but it's quite confusing if you're used to Unix. bash is pretty confusing eve if you're used to unix -- Greg's

Bash is simply outdated. It grown organically and thats what you got. Now you have zillion scripts and situation is even worst then with cobol. PowerShell was made by Unix people after 2+ decades of bash experience. It solved hundreds of things. Yet people complain it didn't solve few or it takes a bit more to load (no, verbosity = RTFM). You can't ever please I guess.

Writing powershell scripts on vscode with the ps plugin is quite pleasant. Would recommend everyone to try it.

Re: eBPF on Windows

#104

Post by salawat »

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.

Re: eBPF on Windows

#105

Post by sanxiyn »

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…

Re: termination, can't you use Ethereum gas style termination? I always found termination verification strange, because "gas" is usually more practical alternative.

Re: eBPF on Windows

#106

Post by gerdesj »

majkinetor wrote: post #46
pjc50 wrote: post #42

Earlier quoted context omitted.

> Everything you complain about Windows Server not supporting is actually supported, but it was your unfamiliarity that was ultimately the issue. Funny, I've seen people saying exactly that when newbies bounce off some aspect of Linux, and in both cases it's a usability failure. Discoverability of this stuff on Windows is terrible . Things like powershell remoting exist but getting them working between two random mac…

Its trivial without domain TBH. If on workgroup, you just have to have the same user name on different machine and it works like in domain. > Discoverability of this stuff on Windows is terrible Meh... matter of taste and adequate Windows social skills, not a fact.

"If on workgroup, you just have to have the same user name on different machine and it works like in domain"

... and password. ... and no it doesn't really because an AD has a few other extras, such as Kerberos and an LDAP database with some odd ideas to chat to. You can of course spin up a Samba AD DC or two for a cheaper alternative.

Re: eBPF on Windows

#107

Post by sanxiyn »

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.

Microsoft did termination proof for Windows drivers in 2006. Termination proof does not require solving halting problem.

Termination proofs for systems code (PLDI 2006): https://dl.acm.org/doi/10.1145/1133255.1134029

Re: eBPF on Windows

#108

Post by DHowett »

jiggawatts wrote: post #40
jaywalk wrote: post #21

Earlier quoted context omitted.

I like Windows Server more than Linux. I administer both of them, although I am more familiar with Windows Server which definitely plays a big part in my preference. But I think that's going to be the biggest part of anyone's preference. Everything you complain about Windows Server not supporting is actually supported, but it was your unfamiliarity that was ultimately the issue. "Linux guy who is unfamiliar with Wind…

"When in Rome, do as the Romans do." I don't complain that Linux is hard to administer with PowerShell. I learned SSH and Bash. The reverse does not seem to be true, Linux admins generally expect everything to work exactly the same in Windows as in Linux. A negative effect of this is that Windows has many recent hires working on some of their teams with mostly Linux experience, and they're copying Linuxisms into Wind…

> A recent example that boiled my blood is that the new Windows Terminal emulates the incorrect "Clear-Host" behaviour of ancient Linux terminals.

Hi! I run the team who made this decision, and I flatly reject the characterization that these changes were made by "recent hires" who are "copying Linuxisms into Windows bug-for-bug."

The discussion you're referring to spans multiple threads, so I'm not certain the exact one you're referring to. I can, however, give some of my input:

1. We worked pretty hard to make sure that PowerShell's Clear-Host and CMD's "CLS", which operate on the entire scrollback buffer in the traditional console, are properly translated into a full buffer clear over SSH/in Terminal/etc.

2. Terminal fully supports CSI 3 J, a non-standard extension to the Erase in Display control sequence that clears the scrollback buffer. The handful of tools I am using that support "clear" actually seem to emit both "clear viewport" and "clear buffer." If you're using a version of clear that has been configured to NOT emit ED 3 (clear scrollback history) by default, that's simply not my team's fault. I've heard that you can use "clear -x" to affect your desired behavior.

It turns out that there being no true standard here plays to our advantage: we can support requests for all manner of clear, and trust that an application can be made to do the right thing. If you're using an application that can't be made to do the right thing per at least thirty other terminal emulators' designs--spanning more than just Windows and Linux, mind you--I apologize.

If you'd like to reopen that discussion here instead of on GitHub, you are more than welcome to.

Re: eBPF on Windows

#109

Post by tptacek »

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.

BPF verifiers don't accept arbitrary programs.

Re: eBPF on Windows

#110

Post by tptacek »

joestringer wrote: post #100
tptacek wrote: post #35

Earlier quoted context omitted.

You can do a lot more in NDIS and probably more in WFP than you can in eBPF, if only because eBPF has strict limits on the kinds of loops you can express (they have to be verifiably bounded). Packet-processing BPF programs are tightly bound to Linux kernel APIs, many of which won't be ported here, so I think write-once-run-anywhere is unlikely to be an attribute of this. Importantly: eBPF has at this point not much t…

The packet-processing BPF programs are less tightly bound to Linux kernel APIs than you might think. Even in Linux, there has been motivation to make the APIs more generic to support different kernel hooks for packets, in particular XDP which doesn't operate on the standard internal packet buffer representation (skbuff).

Microsoft doesn't support XDP, do they?(And you can only use XDP on Linux in certain circumstances). The clsbpf stuff is all pretty heavily tied to skbs.

Also, even in an XDP program, you're still likely to use a bunch of perf stuff, which is again pretty Linux-specific.

Post reply on HN