Arguments in favor of sys-audio/AudioVM?

[queen]

What arguments or use cases support the use of sys-audio, aside from security?

I just read these posts:

Audio qube

An audio qube acts as a secure handler for potentially malicious audio devices, preventing them from coming into contact with dom0 (which could otherwise be fatal to the security of the whole system). It thereby mitigates some of the security risks of using USB devices and Bluetooth devices. Nonetheless, we strongly recommend carefully reading the security warning on USB input devices devices before proceeding. With an audio qube, many kinds of devices can be used (that previously were eit…

Proper guide on how to use sys-audio (AudioVM) must be created

UPDATED (TL;DR): The best currently existing Guide about how to create and use audio qube (sys-audio) is made by @neowutran and available here: Problem Currently no proper guide exists on how to create and use sys-audio (AudioVM) in R4.1/R4.2. Qubes OS Documentation does not have a single article about it. Qubes Community Documentations also has nothing at all about it. Consequences So many people are trying to create sys-audio qube to listen to Bluetooth headphones and almost nothing help…

[neowutran]

Aside from security, mostly USB devices support + bluetooth device support

[queen]

@neowutran

USB devices support + bluetooth device support

But don’t I have that with sys-usb (without sys-audio) too?
Or does sys-audio offer anything more or better in this context?

[Atrate]

Do you mean that you’d just set-up sys-usb as an AudioVM for all your qubes?

[queen]

No, I don’t have AudioVM. I mean the standard Qubes OS with sys-net and sys-usb. All USB devices are connected to sys-usb, right?

What would be better or different if these devices were connected to sys-audio? (Except that the USB devices with audio are separated from the other USB devices.)

I’m seriously considering it, and sys-audio sounds appealing. But I don’t want to run into new problems. There are already quite a few GitHub issues related to sys-audio like Audio stuttering with audiovm · Issue #10063 · QubesOS/qubes-issues · GitHub.

So, naturally, I’m wondering: What can sys-audio do that’s different or better than what I currently have? In terms of value for money: the balance between problems and features.

[random1]

Currently to use usb or bluetooth audio devices, they need to be directly attached to the qube using them. With sys-audio, they don’t. They are attached to sys-audio instead. And the qubes send their audio to sys-audio instead of dom0 like default.

[Talkabout]

This is not correct if we set sys-usb as audiovm. That is how my configuration currently works. The audio/bluetooth devices are attached to sys-usb (like in standard configuration I guess?) and other qubes use sys-usb as audovm. The question is what advantages sys-audio brings except from separating audio/bluetooth devices from the other ones attached to sys-usb.

[queen]

I’ll try to sketch it out so we’re all on the same page.

Initial situation:

[user@dom0 ~]$ lspci
00:00.0 Host bridge: Intel Corporation Device 4640 (rev 02)
00:02.0 VGA compatible controller: Intel Corporation AlderLake-S GT1 (rev 0c)
00:0a.0 Signal processing controller: Intel Corporation Platform Monitoring Technology (rev 01)
00:0e.0 RAID bus controller: Intel Corporation Volume Management Device NVMe RAID Controller
00:14.0 USB controller: Intel Corporation Device 7a60 (rev 11)
00:14.2 RAM memory: Intel Corporation Device 7a27 (rev 11)
00:15.0 Serial bus controller: Intel Corporation Device 7a4c (rev 11)
00:16.0 Communication controller: Intel Corporation Device 7a68 (rev 11)
00:17.0 SATA controller: Intel Corporation Device 7a62 (rev 11)
00:1a.0 PCI bridge: Intel Corporation Device 7a48 (rev 11)
00:1c.0 PCI bridge: Intel Corporation Device 7a38 (rev 11)
00:1c.2 PCI bridge: Intel Corporation Device 7a3a (rev 11)
00:1d.0 PCI bridge: Intel Corporation Device 7a36 (rev 11)
00:1f.0 ISA bridge: Intel Corporation Device 7a06 (rev 11)
00:1f.3 Audio device: Intel Corporation Device 7a50 (rev 11)
00:1f.4 SMBus: Intel Corporation Device 7a23 (rev 11)
00:1f.5 Serial bus controller: Intel Corporation Device 7a24 (rev 11)
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller (rev 05)

The audio device on the motherboard is:
00:1f.3 Audio device: Intel Corporation Device 7a50 (rev 11)
All audio devices connected via USB run through:
00:14.0 USB controller: Intel Corporation Device 7a60 (rev 11)

Four scenarios:

1. sys-audio no & sys-usb no
   00:1f.3 Internal Audio device (Mainboard) → dom0
   USB non-audio device → 00:14.0 USB controller → dom0
   USB audio device → 00:14.0 USB controller → dom0

2. sys-audio no & sys-usb yes
   00:1f.3 Internal Audio device (Mainboard) → dom0
   USB non-audio device → 00:14.0 USB controller → sys-usb
   USB audio device → 00:14.0 USB controller → sys-usb

3. sys-audio yes & sys-usb yes
   00:1f.3 Internal Audio device (Mainboard) → sys-audio
   USB non-audio device → 00:14.0 USB controller → sys-usb
   USB audio device → 00:14.0 USB controller → sys-usb

4. sys-audio yes & sys-usb no
   00:1f.3 Internal Audio device (Mainboard) → sys-audio
   USB non-audio device → 00:14.0 USB controller → dom0
   USB audio device → 00:14.0 USB controller → dom0

So what are the advantages?
What’s so great about it?
Or am I missing something?

[queen]

@Talkabout

except from separating audio/bluetooth devices from the other ones attached to sys-usb.

You can’t separate them if they’re connected to the same USB controller.
Or are we talking about two different things?

[Talkabout]

Separating on VM level. Hardware level is nothing Qubes controls, but at least virtually those can be separated by XEN boundries.

[queen]

@Talkabout

Separating on VM level. Hardware level is nothing Qubes controls, but at least virtually those can be separated by XEN boundries.

@Talkabout

The question is what advantages sys-audio brings except from separating audio/bluetooth devices from the other ones attached to sys-usb.

But what do you mean by “separate”?
How do you plan to separate them if everything runs through sys-usb and the same USB controller anyway?

[Talkabout]

In my case I consider the bluetooth and audio hardware of the system kind of “connected”, as I am using bluetooth headphones and microphone for calls. This means that I would assign bluetooth and audio hardware to sys-audio. Now, if sys-usb has usb controllers and a device would be able to bring maliscious logic to sys-usb, it would not be possible to spread via bluetooth. This, from my point of view, is kind of a separation which makes sys-usb more secure. But that is only an assumption, I cannot tell if via audio channels things can also be infected.

As mentioned above I don’t have sys-audio, only sys-usb, which I am using as audiovm. My question would be also if there is a stronger argument to introduce sys-audio than having this separation.

[phceac]

@Talkabout

a stronger argument to introduce sys-audio

I am not fully sure what type of argument you are seeking, but here is a thought experiment:

Imagine there is some very serious flaw in the audiovm qrexec protocol or in a linux kermel audio driver which allows a qube to take over its audiovm.

If the audiovm is sys-usb, then maybe the qube now has control or access to keyboard, mouse, external disks, or more.

If the audiovm is sys-audio, then the qube must find another - very serious - flaw to escape further.

Which configuration should a reasonable qubes user choose?

For me, this seems to be a strong argument for sys-audio. I am asking myself why I did not try making one yet.

[queen]

Your scenario only applies if you’re not using any USB audio devices.
If you have sys-usb and sys-audio, then all USB devices run through sys-usb.

[Talkabout]

Thanks for this example, it makes sense. At the moment sys-usb works great as my audiovm, and as I had a lot of issues over the time with audio, which are now gone, I’d rather not take the risk of introducing anything like it again

[phceac]

@queen

you have sys-usb and sys-audio, then all USB devices run through sys-usb.

This is true, but for it to make a difference with sys-audio the bad qube must have a way through the usb device. For an audio subsystem defect, it must still get into sys-audio and then try to get to sys-usb.

[James369]

People running debian-minimal sys-audio do you notice any lag, artifacts, or quality improvements or degradations in their audio quality? Compared to standard?

[fb2043]

@queen

What arguments or use cases support the use of sys-audio, aside from security?

@fb2043

in general, malicious peripherals (usually USB devices) are a real attack vector. the other sensible use case for sys-audio is running DSP software (like an equalizer, noise suppressor etc), which you wouldn’t want to be doing in dom0

---

@James369

People running debian-minimal sys-audio do you notice any lag, artifacts, or quality improvements or degradations in their audio quality? Compared to standard?

I’ve been using a debian-minimal sys-audio a long time with no issues

[queen]

@fb2043

use case for sys-audio is running DSP software (like an equalizer, noise suppressor etc), which you wouldn’t want to be doing in dom0

That’s a good point!

[James369]

true! Curious what FOSS options people use for that?

The sound quality of my (default) audio setup leaves a lot to be desired.

(like its coming out of a tin-can)