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

61–70 of 78 posts

Re: A Beginner's Guide to eBPF

#61

Post by kqr »

blipvert wrote: post #49
diarrhea wrote: post #30

Earlier quoted context omitted.

Reading more about that… How does the verifier detect infinite loops anyway? Halting problem and all. It must use some rather crude heuristics, no?

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.

Re: A Beginner's Guide to eBPF

#62

Post by vocram »

kqr wrote: post #59
cassianoleal wrote: post #54

Earlier quoted context omitted.

Why would your cloud instance panicking affect other users of the cloud provider? Or do you mean something else?

Cloud goes beyond rented VMs. Fully managed cloud services have thousands or millions of production customers on the same node. They have to be very careful about what they run as root.

I understand your point, but millions sounds an exaggeration- I have a hard time believing a single node can handle millions of concurrent users

Re: A Beginner's Guide to eBPF

#63

Post by kqr »

vocram wrote: post #62
kqr wrote: post #59

Earlier quoted context omitted.

Cloud goes beyond rented VMs. Fully managed cloud services have thousands or millions of production customers on the same node. They have to be very careful about what they run as root.

I understand your point, but millions sounds an exaggeration- I have a hard time believing a single node can handle millions of concurrent users

I didn't mean to imply concurrent. A large fraction of the user base is very sporadic in its usage!

Re: A Beginner's Guide to eBPF

#66

Post by blipvert »

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.

Nice. Be good if the language had an easy way to handle it, eg.:

while(condition)[1000 label]{…}

Re: A Beginner's Guide to eBPF

#67

Post by anonymousDan »

madog wrote: post #44
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…

What you can do is quite limited. You're restricted to some preset eBPF program types, and each program type has a restricted set of operations it can perform (eBPF helper methods). So arbitrary modifications, absolutely not without adding a helper method and/or program type for this purpose. More program types and helper methods are being added all the time but overall it's pretty limited in use cases and operations…

Right, that's what I thought. So at a high level helper methods are equivalent in some sense to 'unsafe' code in rust and require manual validation for security (i.e. the verifier ignores them other than to check they are in some helper method whitelist for the program type)?

Re: A Beginner's Guide to eBPF

#68

Post by vocram »

kqr wrote: post #63
vocram wrote: post #62

Earlier quoted context omitted.

I understand your point, but millions sounds an exaggeration- I have a hard time believing a single node can handle millions of concurrent users

I didn't mean to imply concurrent. A large fraction of the user base is very sporadic in its usage!

Thanks for clarifying :)

Re: A Beginner's Guide to eBPF

#69

Post by tptacek »

awesomegoat_com wrote: post #39
Paul-Craft wrote: post #10

This may prove useful: > eBPF (often aliased BPF)[2][5] is a technology that can run sandboxed programs in a privileged context such as the operating system kernel.[6] It is used to safely and efficiently extend the capabilities of the kernel at runtime without requiring to change kernel source code or load kernel modules.[7] Safety is provided through an in-kernel verifier which performs static code analysis and rej…

Haven't sandboxed programs in a privileged context been the root cause of me seeing BSOD so often in the late 90ties?

This is a different kind of sandbox. BPF functions by drastically limiting the shape of the control flow graph that will be accepted for a program; most working C functions will not be accepted in a BPF program. The simplest example (complexified by more recent BPF verifier work that relaxes this... somewhat) is that BPF programs can't have loops, at least in the sense that a normal program can.

You can crash a kernel with a BPF program. But it's overwhelmingly likely that the crash will arise from buggy pre-existing kernel code that just hadn't been seriously exercised before eBPF gave people new tools to push that code with. What's much, much less likely to happen is a segfault or NPE in your own BPF code.

Re: A Beginner's Guide to eBPF

#70

Post by tptacek »

cookiengineer wrote: post #24
DethNinja wrote: post #15

I’m new to Linux kernel programming & eBPF (just started last week) and I’m having major troubles with eBPF verifier. I honestly feel like it would be easier for me to write a kernel module than eBPF code. I do wonder if this is the case for many people. It seems verifier is a bit unpredictable and makes eBPF programming quite painful.

Can confirm, it is quite painful. The bpftools maintainers tell you to learn the bytecode format when you ask them what the errors mean, because they expect you to understand what the verifier means when it tells you "unknown scalar" on every single goddamn line of code. Something like "ebpf coding rules, what to use and what not" would be very helpful. All ebpf examples that are older than say, 3 months, already don…

I mean, the flip side of this is: do you really expect people on a mailing list to debug your custom XDP code for you? You get what you pay for, and you can pay people to help you with this stuff, or not.
Post reply on HN