I get the various little services might change, but ultimately the kernel supporting posix like threading and memory operations should be mostly enough?
Also, I’m curious about the mention of drivers being in user space. Why would one want their drivers in user space? Wouldn’t that increase the attack surface?
Security benefits of driver's being in user space become limited quickly if you lack an iommu. Additionally if it has to set things like voltage regulators or clocks it can easily put the system into precarious states. That said it's still worthwhile and has lots of other benefits.
> In order to avoid porting thousands of device drivers, we would like to port QEMU to Redox, then run a stripped-down Linux to provide device drivers for less common and older devices. The interface between Redox and Linux-in-QEMU will be designed to be secure, so this approach should give us reasonable safety.
What a fascinating approach to this.
Is it something like:
USB directly to the guest OS, then an emulated serial port in the guest OS back that the host OS connects to?
Some related work in the SR-IOV & iommu space makes this a lot easier to implement as well. I would be very surprised if zero new security edge cases get discovered in the next five years or so however. Regardless, I'd look forward to seeing the results of RedoxOS's work here, as this would be a practical alternate implementation of driver domains like you see used in Xen and Qubes.
Regarding the server approach, I wonder if going for a type 1 hypervisor like Firecracker wouldn't be a much better approach than QEMU.
shmerl•4mo ago
surajrmal•4mo ago
shmerl•4mo ago
surajrmal•4mo ago