> 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.
I used to do something very similar with old serial to usb adapters on a newer linux machine and a windows xp guest, it's more common than you might think and rarely unpredictable. The only concern to me would be supporting the incoming protocol as a passthrough (e.g. SCSI or Parallel) though they could just be handed over at the PCI/ISA level if that could be done.
right, I have a hub that I connect it to because (shocker) my computer lacks any usb-a ports, so I just pass through the hub, and the serial children it contains are passed through. I just wish the same could be the case for firewire, I'm not willing to pony up the cash to make the dongle from hell (fw400-fw800-tb2-tb3) that may allow thunderbolt passthrough(?)
the prior art in this area is going to be PCI&USB passthrough implemented in qemu and xen, with related but separate in-guest or 'in-host' virtual devices representing the bridged device.
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.
I agree, as we get even further away from the 90s and 2000s and data gets more valuable, having mechanisms like this to access old systems is vital now that it's getting harder to make "missing link" type machines that have parallel/scsi/ATA/FW/etc. to dump old data
I still disagree with their decision to make libc THE system interface. I understand why it's important to provide a compatibility layer, bit, ideally, I would like to see a Linux-like (potentially semver-versioned) stable sycall API, or at the very least something like libsystem, i.e. a thin wrapper around technically unstable syscalls API.
The wild thing here with a microkernel is that the syscall API to the actual kernel should be theoretically really small right?
I get the various little services might change, but ultimately the kernel supporting posix like threading and memory operations should be mostly enough?
The kernel ABI is notoriously backwards compatible (the famous "we do not break userspace" and all). The primary reason why binaries rot on Linux is GLIBC and other shared library dependencies. I still can execute a MUSL binary compiled more than a decade ago without any issues.
Hey redox team. Great work! Just wanted to point out, you wrote “attack of surface”
Instead of attack surface. (On your home page https://www.redox-os.org/)
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?
The benefit of drivers being in the user-space is it will limit the damage if that driver has vulnerabilities. The downside is, I don't think the performance will be great. The kernel already written in Rust and if all drivers also written in Rust with limited unsafe it should be almost impossible for vulnerabilities related to memory.
Performance can be fine for the vast majority of hardware. Some drivers may need to be colocated in the same process for performance, but your average PCI driver doesn't benefit at all from being in the kernel. People also underestimate what you can accomplish with an efficient async first shared memory based ipc can accomplish.
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.
reply