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

Message-ID: <20120106202342.GA10972@core.coreip.homeip.net>
Date:	Fri, 6 Jan 2012 12:23:42 -0800
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Henrik Rydberg <rydberg@...omail.se>
Cc:	Chase Douglas <chase.douglas@...onical.com>,
	Benjamin Tissoires <benjamin.tissoires@...il.com>,
	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 Fri, Jan 06, 2012 at 09:14:34PM +0100, Henrik Rydberg wrote:
> On Fri, Jan 06, 2012 at 12:02:40PM -0800, Dmitry Torokhov wrote:
> > On Fri, Jan 06, 2012 at 08:48:15PM +0100, Henrik Rydberg wrote:
> > > > > Ok, maybe not to so easy after all, which probably answers my own
> > > > > question. Looks like a EVIOCGMTSLOT, taking both slot and event code
> > > > > as argument, would be the cleaner route to take. Another ioctl, how do we
> > > > > feel about that?
> > > > 
> > > > What's the problem with userspace locking?
> > > 
> > > The idea was to get by without it.
> > > 
> > > Regarding ioctls, it does not seem realizable due to ioctl number
> > > exhaustion.
> > 
> > I am prettu sure we cabn spare 1 ioctl number. We just need to pass slot
> > number not as part of ioctl number but in data instead. Like
> > EVIOCGKEYCODE works.
> 
> Right, thanks. Perhaps we could even pass it as result data -
> returning all mt data in one go? With the purpose being to capture the
> full MT state, it ought to be both simpler and faster.

Yes, if caller passes buffer size and buffer address we can return all
data in one go. We just need to make _really sure_ we are using 32/64 bit
safe interface.

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