8 ms·
Jitk: A Trustworthy In-Kernel Interpreter Infrastructure
- Lowkeyloki 7y agoIf it delivers on its promise, this could be very useful. I'm no kernel hacker, but any tool that makes working with kernel code easier and safer is a real boon!
- AstralStorm 7y agoThere are much better tools. You really shouldn't run user code in kernel space.
- vardump 7y agoExcept for example when the user needs to either do something only doable in kernel space or to diagnose and analyze kernel behavior. I would have loved an option like this for example when working with a power management issue last time (PCI-e surprise removal and hot-plug can be annoying!)... Sure, I can use remote kernel debuggers etc., but those can be sometimes a hassle to set up, not always the most convenient option. Like when an issue occurs on the other side of the world, and kernel dumps and tracing leads nowhere. Having an extra option for easy injection of code in kernel would be a nice thing to have in the toolbox. In other words, one-off scenarios. It wouldn't be something you'd release for wider use. Knee-jerk reactions have been somewhat off-putting lately. All of us should keep in mind other people might have a completely different mindset, problems and needs than our own. We should celebrate new ideas and novel points of view and not to brainlessly use existing dogma or cheap talking points to immediately slam them. (I've developed (among other things) commercial kernel drivers for Windows. And "for fun" for Linux just to keep my skills updated.)
- rwmj 7y agoThat's just a side effect of the way Linux puts everything into a giant trusted binary. The GP is correct that we should separate out services (probably to separate sockets until Spectre-like attacks are fixed), even if it's also true that when dealing with Linux-as-it-is-today the solution to everything being in the kernel is to put more stuff in the kernel.
- aey 7y agoAny sandboxing adds a performance overhead. There is no free lunch in Operating Systems.
- pjmlp 7y agoA tiny performance overhead is worthwhile in name of security. For example, I don't remember the last time I cared about disabling bounds checking, even in C++ code (VC++ allows to keep it on).
- rurban 7y agoTell that the various libc maintainers. They are blocking the C11 Annex K (safe bounds checks) for over a decade now. And talking about performance With good compilers my secure memcpy_s is actually faster than the glibc or BSD libc memcpy, with compile-time constexpr.
- pjmlp 7y agoI would blame ISO C, by making Annex K optional, and not caring to improve C's safety in general.
- aey 7y agoI am quite happy with rust these days. But it still lacks great ‘no allocation’ libraries.
- rurban 7y agoThen you are illusional. None of their safety guarantees are real. Memory, type, concurrency, none. But talking to them fall on deaf ears. Its called hype driven development and very popular amongst HN folks. There exist plenty of real safe languages though.
- 7y ago
- shrimpx 7y agoTranslation: programming languages academics try hard to make their work "relevant" and find a case where programming-languagey thing is happening in the kernel, which is super duper critical, because it's the kernel, so they jump at the opportunity to apply geeky archaic concepts that will for sure never get adopted, but they get a cool-sounding paper accepted at "prestigious" conference which was the final goal all along.
- titzer 7y agoThe papers linked are from 2013. Now we know the implications of Spectre make kernel JITs a potential vulnerability. You should not run untrusted code in the same address space with secrets it could steal.
- AstralStorm 7y agoTrusted and trustworthy is the counterpart to proven. Where you assume something is secure instead of proving it to be secure.
- tgragnato 7y agoYou usually prove something with formal verification, and it fails when the assumptions of the underlying model are wrong. Take the axioms with a grain of salt.
- rurban 7y agoExactly, the array offset rules are missing important parts. Not just bounds checks, but also offsets larger than a page table need to be forbidden. (Spectre). IMHO arrays should be forbidden at all, replaced by a secure hash map, with a max size.
- monocasa 7y agoWay to completely destroy perf by making your memory accesses totally random.
- rurban 7y agoExactly, People need to feel how bad it is to allow anyone getting user-space access into the kernel. It needs to hurt. But the prime reason is security. solaris and freebsd do have their reasons to disallow arrays in their kernel hooks.
- 7y ago
- skybrian 7y agoHow does this compare with eBPF?
- syn0byte 7y agoIt is BPF. It's one of the pavers in the road that got us to the current eBPF implementation today.