Routing Qubes master audio to a VM

[Matt McCutchen]

I have a Bluetooth headset that I'd like to use with multiple VMs.
Assigning the Bluetooth controller to each VM (at either the PCI or USB
level) when I want to use that VM isn't an ideal solution because each
VM needs a pairing key to secure the Bluetooth connection to the
headset.  If I copy the same pairing key to all of the VMs, then an
attacker within Bluetooth range who had access to one VM could
intercept the audio connection when I'm using the headset with a
different VM. It might work to have each VM use a different Bluetooth
device address and share a separate pairing key with the headset, but
I'm liable to reach the headset's limit on number of paired devices.

So I'd like to try to implement a better solution: assigning the
Bluetooth controller to one VM (call it the "AudioVM") and routing the
Qubes master audio source and sink to that VM. I can think of two
basic ways to do this:

1. Run all the pacat-simple-vchan processes in the AudioVM instead of
Dom0. Will it just work for client VMs to specify the domain ID of the
AudioVM when creating the vchan, or are there restrictions? A new
protocol would be needed for Dom0 to control the lifecycle and the
recording-allowed state of the pacat-simple-vchan processes.

2. Run one more module-vchan-sink / pacat-simple-vchan pair (but
without recording restrictions) from Dom0 to the AudioVM. Might
increase latency.

Are there any issues I should be aware of before starting
implementation? If I'm just doing this for myself, I'm inclined to try
#2 first because it should require less new code and high latency isn't
a big problem for me (as long as it's stable, which it has been so far:
I play StepMania!). But if Qubes maintainers are interested in having
the feature upstream and prefer #1, I'll do that instead.

I found a previous thread about roughly the same problem. The author
proposed approach #2, but apparently it wasn't implemented.

https://groups.google.com/d/topic/qubes-users/GrN5OhCwttw/discussion

Thanks,
Matt

[Matteo]

> If I copy the same pairing key to all of the VMs, then an
> attacker within Bluetooth range who had access to one VM could
> intercept the audio connection when I'm using the headset with a
> different VM.

If an attacker is within Bluetooth range he can probably use a
microphone and listen to you without "intercepting" anything.
bluetooth has a very short range.
if there is a simple solution good; but i wouldn't worry about such attack.
or am i wrong?

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

#1 is definitely better for latency, but also from architecture point of
view - ultimately it will allow to get rid of one more thing out of dom0
(either to dedicated AudioVM, or to GUI VM).

Technically, you need to pass domain ID to vchan initialization in
module-vchan-sink (gui-agent-linux/pulse/module-vchan-sink.c). I think
you should use Qubes DB to let VMs know this ID (and set it during VM
startup in dom0, based on some VM property).

Recording
control is currently implemented over dbus (session bus). It's easy to
expose it over qrexec - just add one/two qrexec services with
appropriate dbus-send commands.

For good UX, there should be shortcut to start audio mixer there and
also some audio applet. And probably appropriate handling of volume
control keys (up/down/mute). All over qrexec.

Some references:
https://github.com/QubesOS/qubes-issues/issues/1590

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJZRszGAAoJENuP0xzK19csNpUH/i12ttPJCp5ltfSV1Pb/0e0h
W35OSvCl0DROF7ewLOz5++flQP+Tnn+ppcc3Okd/QOqPakvSYCYrx9XM9PY1IFAV
oP2y+yURZ0XA2OGO9HhE+1IBTwJgaYAQFGp68iBWr7FPaNPSm5NhGK8adWT8nK+9
zsskhqAKEFfqVTquqRcdsT4aMfZyCtRf5qloKkRRzatFHC7EQlt2RRMx5wpMY+CS
3GQZXkRtDt/A7qF3KElCpokEEQxoXg01WYcmDa638QtHR5XaQpcmGyIpHGABUqnn
Fzdl9rcuNbJcBXbJ5S+XpQQ0wZ+Hlnm+6Hy10ouuzqmXySS+TorYBpGSbbkGgFQ=
=+TRr
-----END PGP SIGNATURE-----

[Matt McCutchen]

On Sun, 2017-06-18 at 20:56 +0200, Marek Marczykowski-Górecki wrote:
> #1 is definitely better for latency, but also from architecture point of
> view - ultimately it will allow to get rid of one more thing out of dom0
> (either to dedicated AudioVM, or to GUI VM).

Thanks for the helpful information!

> Technically, you need to pass domain ID to vchan initialization in
> module-vchan-sink (gui-agent-linux/pulse/module-vchan-sink.c). I think
> you should use Qubes DB to let VMs know this ID (and set it during VM
> startup in dom0, based on some VM property).

I was assuming there would be a single AudioVM. I guess it might not
be that much more complicated to have each VM specify an AudioVM, but
is there a reasonable use case?

> Recording
> control is currently implemented over dbus (session bus). It's easy to
> expose it over qrexec - just add one/two qrexec services with
> appropriate dbus-send commands.

OK. Some questions:

1. Currently, Qubes Manager monitors the recording status via a D-Bus
signal, which is nice because Qubes Manager will update properly if
another process sets the D-Bus property. Are you prepared to give up
that functionality, or can you propose another way to implement it?

2. How should dom0 tell pacat-simple-vchan to exit when the VM shuts
down? An additional D-Bus method?

One way to solve both problems would be to have a pacat "controller"
process in Dom0 that executes pacat-simple-vchan in the AudioVM and
keeps pipes open to and from it. The controller would then provide the
existing D-Bus API and communicate with pacat-simple-vchan via a simple
text-based protocol. However, I don't know if this is an architectural
style we'd want to encourage in general.

> For good UX, there should be shortcut to start audio mixer there and
> also some audio applet. And probably appropriate handling of volume
> control keys (up/down/mute). All over qrexec.

I'm not sure I would bother with this just for myself, but I might do
it if it makes the difference between the feature being accepted
upstream or not. ISTM that even if we aren't completely happy with the
UX to advertise the feature to all users, we could offer it via qvm-
prefs or something.

Matt

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mon, Jun 19, 2017 at 09:55:35AM +0100, Matt McCutchen wrote:
> On Sun, 2017-06-18 at 20:56 +0200, Marek Marczykowski-Górecki wrote:
> > #1 is definitely better for latency, but also from architecture point of
> > view - ultimately it will allow to get rid of one more thing out of dom0
> > (either to dedicated AudioVM, or to GUI VM).
>
> Thanks for the helpful information!
>
> > Technically, you need to pass domain ID to vchan initialization in
> > module-vchan-sink (gui-agent-linux/pulse/module-vchan-sink.c). I think
> > you should use Qubes DB to let VMs know this ID (and set it during VM
> > startup in dom0, based on some VM property).
>
> I was assuming there would be a single AudioVM. I guess it might not
> be that much more complicated to have each VM specify an AudioVM, but
> is there a reasonable use case?

I was rather thinking about ability to set "none" there for some VMs.
But I'm not strongly attached to this idea, because without additional
code, it would only hide AudioVM (if one guess its ID, it would
connect), not prevent the connection.

> > Recording
> > control is currently implemented over dbus (session bus). It's easy to
> > expose it over qrexec - just add one/two qrexec services with
> > appropriate dbus-send commands.
>
> OK. Some questions:
>
> 1. Currently, Qubes Manager monitors the recording status via a D-Bus
> signal, which is nice because Qubes Manager will update properly if
> another process sets the D-Bus property. Are you prepared to give up
> that functionality, or can you propose another way to implement it?
>
> 2. How should dom0 tell pacat-simple-vchan to exit when the VM shuts
> down? An additional D-Bus method?

This will happen automatically - pacat-simple-vchan will detect when
target VM disappears.

> One way to solve both problems would be to have a pacat "controller"
> process in Dom0 that executes pacat-simple-vchan in the AudioVM and
> keeps pipes open to and from it. The controller would then provide the
> existing D-Bus API and communicate with pacat-simple-vchan via a simple
> text-based protocol. However, I don't know if this is an architectural
> style we'd want to encourage in general.

When moving it out of dom0, better not depend on such controller there.
For monitoring, we can have additional qrexec service, which fill
function as a pipe in your idea, but terminated with something based on
dbus-monitor (in practice probably a simple python script). And Qubes
Manager (whether running in dom0 or GUI VM) will connect to it to
monitor audio status. And use separate qrexec calls to control audio.

> > For good UX, there should be shortcut to start audio mixer there and
> > also some audio applet. And probably appropriate handling of volume
> > control keys (up/down/mute). All over qrexec.
>
> I'm not sure I would bother with this just for myself, but I might do
> it if it makes the difference between the feature being accepted
> upstream or not. ISTM that even if we aren't completely happy with the
> UX to advertise the feature to all users, we could offer it via qvm-
> prefs or something.

Yes :)

This also means that exposing on qrexec functionality currently provided
through dbus can be done in another iteration. And for 4.1, where
probably GUI VM (with Qubes Manager) will be the same as Audio VM, it
may still not be needed.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJZR52nAAoJENuP0xzK19cstqUH/1CPHl2AP5rSYlrB8lYeuGuD
ozUQeDpNuUeG0QeUBswDZbQPfaaF1TpqXFRope81xs/du6E3m0KLYx36Ni/yTPyR
pu800bOlzCr+BQl/SoRb27rgZ2A+OCoxo6oXidbH0VKCwj0RiiC2l9+QqJLGpTk1
OWQHcAvnEREVXxRPtgw0IiKy2S18QxcDEho4RRVfDnkNIu/cfWSx3CLlI0RL4GWj
DTGViIZ8S05OAoorX7M8U8RwB2LHy/+lRCkbMjiYFOTDRkqortVglFMkMx4NGDnj
/Ko1hIOTbAwQ6hJ3gV9mwSbmeSrjqFkVZ0la1E5kfFgb+vIwOEFTjtoSA4mdG00=
=yFiJ
-----END PGP SIGNATURE-----