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

121–130 of 169 posts

Re: eBPF on Windows

#121

Post by jiggawatts »

DHowett wrote: post #108
jiggawatts wrote: post #40

Earlier quoted context omitted.

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

> 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 some VTY codes or whatever) and I run "Clear-Host", I can scroll back and see content that wasn't cleared.

THIS BREAKS MY WORKFLOW. I used Clear-Host so I can run a command with pages out of output, and then I know that scrolling back will go back to that output only, not something that happened three hours ago but superficially looks identical.

If I do this with PowerShell 5.1 with the old Terminal, it works as expected. It works like it has for the last 40 years of DOS and Windows history.

PS: It's broken even worse in Visual Studio Code.

You guys outright abandoned your user base to pander to Linux users. On Windows. Linux users on Windows. That enormous, huge majority of your paying user base that is apparently more important that the hundreds of millions of people like me.

So yeah, you should reopen the issue and rethink your priorities...

Re: eBPF on Windows

#122

Post by tptacek »

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

This is all super exciting. A weird aside: one thing that'd be really nice to have is a userland verifier that we could build into our CI system; testing verifiability involves a lot of really contrived steps in our current process.

Re: eBPF on Windows

#123

Post by MarkSweep »

sanxiyn wrote: post #105
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.

The ZFS file system supports running Lua programs in Kernel mode. It supports setting a limit on the number of instructions run and the amount of memory used:

https://www.delphix.com/blog/delphix-engineering/zfs-channel...

So it’s been done before. I think traditional BPF programs were really short and ran in performance critical contexts. Disallowing backwards branches and limiting size was preferred to slowing down these code paths with instruction counting.

Re: eBPF on Windows

#124

Post by RulerOf »

jiggawatts wrote: post #121
DHowett wrote: post #108

Earlier quoted context omitted.

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

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

Re: eBPF on Windows

#125

Post by salawat »

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.

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

Re: eBPF on Windows

#126

Post by bztzt »

jaywalk wrote: post #31
hkt wrote: post #23

Earlier quoted context omitted.

One assumes the idea is to make windows have feature parity with linux, then try to leverage network effects for features windows has but linux doesn't, such that the "extinguish" step will follow the "extend" step.

That's called "being better than the competition" and not really what EEE was meant to describe.

I'm not sure there's any crisply definable bright line separating them. Generally embrace/extend strategies do involve trying to make extensions that some people will consider valuable.

Re: eBPF on Windows

#127

Post by MichaelMoser123 »

sanxiyn wrote: post #105
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.

How would you maintain the gas cout? Per instruction or per basic block?

Re: eBPF on Windows

#128

Post by zokula »

skinkestek wrote: post #27
encryptluks2 wrote: post #5

Earlier quoted context omitted.

They implement Linux functionality enough to suck at it and then the Windows users that try it thinks it is Linux that sucks and not Windows.

Let me tell you something interesting: .Net Core programs run much faster on Linux. Does that sound like something they would let happend if they wasn't serious about their Linux efforts? That said: all is not good. For years there seems to be a fight going on in the wheelhouse. One month it is: Microsoft, the reliable, reasonable vendor in a world full of Oracle and Google. Next month it is: let's increase the cost…

Found the Micro$oft fanboy.

Re: eBPF on Windows

#129

Post by corty »

EvanAnderson wrote: post #62
kwdc wrote: post #28

Earlier quoted context omitted.

I won't comment on the eBPF or WSL or even the Windows as linux debate, but I used to do some Windows admin. Some clarifications are in order. MSIs CAN be installed on servers with no gui required. Or much more commonly via powershell automation. Completely remotely and I'm not referring to remote desktop either. I know its fun to complain about Windows, but really, if you're not using powershell and the right tools…

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.

Re: eBPF on Windows

#130

Post by salawat »

sanxiyn wrote: post #107
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.

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

As mentioned in a sibling reply, there goes my week. Thanks for the reference! Time to learn something I apparently did not know!
Post reply on HN