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

131–140 of 169 posts

Re: eBPF on Windows

#131

Post by tptacek »

roblabla wrote: post #73
tptacek wrote: post #38

Earlier quoted context omitted.

Windows already has a native system call filter, doesn't it?

I don't think so? I actually looked for such functionality recently and couldn't find anything. Kaspersky uses a hypervisor to hook syscalls[0] in order to provide such functionality. There's also DTrace for Windows[1], but that requires being enabled through bcdedit which is a bit... meh. [0]: https://github.com/iPower/KasperskyHook [1]: https://docs.microsoft.com/en-us/windows-hardware/drivers/de...

I'm thinking of the win32k.sys filter, which, my Windows-literate friends inform me, only blocks a subset (a gnarly subset, but a subset still) of the total kernel attack surface; it's not a general-purpose filter.

Re: eBPF on Windows

#132

Post by hinkley »

staticassertion wrote: post #25
morelisp wrote: post #8

I see we're now firmly on the "extend" step.

No, this would just be embrace, they have not extended the ebpf capabilities. It would be "extend" if there were one way comparability, which doesn't seem to be the case.

If they patent ways to analyze more complex eBPF programs that would be extend in a very literal sense of the term.

Re: eBPF on Windows

#133

Post by EvanAnderson »

corty wrote: post #129
EvanAnderson wrote: post #62

Earlier quoted context omitted.

I can't imagine how anybody manages any number of Windows machines w/o a domain. Even just an NT 4.0-style "downlevel" domain (hosted with Samba, if need be) made life so much easier "back in the day". Once Active Directory came out I never looked back. Group Policy makes so many Windows administration tasks reproducible and automated. I keep meaning, year after year, to take at Samba and see how its Active Directory…

Group policy "automation" is painful and inconsistent. Parts are only applied on user login. Parts only on reboot. Parts instantly. Hard to impossible to know which is which. And no way to log off users or reboot machines via group policy, so you need remote logins anyways.

I'd argue it's just being familiar with the tools. I'm biased, no doubt. Windows sysadmin work has paid the lion's share of my bills since the late 90s.

I've been using Group Policy heavily since 1999 (during the Windows 2000 beta), so I'm used to knowing what applies when. Being familiar with which client-side extensions (CSEs) do which processing helps. The documentation for Microsoft's own functionality is reasonably good. Third-party software is a mixed bag.

Remotely rebooting machines is easy. There has been a remote shutdown API in Windows NT since the at least Windows NT 4.0 (and probably going all the way back to the beginning). Since Windows 2003 there has been a command line tool included to actually use the API. Likewise, there are command line methods to remotely logoff users, refresh Group Policy, etc.

Re: eBPF on Windows

#134

Post by jiggawatts »

RulerOf wrote: post #124
jiggawatts wrote: post #121

Earlier quoted context omitted.

> 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." Hi! I see Microsoft people on "docs.microsoft.com" use forward slashes now in examples that only work on Windows. So, there's that . If I open the latest version of Windows Terminal, running PowerShell Core (not some Bash thing with…

>You guys outright abandoned you user base to pander to Linux users. On Windows. Linux users on Windows. IMO they're going after developers using Macs. Linux (and Docker) runs better on Windows than it does on Mac OS. They're doing _something_ right.

So you're saying that Linux developers on Macs are now Microsoft's target market?

Not Windows developers on Windows?

Re: eBPF on Windows

#135

Post by pjmlp »

jiggawatts wrote: post #134
RulerOf wrote: post #124

Earlier quoted context omitted.

>You guys outright abandoned you user base to pander to Linux users. On Windows. Linux users on Windows. IMO they're going after developers using Macs. Linux (and Docker) runs better on Windows than it does on Mac OS. They're doing _something_ right.

So you're saying that Linux developers on Macs are now Microsoft's target market? Not Windows developers on Windows?

Basically it feels like going after the SV crowd coding with macs on starbucks.

Re: eBPF on Windows

#136

Post by dataflow »

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…

If all you want is user-mode tracing, there's ETW. Where you run into problems is that it doesn't let you block on calls, etc.

Re: eBPF on Windows

#137

Post by coolspot »

dang wrote: post #61
coolspot wrote: post #2

And that is, kids, how MS Windows piece-by-piece was slowly transformed into a Linux distro.

" Eschew flamebait. Avoid unrelated controversies and generic tangents. " https://news.ycombinator.com/newsguidelines.html Comments like this one take threads in predictable, uninteresting directions, and—what's worse—they often get upvoted, accumulating mass at the top of the thread and choking out the specific interesting stuff. "Windows v Linux" is a classic example of a generic black hole, sucking passing spacesh…

Oops, sorry about that!

Intention was to highlight how MS, that fought with *nix tooth and nail, now they are adopting more and more ideas from *nix, basically moving towards being best enterprise Linux.

Re: eBPF on Windows

#138

Post by alexeldeib »

salawat wrote: post #125
salawat wrote: post #104

Earlier quoted context omitted.

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

Awww shit. I knew this day would come. Be back in like a week. Gotta get my neurons warmed up and translating Theoretic CompSci/discrete math notation again. If I don't come back send a search party. I'll probably be stuck somewhere around pumping lemmas screaming "This is arbitrary bullshit!"

It’s not magic, just constraints. there are some obvious tricks (which have since been relaxed).

No unbounded loops for one. I think no backward jumps was previously a rule? I think the ability to tail call another bpf program was added, so not sure if you can accidentally loop forever between individually terminating programs.

Re: eBPF on Windows

#139

Post by Genbox »

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…

Sysinternal's Process Monitor does that from a process perspective: https://docs.microsoft.com/en-us/sysinternals/downloads/proc...

There is also System Monitor which logs the events to EventLog: https://docs.microsoft.com/en-us/sysinternals/downloads/sysm...

Are those not enough?

Re: eBPF on Windows

#140

Post by tptacek »

alexeldeib wrote: post #138
salawat wrote: post #125

Earlier quoted context omitted.

Awww shit. I knew this day would come. Be back in like a week. Gotta get my neurons warmed up and translating Theoretic CompSci/discrete math notation again. If I don't come back send a search party. I'll probably be stuck somewhere around pumping lemmas screaming "This is arbitrary bullshit!"

It’s not magic, just constraints. there are some obvious tricks (which have since been relaxed). No unbounded loops for one. I think no backward jumps was previously a rule? I think the ability to tail call another bpf program was added, so not sure if you can accidentally loop forever between individually terminating programs.

You can't; each program is verified independently, and there's a small limit to the number of tail calls you can do.

Being able to run an unbounded loop in eBPF would be a big deal (doesn't mean it can't be done; in fact: it almost surely can be) --- a serious vulnerability.

Post reply on HN