USB input proxies

[Achim Patzner]

Hi

[No discussions about using wireless devices in secure environments, please...]

We've got a test system running r3.1 plus all updates where one of the users wanted to connect his wireless Logitech K400 (keyboard with built-in touch pad) and MX Master mouse which are aired with the same universal receiver. While all other devices are working on their own, bringing up two mice and one keyboard at the same time seems to be a problem. Two of the devices are working (usually the mice, but this is not deterministic), the third gets lost on the way.

It is (of course) working out of the box on other systems.

systemd-udev's actions upon insertion: https://oc.bnc.net/index.php/s/BzkgBhp8IR7uuHx
lsusb: https://oc.bnc.net/index.php/s/gJQInLcbwL9flL1
(links valid till 20160207)

Is there something else to log to provide enough data for a meaningful bug report? Right now I wouldn't know whether I should blame it on systemd or on the scripts Qubes added.


Achim

[Marek Marczykowski-Górecki]

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

On Sun, Jan 10, 2016 at 03:18:25PM +0100, Achim Patzner wrote:
> Hi
>
> [No discussions about using wireless devices in secure environments,
> please...]
>
> We've got a test system running r3.1 plus all updates where one of the
> users wanted to connect his wireless Logitech K400 (keyboard with
> built-in touch pad) and MX Master mouse which are aired with the same
> universal receiver. While all other devices are working on their own,
> bringing up two mice and one keyboard at the same time seems to be a
> problem. Two of the devices are working (usually the mice, but this is
> not deterministic), the third gets lost on the way.

I assume you're using USB VM, right?

Currently by default only mouse input proxy is enabled, for the keyboard
one it is set to "deny" in /etc/qubes-rpc/policy/qubes.InputKeyboard.
Take a look at input-proxy[1] documentation and read the security warning
first, before enabling the device. And if you decide to enable keyboard
proxy, take a look at InputMouse policy - how to allow it only from USB
VM.

> It is (of course) working out of the box on other systems.
>
> systemd-udev's actions upon insertion:
> https://oc.bnc.net/index.php/s/BzkgBhp8IR7uuHx
> lsusb: https://oc.bnc.net/index.php/s/gJQInLcbwL9flL1
> (links valid till 20160207)

The first link returns server error :(

> Is there something else to log to provide enough data for a meaningful
> bug report? Right now I wouldn't know whether I should blame it on
> systemd or on the scripts Qubes added.

I think the most probable cause is simply blocked (by default) keyboard
proxy. But it can be also something else: if logitech receiver expose
only one HID device, with all the functions (keyboard, mouse), you'll
need separate proxy service to handle all of them in single proxy
connection (it is possible to attach only one proxy connection to a
device). I don't think it is the case, since I see "bNumInterfaces 3" in
lsusb output (but not actual interface descriptors, so not sure).
Anyway, to do that, take a look at input-proxy documentation, or simply
existing proxy services and create new one, with different service name
(like qubes.InputKeyboardMouse) and configure it to run
"input-proxy-receiver --mouse --keyboard" at dom0 side. You'll also need
to disarm existing services to not conflict, but you can simply disable
them in qubes-rpc policy.

Also one important warning: "ask" in qrexec policy works only after user
login. So if you depend on such USB keyboard to enter login password,
you unfortunately need to set it to "allow", with all its consequences.

[1] https://github.com/qubesos/qubes-app-linux-input-proxy

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

iQEcBAEBCAAGBQJWknS/AAoJENuP0xzK19csVBQH/iQiHEihy4G+62HzZtDHKsN2
OA/T+Odpk2Ihf1RolLASybOtEgm+d+rJKIs1v4qiuvhfcWqPw6WwbryeeSbJr9Rc
YOxY4sJKU+a64wh9G5AbruhteiQx92gv8T382Ts0QCd1m7/QRb6wnZiouMW9nJYr
N/fvwyZOiBZvuurUvWvJ7MDh/q/SzmyD4RXuvDByYF2/U5lNbyHfH0vYyFXdS9Y7
1vd3CKjB+zshkCLroI0DwqoM08ZL34ZLgkCIMa0VVkblYZV1F8vz/DL8+XqbWzjr
zFbthaQ1A2KibMPhYDoNlgp55fBiZgScKAMxGqrALOJO+iDJwAJg1dtuyDUqQZI=
=A7Vf
-----END PGP SIGNATURE-----

[Achim Patzner]

Am 10.01.2016 um 16:11 schrieb Marek Marczykowski-Górecki:
> On Sun, Jan 10, 2016 at 03:18:25PM +0100, Achim Patzner wrote:
> > We've got a test system running r3.1 plus all updates where one of the
> > users wanted to connect his wireless Logitech K400 (keyboard with
> > built-in touch pad) and MX Master mouse which are aired with the same
> > universal receiver. While all other devices are working on their own,
> > bringing up two mice and one keyboard at the same time seems to be a
> > problem. Two of the devices are working (usually the mice, but this is
> > not deterministic), the third gets lost on the way.
>
> I assume you're using USB VM, right?

Yes.

> Currently by default only mouse input proxy is enabled, for the keyboard
> one it is set to "deny" in /etc/qubes-rpc/policy/qubes.InputKeyboard.

I enabled it before trying... I would have been wondering about

Jan 07 11:38:47 sys-usb systemd-udevd[5554]: RUN '/bin/systemctl
--no-block start qubes-input-sender-keyboard@%k.service'
/usr/lib/udev/rules.d/90-qubes-input-proxy.rules:4

and the fact that the keyboard is working sometimes. But we can't figure
out under which conditions.

> > It is (of course) working out of the box on other systems.
>
> > systemd-udev's actions upon insertion:
> > https://oc.bnc.net/index.php/s/BzkgBhp8IR7uuHx
> > lsusb: https://oc.bnc.net/index.php/s/gJQInLcbwL9flL1
> > (links valid till 20160207)
>
> The first link returns server error :(

I tried it and it worked form me... Well. 50 kB won't kill anyone. I hope.

> But it can be also something else: if logitech receiver expose
> only one HID device, with all the functions (keyboard, mouse), you'll
> need separate proxy service to handle all of them in single proxy
> connection (it is possible to attach only one proxy connection to a
> device).

Take a look at the insertion log; something else is going on. I asked
the user in question who had this set-up conected to a r3.0 machine
without sys-usb and it was doing its job.

> I don't think it is the case, since I see "bNumInterfaces 3" in
> lsusb output (but not actual interface descriptors, so not sure).

Any place to look for to get more interesting/precise information
(sorry, I've spent the last 20+ years as far away from Linux as I could)?

> Anyway, to do that, take a look at input-proxy documentation, or simply
> existing proxy services and create new one, with different service name
> (like qubes.InputKeyboardMouse) and configure it to run
> "input-proxy-receiver --mouse --keyboard" at dom0 side. You'll also need
> to disarm existing services to not conflict, but you can simply disable
> them in qubes-rpc policy.

I'll try that after you've taken a look at the udevd log; I'm a bit
unhappy about the /dev/input/event* that have been created but don't
have the slightest idea if the thing is broken or if some of the
Qubes-related scripts are causing a problem.

This

an 07 11:38:47 sys-usb systemd-udevd[5554]: starting '/bin/systemctl
--no-block start qubes-input-...@event4.service'
Jan 07 11:38:47 sys-usb systemd-udevd[5554]: Process '/bin/systemctl
--no-block start qubes-input-...@event3.service' succeeded.
Jan 07 11:38:47 sys-usb systemd-udevd[5554]: starting '/bin/systemctl
--no-block start qubes-input-s...@event3.service'
Jan 07 11:38:47 sys-usb systemd-udevd[5554]: Process '/bin/systemctl
--no-block start qubes-input-...@event4.service' succeeded.
Jan 07 11:38:47 sys-usb systemd-udevd[5554]: starting '/bin/systemctl
--no-block start qubes-input-s...@event4.service'
Jan 07 11:38:47 sys-usb systemd-udevd[5554]: Process '/bin/systemctl
--no-block start qubes-input-s...@event3.service' succeeded.

is definitely looking messy. Like in "my parents told me I could be
everything so I am".

> Also one important warning: "ask" in qrexec policy works only after user
> login. So if you depend on such USB keyboard to enter login password,
> you unfortunately need to set it to "allow", with all its consequences.

We found out the hard way 8-). Right now I'm looking for an affordable
small desktop system that has as many independent and accessible USBs as
possible...


Achim

[Marek Marczykowski-Górecki]

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

On Sun, Jan 10, 2016 at 06:02:11PM +0100, Achim Patzner wrote:
> Am 10.01.2016 um 16:11 schrieb Marek Marczykowski-Górecki:
> > On Sun, Jan 10, 2016 at 03:18:25PM +0100, Achim Patzner wrote:
> > But it can be also something else: if logitech receiver expose
> > only one HID device, with all the functions (keyboard, mouse), you'll
> > need separate proxy service to handle all of them in single proxy
> > connection (it is possible to attach only one proxy connection to a
> > device).
>
> Take a look at the insertion log; something else is going on. I asked
> the user in question who had this set-up conected to a r3.0 machine
> without sys-usb and it was doing its job.
>
> > I don't think it is the case, since I see "bNumInterfaces 3" in
> > lsusb output (but not actual interface descriptors, so not sure).
>
> Any place to look for to get more interesting/precise information
> (sorry, I've spent the last 20+ years as far away from Linux as I could)?

Full lsusb from the attachment is ok. I see there separate interfaces:
one for mouse and one for keyboard.

Yes, something is wrong here.

According to the log, both devices (event3 and event4) expose "mouse"
functionality, but only event4 - keyboard. I guess event4 is keyboard
with touchpad, while event3 is just a mouse.
So, probably a rule for mouse needs additional condition, which would
exclude keyboard+mouse devices, like ENV{ID_INPUT_KEYBOARD}!="1". It is
in /usr/lib/udev/rules.d/90-qubes-input-proxy.rules.

And then a separate rule+service for such device
(ENV{ID_INPUT_KEYBOARD}=="1", ENV{ID_INPUT_MOUSE}=="1"), because only
one proxy process can be attached to a single device.
Or if you don't want to use touchpad, using just qubes.InputKeyboard
should be fine (so no change here).

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

iQEcBAEBCAAGBQJWkrxDAAoJENuP0xzK19csYLcH/285mhhEFWZD3fNc1TLOammU
caDhvIQI/e1CEIfgy8tE6qsKatllQh+EGPJ5Uarba6G+pFk9HQ8JHSkzaWVG55W5
236eFrR10GIjzqph/hLkzJMqSa6dI4YmVuNmKU26Q6u/6F4VT9AM/ph0yo2Ngc8h
vnPVVOx7iWK2sHr8kNWq+KctPS+1mfgSaCN4iVgCgc/+6QTUIr6+8auY3Phkey0n
lHr3qL8NkdwL3wsXVOyuhIFeAdIDfzje1DKZLs/fbYYldB1cHyENMt5RjPolUB03
qxsD0GIzbc6JPOuebHptInXuPDdnCRFXr3/BR+ETRCXg4GLStDlo4HvEQbtjIms=
=4oSO
-----END PGP SIGNATURE-----

[Achim Patzner]

Am 10.01.2016 um 21:17 schrieb Marek Marczykowski-Górecki:

Full lsusb from the attachment is ok. I see there separate interfaces:
one for mouse and one for keyboard.

There should be three, actually: The keyboard, it's built-in trackpad and the additional mouse (those Logitech devices can connect to 6 separate devices and the devices could be composite devices like the keyboard so there could be even more appearing after connecting the USB receiver).

Which is what is making this so awkward: Sometimes it's the keyboard and the trackpad, sometimes keyboard and mouse but in 95% of the cases trackpad and mouse are appearing.

I don't know anything about udev as it is implemented in Linux but this feels like a race condition.

According to the log, both devices (event3 and event4) expose "mouse"
functionality, but only event4 - keyboard. I guess event4 is keyboard
with touchpad, while event3 is just a mouse.

The question behind this is: How did we get there?

Lines 76ff:

Jan 07 11:38:47 sys-usb systemd-udevd[5554]: seq 1276 queued, 'add' 'input'
Jan 07 11:38:47 sys-usb systemd-udevd[5554]: seq 1277 queued, 'add' 'input'
Jan 07 11:38:47 sys-usb systemd-udevd[5554]: seq 1278 queued, 'add' 'input'
Jan 07 11:38:47 sys-usb systemd-udevd[5554]: seq 1279 queued, 'add' 'hidraw'

Three input devices and a "hidraw", just as expected (well, _some_ fourth device had to appear as there is a communications channel to configure the wireless controller). But from there on everything happens in threes.

Is there anything I could find somewhere hidden in Xen's or Qubes' databases?

So, probably a rule for mouse needs additional condition, which would
exclude keyboard+mouse devices, like ENV{ID_INPUT_KEYBOARD}!="1". It is
in /usr/lib/udev/rules.d/90-qubes-input-proxy.rules.

I'll take a look at the script but I'd bet they are doing their job here or I would never get the keyboard connected. And I refuse to believe in the phase of the moon being the important parameter.

Or if you don't want to use touchpad, using just qubes.InputKeyboard
should be fine (so no change here).

I'd still want to use the mouse. I guess I'd go for another keyboard.


Achim

[Marek Marczykowski-Górecki]

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

I think the most useful would be examining what udev have at the end:
udevadm info -q all -n input/event3 (and the same for event4, and maybe
others if present).

> > So, probably a rule for mouse needs additional condition, which would
> > exclude keyboard+mouse devices, like ENV{ID_INPUT_KEYBOARD}!="1". It is
> > in /usr/lib/udev/rules.d/90-qubes-input-proxy.rules.
>
> I'll take a look at the script but I'd bet they are doing their job here
> or I would never get the keyboard connected. And I refuse to believe in
> the phase of the moon being the important parameter.

You should not ;)

If event4 expose both mouse and keyboard, both mouse and keyboard proxy
services are started for it. The first wins. So yes, it is a race
condition.

> > Or if you don't want to use touchpad, using just qubes.InputKeyboard
> > should be fine (so no change here).
>
> I'd still want to use the mouse. I guess I'd go for another keyboard.

I don't have such multi function device to test. But if/when you get
working configuration I can include it in the next version of the
package.

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

iQEcBAEBCAAGBQJWkswHAAoJENuP0xzK19csvzYH/RWTfxQosgAc7Ka7OQBzwsjv
pjC4knRobqfCI7nc7XFKN/05hKiA8tKyMH4TY3KT44SltGn3T6KCWL6Ly41H9nLn
8eEnV/a8f/jg9F2/2YvqKK0azJowQ4wzyP3o9J9mfc7W1jDmK6Xz5YnHBEXpqVfn
o/Dg9WH/L1HXCi4YcBqTOOamhTj9lOeXs8iESRrMOtSRafxOE39Nq7vy/U6x3Cor
hOMfq5fhFzXQqYwHvK4zBg58R8YXmrdd+6VB650nKQsnGoYk7+50SA21rC+BN2BD
snMCjAkLtfpp0O6TZc7fhKhVxVKzfcag0FeCNFfp9uDT1iAEGM6suqVN4h5yqKA=
=F+qg
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

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

Ok, my guess was right. The single device have both ID_INPUT_MOUSE and
ID_INPUT_KEYBOARD. Written a summary here:
https://github.com/QubesOS/qubes-issues/issues/1618

Working solution is to add ENV{ID_INPUT_KEYBOARD}!="1" to the rule
starting mouse service (in template / sys-usb), then add "--mouse" to
/etc/qubes-rpc/qubes.InputKeyboard in dom0 to allow also keyboard events
there.

After deciding on some details (see linked ticket) it would go into the
next package version.

> > > Or if you don't want to use touchpad, using just qubes.InputKeyboard
> > > should be fine (so no change here).
> >
> > I'd still want to use the mouse. I guess I'd go for another keyboard.
>
> I don't have such multi function device to test. But if/when you get
> working configuration I can include it in the next version of the
> package.

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

iQEcBAEBCAAGBQJWlrciAAoJENuP0xzK19cshYwH/jLrGlfGGXiqPJMD92yFIq0F
245xiqFw6sgd71gjXQEUeWN8b41MDdPOVthN+nT3v2F3L4HGo3OHmytclLEal77c
Q3Sjx2hXyFnL2rYUVJUJ28xVNZRHfrPeDNQtCNMqiai5C7BUj4FuxfvBDkrKKapm
GyS/9gp2n6y9PS0x8qgone3gvoYaKVnCcRZtrj23gAYR2Z7L5dlwxaOPS5SWfMvv
VNBYLS96bVRIVzU7A7hyvIAk0jGTyFUk6u3eZ0qSCBzahGwrl/sSgQmkhSME8PAa
cBrRhejSVct+OclX1IKMiEKSvpXEtxbOCduR6BaeL2fkUJn33qSZ6t380ub9UCk=
=7aPO
-----END PGP SIGNATURE-----