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

131–140 of 282 posts

Re: No More Blue Fridays

#131

Post by MetaWhirledPeas »

uticus wrote: post #121

> eBPF programs cannot crash the entire system because they are safety-checked by a software verifier and are effectively run in a sandbox. Isn’t one of the purposes of an OS to police software? I get that this has to do with the OS itself, but what does watching the watchers accomplish other than adding a layer which must then be watched? Why not reduce complexity instead of naively trusting that the new complexity…

Right? I might spend a few minutes seeing if an AI chatbot can explain all the justifications that lead to using something like CrowdStrike in the first place.

Re: No More Blue Fridays

#132

Post by lizxrice »

red_admiral wrote: post #93
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…

eBPF is not Turing-complete, I suppose.

In this talk we demo Conway's Game of Life implemented in eBPF: https://www.youtube.com/watch?v=tClsqnZMN6I

Re: No More Blue Fridays

#133

Post by whynotminot »

hello_moto wrote: post #71
whynotminot wrote: post #51

Earlier quoted context omitted.

Canary deployments are already an industry accepted practice and it’s shocking Crowdstrike apparently doesn’t do them.

Which industry? Cybersecurity or Cloud software?

Any industry that wants to reliably deliver software that doesn’t brick systems at scale? I’m confused by your question.

Are you telling me the cybersecurity scene is special and shouldn’t follow best practices for software deployment?

Re: No More Blue Fridays

#134

Post by SoftTalker »

aksdlf wrote: post #35
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…

I'm glad to hear that Meta and Google code is "rigorous". I'd prefer INRIA, universities that fund theorem provers, industries where correctness matters like aerospace or semiconductors.

Also that lines of code is a proxy for rigor, something new I learned today. /s

Re: No More Blue Fridays

#135

Post by marcosdumay »

throwaway2037 wrote: post #94
stackskipton wrote: post #74

Earlier quoted context omitted.

Doubt it. Microsoft is clearly over Windows. They continue to produce it but every release feels like "Ugh, fine, since you are paying me a ton of money." Internally, Microsoft is running more and more workloads on Linux and externally, I've had .Net team tell me more than once that Linux is preferred environment for .Net. SQL Server team continues to push hard for Linux compatibility with every release. EDIT: Window…

This claim about SQL Server: Is it due to disk access being slower from NT kernel compared to Linux kernel?

There's something very wrong with Windows disk access, you can see it easily by trying to run a Windows desktop with rotating disks.

But SQL Server is in the unique position of being able to optimize Windows for their own needs. So they shouldn't have this kind of problem.

Re: No More Blue Fridays

#136

Post by mauvehaus »

nullindividual wrote: post #104
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/…

Microsoft already has an extensible file system filter capability in place, which is what current AV uses. Does it make sense to add eBPF on top of that and if so, are there any performance downsides, like we see with file system filters?

They've done a technology transition once already from legacy file system filter drivers to the minifilter model. If they see enough benefit to another change, it wouldn't be unprecedented.

Mind you, it looks like after 20-ish years Windows still supports loading legacy filter drivers. Given the considerable work that goes into getting even a simple filesystem minifilter driver working reliably, it's safe to assume that we'd be looking at a similarly protracted transition period.

As to the performance, I don't think the raw infrastructure to support minifilters is the major performance hit. The work the drivers themselves end up doing tends to be the bigger hit in my experience.

Some background for the curious:

https://www.osr.com/nt-insider/2019-issue1/the-state-of-wind...

Re: No More Blue Fridays

#137

Post by javierhonduco »

red_admiral wrote: post #93
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…

eBPF is not Turing-complete, I suppose.

It is not, programs that are accepted are proved to terminate. Large and more complex programs are accepted by BPF as of now, which might give the impression that it's now Turing complete, when it is definitely not the case.

Re: No More Blue Fridays

#138

Post by lucianbr »

michaelt wrote: post #105
lucianbr wrote: post #50

Earlier quoted context omitted.

It's casually claiming to have solved the halting problem, at least within some limited but useful context. That should be impossible, and it turns out, it is. I expect it can be solved within some limited contexts, but those contexts are not useful, at least not at the level of "generic kernel code".

eBPF started out as Berkeley Packet Filters. People wanted to be able to set up complex packet filters. Things like 'udp and src host 192.168.0.3 and udp[4:2]=0x0034 and udp[8:2]=0x0000 and udp[12]=0x01 and udp[18:2]=0x0001 and not src port 3956' So BPF introduced a very limited bytecode, which is complex enough that it can express long filters with lots of and/or/brackets - but which is limited enough it's easy to c…

Did you read the article? It says computers will not crash in the future due to updates. It literally says that in the very first line of the article.

> In the future, computers will not crash due to bad software updates, even those updates that involve kernel code. In the future, these updates will push eBPF code.

What you are claiming is completely different. A kind of "firewall" for syscalls. But updates to drivers and software must contain code and data. The author is not talking about updates to the firewall between drivers and the kernel, they talk about updating drivers themselves. It literally says "updates that involve kernel code". Will the kernel only consist of eBPF filtering bytecode? How could that possibly work?

Re: No More Blue Fridays

#140

Post by hello_moto »

whynotminot wrote: post #133
hello_moto wrote: post #71

Earlier quoted context omitted.

Which industry? Cybersecurity or Cloud software?

Any industry that wants to reliably deliver software that doesn’t brick systems at scale? I’m confused by your question. Are you telling me the cybersecurity scene is special and shouldn’t follow best practices for software deployment?

Canary deployment for subset of Salesforce customers won't see much of revolt from customers compare to AV definition rollout (not software, but AV definition) in Cybersecurity where gaps between 0day and rollout means you're exposed.

If customers found out that some are getting roll out faster than the others, essentially splitting the group into 2, there will be a need for customer opt-in/opt-out.

If everyone is opting-out because of Friday, your Canary deployment becomes meaningless.

Any proof that other Cybersecurity vendors do Canary deployment for their AV definition? :)

PS: not to say that the company should test more internally...

Post reply on HN