Meanwhile, don't ever run untrusted code in the same process as any kind of secret. Better yet, don't ever run untrusted code.
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.
Of course, that means now monolithic kernels run just as slow as microkernels.
* http://blog.darknedgy.net/technology/2016/01/01/0/ (https://news.ycombinator.com/item?id=10824382)
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.
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.
I don't think that's an option either.
