| Message ID | 1377602704-23301-1-git-send-email-dh.herrmann@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi David, Sorry for reviving this old thread (I didn't find more recent patch series at first glance or have not been using the proper keyword while searching). At FOSDEM 2015 last Sunday Hans presented libinput X input driver and mentioned evdev FD revoking. A question I raise was how are input devices to be put in a reasonable state on FD revoking? The specific case of force-feedback game-pads/wheels and the like that libinput is expected to pass through to games was the main trigger. Assume: - Game triggers some force-feedback event like vibrating device - Game looses focus and gets its evdev FD revoked - Newly focused application does not care about the game-pad/wheel How should the force-feedback activity get stopped on that focus change and thus FD revoking? Is the game expected to react before the FD being revoked (how long to wait?) or should the kernel somehow reset the device to a sane state on revoke (and if so, under which conditions?). Should some other evdev devices also receive a special treatment to reset them into a known/idle state (eventually LEDs on keyboards, beep, ...)? Bruno On Tue, 27 August 2013 David Herrmann <dh.herrmann@gmail.com> wrote: > If we have multiple sessions on a system, we normally don't want > background sessions to read input events. Otherwise, it could capture > passwords and more entered by the user on the foreground session. This is > a real world problem as the recent XMir development showed: > http://mjg59.dreamwidth.org/27327.html > > We currently rely on sessions to release input devices when being > deactivated. This relies on trust across sessions. But that's not given on > usual systems. We therefore need a way to control which processes have > access to input devices. > > With VTs the kernel simply routed them through the active /dev/ttyX. This > is not possible with evdev devices, though. Moreover, we want to avoid > routing input-devices through some dispatcher-daemon in userspace (which > would add some latency). > > This patch introduces EVIOCREVOKE. If called on an evdev fd, this revokes > device-access irrecoverably for that *single* open-file. Hence, once you > call EVIOCREVOKE on any dup()ed fd, all fds for that open-file will be > rather useless now (but still valid compared to close()!). This allows us > to pass fds directly to session-processes from a trusted source. The > source keeps a dup()ed fd and revokes access once the session-process is > no longer active. > Compared to the EVIOCMUTE proposal, we can avoid the CAP_SYS_ADMIN > restriction now as there is no way to revive the fd again. Hence, a user > is free to call EVIOCREVOKE themself to kill the fd. > > Additionally, this ioctl allows multi-layer access-control (again compared > to EVIOCMUTE which was limited to one layer via CAP_SYS_ADMIN). A middle > layer can simply request a new open-file from the layer above and pass it > to the layer below. Now each layer can call EVIOCREVOKE on the fds to > revoke access for all layers below, at the expense of one fd per layer. > > There's already ongoing experimental user-space work which demonstrates > how it can be used: > http://lists.freedesktop.org/archives/systemd-devel/2013-August/012897.html -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi On Wed, Feb 4, 2015 at 2:12 PM, Bruno Prémont <bonbons@linux-vserver.org> wrote: > Hi David, > > Sorry for reviving this old thread (I didn't find more recent patch series > at first glance or have not been using the proper keyword while searching). > > At FOSDEM 2015 last Sunday Hans presented libinput X input driver and mentioned > evdev FD revoking. > > A question I raise was how are input devices to be put in a reasonable > state on FD revoking? > The specific case of force-feedback game-pads/wheels and the like that libinput > is expected to pass through to games was the main trigger. > > Assume: > - Game triggers some force-feedback event like vibrating device > - Game looses focus and gets its evdev FD revoked > - Newly focused application does not care about the game-pad/wheel > > How should the force-feedback activity get stopped on that focus change > and thus FD revoking? > Is the game expected to react before the FD being revoked (how long to > wait?) or should the kernel somehow reset the device to a sane state on > revoke (and if so, under which conditions?). > > Should some other evdev devices also receive a special treatment to reset > them into a known/idle state (eventually LEDs on keyboards, beep, ...)? We call input_device_flush() on EVIOCREVOKE, which stops any ongoing FF owned by this handle. Same should be done for any per-handle state. However, LEDs are not associated with a handle, so it will stay the same. Applications are expected to re-sync their LEDs after they revoked a file-descriptor of someone else. Thanks David -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi David, On Wed, 04 February 2015 David Herrmann wrote: > On Wed, Feb 4, 2015 at 2:12 PM, Bruno Prémont wrote: > > Hi David, > > > > Sorry for reviving this old thread (I didn't find more recent patch series > > at first glance or have not been using the proper keyword while searching). > > > > At FOSDEM 2015 last Sunday Hans presented libinput X input driver and mentioned > > evdev FD revoking. > > > > A question I raise was how are input devices to be put in a reasonable > > state on FD revoking? > > The specific case of force-feedback game-pads/wheels and the like that libinput > > is expected to pass through to games was the main trigger. > > > > Assume: > > - Game triggers some force-feedback event like vibrating device > > - Game looses focus and gets its evdev FD revoked > > - Newly focused application does not care about the game-pad/wheel > > > > How should the force-feedback activity get stopped on that focus change > > and thus FD revoking? > > Is the game expected to react before the FD being revoked (how long to > > wait?) or should the kernel somehow reset the device to a sane state on > > revoke (and if so, under which conditions?). > > > > Should some other evdev devices also receive a special treatment to reset > > them into a known/idle state (eventually LEDs on keyboards, beep, ...)? > > We call input_device_flush() on EVIOCREVOKE, which stops any ongoing > FF owned by this handle. Same should be done for any per-handle state. > However, LEDs are not associated with a handle, so it will stay the > same. Applications are expected to re-sync their LEDs after they > revoked a file-descriptor of someone else. Thanks for the explanation! It answers my question. So all that's needed should be there unless a specific kernel-side driver does not properly have state associated to handles. > Thanks > David Bruno -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c index d2b34fb..2ea70ec 100644 --- a/drivers/input/evdev.c +++ b/drivers/input/evdev.c @@ -48,6 +48,7 @@ struct evdev_client { struct evdev *evdev; struct list_head node; int clkid; + bool revoked; unsigned int bufsize; struct input_event buffer[]; }; @@ -164,6 +165,9 @@ static void evdev_pass_values(struct evdev_client *client, struct input_event event; bool wakeup = false; + if (client->revoked) + return; + event.time = ktime_to_timeval(client->clkid == CLOCK_MONOTONIC ? mono : real); @@ -795,6 +799,15 @@ static int evdev_handle_mt_request(struct input_dev *dev, return 0; } +static int evdev_revoke(struct evdev *evdev, struct evdev_client *client, + struct file *file) +{ + client->revoked = true; + input_flush_device(&evdev->handle, file); + + return 0; +} + static long evdev_do_ioctl(struct file *file, unsigned int cmd, void __user *p, int compat_mode) { @@ -808,12 +821,27 @@ static long evdev_do_ioctl(struct file *file, unsigned int cmd, unsigned int size; int error; - /* First we check for fixed-length commands */ + /* First check for ioctls allowed while revoked */ switch (cmd) { case EVIOCGVERSION: return put_user(EV_VERSION, ip); + case EVIOCREVOKE: + if (p) + return -EINVAL; + else + return evdev_revoke(evdev, client, file); + + default: + if (client->revoked) + return -EACCES; + break; + } + + /* Then check for fixed-length commands */ + switch (cmd) { + case EVIOCGID: if (copy_to_user(p, &dev->id, sizeof(struct input_id))) return -EFAULT; diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h index 2fb6fae..d61c61c 100644 --- a/include/uapi/linux/input.h +++ b/include/uapi/linux/input.h @@ -152,6 +152,7 @@ struct input_keymap_entry { #define EVIOCGEFFECTS _IOR('E', 0x84, int) /* Report number of effects playable at the same time */ #define EVIOCGRAB _IOW('E', 0x90, int) /* Grab/Release device */ +#define EVIOCREVOKE _IOW('E', 0x91, int) /* Revoke device access */ #define EVIOCSCLOCKID _IOW('E', 0xa0, int) /* Set clockid to be used for timestamps */
If we have multiple sessions on a system, we normally don't want background sessions to read input events. Otherwise, it could capture passwords and more entered by the user on the foreground session. This is a real world problem as the recent XMir development showed: http://mjg59.dreamwidth.org/27327.html We currently rely on sessions to release input devices when being deactivated. This relies on trust across sessions. But that's not given on usual systems. We therefore need a way to control which processes have access to input devices. With VTs the kernel simply routed them through the active /dev/ttyX. This is not possible with evdev devices, though. Moreover, we want to avoid routing input-devices through some dispatcher-daemon in userspace (which would add some latency). This patch introduces EVIOCREVOKE. If called on an evdev fd, this revokes device-access irrecoverably for that *single* open-file. Hence, once you call EVIOCREVOKE on any dup()ed fd, all fds for that open-file will be rather useless now (but still valid compared to close()!). This allows us to pass fds directly to session-processes from a trusted source. The source keeps a dup()ed fd and revokes access once the session-process is no longer active. Compared to the EVIOCMUTE proposal, we can avoid the CAP_SYS_ADMIN restriction now as there is no way to revive the fd again. Hence, a user is free to call EVIOCREVOKE themself to kill the fd. Additionally, this ioctl allows multi-layer access-control (again compared to EVIOCMUTE which was limited to one layer via CAP_SYS_ADMIN). A middle layer can simply request a new open-file from the layer above and pass it to the layer below. Now each layer can call EVIOCREVOKE on the fds to revoke access for all layers below, at the expense of one fd per layer. There's already ongoing experimental user-space work which demonstrates how it can be used: http://lists.freedesktop.org/archives/systemd-devel/2013-August/012897.html Signed-off-by: David Herrmann <dh.herrmann@gmail.com> --- drivers/input/evdev.c | 30 +++++++++++++++++++++++++++++- include/uapi/linux/input.h | 1 + 2 files changed, 30 insertions(+), 1 deletion(-)