9 ms·
Extending the Linux Kernel with Built-In Kernel Headers
- kumbel 7y ago> 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
- quotemstr 7y agoWhy eww?
- forgottenpass 7y agoFile this one under: kludges to get around openly user-hostile userland.
- MBCook 7y agoHow so? Seems like an elegant enough solution to ensure you always have the right headers to build modules against the currently running kernel.
- deleted 7y ago[deleted]
- AnIdiotOnTheNet 7y agoAn elegant solution would be not having that problem in the first place.
- forgottenpass 7y agoIsn't kernel header availability a solved problem on any linux system that isn't busy pretending not to be built on linux?
- danudey 7y agoThe nice thing about this is that you can keep kernel headers around in a much smaller format on-disk, while still making them available separately as a package if you want. A few problems this solves: 1. Neither user nor tool knows specifically how to install the headers for specifically this version of the kernel. 2. Manually installing a header package on e.g. Ubuntu marks it as manually selected, meaning it doesn't get cleaned up with an 'autoremove'; selecting a generic kernel headers package (like linux-headers-4.14-generic or something) means that every time your system auto-updates the kernel package version (which happens by default on, for example, AWS IIRC, and happens a lot) you end up with yet another copy of the kernel headers, and then you blow your I/O budget uninstalling them. 3. It removes one extra step to running e.g. an eBPF program, or building an e.g. out-of-tree kernel module, so make scripts can now start to take advantage of that. For example: # Get headers if modprobe kernel_headers; then <unpack the tgz> else <scan through /usr/src, /usr/local/src, etc. for what looks like the right version, or fail> fi
- tssva 7y agoThe article goes into detail as to why this actually can't be used to build modules against the currently running kernel.
- sigjuice 7y agoDid you read the article? Or even the title? How is userland involved in any of this?
- d33 7y agoWhy tarred and compressed though? If it wasn't, one could point a compiler directly at it.
- WhatIsDukkha 7y agoIt goes into that, at length, in the article.
- dang 7y ago"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- riyakhanna1983 7y agoWhy can't they build the eBPF bytecode offline using the correct kernel API and ship the bytecode to the Android device?
- derefr 7y agoIf 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.)
- a_t48 7y agoeBPF is not Turing complete, and from my understanding is made to be sandboxed.
- stefan_ 7y agoeBPF is specifically not Turing-complete because you can not prove any property of Turing-complete language code.
- sp332 7y agoeBPF is not Turing-complete, but static analysis can absolutely prove things about individual programs in Turing-complete languages.
- colechristensen 7y agoYou can prove some code in Turing complete languages. You can construct non-turing-complete languages which all code can be proven, and that is the point the parent is making.
- eeeficus 7y agoIt’s a simple and practical solution. It irks me for some reason but I can’t think of something better.
- TheSoftwareGuy 7y agoIt 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
- colechristensen 7y agoAre there other languages that provide interfaces as cleanly as exposing C header files?
- java-man 7y agojava interfaces. I think the concept of coding to an interface (or an API specification) goes beyond what java did. In my professional life, I see people constantly downplaying and ignoring importance of a formal and stable API specification, just to suffer consequences later.
- colechristensen 7y agoIf you just give me a .jar do I get those interfaces in a consumable form? Said differently, can I download your .jar and write my own code to interface with it while on a desert island without any other resources?
- Mister_Snuggles 7y agoYes. If you have a random JAR file, an IDE can introspect it to see what classes are in it and what methods are in those classes. The only exception is if you run it through some kind of obfuscator first.
- dTal 7y agoWhy /sys and not /proc ? After all, the kernel binary itself is under /proc .
- quotemstr 7y agoThe file started out in proc. There was a very long lkml discussion on the subject.
- cyphar 7y agoThere is a very long thread on LKML discussing this. But I'm pretty sure the primary reason is that procfs has been slowly accumulating more and more random knobs, while sysfs actually has a structure that can be used reasonably by userspace.
- jononor 7y agoShipping the kernel headers is complicated, but somehow a whole C compiler is not? Or doesnt BPF compilation need a C compiler?
- cyphar 7y agoBPF is compiled in user-space and the bytecode is provided to the kernel -- the compiler definitely isn't shipped as part of the kernel.
- Aissen 7y agoToo bad there's no mention of the new BTF file format, which is supposed to resolve this issue for the eBPF side: https://www.kernel.org/doc/html/latest/bpf/btf.html https://www.kernel.org/doc/html/latest/bpf/btf.html
- de_watcher 7y agoWhat's wrong with shipping headers and using DKMS for building like in GNU/Linux?
- deleted 7y ago[deleted]