genode VS qubes-app-linux-usb-proxy

seL4 foundation members[0] are using it.

There's Genode[1], which supports it among other kernels, offering a fancy desktop environment.

However, efforts like this driver framework do help. There's also Makatea[2], an effort to implement a stronger Qubes-like system based on seL4.

0. https://sel4.systems/Foundation/Membership/

1. https://genode.org/

2. https://trustworthy.systems/projects/makatea/

> While this is true from a certain perspective, machine code creates a system which must grand access to many things to become usable. A shared file system is a good example of this. Some software could easily echo a line into you .profile that tries to launch a key-logger, and this works in many cases.

That's common, but it's certainly not a requirement to run native code. For example, we've done a pretty good job at retroactively fixing that while preserving backwards compatibility with containers (I can, and have run normal official Firefox binaries inside a docker container with zero access to my real home directory) or sandboxes like flatpak (bubblewrap). If you want to run real native binaries but don't have to preserve backwards compatibility, then it gets easy; genode ( https://genode.org/ ) does a lovely job of truly practicing only giving programs what access you want to give them.

> The expectation of software existing as opaque files creates a huge amount of work for the OS in verifying the exact behaviour of the software as it runs (and in ways which can often be circumvented), rather than a source-based approach in which malware is never allowed to touch the processor.

I think you're overoptimistic regarding what you can do with the source code short of manual (human) auditing. I mean, sure there are things you can scan for to try and catch bad behavior, but in the case of actual malice I wouldn't trust automatic code analysis to protect me.

>> I'm typing this on a nice comfy GNU/Linux box where the only blobs are some firmware

> So you suffer the worst of both worlds then. You've had to download and compile the source yourself, but as the software is designed around being distributed as blobs, so you enjoy none of the benefits that might come from source distribution.

I have no idea why you think either of those things? Depending on the distro I certainly can compile from source on my own box (ex. Gentoo, NixOS), but I can also use precompiled binaries (ex. Debian, NixOS) while still having it be trivial to go find the exact source that went in to the binary package I downloaded (this has gotten even stronger with Reproducibility efforts meaning that I can even verify the exact source and build config that created a specific binary). The actual application software and OS are available as Open Source code that can be audited, with binaries available as a convenience, and the only remaining blobs (unwelcome but impractical to fix so far) are firmware blobs with relatively constrained roles (and on machines with an IOMMU we can even enforce what access they have, which is a nice mitigation).

Genode[1] is slowly approaching the point at which I can use it as a daily driver. I hope it makes it before Windows 10 goes away. It will be nice to never have to work about viruses, or spyware, etc., any more. It'll be like a trip back to the free spirited days of DOS and write protected floppy boot disks.

[1] https://genode.org/

I'd dig into genode[1], which is a capability based operating system. You'll likely see an upsurge in interest in capability based systems in the next decade.

[1] https://genode.org/

Yet another exploit that just wouldn't work on a well-designed system, such as Genode[0].

0. https://genode.org/

Have you looked at Genode? I don't think it's usable day-to-day yet but the concepts seem interesting.

Maybe you should go into details a bit more what you are planning and why. There are (and have been) several approaches here. The most prominent might be Genode (https://www.reddit.com/r/genode, https://genode.org) and joining forces there might be a better approach than starting another project that will get lost in the details and complexity eventually.

Regarding USB, yeah, the usb-proxy doesn't have support for all things. I think it comes down to stuff not implemented in Linux USBIP or USB support (I've had issues with some device controllers not actually implementing what they claim to implement).