81–90 of 116 posts
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…
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…
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…
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.
The whole BPF verifier and development process is so botched, it's ridiculous. It's like maintainers decided to make this as hard as possible out of pettiness and "they have to use C APIs instead" or something. - Loading an eBPF module without the CAP_BPF (and in some cases without the CAP_NET_ADMIN which you need for XDP) capabilities will generate a "unknown/invalid memory access" error which is super useless as an…
I used to hand-code BPF before LLVM had a backend for it, and I can tell you that each enhancement added to the userland tooling made sense in isolation to help you if you already knew what you were doing. But the overall picture isn't really an SDK - it's more like a collection of someone's bash scripts used to automate repetitive parts of writing the bytecode.
For one thing, 80% of the contents of the popular toolkits is just there to accomplish two goals:
1) Let you pretend to write C / some other higher level language 2) Cut down on manual set up of the maps, checking if BPF is enabled, etc.
Arguably the only really complicated thing the tooling does is CO-RE, which is largely done in the loader, with some C macros to support it.
What you pay for this "convenience" is that the kernel has no idea what the hell you're trying to do. All it sees is the generated, rewritten and relocated BPF bytecode which it has no way of tying back to the C code you made it from.
To arrive at a point - I would honestly recommend trying to write BPF by hand. The bytecode is pretty friendly, the BPF helpers are numbered and you'll see what the verifier is talking about.
After you've got that down, you'll see the two annoying parts: doing BTF-based relocations and doing the setup with BPF maps, etc, and you'll get a feeling for how the clang-based tooling does those things, and what cost it extracts: IMO it's not worth it.
Earlier quoted context omitted.
Program termination is a solved problem with gas metering. Ethereum popularized the idea, but the idea itself is as old as hills.
There's a subtlety being missed here. Proven termination of BPF programs far predates the adversarial threat model you and the WASM person are thinking about. It was a property of the original 1991 McCanne BPF. It's a safeguard for the programmer against themselves . eBPF shims in all over the place in the kernel; it would not be OK for the guarantee to simply be "there's a worst case maximum cycle budget for program…
Earlier quoted context omitted.
that's what GP said. They are semantically simple string operations whose computational complexity scales with string length. Near unbound string lengths would exhaust the time (somewhat aproximated by instruction) budget of eBPF applications doing even a single one.
That's all that's there. String-integer conversion and comparison.
Earlier quoted context omitted.
No, not driver verifier. https://github.com/vbpf/ebpf-verifier
This link is about a proposed new eBPF verifier for the Linux kernel that doesn't use signing. As a research project it is not integrated to the kernel, but their plan does not involve trusting user space (instead they suggest doing the heavy lifting of the verification in user space and provide a proof of safety that the kernel checks, which seems sensible to me). I believe you meant to link https://github.com/micro…
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…
https://news.ycombinator.com/item?id=35501065
They do ban unsafe and also the stdlib which probably covers a lot of soundness holes.
Also I suspect the trust level required is somewhere in the middle.
Earlier quoted context omitted.
That's all that's there. String-integer conversion and comparison.
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"