3 ms·
This seems like a case of two classic mistakes to me… #1 starting with a solution, and then applying it to problems (imperfectly); #2 solving the problem at the
by jmull 3y ago
This seems like a case of two classic mistakes to me… #1 starting with a solution, and then applying it to problems (imperfectly); #2 solving the problem at the wrong level (related to problem #1) - in this case at too low a level, which can work, but is a lot more work than a solution at the right level.
That is: why not sandboxing rather than a rewrite?
- saagarjha 3y agoSandboxing an in-kernel codec?
- blipvert 3y agoeBPF?
- st_goliath 3y agoThe kernel has API in place to run code in userspace from within a kernel module ("usermode driver"). That would in theory be one way something complex in the kernel could be isolated. The obvious downside being the additional context switches and round trips for the data adding latency. Here's a blog post that demonstrates embedding an entire Go program as a blob into a kernel module and running it in userspace from the module: https://www.sigma-star.at/blog/2023/07/embedded-go-prog/ https://www.sigma-star.at/blog/2023/07/embedded-go-prog/
- saagarjha 3y agoWhile this is definitely an interesting idea (if with a lot of sharp edges, some of which you’ve discussed) some of these things are difficult to actually sandbox like this. Like, how do you meaningfully sandbox something that sets up page tables? Yes, it’s running in userspace–but if I exploit it there then I have extremely access to the system, largely equivalent to it running with kernel privileges in the first place. Likewise code that manages where the processor comes out of reset effectively has privileges regardless of where it runs, because the processor comes out of reset in a privileged state and influences on its execution are largely equivalent to having that privilege.