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.)
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.
Comments
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...
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/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.
Yeah, I had intended to link to that repo, which also links to the one I provided - unsure what happened there.