2 ms·
> The GP is correct that we should separate out services... That's why I said "It wouldn't be something you'd release for wider use.". I wanted to point out t
by vardump 7y ago
> The GP is correct that we should separate out services...
That's why I said "It wouldn't be something you'd release for wider use.".
I wanted to point out there are use cases where a full-fledged kernel module would be an overkill, and some safety would be desirable.
Not safety and security from others, but from myself, so that small dumb mistakes are less likely to cause kernel crashes. For research, debugging, curiosity, and so on. Not necessarily for production use!
Although, now that I think about it, it would be nice to be able to sandbox trusted code as a part of a kernel module as well. Writing kernel code is hard work, because it needs to be truly correct.
There's often code in kernel drivers that's not performance critical, but must be done in kernel mode and must be crash-free and secure to execute. So why not take advantage of sandboxing for additional safety?
- pjmlp 7y agoThat is what Windows 10 introduced with its secure kernel hypervisor. https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-vbs https://docs.microsoft.com/en-us/windows-hardware/design/dev...
- AstralStorm 7y agoWhat would this sandboxing achieve? If you mean kernel internally using multiple protection rings, tricky to do in Linux, because the API in that either has to be tight or it's still not too secure. E.g. if you just take RCU or softirqd into near userspace, as done in RT patchset, but then introduce context switching overhead, life is going to be relatively ok, but you've covered only relatively small parts of the drivers. And RT breaks drivers without even introducing more overhead. It would take a major overhaul.