Why does sys-usb need so much RAM?

Singer · May 15, 2024, 2:38pm

On the old computer and Qubes 4.1 there were never any problems with video conferences (with webcam and USB headset). Now (on Qubes 4.2) the system freezes for minutes when the webcam and USB headset from sys-usb are attached to the conference VM and then started to be used. It got much better when I allocated 3000 MB RAM to sys-usb. Since then I have been able to write in a text editor in another VM during the conference. But at some point no new windows can be opened. There still seems to be too little RAM. How can I solve this?

alimirjamali · May 15, 2024, 2:44pm

I am personally using a Fedora minimal template and use it as the template for sys-usb. The allocated memory for sys-usb is 400MB for initialmem. Maxmem is irrelevant here as it is an HVM. But I am suspicious that your issue might be beyond memory allocation. As even the xfce template should work well with 2GB

Singer · May 15, 2024, 2:45pm

I use a debian minimal template as template for sys-usb.

alimirjamali · May 15, 2024, 2:47pm

The I would suggest running top (or htop if you have it installed) and analyze memory usage per process to find the culprit.

otter2 · May 15, 2024, 2:50pm

That sounds weird. Why would sys-usb’s RAM be relevant when the devices are passed through to another domain?

Just as a confirmation, when my audio devices are passed to my sys-audio, sys-audio’s memory is used, not sys-usb’s.

Are you sure that the source of your problem is not in the conference system?

Singer · May 15, 2024, 2:56pm

I had the same problem when I was using a phone call app with a usb headset only. In this case the problem disappeared when I gave sys-usb 3000 MB RAM.

Earlier before sys-usb had only 400 MB of RAM. Until then I had the problems even if I only used USB disks.

apparatus · May 15, 2024, 2:58pm

You can try Qubes Video Companion:

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.

github.com/QubesOS/qubes-issues

Hyperminimal sys-usb

opened 02:04AM - 29 Dec 21 UTC

DemiMarie

T: enhancement P: major security hardware support C: usb proxy

[How to file a helpful issue](https://www.qubes-os.org/doc/issue-tracking/) #…## 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.

Singer · May 15, 2024, 3:16pm

Great, this works for me. And it seems to be more secure. Can I also use qubes video companion for an usb headset?

apparatus · May 15, 2024, 3:24pm

Maybe if you configure sys-usb as audiovm for your conferences qube: