3 ms·

Chrome's v8 Javascript JIT gets attacked all the time. I can only imagine the fun to be had attacking a kernel which uses JIT extensively.

saagarjha 7y ago
Yeah, I’m surprised that security wasn’t mentioned at all. The Linux kernel’s BPF JIT is incredibly restrictive on what it can interpret and produce: presumably a JIT like this would be much less constrained.
- gpvos 7y ago
  Security was mentioned in passing: > In production we’d need to think carefully whether we wanted to include a big chunk of non-hardened code in the kernel.
- timClicks 7y ago
  But in a sense, security is just part of the engineering required to make such a project a reality. No one is going to be deploying a kernel like this until it's proven, so perhaps the emphasis on security isn't needed for an initial blog post.
daoxid 7y ago
The way I understood it is that it would only perform code generation for trusted kernel code, not for arbitrary code provided by the user. Doesn't this resolve most (all?) security concerns?
- vidarh 7y ago
  Not necessarily, because it means you need to be sure that the combination of the JIT, the trusted kernel code and user data will only ever result in safe code paths. E.g. consider a JIT that mistakenly optimizes away a bounds check in the original trusted code in certain cases where it is not safe to optimize it away.
vidarh 7y ago
I think one interesting approach for this would be to look for cases where the kernel can leverage information it has to JIT code into userspace that allows the userspace process to reduce the number of context switches it needs into the kernel. Obviously that could not get as aggressive, as anything that requires security checks or access to information not accessible to the calling process would still need to enter the kernel. E.g. is the other end of that file descriptor you're writing to another process on the same machine? Intercept the calls and replace them with operations directly on shared memory using a futex to coordinate, for example. Or is the process doing read()'s that are smaller than what is most efficient on the current system, and it's the only reader? JIT buffering into user space. A lot of what you might consider it for could be done just fine in user-space with sufficiently smart libraries that knows how to handle a bunch of special cases, but the caveat is that you then depend on users knowing to use them, and my experience is that there is enough code out there doing tiny read()'s that I have no faith whatsoever that people will do a good job at even the very basics. Meanwhile the kernel has a lot of information very easily accessible that a userspace implementation might have to jump through hoops to find out.
hinkley 7y ago
Least Power doesn't necessarily mean no JIT. There is a lot of space between 'fully Turing complete' and 'useful' where you can allow certain patterns but not arbitrary code. This area gets discussed every ten years or so. There was even something called Proof Carrying Code where you make the caller do some of the work up front.

saagarjha 7y ago

Yeah, I’m surprised that security wasn’t mentioned at all. The Linux kernel’s BPF JIT is incredibly restrictive on what it can interpret and produce: presumably a JIT like this would be much less constrained.

gpvos 7y ago
Security was mentioned in passing: > In production we’d need to think carefully whether we wanted to include a big chunk of non-hardened code in the kernel.
timClicks 7y ago
But in a sense, security is just part of the engineering required to make such a project a reality. No one is going to be deploying a kernel like this until it's proven, so perhaps the emphasis on security isn't needed for an initial blog post.

daoxid 7y ago

The way I understood it is that it would only perform code generation for trusted kernel code, not for arbitrary code provided by the user. Doesn't this resolve most (all?) security concerns?

vidarh 7y ago
Not necessarily, because it means you need to be sure that the combination of the JIT, the trusted kernel code and user data will only ever result in safe code paths. E.g. consider a JIT that mistakenly optimizes away a bounds check in the original trusted code in certain cases where it is not safe to optimize it away.

vidarh 7y ago

I think one interesting approach for this would be to look for cases where the kernel can leverage information it has to JIT code into userspace that allows the userspace process to reduce the number of context switches it needs into the kernel. Obviously that could not get as aggressive, as anything that requires security checks or access to information not accessible to the calling process would still need to enter the kernel. E.g. is the other end of that file descriptor you're writing to another process on the same machine? Intercept the calls and replace them with operations directly on shared memory using a futex to coordinate, for example. Or is the process doing read()'s that are smaller than what is most efficient on the current system, and it's the only reader? JIT buffering into user space. A lot of what you might consider it for could be done just fine in user-space with sufficiently smart libraries that knows how to handle a bunch of special cases, but the caveat is that you then depend on users knowing to use them, and my experience is that there is enough code out there doing tiny read()'s that I have no faith whatsoever that people will do a good job at even the very basics. Meanwhile the kernel has a lot of information very easily accessible that a userspace implementation might have to jump through hoops to find out.

hinkley 7y ago

Least Power doesn't necessarily mean no JIT. There is a lot of space between 'fully Turing complete' and 'useful' where you can allow certain patterns but not arbitrary code. This area gets discussed every ten years or so. There was even something called Proof Carrying Code where you make the caller do some of the work up front.