[mananaysiempre]

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 for now, millions of lines of C++ from LLVM) in the TCB of your system also feels less than inspiring.

There’s also the part where if you want to instrument the kernel with something other than Rust but still relatively powerful—I dunno, Ada—then you’re looking at putting the compiler for that in the TCB, too; you benefit from none of the verification work. Sound, tractable, and expressive type systems are usually fairly isolated in design space, so source-to-source translation of arbitrary programs is impossible most of the time.

Uploading System F (e.g. Dhall) or CoC to the kernel I could see—except for the tiny problem of memory management of course—but uploading Rust, even precompiled, I honestly can’t.

[the8472]

> 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

Yeah, rustc currently does not claim to be resilient to hostile source inputs. Those are bugs that need to be fixed, but they're not p-critical warranting a point release.

[DelightOne]

> to be secure against actively hostile code

Was that a requirement for the predecessor of eBPF: Custom kernel modules?

[insanitybit]

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.

[DelightOne]

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.

[insanitybit]

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

[tptacek]

eBPF is not a replacement for the general concept of custom kernel modules.

[pjmlp]

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.

[mananaysiempre]

I’m not sure how true that is. I seem to remember that some of the problems in JVM bytecode verification are due to a wrong design and not shared by e.g. WASM, and I’m under the impression that (if you don’t try for the absolute best performance and streaming) WASM verification is fairly straightforward. Also, eBPF should probably also fall into the “designed for verification” category, so I can’t figure out what your point is here.

[pjmlp]

If it had been we wouldn't been having this discussion thread on a security paper.

[cryptonector]

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.

[mananaysiempre]

I’m not talking about writing parts of the kernel in Rust. I‘m not even talking about using Rust inside the eBPF implementation specifically. In either case that’s replacing C with Rust, and if that’s what you want, sure, knock yourself out. In the spirit of full disclosure, I’ll admit to not being a fan, but it’s still entirely plausible and one can seriously argue it’d be an improvement.

But what TFA talks about amounts to replacing the eBPF verifier with (a blessed userspace version of) the Rust typechecker—dragging the rest of the compiler along for the ride—and that just feels like a downgrade in almost every respect. It’s humongous, it requires strange contortions due to not fitting in the kernel, it implements a comparatively very complicated spec, that spec is not written down, etc. The eBPF machine is not perfect, especially (as the authors point out) when you account for the “helpers“, but it mostly avoids these downsides. It’s not the moon—it’s already there.

[lcvw]

You can write ebpf programs in rust. Bpftrace generates programs from an awk like language, you can make the program however you want. Solana does it with rust, I don’t know what it gains you though given the verifier protecting you from most of the pitfalls of C.

[rurban]

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.

[cryptonector]

Yes! But, NIH. Hmm, well, then again, BPF is NIH..