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

91–100 of 116 posts

Re: eBPF Verification Is Untenable

#91

Post by eqvinox »

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

> 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, and if some…

> FWIW I'm pretty sure this is how Microsoft does it. Verifier is in userland and signs programs post-verification.

Almost. Yes the verifier is in userland, but it doesn't sign things — it's a trusted component of the system, there's no need for a signature on this step. It simply says "OK". But the verifier itself is covered by the usual system integrity mechanisms.

Re: eBPF Verification Is Untenable

#92

Post by DelightOne »

insanitybit wrote: post #12
DelightOne wrote: post #8

Earlier quoted context omitted.

> to be secure against actively hostile code Was that a requirement for the predecessor of eBPF: Custom kernel modules?

Kernel modules require root privileges to load and the Linux kernel's philosophy (pre user namespaces lollllll) was that root -> kernel privesc didn't matter.

Of course it would be nice if every app can load up its own untrusted eBPF code and for the kernel to not be compromised. But why such high standards, where else is that the standard to go for? Seems perfect is the enemy of good.

Re: eBPF Verification Is Untenable

#93

Post by monocasa »

tptacek wrote: post #90
bandrami wrote: post #86

Earlier quoted context omitted.

I think the point was not to show "there are a lot of helper functions" but rather to point out "the (undocumented) helper functions that exist are problematic"

That's not "quite a few" string helpers.

There are others too, for instance string formatting: https://elixir.bootlin.com/linux/latest/source/kernel/bpf/he...

Re: eBPF Verification Is Untenable

#94

Post by rurban »

cryptonector wrote: post #22
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.

Back to dTrace would be the obvious solution. Only OracleLinux has that.

Seemless probes across the kernel, libs and user-facing app.

No arrays.

Works for decades, but linux devs thought it they could do better.

Re: eBPF Verification Is Untenable

#95

Post by madog »

saagarjha wrote: post #70
tptacek wrote: post #45

Earlier quoted context omitted.

Unprivileged BPF is used for socket filters, for programs to BPF-extend themselves. It wasn't ever the case that unprivileged eBPF would allow you to, say, load a TC filter and read everybody's traffic.

Ok but you can like put a tracepoint on read/write and peek at what’s going through those, no?

Nope. Tracepoint eBPF programs require root to load always. For eBPF you select a program type, and that limits what you can do (aka what helper functions are available to you) and what privileges are required.

Re: eBPF Verification Is Untenable

#97

Post by pjmlp »

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…

Also JVM, ART, .NET verifiers show how complexity hard is to write bytecode verifiers and that is with bytecode that was designed for verification to start with.

Re: eBPF Verification Is Untenable

#98

Post by insanitybit »

DelightOne wrote: post #92
insanitybit wrote: post #12

Earlier quoted context omitted.

Kernel modules require root privileges to load and the Linux kernel's philosophy (pre user namespaces lollllll) was that root -> kernel privesc didn't matter.

Of course it would be nice if every app can load up its own untrusted eBPF code and for the kernel to not be compromised. But why such high standards, where else is that the standard to go for? Seems perfect is the enemy of good.

I don't think "standard" is the point. It's about unlocking new features and capabilities.

Re: eBPF Verification Is Untenable

#99

Post by insanitybit »

eqvinox wrote: post #91
insanitybit wrote: post #7

Earlier quoted context omitted.

> 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, and if some…

> FWIW I'm pretty sure this is how Microsoft does it. Verifier is in userland and signs programs post-verification. Almost. Yes the verifier is in userland, but it doesn't sign things — it's a trusted component of the system, there's no need for a signature on this step. It simply says "OK". But the verifier itself is covered by the usual system integrity mechanisms.

I see, thanks.

Re: eBPF Verification Is Untenable

#100

Post by cryptonector »

rurban wrote: post #94
cryptonector wrote: post #22

Earlier quoted context omitted.

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.

Back to dTrace would be the obvious solution. Only OracleLinux has that. Seemless probes across the kernel, libs and user-facing app. No arrays. Works for decades, but linux devs thought it they could do better.

Yes! But, NIH. Hmm, well, then again, BPF is NIH..
Post reply on HN