PulseAudio doesn't need to run in dom0

[coypoop]

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.

[marmarek]

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:

• "over the network" - not a network (dom0 has no network), but vchan (socket-like inter-VM connection)
• there is no pulseaudio protocol there, only raw samples, with predefined format (2 channels, S16LE, 44.1kHz), so the attack surface is quite small

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.

[marmarek]

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:

• "over the network" - not a network (dom0 has no network), but vchan (socket-like inter-VM connection)
• there is no pulseaudio protocol there, only raw samples, with predefined format (2 channels, S16LE, 44.1kHz), so the attack surface is quite small

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.

[v6ak]

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.)

[v6ak]

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.)

[marmarek]

But I am not sure if a major improvement can be done there without too much of work.

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.

[marmarek]

But I am not sure if a major improvement can be done there without too much of work.

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.

[mattmccutchen]

I'm planning to work on this soon. See thread.

[mattmccutchen]

I'm planning to work on this soon. See thread.