Re: INPUT_COMPAT_TEST

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jul 08, 2011 at 03:37:09PM -0700, Dmitry Torokhov wrote:
> On Fri, Jul 08, 2011 at 03:22:24PM -0700, H. Peter Anvin wrote:
> > On 07/08/2011 01:46 PM, Dmitry Torokhov wrote:
> > > 
> > > 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.
> > > 
> > 
> > So these are actually present on all the read/write path system calls.
> > That is truly awful.
> > 
> > Do you happen to know if there is any kind of passing around of file
> > descriptors, or if this could perhaps be tied to file descriptor state.
> 
> Not sure.
> 
> > 
> > > We also have similar issues with uinput API and uploading force-freedack
> > > effects.
> > 
> > Those are ioctl, though, if I read the code right, or did I miss
> > something obvious?
> 
> Ah, yes, indeed.
> 

uinput uses input_event_from_user in its write path. To inject events
into the kernel, one must write struct input_event into uinput. So, in
this case, it's not only ioctl that is affected.

Regards,
Cascardo.

> > 
> > >> 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.
> > 
> > "Compressed form"?  Could you give a concrete example?  They look like
> > they are emitted in text form.
> 
> We drop leading zeroes so if you get "1 0 0 1ffff" you do not know
> the bit position of the most significant '1' unless we keep segments of
> known size. Unfortunately we started with 32 bit segments on 32 bit
> kernels and 64 bit segments on 64 bit kernels so we coudl not simply say
> that we always split on 32 bit boundary when we discovered compat
> problem a few years later.
> 
> > 
> > Do you have a program that someone could run to see the differences
> > between compat and non-compat paths?
> 
> Hmm, cat for /proc/bus/input/devices and sysfs nodes and evtest would
> either work or give garbage if compat code woudl not work.
> 
> -- 
> Dmitry
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Attachment: signature.asc
Description: Digital signature


[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux