
Jitk: A Trustworthy In-Kernel Interpreter Infrastructure - lelf
https://css.csail.mit.edu/jitk/
======
titzer
The 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.

~~~
candiodari
Didn't spectre work cross-address-space ? I mean the whole point of the
spectre vulnerability was that one process read kernel memory or another
process' memory.

So that would make executing any code anywhere on the same cpu (anything
behind the same cache) potentially vulnerable. JIT or not, kernel or not, ...

~~~
lucian1900
That's Meltdown, the Intel bug in memory isolation.

Spectre is a CPU cache timing attack to derive data. Cache lines are cleared
in between context switches, so it can only affect the same process.

~~~
monocasa
Cache lines aren't cleared on context switches, and there are Spectre variants
that are cross address space. There's even a remote Spectre exploit.
[https://arxiv.org/abs/1807.10535](https://arxiv.org/abs/1807.10535)

~~~
lucian1900
Oh. I entirely misunderstood, then. I stand corrected.

------
Lowkeyloki
If 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
There are much better tools. You really shouldn't run user code in kernel
space.

~~~
vardump
Except 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
That'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.

~~~
vardump
> The GP is correct that we should separate out services...

That's why I said "It wouldn't be something you'd release for wider use.".

I wanted to point out there are use cases where a full-fledged kernel module
would be an overkill, and some safety would be desirable.

Not safety and security from others, but _from myself_ , so that small dumb
mistakes are less likely to cause kernel crashes. For research, debugging,
curiosity, and so on. Not necessarily for production use!

Although, now that I think about it, it would be nice to be able to sandbox
trusted code as a part of a kernel module as well. Writing kernel code is hard
work, because it needs to be truly correct.

There's often code in kernel drivers that's not performance critical, but must
be done in kernel mode and must be crash-free and secure to execute. So why
not take advantage of sandboxing for additional safety?

~~~
pjmlp
That is what Windows 10 introduced with its secure kernel hypervisor.

[https://docs.microsoft.com/en-us/windows-
hardware/design/dev...](https://docs.microsoft.com/en-us/windows-
hardware/design/device-experiences/oem-vbs)

------
skybrian
How does this compare with eBPF?

~~~
syn0byte
It is BPF. It's one of the pavers in the road that got us to the current eBPF
implementation today.

