iacore
commented
2 years ago unikernel is utterly impossible to debug/understand/inspect, including sel4. Genode OS is better, since it has official GUI environment. (personally, seL4's CAMKES build system is written in CMake and pain)
As for security, this is probably non-concern.
A quick search shows that at best(worst?), a malicious actor can crash the linux kernel by plugging in a malicious USB device. They need the device plugged in while you are using the computer.
To me, further security is not a concern. #6330 is more important.
DemiMarie
SemanticBeeng
marmarek
How to file a helpful issue
The problem you're addressing (if any)
sys-usb is based on Linux, which has a history of security holes in its USB stack. Since sys-usb is the interface between the system and most external peripherals, this a serious security limitation. Since it is well-known and documented, it does not qualify as a vulnerability in Qubes OS per se, but it is still something that should be fixed someday. Additionally, sys-usb cannot be started until very late in the boot sequence, which prevents USB security devices from being used to unlock the system boot drive.
The solution you'd like
sys-usb should be implemented as a stateless unikernel written in a memory-safe language. The unikernel only supports a minimal set of USB devices itself, but it can expose USB devices to other qubes via USBIP or Xen usbback. The unikernel is included in the initramfs and is started before the LUKS decryption prompt, allowing hardware devices such as the YubiKey or Nitrokey to be used to decrypt the drive and perform attestation.
Due to its minimal attack surface and memory-safe implementation, the unikernel sys-usb is considered a security boundary. A malicious USB device must not be able to compromise sys-usb, spoof the port or controller that it is plugged into, or access or tamper with other USB devices. A security bulletin will be issued for vulnerabilities that allow these features to be bypassed.
A unikernel is one possible implementation for sys-usb, but not the only one. A system based on the seL4 Core Platform is also an option. If the Xen hypervisor is replaced by a microkernel, sys-usb could be a tightly confined userspace process. The word “unikernel” is (ab)used above to refer to all of these possibilities.
Drivers will only be included in sys-usb if doing so is necessary for performance, functionality, or security. Likely candidates for inclusion are audio, video, and HID drivers. HID devices are needed during very early boot, and audio and video devices are security-critical (they allow access to highly sensitive information). Video devices are also performance-critical: as shown by Qubes Video Companion, transmitting video using qrexec is much faster and has lower latency than USB pass-through does.
The value to a user, and who that user might be
All users will benefit from dramatically improved security for USB device handling.