Re: INPUT_COMPAT_TEST

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

Hi Peter,

On Fri, Jul 08, 2011 at 11:45:35AM -0700, H. Peter Anvin wrote:
> Hello,
> 
> I'm trying to figure out what system calls can actually invoke code that
> depends on INPUT_COMPAT_TEST, and in particular which of those changes
> actually matter.
> 
> The input system and seccomp are the *only* arch-neutral subsystem in
> Linux which appear to trigger on if we are in compat mode, and this is
> causing some serious consternation in trying to freeze the proposed x32
> (32-bit x86-64) ABI.
> 
> I would really like to understand if that dependency can be eliminated
> or mitigated; as it currently sits we may need an entirely separate
> system call table *just to support the input system*.
> 
> The problem is that I am personally not familiar enough with the input
> subsystem to know what the dependencies are.  ioctls are not an issue;
> there is already an entire infrastructure to handle compatibility ioctls
> (and that infrastructure should be used!),

One such place is evdev read/write - unfortunately "struct input_event"
was not created 32/64 bit safe so we need to mangle it when running 32
bit userspace with 64-bit kernels. See drivers/input/input-compat.c.

We also have similar issues with uinput API and uploading force-freedack
effects.

> but it looks like input also
> does things like change the format(?!) of sysfs entries, all of which
> makes me very concerned.

Another historical unfortunate decision. /proc/bus/input (and later
added sysfs entries) export bitmaps in "compressed" form so that
userspace can not figure out the size of the segment (32 or 64 bit) on
its own so we have to convert to userspace size for longs.

> 
> Any help in creating an inventory for this would be appreciated.
> 

I believe the above are the only non-ioctl compat issues in input core.

-- 
Dmitry