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]

Date:	Tue, 25 Jan 2011 09:32:51 -0500
From:	Mark Lord <kernel@...savvy.com>
To:	Mauro Carvalho Chehab <mchehab@...hat.com>
CC:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	linux-input@...r.kernel.org, linux-media@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>, rjw@...k.pl
Subject: Re: 2.6.36/2.6.37: broken compatibility with userspace input-utils
 ?

On 11-01-25 06:42 AM, Mauro Carvalho Chehab wrote:
>
> I lost part of the thread, but a quick search via the Internet showed that you're using
> the input tools to work with a Remote Controller, right? Are you using a vanilla
> kernel, or are you using the media_build backports? There are some distros that are
> using those backports also like Fedora 14.

I use kernel.org kernels exclusively.

> The issue is simple, and it is related on how the input.c used to handle EVIOSGKEYCODE.
> Basically, before allowing you to change a key, it used to call EVIOCGKEYCODE to check
> it that key exists. However, when you're creating a new association, the key didn't
> exist, and, to be strict with input rules, EVIOCGKEYCODE should return -EINVAL.

No, if the parameters are a valid key, then -EINVAL is never the correct
thing for a kernel to return.  -EINVAL means "bad parameters",
and that's not an accurate description of a valid yet unmapped key.

> To circumvent that behaviour, old versions were returning 0, and associating unmapped
> scancodes to KEY_RESERVED. We used this workaround for a few kernel versions, while
> we were discussing the improvements so support larger scancodes.

And now we're stuck with it.  If that is how it works,
and userspace depends upon it (it does), then consider
it cast in stone.  Immutable by Linus's Law: don't break userspace.

Create a new ioctl() number for the new behaviour,
but preserve the old behaviour in exact form for
a suitable (multi-year) overlap period.

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