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

A Beginner's Guide to eBPF

github.com

Post reply on HN
Print view View original

71–78 of 78 posts

Re: A Beginner's Guide to eBPF

#71

Post by tptacek »

autoexec wrote: post #29
yawnxyz wrote: post #18

Earlier quoted context omitted.

The joke is you have to give them all your information in a form to then download some B2B report... rather than add two sentences about what ePBF is

Seriously. I really don't know why people think that's acceptable. Who sees a website titled "A beginner's guide to X" that makes people hand over their data to even get "X" defined, and thinks "This looks good to me! Sign me up!"

This is a Github repository accompanying a book. Neither of those things were submitted here by their author. A real problem HN has sometimes is treating the entire Internet as if it was was written for HN specifically.

Re: A Beginner's Guide to eBPF

#72

Post by tptacek »

anonymousDan wrote: post #37

As I understand it, eBPF is primarily an observation tool and thus is quite limited in the modifications it can make to kernel memory. Does it have any generic way to make arbitrary modifications to kernel memory? Obviously this would invalidate any verification guarantees, but I would expect this to be very minor modifications in practice. For example, if I wanted to hook a page fault handler to change the behaviour…

eBPF has pretty significant latitude with network traffic, but for everything else the idiom is to use it to do fast kernel telemetry to a userland process that does the actual acting.

Re: A Beginner's Guide to eBPF

#73

Post by guenthert »

kqr wrote: post #61
blipvert wrote: post #49

Earlier quoted context omitted.

You need to slightly modify your code. Rather than: while (condition) { … } Do: #define MAX 1000 for n = 0; n Unroll all loops, don’t allow any backward jumps and limit to (say) 1m instructions.

Incidentally, iteration limits are a good idea for production code anyway. If you don't imagine any input needing more than 50 k iterations, throw a user-friendly exception after something like 10 M iterations. Prevents much more annoying problems than it causes.

> If you don't imagine any input needing more than 50 k iterations

What could possibly go wrong.

Re: A Beginner's Guide to eBPF

#74

Post by kqr »

guenthert wrote: post #73
kqr wrote: post #61

Earlier quoted context omitted.

Incidentally, iteration limits are a good idea for production code anyway. If you don't imagine any input needing more than 50 k iterations, throw a user-friendly exception after something like 10 M iterations. Prevents much more annoying problems than it causes.

> If you don't imagine any input needing more than 50 k iterations What could possibly go wrong.

You get an error is the worst that happens.

Way better than running a denial of service attack on your own systems or those of your customer's.

Re: A Beginner's Guide to eBPF

#75

Post by [deleted] »

kqr wrote: post #74
guenthert wrote: post #73

Earlier quoted context omitted.

> If you don't imagine any input needing more than 50 k iterations What could possibly go wrong.

You get an error is the worst that happens. Way better than running a denial of service attack on your own systems or those of your customer's.

[deleted]

Re: A Beginner's Guide to eBPF

#76

Post by guenthert »

kqr wrote: post #74
guenthert wrote: post #73

Earlier quoted context omitted.

> If you don't imagine any input needing more than 50 k iterations What could possibly go wrong.

You get an error is the worst that happens. Way better than running a denial of service attack on your own systems or those of your customer's.

> You get an error is the worst that happens.

That certainly depends on what eBPF is used for. If your load balancer errors out at [greatest number of connections envisioned] and an adversary manages to establish [greatest number of connections envisioned] then the result is a denial of service.

Not every operator is confident in making code changes in 3rd party software or might even be allowed to make such changes. Increasing resources o.t.o.h., e.g. adding RAM, is rarely banned. I sure would want a system to make best use of available resources.

Re: A Beginner's Guide to eBPF

#77

Post by kqr »

guenthert wrote: post #76
kqr wrote: post #74

Earlier quoted context omitted.

You get an error is the worst that happens. Way better than running a denial of service attack on your own systems or those of your customer's.

> You get an error is the worst that happens. That certainly depends on what eBPF is used for. If your load balancer errors out at [greatest number of connections envisioned] and an adversary manages to establish [greatest number of connections envisioned] then the result is a denial of service. Not every operator is confident in making code changes in 3rd party software or might even be allowed to make such changes.…

I still think a denial of service due to tripping some sort of circuit breaker is preferable to one due to resource exhaustion.

If the code is intended to use as a library or the binary distributed to third parties one will have to handle it differently. For libraries taking a parameter indicating the maximum expected is common, for example. See e.g. man 3 read.

Re: A Beginner's Guide to eBPF

#78

Post by jooz »

compared to making a module, apart the fact that the module can end in kernel panic (thats my problem), is there any significance performance difference between BPF and kernel modules ?

If my goal is to reduce the cpu cloud bill, is BPF good enough compared to making a kernel module ?

Post reply on HN