Why /sys and not /proc ? After all, the kernel binary itself is under /proc .
The file started out in proc. There was a very long lkml discussion on the subject.
Extending the Linux Kernel with Built-In Kernel Headers
11–20 of 62 posts
Re: Extending the Linux Kernel with Built-In Kernel Headers
#12> 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
File this one under: kludges to get around openly user-hostile userland.
Re: Extending the Linux Kernel with Built-In Kernel Headers
#13> 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
File this one under: kludges to get around openly user-hostile userland.
How so?
Seems like an elegant enough solution to ensure you always have the right headers to build modules against the currently running kernel.
Re: Extending the Linux Kernel with Built-In Kernel Headers
#14Earlier quoted context omitted.
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.
eBPF is not Turing-complete, but static analysis can absolutely prove things about individual programs in Turing-complete languages.
Re: Extending the Linux Kernel with Built-In Kernel Headers
#15Why can't they build the eBPF bytecode offline using the correct kernel API and ship the bytecode to the Android device?
The problem is that different kernel configurations end up changing the layout of important data structures. Basically, you need to change the offsets that the eBPF uses.
There is another proposal that uses BTF to do the fixup at load (not compile) time, but that ends up having it's own complications.
Re: Extending the Linux Kernel with Built-In Kernel Headers
#16Earlier quoted context omitted.
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.
The bytecode format of eBPF is Turing complete, it's the verification pass that makes sure the code flow graph is a DAG for instance.
cBPF was different, and only allowed you to jump forward (guaranteeing termination), but eBPF is a much more general VM.
Re: Extending the Linux Kernel with Built-In Kernel Headers
#17Why 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…
I think singularity did at least a piece of what you're describing, signing the bartok compiler output after install time and post verification so that it could be saved to disk and retrieved later without the compilation and verification steps.
Re: Extending the Linux Kernel with Built-In Kernel Headers
#18> 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
File this one under: kludges to get around openly user-hostile userland.
Did you read the article? Or even the title? How is userland involved in any of this?
Re: Extending the Linux Kernel with Built-In Kernel Headers
#19It’s a simple and practical solution. It irks me for some reason but I can’t think of something better.
It's too bad the squashfs idea was dropped. Having to download and unpack the archive somewhere seems like an extra step that should be unnecessary vs just loading the module and having the tree appear in /sys for you to point your compiler directly at.
Also a bummer that it looks like you have to be running the kernel to get access to this— perhaps the archive could be marked off in the binary somehow so that there's a way to access it for non-running kernels (eg, the dkms use case of wanting to build the module for that kernel you just installed ahead of booting it for the first time).
Overall binary size is a legit concern, but if this is going to be in an optionally-loaded module anyway, it seems weird to make that call just based on memory usage. I imagine most distro kernel builds will just disable this, since they already ship the headers in separate packages.
Re: Extending the Linux Kernel with Built-In Kernel Headers
#20It’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
Are there other languages that provide interfaces as cleanly as exposing C header files?