[insanitybit]

> 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 someone can get the signing key then the kernel will run their signed code no problem.

FWIW I'm pretty sure this is how Microsoft does it. Verifier is in userland and signs programs post-verification. This keeps the attack surface unprivileged and is a great idea if you couple your Kernel to your userland and if your operating system has a notion of process protection - Linux doesn't do either.

[mananaysiempre]

Driver Verifier? That’s not intended to prove the code under test secure, only to hopefully show that it’s not complete crap in well-known ways. Even a signed driver is still trusted code and requires administrator privileges to install. I guess the closest Linux counterpart would be a distro maintainer running a hardware vendor’s out-of-tree module under KASAN and, if it passes, signing the package with their PGP key.

But none of that is intended or able to check the module (resp. driver) is not gimmeroot.ko (resp. gimmesystem.dll)—that’s left to humans inspecting the source (resp. thoughts and prayers[1]). On the other hand, the eBPF VM absolutely is intended to be able to load anything any unprivileged user throws at it and emerge unscathed.

It’s not precisely essential that a kernel have this capability, but if one is to have it, restricting the allowable code to a predetermined vendor-approved set defeats most of the point. (The authors propose that a userspace compiler running on the user’s computer be allowed to extend it, as I understood them.)

[1] https://www.zdnet.com/article/these-hackers-used-microsoft-s...

[insanitybit]

No, not driver verifier. https://github.com/vbpf/ebpf-verifier

[deredede]

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/microsoft/ebpf-for-windows/ instead (discussed on HN recently) which is an implementation by Microsoft using the above research project that indeed does not follow the suggestion from the authors of the research project to use validation and does require trusting user space.

[insanitybit]

Yeah, I had intended to link to that repo, which also links to the one I provided - unsure what happened there.

[eqvinox]

> 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.

[insanitybit]

I see, thanks.

[edefefefee2]

I'm a bit skeptical of this. It will work for some BPF use cases, but for others it might be a nightmare to deploy something in production at scale this way. Essentially on the target machine you're no better than signed kernel modules. If someone gets in possession of the key, they can do whatever they want given there is no verification mechanism anymore. It sounds good for programs of rather static nature, but for more complex application it's rather theory imo.