linux-kernel - Re: [PATCH v2] Input: evdev - Add EVIOC mechanism to extract the MT slot state

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] [day] [month] [year] [list]

Message-ID: <4F075D40.6080001@canonical.com>
Date:	Fri, 06 Jan 2012 12:44:48 -0800
From:	Chase Douglas <chase.douglas@...onical.com>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
CC:	Benjamin Tissoires <benjamin.tissoires@...il.com>,
	Henrik Rydberg <rydberg@...omail.se>,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] Input: evdev - Add EVIOC mechanism to extract the
 MT slot state

On 01/06/2012 12:17 PM, Dmitry Torokhov wrote:
> On Fri, Jan 06, 2012 at 12:09:36PM -0800, Chase Douglas wrote:
>> I know there's a slight distinction between these two scenarios, but my
>> point is that if you are doing multithreaded evdev reading from the same
>> evdev fd, you are asking for trouble and you need to be careful. That
>> even goes for modifying any of the other state through EVIOCSABS from
>> multiple processes. And really, how many programs are out there reading
>> from the same evdev fd in multiple threads. I'd wager a fair amount of
>> money the answer is 0.
> 
> I am really not concerned about what userspace might do - I've looked at
> enough code to see all kinds of weird stuff. My task is to make sure
> that kernel interface is sane and since it is userspace ABI matter I
> want to be extra careful.

Evdev by its very nature is thread unsafe. There's no way to atomically
retrieve an event frame including all the new values up through the next
EV_SYN. That's the meat and potatoes of evdev. If the base of an API is
thread-unsafe, it does very little to add thread safety to functions
surrounding it.

If you want to make a line of demarcation to say that evdev reads are
not thread-safe, but ioctls are, then that makes a slight bit of
technical sense. However, it still seems like a fools errand to me,
because no one will ever make a multithreaded program that opens an
evdev device, accesses its ioctls through multiple threads, while never
reading from the evdev fd. If for some reason someone actually does
this, all they need is a simple mutex.

I really think this is a waste of time when Henrik's patch is ready to
go, is small and self contained, and meets everyone's needs. But this is
the last I'll speak of it.

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