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

eBPF – The Future of Networking and Security

cilium.io

Post reply on HN
Print view View original

31–38 of 38 posts

Re: eBPF – The Future of Networking and Security

#31

Post by rurban »

tgraf wrote: post #7

Disclaimer: I wrote the post. Happy to answer any questions.

At first two annoying lies in the title alone.

The Future of Networking? Networking is not only linux. eBPF is linux-only. Everyone else uses the secure variant dTrace, which has even wide-spread user-space support. So you can trace across the kernel, processes and its extensions/scripts. For decades.

Future of Security? eBPF is insecure. User-accessible arrays in the kernel can never be secure. dTrace did not do that for a reason, it was already compromised with the spectre-like attacks, and the fixes were laughable at best to safe face.

Linux might be advised to do better (or is just NIH?), but advertising Worse as Better was fashionable in the 80ies only.

Re: eBPF – The Future of Networking and Security

#32

Post by ninjha »

I was under the impression that Cilium was one of the more common choices for Kubernetes CNI but judging by the other comments... maybe not?

We’re currently moving to Kubernetes for our infrastructure at the Berkeley OCF (https://ocf.berkeley.edu/), and picked Cilium for all the networking things.

It’s good to see that there’s a company backing it now!

Re: eBPF – The Future of Networking and Security

#33

Post by pjmlp »

teleforce wrote: post #24
tptacek wrote: post #6

Earlier quoted context omitted.

FWIW: I just wrote a long-ish post on the history from BPF (and before BPF) to eBPF and XDP: https://fly.io/blog/bpf-xdp-packet-filters-and-udp/ An interesting fact is that packet filtering as a problem domain has been dominated by in-kernel virtual machines going back into the 1980s; it's an idea that comes all the way from Xerox.

Need to know what's type of water the people at Xerox Palo Alto were drinking. They pioneered many groundbreaking and game changing works on computing including (but not limited to) windowing desktop environment, integrated programming/structural editor with CEDAR/Tioga, SQL (team moved to Oracle), Ethernet networks, laser printer, VLSI and Jupiter operational transform for distributed computing (precursor to CRDT).…

Unfortunately we are still quite far from the safe computing platforms they were using at Xerox (Interlisp-D, Smalltalk, Mesa and Mesa/Cedar).

The best we have gotten so far are the hybrids .NET/Windows, JME, Android Java/Linux, Chrome/Linux, Swift/iOS/macOS.

Re: eBPF – The Future of Networking and Security

#34

Post by tgraf »

rurban wrote: post #31
tgraf wrote: post #7

Disclaimer: I wrote the post. Happy to answer any questions.

At first two annoying lies in the title alone. The Future of Networking? Networking is not only linux. eBPF is linux-only. Everyone else uses the secure variant dTrace, which has even wide-spread user-space support. So you can trace across the kernel, processes and its extensions/scripts. For decades. Future of Security? eBPF is insecure. User-accessible arrays in the kernel can never be secure. dTrace did not do tha…

I personally think that networking will be almost exclusively based Linux in some form. If you want to interpret it as "eBPF - The Future of Linux Networking" then that is totally fine as well. That said, eBPF-based networking can be offloaded to SmartNICs already so it may be less Linux specific than you seem to assume right now.

Comparing dTrace and eBPF is definitely a very interesting question. I've actually asked Brendan Gregg in the Q&A of his keynote at eBPF summit this year how he compares dTrace and eBPF these days. Here is his answer (jumps right to the specific question): https://youtu.be/jw8tEPP6jwQ?t=4618

I doubt that eBPF will remain a Linux-only technology. Ports to FreeBSD are already underway it seems [0] and Microsoft declared intent to invest into eBPF [1]. I'm not sure what that means on timeline for eBPF availability on Windows though. There are also several user space implementations for eBPF which could become interesting to provide a universal programmability approach across traditional kernels like Linux, microkernels like Snap and application kernels like gVisor.

[0] https://papers.freebsd.org/2018/bsdcan/hayakawa-ebpf_impleme... [1] https://twitter.com/markrussinovich/status/12830391539203686...

Re: eBPF – The Future of Networking and Security

#35

Post by tgraf »

silly-silly wrote: post #22
trasz wrote: post #16

Earlier quoted context omitted.

AFAIK BPF wasn’t conceived as anything security-related, it was just an optimization.

From the article: Buggy kernel code will crash your machine. The kernel is not protected from a buggy kernel module. I think people assumed that this is just how things are; that's the price to do kernel programming. eBPF changed this dogma. It brought safety to kernel programming. "It brought safety to kernel programming" , if you use eBPF and don't expose bugs in the parser, or checking or validation systems. (Thes…

Extending a bit on what Alexei is talking about (Full eBPF summit talk: https://youtu.be/jw8tEPP6jwQ?t=639)

Many people seem to make an assumption that kernel code is perfect and that when code is merged into the Linux kernel, it is automatically secure. That is definitely not the case. Kernel developers make mistakes as well and they have devastating consequences.

Right now, the security of the Linux kernel code depends on a combination of code review, fuzzing, controlling the pace of code changes, and running LTS releases to increase the chance others found the bugs already.

eBPF further increases the security model of kernel development by adding a verification step to the model. It means that there is an additional layer of protection in case of code imperfections.

The focus on eBPF safety is awesome. eBPF is software, software will have bugs, eBPF is no exception. The best way to improve the security of software is to question it. Given the wide spread use of eBPF in highly critical and exposed scenarios, the pressure on making it as bug-free as possible is very high so it's probably fair to assume that the scrutiny put in place, will lead to a high quality implementation of the verifier.

Re: eBPF – The Future of Networking and Security

#36

Post by miohtama »

chc4 wrote: post #29
miohtama wrote: post #17

eBPF is also used high throughput blockchain, Solana https://github.com/solana-labs/rbpf Unlike more common Rust + LLVM + WASM toolchain, Solana smart contracts use Rust + LLVM + eBPF.

Solana uses a custom Rust re-implementation of a custom C re-implementation of the Linux BPF VM for what appears to be licensing reasons. Notably, it's jitting all bytecode without a verifier or emitting runtime bounds checks [0]. I suspect you can pop a shell on every single computer on their testnet somewhere between "trivially" and "extremely trivially". They appear to be running some kind of "open security test"[…

Interesting. I am not sure if your comment Without a verifier make sense. Because AFAIK you need to verify the contract only once, when it is deployed. Not every time it is invoked. Verifying a contract should be super cheap compared to executing it, unless eBPF verification is somehow super expensive.

Re: eBPF – The Future of Networking and Security

#37

Post by tptacek »

tgraf wrote: post #35
silly-silly wrote: post #22

Earlier quoted context omitted.

From the article: Buggy kernel code will crash your machine. The kernel is not protected from a buggy kernel module. I think people assumed that this is just how things are; that's the price to do kernel programming. eBPF changed this dogma. It brought safety to kernel programming. "It brought safety to kernel programming" , if you use eBPF and don't expose bugs in the parser, or checking or validation systems. (Thes…

Extending a bit on what Alexei is talking about (Full eBPF summit talk: https://youtu.be/jw8tEPP6jwQ?t=639 ) Many people seem to make an assumption that kernel code is perfect and that when code is merged into the Linux kernel, it is automatically secure. That is definitely not the case. Kernel developers make mistakes as well and they have devastating consequences. Right now, the security of the Linux kernel code de…

BPF has always been statically verified, back to 1991 or whenever.

If anything, eBPF is less sound than classic BPF, because the verifier is dramatically more complicated, as is the execution environment.

Re: eBPF – The Future of Networking and Security

#38

Post by alexgartrell »

codys wrote: post #30
alexgartrell wrote: post #21

Earlier quoted context omitted.

Can you provide more context on why you feel that's true (or even possible)? For the last few years, I managed the Container Runtime group at Facebook. My experience has been: 1. `if (has_capability(..., X)) { ... }` gets put into code pretty haphazardly in a way that's not necessarily super well structured. Once it's there, it's ABI, and you're screwed if you want to iterate on it. That's why cap_sys_admin is /almos…

What POSIX and the linux kernel calls "capabilities" unfortunately result in quite a bit of confusion, which I believe is the cause of your post. POSIX capabilities bear little resemblance to actual capability based security (where a capability is a send/recv-able token that references an object and a set of rights for interacting with that object).

I was not aware of object capabilities -- TIL.

That said, looking at the (apparently) leading implementation, capsicum

> Capsicum also introduces capability mode, which disables (with ECAPMODE) all syscalls that access any kind of global namespace; this is mostly (but not completely) implemented in userspace as a seccomp-bpf filter.

So I do feel that bpf ultimately enables building the kinds of abstractions that people want.

Post reply on HN