> 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 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.
> Hosted Linux for Driver Support
> 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.
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.
How do you set up the interface "back" to the host?
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?
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.
HarmonyOS NEXT already does something like this for driver support and I believe real phones already use it.
Great to see in the priorities "sandboxing by default" (under desktop variety) and https://nlnet.nl/project/Capability-based-RedoxOS/ (under security).
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 fact that binaries tend to rot on Linux shows that maybe only having a stable syscall ABI the best way to handle things either.
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.
How close is Redox to being able to run a web browser? I'd love to try doing real work on it.
Don't know your requirements, but it does say "Working basic web browser with NetSurf" on the front page.
It's a Rust based OS, so I expect people to try a Servo port instead!
This is interesting project, but it saddens me that we are stuck with Unix-like for the rest of eternity.
I'll be watching this project with keen interest!
Did they stop developing ralloc allocator?
That hasn't seen any commits in 6 years.
It wasn't promising?
I believe the primary developer lost interest and no one else jumped in to take over. Not very unusual for a hobby project.
Looks very interesting roadmap, looking forward to where Redox goes.
Regarding the server approach, I wonder if going for a type 1 hypervisor like Firecracker wouldn't be a much better approach than QEMU.