linux-kernel - Re: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?

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: <4D407F15.4030204@redhat.com>
Date:	Wed, 26 Jan 2011 21:07:49 +0100
From:	Gerd Hoffmann <kraxel@...hat.com>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
CC:	Mauro Carvalho Chehab <mchehab@...hat.com>,
	Mark Lord <kernel@...savvy.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	linux-input@...r.kernel.org, linux-media@...r.kernel.org
Subject: Re: 2.6.36/2.6.37: broken compatibility with userspace input-utils
 ?

   Hi,

> It depends. We do not have a clear way to see if new ioctls are
> supported (and I do not consider "try new ioctl and see if data sticks"
> being a good way) so that facilitated protocol version rev-up.

Yea, EVIOCGKEYCODE_V2 on a old kernel returns EINVAL.  Not good.  There 
is another one which should have been used to signal "unknown ioctl", 
ENOTTY IIRC (a bit silly for historical reasons), so you can figure 
whenever your input data is invalid or whenever the ioctl isn't 
supported in the first place (in which case you could just fallback to 
the old version).

> So keymap
> manipulating tools might be forced to check protocol version.

Guess that is the best way indeed.

cheers,
   Gerd.
--
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/