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

eBPF Verification Is Untenable

twitter.com

Post reply on HN
Print view View original

21–30 of 116 posts

Re: eBPF Verification Is Untenable

#21

Post by insanitybit »

dathinab wrote: post #4

I hope no one tries to use the rust "safety" guarantees for security guards. They are designed to prevent bugs not intentional abuse. If perfect without bugs they theoretically might be usable for security guards, but it's not where priorities lies when it comes to bug fixes and design. And people mistaking rust safety + no unsafe lint for "security against evil code" could be long term quite an issue for rust in var…

They didn't mistake rust safety for anything. This is called out by them as a shrotcoming of their approach that has to be mitigated separately.

Re: eBPF Verification Is Untenable

#22

Post by cryptonector »

mananaysiempre wrote: post #2

Hm. Doesn’t look viable to me. I’m not against language-based security, proof-carrying code, and all that, but I have less than perfect confidence that the Rust compiler currently is or will soon be sound enough to be secure against actively hostile code—AFAIU the language designers haven’t even written down their core calculus, let alone proven it sound. Putting the entirety of the Rust compiler (including, at least…

OK then! Back to C it is I guess. More seriously, we're talking about the Linux kernel here: it's written in C, and there's some momentum to write new code in Rust. You're asking for the moon, but you may have to settle for a picture of it.

Re: eBPF Verification Is Untenable

#23

Post by stefan_ »

tptacek wrote: post #14

This paper is an easy read, but it's basically just restating the premises of eBPF: * Most programs can't be expressed in verified eBPF. * The verifier functions, to the extent it does, in large part by rejecting most programs (and implicitly limiting the uses to which eBPF can be put). * This is "extension code", and by definition, it interacts with the unsafe, unverified C code that the kernel is built out of. (In…

Surely if you are allowing non-root eBPF then security of the programs is one of your least worries? Given all the implicit privilege escalation that comes with allowing non-root to spy on everything the kernel does.

Re: eBPF Verification Is Untenable

#24

Post by nightowl_games »

When I read about eBPF for kernel extension, it immediately made me think it would be full of security problems. I don't even know anything about the kernel, eBPF validation and barely anything about security, but just from a theoretical level, it seems highly insecure to run someone else's code in the kernel. "Verifying" it seems impossible from a theoretical level. Am I wrong? What's the limits of security in eBPF kernel extensions?

Re: eBPF Verification Is Untenable

#25

Post by lcvw »

nightowl_games wrote: post #24

When I read about eBPF for kernel extension, it immediately made me think it would be full of security problems. I don't even know anything about the kernel, eBPF validation and barely anything about security, but just from a theoretical level, it seems highly insecure to run someone else's code in the kernel. "Verifying" it seems impossible from a theoretical level. Am I wrong? What's the limits of security in eBPF…

1. Using eBPF requires root

2. The verifier checks memory bounds access, guarantees termination in a certain number of instructions, and restricts function calls to a limited number of helper functions provided by the kernel.

3. BPF code runs on a vm, think like the jvm. It’s impossible to express a lot of nasty stuff given the restrictive bytecode language.

There have been bugs in the verifier, but overall it works very well, the biggest issue being that it drastically limits the complexity of your program.

Re: eBPF Verification Is Untenable

#26

Post by andrewflnr »

I haven't been following the eBPF situation for a while, but... how did it come to this? I thought the point of BPF (sans 'e' anyway) was that it was pretty much secure by construction, or at minimum was simple enough to fully verify in polynomial time. So these eBPF vulnerabilities sound like a completely invented, unnecessary class of problems.

Re: eBPF Verification Is Untenable

#27

Post by lcvw »

insanitybit wrote: post #11

First off, I kinda skimmed this. So I think the critical thing here is that verification is not enough . It has to be the critical thing, because the implementation in the kernel might suck but Microsoft has shown that it's possible to build a powerful eBPF verifier that isn't a hacky mess. The main issue is seemingly these helper functions. The position is that even a perfectly verified program won't be safe because…

It’s worth noting the verifier doesn’t verify C code, it verifies the compiled ebpf bytecode. You can generate that bytecode from rust (the solana cryptocurrency does this) but you still need to verify the actual instructions since someone can just write whatever they want by hand.

Re: eBPF Verification Is Untenable

#28

Post by zyedidia »

dathinab wrote: post #4

I hope no one tries to use the rust "safety" guarantees for security guards. They are designed to prevent bugs not intentional abuse. If perfect without bugs they theoretically might be usable for security guards, but it's not where priorities lies when it comes to bug fixes and design. And people mistaking rust safety + no unsafe lint for "security against evil code" could be long term quite an issue for rust in var…

I agree -- relying on Safe Rust's "guarantees" for security purposes is very likely to be problematic. To make the reasons concrete: for the last 4 years rustc has had a bug that allows writing transmute (arbitrary type conversion) without the use of unsafe: https://zyedidia.github.io/blog/posts/5-safe-transmute/. This is one of the 77 current open unsoundness bugs on the Rust issue tracker. To make this tenable you would probably have to use a separate language -- maybe some formally-verified minimal Rust-like language, and with different priorities from a people perspective.

Re: eBPF Verification Is Untenable

#29

Post by lcvw »

I feel that this proposal defeats the entire purpose of ebpf. The point is to have a bytecode language that can do simple processing in the kernel. This code is frequently generated adhoc, such as with bpftrace. I don’t like all the limitations that currently exist in bpf, but just replacing it with rust and signature verification basically turns this into kernel modules all over again.

Re: eBPF Verification Is Untenable

#30

Post by skywhopper »

wzdd wrote: post #3

This is weird. 1. Instead of having the kernel verify the program about to be installed at installation time, they rely on a trusted compiler and having the kernel perform signature validation. This means that the kernel is relying on a userspace component to enforce kernel-level safety guarantees, adds another level of coupling (via key infrastructure) between the kernel and a particular version of the Rust compiler…

In re 1, the system operator could configure the kernel to trust their signing key, and build the extensions themselves, which is still highly complex but would minimize the risk of a general compromise.

That said, I agree in general that this approach is mostly going backwards and fails to address the core risks. It’s also important to push back on the Rust-as-security-panacea meme. Rust prevents a certain class of bugs, but it doesn’t ensure reliable operation.

Post reply on HN