undefined | Better HN

0 pointsFilligree8y ago0 comments

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.

0 comments

8 comments · 2 top-level

hinkley8y ago· 6 in thread

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.

kuschku8y 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.

JdeBP8y ago

I suggest some reading first, starting with (but not limited to):

* http://blog.darknedgy.net/technology/2016/01/01/0/ (https://news.ycombinator.com/item?id=10824382)

* https://news.ycombinator.com/item?id=10483467

1 more reply

astrange8y ago

Recent Intel CPUs have PCID (TLB tagged by process ID), which makes KPTI not much slower than what we had last week.

hinkley8y 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.

Symmetry8y 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.

mike_hearn8y 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.

Havoc8y ago

>We'll need new CPUs.

I don't think that's an option either.

j / k navigate · click thread line to collapse