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

No More Blue Fridays

brendangregg.com

Post reply on HN
Print view View original

231–240 of 282 posts

Re: No More Blue Fridays

#231

Post by pas »

kjellsbells wrote: post #227

Lets suppose that eBPF solves this particular problem, eventually, for Windows. Doesn't sidestepping the entire class of Crowdstrike-style fubars require that Microsoft then mandate that no, backward compatibility will not be offered? Back compat seems to be such a shibboleth in the Windows world, but comes at an incredible price. The reasons cited all seem to boil down to keeping some imagined customers' obscure LOB…

it would be enough if MS offered knobs and switches for admins/devs/vendors to disallow non-static-verified stuff in the kernel

Re: No More Blue Fridays

#232

Post by [deleted] »

shrx wrote: post #18

From the article: > If the verifier finds any unsafe code, the program is rejected and not executed. The verifier is rigorous -- the Linux implementation has over 20,000 lines of code [0] -- with contributions from industry (e.g., Meta, Isovalent, Google) and academia (e.g., Rutgers University, University of Washington). [0] links to https://github.com/torvalds/linux/blob/master/kernel/bpf/ver... which has this inter…

[deleted]

Re: No More Blue Fridays

#233

Post by [deleted] »

joker99 wrote: post #226

I used to work for an EDR vendor and this post glosses over two major and important things. 1. There’s no need for eBPF on windows, it has the ETW framework (event tracing) which is much more powerful and provides applications subscribing to a class of events almost too detailed insights. the issue most AV vendors have with it though is speed. Leading to … 2. eBPF lets you watch. Congrats. It’s something, but it’s no…

[deleted]

Re: No More Blue Fridays

#234

Post by thayne »

joker99 wrote: post #226

I used to work for an EDR vendor and this post glosses over two major and important things. 1. There’s no need for eBPF on windows, it has the ETW framework (event tracing) which is much more powerful and provides applications subscribing to a class of events almost too detailed insights. the issue most AV vendors have with it though is speed. Leading to … 2. eBPF lets you watch. Congrats. It’s something, but it’s no…

> eBPF lets you watch. Congrats. It’s something, but it’s not the reason why these tools are deployed. Orgs deploy these tools to prevent or stop potentially bad stuff from executing

eBPF let's you prevent things too. seccomp filters can block syscalls.

The bigger problem is the performance you mentioned in 1. Crowdstrike's linux agent can work using eBPF instead of a kernel module, and will fall back to that if the current kernel version is more recent than the agent supports. But... then it uses up a lot more CPU.

Re: No More Blue Fridays

#235

Post by 3np »

> The worst thing an eBPF program can do is to merely consume more resources than is desirable, such as CPU cycles and memory.

This is obviously not true. It might be the worst it can do, by itself, to the currently running kernel. It's not the worst it can do to the machine or its user(s).

There are infinite harmful things an eBPF program can do. As can programs solely in user-space. There is a specific class of vulnerabilities being mitigated by moving code from kernel to BPF. That does not mean that eBPF programs are in general safe.

Re: No More Blue Fridays

#236

Post by doctorpangloss »

brendangregg wrote: post #46
mrpippy wrote: post #31

> Once Microsoft's eBPF support for Windows becomes production-ready, Windows security software can be ported to eBPF as well. This doesn’t seem grounded in reality. If you follow the link to the “hooks” that Windows eBPF makes available [1], it’s just for incoming packets and socket operations. IOW, MS is expecting you to use the Berkeley Packet Filter for packet filtering. Not for filtering I/O, or object creation/…

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…

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?

Re: No More Blue Fridays

#237

Post by roenxi »

Analemma_ wrote: post #210
wongarsu wrote: post #188

Earlier quoted context omitted.

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…

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…

Microsoft made the reasonable point that locking 3rd parties out of the kernel might have resulted in legal challenges in the EU [0]. It is an interesting case where everyone is certain in hindsight that they would have been ok with MS blocking access, but it is less obvious that they would have taken that view if MS had pressured a bunch of security products out of the kernel with no obvious prompting.

[0] https://www.theregister.com/2024/07/22/windows_crowdstrike_k...

Re: No More Blue Fridays

#239

Post by [deleted] »

haberman wrote: post #205
muth02446 wrote: post #163

```The verifier is rigorous -- the Linux implementation has over 20,000 lines of code -- with contributions from industry (e.g., Meta, Isovalent, Google) and academia (e.g., Rutgers University, University of Washington). The safety this provides is a key benefit of eBPF, along with heightened security and lower resource usage. ``` Wow, 20k is not exactly encouraging. Besides the extra attack surface, who can vouch fo…

I had exactly the same thought. I don’t know if that 20k number was supposed to inspire confidence, but for me it did the opposite. It would have inspired confidence if it was 300 lines of code. My impression is that the WebAssembly verifier is much simpler.

[deleted]

Re: No More Blue Fridays

#240

Post by supriyo-biswas »

egorfine wrote: post #183

One option to prevent this is to not run corporate spyware. But I guess for some industries this isn't an option.

I don’t understand statements like this. You only need to have some employee install some malware (unintentionally or otherwise); and you have a data breach on your hands.
Post reply on HN