Hacker News new | comments | ask | show | jobs | submit login
Founder of GenodeLabs OS framework discusses impact of Meltdown/Spectre attacks (sourceforge.net)
58 points by DyslexicAtheist on Jan 6, 2018 | hide | past | web | favorite | 12 comments

Microkernels are interesting approach to resist Spectre and Meltdown attacks. Computational costs of KPTI + retpoline patches are already higher than computational costs of microkernel IPC. And properly implemented microkernel may never let privileged system code run on the same physical core(s) as user code, so microarchitectural leaks (cache state, branch prediction stats etc) which enable Spectre and Meltdown attacks are not possible in this design.

Intel's L3 cache is inclusive. Spectre most definitely also applies across different cores.

Spectre attack relies on microarchitectural leaks of branch prediction statistics, which (according to my understanding) is not shared between cores in multi-core CPU.

If privileged system code never runs on the same physical core(s) as user code, and so we leave out branch prediction leaks, we are dealing only with cache timing leaks via L3 cache (Meltdown attack). But in the data segment of pure microkernel (which only does IPC and task switching) there's not much to hunt for.

No no no, you can easily train the branch predictor by sending a bunch of valid requests followed by an invalid request with a payload that redirects the ensuing speculative load into your desired address range.

Yes, but to do that, your code needs to use the same branch predictor as the victim code. If the branch prediction buffer is per-core and not shared among multiple cores, then that means you have to run on hte same core as the kernel. If the kernel always runs on a different core, you cannot do anything.

Spectre works across address spaces, user->user so how does a microkernel help?

It works across address spaces only if OS scheduler runs affected processes on the same CPU core, so hardware state of branch predictor is shared.

"The irony is that our custom base-hw kernel actually used to keep the kernel in a dedicated virtual address space - until three months ago when we reworked the kernel to follow the main stream where the kernel is mapped in each user-level address space as privileged pages."

That hurts. Reminds me of when we finally relented and started to stream video using Flash only to have Adobe announce the end of life on Flash.

I'd like to post my complements to the author here. I don't use Genode, but the first 5 paragraphs are a spectacularly lucid intro to the implications of both these vulnerabilities.

hey GenodeLabs guy

please make a livedisk or usb image like every one else

In addition to what alex posted, the new package system along with the build system means that you can build a custom OS based on Genode in under under an hour (my fastest build takes 5ish minutes). The core/base kernels are also packages in Genode, which means you just "shop" for everything you want: a base kernel, services, packages, libs, etc.

It's not perfect and it could use slightly better tooling (which will come once everyone is convinced the design is completely correct), but it's the best system for an OS I've seen to date.

Even though I would also like something like this I understand they do have their reasons for not doing so. AFAIU they are of the opinion that a livedisk would misrepresent the capabilities of the system.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact