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

81–90 of 282 posts

Re: No More Blue Fridays

#81

Post by brendangregg »

surajrmal wrote: post #73
brendangregg wrote: post #46

Earlier quoted context omitted.

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…

This assumes eBPF becomes the standard. It's not clear Microsoft wants that. They could create something else which integrates with dot net and push for that instead. Also this problem of too much software running in the kernel in an unbounded manner has long existed. Why should Microsoft suddenly invest in solving it on Windows?

Microsoft have been driving the work to make eBPF an IETF industry standard.

Re: No More Blue Fridays

#82

Post by dathinab »

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…

the halting problem is only true for _arbitrary_ programs

but there are always sets of programs for which it is clearly possible to guarantee their termination

e.g. the program `return 1+1;` is guaranteed to halt

e.g. given program like `while condition(&mut state) { ... }` with where `condition()` is guaranteed to halt but otherwise unknown is not guaranteed to halt, but if you turn it into `for _ in 0..1000 { if !condition(&mut state) { break; } ... }` then it is guaranteed to halt after at most 1000 iterations

or in other words eBPF only accepts programs which it can proof will halt in at most maxins "instruction" (through it's more strict then my example, i.e. you would need to unroll the for-loop to make it pass validation)

the thing with programs which are provable halting is that they tend to also not be very convenient to write and/or quite limited in what you can do with them, i.e. they are not suitable as general purpose programming languages at all

Re: No More Blue Fridays

#83

Post by hello_moto »

lordnacho wrote: post #76
hello_moto wrote: post #39

Earlier quoted context omitted.

"find a subset of low risk customers" and use them as test subject? Repeat that a few times to understand the repercussions. If I were the customers and I found out that I was used as test subject, how would I feel?

> If I were the customers and I found out that I was used as test subject, how would I feel? In reality, every business has relationships that it values more than others. If I wasn't paying a lot for it, and if I was running something that wasn't critical (like my side project) then why not? You can price according to what level of service you want to provide.

Customers will ask to opt-out.

Re: No More Blue Fridays

#84

Post by CodeWriter23 »

nine_k wrote: post #77
CodeWriter23 wrote: post #66

> an unprecedented example of the inherent dangers of kernel programming I take issue with that. Kernel programming was not to blame; looking up addresses from a file and accessing those memory locations without any validation is. The same technique would yield the same result at any Ring.

At Ring 3 it would crash an app, not the entire OS. Yes, the kernel is fine and is not to blame. But running basically a rootkit controlled by a third party indeed is to blame.

> At Ring 3 it would crash an app, not the entire OS.

That's still an outage for those key systems.

Re: No More Blue Fridays

#85

Post by lucianbr »

tptacek wrote: post #75
lucianbr wrote: post #63

Earlier quoted context omitted.

Bad wording on my part, and I still don't know how to word it better. I'm sure this thing is useful, I don't think everyone who contributed code was just clueless. However, the claim "in the future, computers will not crash due to bad software updates, even those updates that involve kernel code" must be false. There is no way it is true. Whatever Cilium is, I cannot believe it generally prevents kernel crashes.

The claim isn't that eBPF generally prevents kernel crashes. It's that it prevents crashes in the subset of programs it's designed for, in particular for instrumentation, which Crowdstrike is (in this author's conception) an instance of.

I have quoted the claim verbatim from the article. It is obviously the claim of the article.

Re: No More Blue Fridays

#86

Post by CodeWriter23 »

lucianbr wrote: post #69
CodeWriter23 wrote: post #66

> an unprecedented example of the inherent dangers of kernel programming I take issue with that. Kernel programming was not to blame; looking up addresses from a file and accessing those memory locations without any validation is. The same technique would yield the same result at any Ring.

Obviously in userspace it would only crash the running program and not the entire operating system? It's a significant difference. All of the service interruptions would have been just "computer temporarily not protected by crowdstrike agent". Not the same thing at all.

> It's a significant difference.

When various apps running the world are crashing, unable to execute because malware protection is failing, there is no difference.

Re: No More Blue Fridays

#87

Post by chasil »

twen_ty wrote: post #60

Can someone tell me what's the advantage of eBPF over a user mode driver? The article makes it look it eBPF is have your cake and eat it too solution which is too good to be true? Can you run graphics drivers in eBPF for example?

This is the wiki. I haven't kept up, but this isn't a kernel module.

"eBPF is a technology that can run programs in a privileged context such as the operating system kernel. It is the successor to the Berkeley Packet Filter (BPF, with the "e" originally meaning "extended") filtering mechanism in Linux and is also used in non-networking parts of the Linux kernel as well."

https://en.wikipedia.org/wiki/EBPF

Re: No More Blue Fridays

#88

Post by kevincox »

stackskipton wrote: post #74
shahahqq wrote: post #38

Earlier quoted context omitted.

I hope though that Microsoft will double down on their eBPF support for Windows after this incident.

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…

They aren't over windows. They continue to be incredibly interested in and actively developing how much money they can suck from their users. Especially via various forms of ads.

But yeah, kernel features are few and far between.

Re: No More Blue Fridays

#89

Post by lucianbr »

School-Cotton wrote: post #68
lucianbr wrote: post #63

Earlier quoted context omitted.

Bad wording on my part, and I still don't know how to word it better. I'm sure this thing is useful, I don't think everyone who contributed code was just clueless. However, the claim "in the future, computers will not crash due to bad software updates, even those updates that involve kernel code" must be false. There is no way it is true. Whatever Cilium is, I cannot believe it generally prevents kernel crashes.

Correct, you will never be able to write any possible arbitrary code and have it run in eBPF. It necessarily constrains the class of programs you can write. But the constrained set is still quite useful and probably includes the crowdstrike agent. Also, although this isn't the case now, it's possible to imagine that the verifier could be relaxed to allow a Turing-complete subset of C that supports infinite loops whil…

If the verifier allowed a Turing-complete language, it would solve the halting probem, which is impossible.

Re: No More Blue Fridays

#90

Post by throwaway2037 »

The blog post says:

    > eBPF, which is immune to such crashes.
I tried to Google about this, but I cannot find anything definitive. It looks like you can still break things. Can an expert on eBPF please comment on this claim? This is the best that I could find: https://stackoverflow.com/questions/70403212/why-is-ebpf-sai...
Post reply on HN