Extending the Linux Kernel with Built-In Kernel Headers
linuxjournal.com
Extending the Linux Kernel with Built-In Kernel Headers
1–10 of 62 posts
Re: Extending the Linux Kernel with Built-In Kernel Headers
#2> embed the kernel headers within the kernel image itself and make it available through the sysfs virtual filesystem (usually mounted at /sys) as a compressed archive file (/sys/kernel/kheaders.tar.xz)
eeww
Re: Extending the Linux Kernel with Built-In Kernel Headers
#3Why can't they build the eBPF bytecode offline using the correct kernel API and ship the bytecode to the Android device?
Re: Extending the Linux Kernel with Built-In Kernel Headers
#4It’s a simple and practical solution. It irks me for some reason but I can’t think of something better.
Re: Extending the Linux Kernel with Built-In Kernel Headers
#5Why can't they build the eBPF bytecode offline using the correct kernel API and ship the bytecode to the Android device?
If it’s anything like GPU shaders, it’s because the bytecode format itself is Turing-complete and not-so-sandboxed, and the actual security/fault-tolerance comes from a static analysis pass done during compilation that ensures the source code being compiled isn’t doing anything crazy.
If you were able to load bytecode directly, you’d skip this verification step.
(I’ve always thought VM runtimes should have signing keys, sign build artifacts—e.g. bytecode—as they create them, and then have the VM’s module loader check the signature. This way, you could still rely on build-time static verification for your security, while also being able to share compiled artifacts among any set of runtimes that trust one-another’s signing keys.)
Re: Extending the Linux Kernel with Built-In Kernel Headers
#6It’s a simple and practical solution. It irks me for some reason but I can’t think of something better.
It irks you because storing source code directly in the final binary is bonkers, but unfortuantely it is the only way to reveal all the complexity that can be exposed in a C header file.
This isn't really just a C problem though. Even rust has a similar problem for propagating macros. The reason for this limitation is really that making an ABI for metaprograms (macros) is exceedingly difficult
Re: Extending the Linux Kernel with Built-In Kernel Headers
#7Why can't they build the eBPF bytecode offline using the correct kernel API and ship the bytecode to the Android device?
If it’s anything like GPU shaders, it’s because the bytecode format itself is Turing-complete and not-so-sandboxed, and the actual security/fault-tolerance comes from a static analysis pass done during compilation that ensures the source code being compiled isn’t doing anything crazy. If you were able to load bytecode directly, you’d skip this verification step. (I’ve always thought VM runtimes should have signing ke…
eBPF is not Turing complete, and from my understanding is made to be sandboxed.
Re: Extending the Linux Kernel with Built-In Kernel Headers
#8Why /sys and not /proc ? After all, the kernel binary itself is under /proc .
Re: Extending the Linux Kernel with Built-In Kernel Headers
#9Why can't they build the eBPF bytecode offline using the correct kernel API and ship the bytecode to the Android device?
If it’s anything like GPU shaders, it’s because the bytecode format itself is Turing-complete and not-so-sandboxed, and the actual security/fault-tolerance comes from a static analysis pass done during compilation that ensures the source code being compiled isn’t doing anything crazy. If you were able to load bytecode directly, you’d skip this verification step. (I’ve always thought VM runtimes should have signing ke…
eBPF is specifically not Turing-complete because you can not prove any property of Turing-complete language code.
Re: Extending the Linux Kernel with Built-In Kernel Headers
#10> embed the kernel headers within the kernel image itself and make it available through the sysfs virtual filesystem (usually mounted at /sys) as a compressed archive file (/sys/kernel/kheaders.tar.xz) eeww
Why eww?