linux-kernel - Re: [PATCH v4] Input: Add EVIOC mechanism for MT slots

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120206090028.GA4137@polaris.bitmath.org>
Date:	Mon, 6 Feb 2012 10:00:28 +0100
From:	"Henrik Rydberg" <rydberg@...omail.se>
To:	Daniel Kurtz <djkurtz@...gle.com>
Cc:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	chasedouglas@...il.com, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4] Input: Add EVIOC mechanism for MT slots

Hi Daniel,

> Instead of returning the values of just one event type, can you please
> return values for all defined MT event types for all slots?  Userspace
> can already know how big such an array would be required, since it can
> probe to determine how many ABS_MT types have been defined.

Userland does not always want all MT values, it depends on which are
in actual use. Having an ioctl that returns the values for a single
event code therefore makes sense. We also have to care about the
restrictions of the ioctl interface: Even with the present patch, we
are limited to 4000 slots, since we can only specify a buffer size of
16 kilobytes.

> It seems like the most common use case for this API is to fetch the
> complete "initial state" when a userspace program first attaches to a
> (stateful) evdev device.  Fetching all at once would be slightly more
> efficient, and would resolve (or at worst minimize) race conditions
> that could occur if input events are arriving while userspace is still
> slowly ioctl'ing out the event type initial states, one at a time.

The same argument applies to _all_ input events, but in practise, only
a few less frequent events really need to be looked up. I agree that a
one-call-captures-all function would not hurt in some situations, but
I do not think it is justified in this case.

The race condition is present regardless of the method used. Looking
at input events as a whole, a method to capture the state in
conjunction with opening the device would be good, but that problem is
of quite a different scope.

> If there are strong use cases for 'just probe one event type', perhaps
> you can keep the proposed API, but allow a special event type value,
> like "ABS_MT_*", to fetch all?

I really think "all" is less useful; a bitmask of wanted values would
make more sense. You are welcome to supply such a patch. ;-)

> BTW, I am very happy that you are finally plugging this particular
> issue since it has been bugging me for many months.  We sometimes use
> a userspace tools to record evdev events for a touch device while a
> user is performing a multitouch gesture.  If the userspace tool starts
> while there are already contacts on the device, there is currently no
> unambiguous way to determine what that initial state should have been.
>  Thus, some information is always lost.  This patch would allow us to
> address this in the tools.  I've just been to busy/lazy to propose a
> fix of my own :).

Yep, this goes for all of us. :-)

Cheers,
Henrik
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/