4 ms·
The threat model is basically another process compromising the kernel. Think security systems in shared environments. It's supposed to be hardware based. If pr
by hvidgaard 7y ago
The threat model is basically another process compromising the kernel. Think security systems in shared environments.
It's supposed to be hardware based. If process A requests memory with MAP_EXCLUSIVE, and it verifies that it got it that way, the hardware is supposed to make sure the memory is only available to that particular process. No amount of context switching is allowing the kernel to read it, nor could should it be able to modify the running code in a process if it's properly hardened (e.g. put the code to run in the protected area). It pose some interesting challenges, but it seems quite possible
- PeterisP 7y agoThis seems weird - the hardware has no notion of processes, that's a construct implemented by the kernel. It can enforce a separation of privileges between kernel and non-kernel, but that's about it. Hardware gets a flag that says "am I in privileged mode now?" and it does not (and fundamentally can not) know to whether the currently running code belongs to process A or something else, or to whom a particular memory region belongs - as far as hardware is concerned, there's no "whom" at all, that's an abstract construct arbitrarily introduced and maintained by the OS.
- Dylan16807 7y agoThat's how it works right now on x86. There's no reason hardware can't be given a notion of processes, and used to set boundaries between each other and the kernel. It's not an untested idea.
- hvidgaard 7y agoWhile the current crop of mainstream CPUs does not support anything like it, the idea is old. Basically the CPU need to have hardware support for a PCB and be solely responsible for context switching, and the already complex MMU needs to be context aware. I'm pretty sure we've seen specialized CPUs in the past that did exactly that.