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: <20110125005555.GA18338@core.coreip.homeip.net>
Date:	Mon, 24 Jan 2011 16:55:55 -0800
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Mark Lord <kernel@...savvy.com>
Cc:	Linux Kernel <linux-kernel@...r.kernel.org>,
	linux-input@...r.kernel.org
Subject: Re: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?

On Mon, Jan 24, 2011 at 07:32:08PM -0500, Mark Lord wrote:
> On 11-01-24 12:54 PM, Dmitry Torokhov wrote:
> > Hi Mark,
> > 
> > On Sun, Jan 23, 2011 at 12:03:47PM -0500, Mark Lord wrote:
> >> As of the 2.6.36 kernel, the userspace commands lsinput and input-kbd
> >> no longer work.  And if I grab newer/patched versions of those from the latest
> >> Ubuntu 10.10, then those newer/patched versions do not work with kernels
> >> *before* 2.6.36.
> >>
> >> At first glance, this looks like a visible regression.
> >> Is there a version of input-utils that works with both
> >> old and new kernels ?
> >>
> > 
> > The event protocol number was updated to reflect support of large
> > scancodes, unfortunately some of the utilities expected exact version
> > and refuse to work with updated one.
> 
> 
> So is there a danger of memory corruption if running a binary
> that doesn't check the version number?
> 

No, as far as I know we kept ABI intact.

> In other words, did the size and/or format of returned data
> change for an ioctl() or something here?

Yes, we introduced new ioctls (keeping old ones and their ABI intact).
The change is that EVIOCGVERSION ioctl now returns 0x10001 instead of
0x10000.

> 
> If so, then that is a user-visible regression, and shouldn't happen.
> One correct way to handle that, would be to create a new ioctl(),
> and mark the old one as deprecated, for removal a few years later perhaps.
> 
> ???

Right.

However a few input utilities insist that they will only work with event
protocol version 0x10000. It is purely their choice, however misguided
it might be.

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