4 ms·

There's no mitigation. We'll need new CPUs. Meanwhile, don't ever run untrusted code in the same process as any kind of secret. Better yet, don't ever run untr

There's no mitigation. We'll need new CPUs. Meanwhile, don't ever run untrusted code in the same process as any kind of secret. Better yet, don't ever run untrusted code.

Havoc 9y ago
>We'll need new CPUs. I don't think that's an option either.
hinkley 9y ago
I wonder what fraction of data inside a kernel is really ‘private’. Obviously we want 100% of the data in the kernel not to be writeable, but if only a small amount shouldn’t be accessible at all then maybe the long term solution is to handle that data in a special way. Something that makes using it slower but doesn’t make every other syscall suffer as much as a consequence. Or maybe the solution is to prioritize moving more and more code into userspace.
- kuschku 9y ago
  Well the good news is that now microkernels can take over. With KPTI (also known as FUCKWIT), a syscall is now as expensive as a context switch to another userland process. Of course, that means now monolithic kernels run just as slow as microkernels.
  - astrange 9y ago
    Recent Intel CPUs have PCID (TLB tagged by process ID), which makes KPTI not much slower than what we had last week.
  - JdeBP 9y ago
    I suggest some reading first, starting with (but not limited to): * http://blog.darknedgy.net/technology/2016/01/01/0/ http://blog.darknedgy.net/technology/2016/01/01/0/ (https://news.ycombinator.com/item?id=10824382 https://news.ycombinator.com/item?id=10824382) * https://news.ycombinator.com/item?id=10483467 https://news.ycombinator.com/item?id=10483467
    - kuschku 9y ago
      I've read them — but the important factor is that Linux with KPTI is now doing a full context switch between userland and kernel, which is the same cost as switching to another userland process to handle the syscall (which is exactly what a naive microkernel would do). I've always been a proponent of microkernels, and this is another situation that might help with this. (Personally, I've been affected by the failures of monolithic kernels way too often. When a simple OpenGL or WebGL program manages to hang your GPU driver, parts of the kernel, and all DMA operations in the kernel, and your system becomes unusable, then reasonable isolation would be preferable)
  - Symmetry 9y ago
    The performance differential is a concern with classical microkernel designs but not really with modern ones. The process isolation is useful when dealing with Meltdown but not with Spectre.
  - hinkley 9y ago
    Hypervisors and containers already blur this line. I think we were heading there anyway. But a microkernel is going to have multiple processes talking to each other, so there will still be more overhead whenever a message requires coordination between more than two processes.
- mike_hearn 9y ago
  I wondered that. But it's really hard. My guess is that most of it needs to be read protected. Consider: • Network packet buffers? Yes. • Graphics driver command buffers? Yes. • Disk caches? Yes. • Kernel pointers of any kind? Yes if you care about KASLR. It's actually kind of hard to think of data in the kernel that shouldn't be read protected.

There's no mitigation. We'll need new CPUs. Meanwhile, don't ever run untrusted code in the same process as any kind of secret. Better yet, don't ever run untrusted code.

Havoc 9y ago

>We'll need new CPUs. I don't think that's an option either.

hinkley 9y ago

I wonder what fraction of data inside a kernel is really ‘private’. Obviously we want 100% of the data in the kernel not to be writeable, but if only a small amount shouldn’t be accessible at all then maybe the long term solution is to handle that data in a special way. Something that makes using it slower but doesn’t make every other syscall suffer as much as a consequence. Or maybe the solution is to prioritize moving more and more code into userspace.

kuschku 9y ago
Well the good news is that now microkernels can take over. With KPTI (also known as FUCKWIT), a syscall is now as expensive as a context switch to another userland process. Of course, that means now monolithic kernels run just as slow as microkernels.
- astrange 9y ago
  Recent Intel CPUs have PCID (TLB tagged by process ID), which makes KPTI not much slower than what we had last week.
- JdeBP 9y ago
  I suggest some reading first, starting with (but not limited to): * http://blog.darknedgy.net/technology/2016/01/01/0/ http://blog.darknedgy.net/technology/2016/01/01/0/ (https://news.ycombinator.com/item?id=10824382 https://news.ycombinator.com/item?id=10824382) * https://news.ycombinator.com/item?id=10483467 https://news.ycombinator.com/item?id=10483467
  - kuschku 9y ago
    I've read them — but the important factor is that Linux with KPTI is now doing a full context switch between userland and kernel, which is the same cost as switching to another userland process to handle the syscall (which is exactly what a naive microkernel would do). I've always been a proponent of microkernels, and this is another situation that might help with this. (Personally, I've been affected by the failures of monolithic kernels way too often. When a simple OpenGL or WebGL program manages to hang your GPU driver, parts of the kernel, and all DMA operations in the kernel, and your system becomes unusable, then reasonable isolation would be preferable)
- Symmetry 9y ago
  The performance differential is a concern with classical microkernel designs but not really with modern ones. The process isolation is useful when dealing with Meltdown but not with Spectre.
- hinkley 9y ago
  Hypervisors and containers already blur this line. I think we were heading there anyway. But a microkernel is going to have multiple processes talking to each other, so there will still be more overhead whenever a message requires coordination between more than two processes.
mike_hearn 9y ago
I wondered that. But it's really hard. My guess is that most of it needs to be read protected. Consider: • Network packet buffers? Yes. • Graphics driver command buffers? Yes. • Disk caches? Yes. • Kernel pointers of any kind? Yes if you care about KASLR. It's actually kind of hard to think of data in the kernel that shouldn't be read protected.