Comment by tscs37 | Hacker News Reader

Comment by tscs37 | Hacker News Reader

Parent Full thread

That's all nice but what if you have a CPU bug like Spectre?

Isolation is nice in userspace but in kernelspace the rules are somewhat different, especially considering that it is the task of kernelspace to mediate and abstract hardware access to arbitrary programs running on your system. Any number of hardware bugs may break isolation. Any number of wrong assumption or subtle logic bugs can happen and break the isolation.

The documentation on Monte also mentions that it is rather slow and requires memory management, two properties that simply do not exist in kernel space.

Writing a kernel is like writing a modern web browser except if you get it wrong the malicious program can access everything, all webpages, all the history and send your mom rude jokes on facebook after literally setting your computer on fire.

So you can't simply say "we will never break isolation", you must question "in the absolutely infinitely small occurence that isolation breaks, what do we do?". A Kernel must be prepared to deal with such a possibility. Even if it "cannot happen".

That's why high assurance systems (like L4/seL4) minimize privileged code to a tiny fraction of what you find in a regular system, which absolutely makes sense and provably improves security.

Apart from the obvious advantages, minimal privileged code also means that it becomes far more feasible to formally verify the privileged code, like it has been done for seL4, which in turn is an important cornerstone to ensure that isolation (or more generally, specification invariants) does not break in any reachable system state.

Even a perfect kernel will have to crash.

Something like Rowhammer can turn perfectly written code into malicioous gadgets for an attacker. Until ECC or preventative measures becomes widespread in consumer hardware, this attack will remain viable.

Additionally, cosmic rays may at any time write arbitrary data into memory. In these situations it is perfectly reasonable to crash the machine if essential datastructures were affected.

Or suppose you just received a MACHINE CHECK exception, the type of interrupt which essentially just tells the OS that the machine is no longer capable of operating in it's current state.

This isn't all about an attacker gaining privilege, the mere act of crashing the kernel in a hostile or other event (cosmic rays, voltage fluctuation) which leads to corruption or compromise of the continued operation of the machine is perfectly acceptable and normal.

"That's all nice but what if you have a CPU bug like Spectre?"

Use VAMP [1] or AAMP7G [2] with techniques [3] that prevent leaks if you're worried about that. Far as RAM/Rowhammer, either use techniques that trust it less like Edmison's [4] or actually do QA when you build your own. A RAM engineer told me they were intentionally under-designed for cost-cutting and/or rushing to market. There's also an open, cell library available. Then, you get some analog and RF engineers that don't trust each other to look at the rest of the mixed-signal chip. You should be good on what requirements you've stated so far. If worried about kernel security, modify that same chip to use CHERI [5] which already runs FreeBSD but you'll want a separation kernel. Throw in asynchronous or masked execution for timing channel mitigation.

I still agree you want containment, detection, and recovery mechanisms just in case where you can put them in. Mainly in case of hardware failures but also unknown attack classes.

[1] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.217...

[2] http://www.ccs.neu.edu/home/pete/acl206/slides/hardin.pdf

[3] https://pastebin.com/ajqxDJ3J

[4] https://vtechworks.lib.vt.edu/bitstream/handle/10919/29244/e...

[5] http://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

Reply on news.ycombinator.com