4 ms·
it seems like it might be totally feasible to make a CPU where one core runs all the Ring 0 stuff, and the rest don't.
by adgjlsfhk1 6y ago
it seems like it might be totally feasible to make a CPU where one core runs all the Ring 0 stuff, and the rest don't.
- toast0 6y agoYou don't really need a CPU to do that. Just operating system decisions. a) route all hardware interrupts to CPU 0 only b) when a user thread does a syscall, immediately task switch to another thread, marking the current thread as entering/in the kernel. Only service threads entering/in the kernel on CPU 0. Technically, you need a little bit of ring 0 time to task switch. But if you make all of the syscalls amazingly slow, timing attacks are a lot harder.
- angry_octet 6y agoThere are some patches out there that allow you to lock kernel threads to particular cores. With all the cache flushes on context switch, making syscalls slow should be no problem at all.
- KMag 6y agoMy memory could very well be wrong here, but isn't this how multi-core was first implemented on FreeBSD, with all post-context-switch kernel code running on CPU0? It's certainly a much more simple design, easier to avoid data races and deadlocks. However, I believe the performance penalties were pretty apparent early on, even on 2-4 core systems.
- toast0 6y agoI wasn't that understanding of kernel stuff back then, but I don't recall seeing anything that the kernel was always running on CPU0; but I think everything was behind the GIANT lock, so there was effectively zero kernel concurrency.
- samus 6y agoI like that idea! There's already a large slowdown because of communication and NUMA. The syscall arguments have to be transferred to CPU 0 memory as well.
- elihu 6y agoI just skimmed a little bit of the paper so I'm probably missing a lot of context, but would restricting to one core even help in this instance? Information is leaking via the L3 cache, which is shared.