Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 19 9月, 2013 1 次提交
    • A
      Input: i8042 - i8042_flush fix for a full 8042 buffer · 2f0d2604
      由 Andrey Moiseev 提交于 
      When 8042 internal data buffer is full, the driver
erroneously decides that the controller is not present.

i8042_flush returns the number of flushed bytes, which is
in 0 - I8042_BUFFER_SIZE range inclusive. Therefore, i8042_flush
has no way to indicate an error. Moreover i8042_controller_check
takes initially full buffer (i8042_flush returned
I8042_BUFFER_SIZE) as a sign of absence of the controller.

Let's change i8042 to return success/error instead and make sure
we do not return error prematurely.
Signed-off-by: NAndrey Moiseev <o2g.org.ru@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      2f0d2604
  3. 18 9月, 2013 1 次提交
  5. 08 9月, 2013 1 次提交
    • D
      Input: evdev - add EVIOCREVOKE ioctl · c7dc6573
      由 David Herrmann 提交于 
      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.htmlSigned-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      c7dc6573
  7. 07 9月, 2013 1 次提交
  9. 30 8月, 2013 4 次提交
  11. 29 8月, 2013 2 次提交
  13. 27 8月, 2013 1 次提交
  15. 26 8月, 2013 7 次提交
  17. 25 8月, 2013 4 次提交
  19. 15 8月, 2013 3 次提交
  21. 14 8月, 2013 4 次提交
  23. 13 8月, 2013 11 次提交