Re: [qubes-devel] Routing Qubes master audio to a VM

2017-06-19 Thread 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

Re: [qubes-devel] Routing Qubes master audio to a VM

2017-06-19 Thread 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

Re: [qubes-devel] Routing Qubes master audio to a VM

2017-06-18 Thread Marek Marczykowski-Górecki
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, Jun 18, 2017 at 04:17:02PM +0100, Matt McCutchen wrote: > 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

Re: [qubes-devel] Routing Qubes master audio to a VM

2017-06-18 Thread 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

[qubes-devel] Routing Qubes master audio to a VM

2017-06-18 Thread 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