-
-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AudioVM outside of dom0 #1590
Comments
Good idea. Dedicated SoundVM would be good idea. Reusing NetVM isn't good because this VM will have access to the audio hardware, including microphone. A correction to the description:
But still, having even less hardware "in dom0" is a good idea. It would also ease things like USB sound cards or bluetooth headphones - when you use USB VM as SoundVM. |
I don't think there is much attack surface there, but it still might be useful, e.g. for optional streaming audio output over network. In such case, sound output should probably use a different VM than sound input. But I am not sure if a major improvement can be done there without too much of work. (E.g. I am not sure if network sound is so important for many users. And I am not sure if just moving the sound to a separate VM brings enough advantages.) |
This is why I've assigned "Far in the future" milestone ;) Anyway changes on pulseaudio side would be trivial - just change target domain ID. Much more work would be needed on configuration/management side, like tools to choose which VM would be sound VM. |
|
Has anything been implemented regarding this issue? Has it been decided how to approach this issue? I would strongly propose any solution that allows using sys-usb as AudioVM to circumvent the need for USB forwarding of audio hardware. I definitely want to do this for myself one way or another. (USB forwarding does not agree with my audio hardware.) So I'd be happy to contribute implementation. |
I ended up deciding not to work on this. |
Thanks for the update, @mattmccutchen. @tfm1, if you decide to start working on this, please let us know. |
Audio VM may not be dom0, so lets allow control it through qrexec QubesOS/qubes-issues#1590
Call qrexec service for control, read state from QubesDB. QubesOS/qubes-issues#1590 QubesOS/qubes-issues#4547
Audio VM may not be dom0, so lets allow control it through qrexec QubesOS/qubes-issues#1590
Call qrexec service for control, read state from QubesDB. QubesOS/qubes-issues#1590 QubesOS/qubes-issues#4547
This is partially implemented in: Also, gui-daemon component (including backend side of pulseaudio) is already built for VM (as part of #833 ). I'll also add gui-agent-linux building for dom0, so the other side would also be available everywhere. The missing part is some tooling to integrate it all together, with a simple switch for the user. This means:
|
This is useful if GUI VM and/or Audio VM is not the same as dom0. Then, frontend is useful in dom0, connecting to a backend running elsewhere. The audio part is also useful for more complex configurations, like proxying audio from one VM, through dom0, to sys-usb, to a USB/bluetooth connected audio output. QubesOS/qubes-issues#1590
Audio VM may not be dom0, so lets allow control it through qrexec QubesOS/qubes-issues#1590
Call qrexec service for control, read state from QubesDB. QubesOS/qubes-issues#1590 QubesOS/qubes-issues#4547
Call qrexec service for control, read state from QubesDB. QubesOS/qubes-issues#1590 QubesOS/qubes-issues#4547
Is there a way to test this? |
Is there a way to implement this into an already running Qubes instance? |
During testing, I came to the point when I set up PCI passthrough for my audio device. Unfortunately, it seems to need ACPI NHLT table: user@sys-audio: $ sudo dmesg | grep -i nhlt Is there any way to enable NHLT table in DomU? |
You probably could copy it from dom0 ( |
I can't recognize more info about why it actually failed, so this is the full output of 'dmesg' in my debian 11 test-vm:
This is from a ThinkPad X13. |
So right now I think that:
Worth closing this issue? |
We just need controller for the speaker as well, not just for mics, due to this issue. |
I'm using my sys-net as AudioVM so I can use a bluetooth headshet. I assume the alternative proposal will be to create a sys-bluetooth (#8994) that somehow will send the audio the dom0. I will love to see this working. |
Do not interrupt enumerating VMs if one gets policy deny. QubesOS/qubes-issues#1590
Do not even consider starting audio/gui daemons for local domain (like sys-gui's gui-daemon insider sys-gui itself), that doesn't make sense. Skipping it early avoids also trying to access properties guivm/audiovm doesn't have access to. QubesOS/qubes-issues#1590
Do not even consider starting audio/gui daemons for local domain (like sys-gui's gui-daemon insider sys-gui itself), that doesn't make sense. Skipping it early avoids also trying to access properties guivm/audiovm doesn't have access to. QubesOS/qubes-issues#1590
Do not interrupt enumerating VMs if one gets policy deny. QubesOS/qubes-issues#1590
Currently, PulseAudio is running in the VMs and passing all the audio data over the network to a PulseAudio instance running on dom0.
However, this provides an unnecessary possibility for attacks on dom0, perhaps even between domU instances.
I believe that a similar set-up to NetVM can be equally powerful without providing this possibility for an attack.
I must say, this works very beautifully and is very user friendly. I've had Linux distros running on bare metal work less well out of the box with audio.
The text was updated successfully, but these errors were encountered: