linux-kernel - Re: [PATCH 0/3] introduce new evdev interface type

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <CB4E5A6F-D514-4D3B-9C95-13A52C509EC9@linaro.org>
Date:	Tue, 1 Dec 2015 16:34:00 +0800
From:	Pingbo Wen <pingbo.wen@...aro.org>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Pingbo Wen <pingbo.wen@...aro.org>, y2038@...ts.linaro.org,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	aksgarg1989@...il.com, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-api@...r.kernel.org
Subject: Re: [PATCH 0/3] introduce new evdev interface type

Hi, Arnd

>>>> 
>>>> The patch series add three evdev interface type:
>>>> 
>>>> - EV_IF_LEGACY
>>>> send event by input_event. This is the default option, keep kernel
>>>> backward compatible.
>>> 
>>> The problem I see with this approach is that it still breaks any
>>> legacy source code that is compiled with a new libc that uses 64-bit
>>> time_t. If we are requiring source code changes for building users
>>> of input devices with a new libc, we can easily get them to handle
>>> the overflow (they normally only care about the microsecond portion
>>> anyway, so it doesn't matter in most cases), or to use monotonic time.
>> 
>> I don’t think so.
>> 
>> Actually, from the view of userspace, EV_IF_LEGACY interface is work
>> exactly the same as old evdev. We didn’t change anything in input_event
>> and input_event_compat. And the problem you said will still be there,
>> even without those patches.
> 
> I think we're still talking past one another. I thought we had established
> that
> 
> 1. the current interface is broken when time_t changes in user space

What kinds of changes in time_t? Extending it to 64-bits in both kernel
and userspace? Ok, I get confused here, if there are some sample codes
or use-cases here, it will help me a lot.

> 2. we can fix it by redefining struct input_event in a way that
>   is independent of time_t
> 3. once both user space and kernel are using the same ABI independent
>   of time_t, we can look improving the timestamps so they don't
>   overflow
> 4. the monotonic timestamp interface already avoids the overflow, so
>   it would be sufficient as a solution for 3.
> 
> Where did I lose you here? Did you find any other facts that I
> was missing? I don't know whether the two new event structures make
> the interface better in some other way, but it seems mostly unrelated
> to either of the two problems we already have with time_t (the
> ABI mismatch, and the use of non-monotonic timestamps).

It seems we are mismatch here.

Actually input_composite_event has the similar structure with input_event,
but with a nicer definition, which can take both monotonic and non-monotonic
timestamps safely.

What I assumed here, is that leaving EV_IF_LEGACY as a untouched, deprecated
interface. If userspace try to adapt to new libc and kernel, it should move
to new interface. The userspace can do a lazy update, keep the code untouched,
but suffer the y2038 problem by itself.

We can force kernel using monotonic time in EV_IF_LEGACY interface, and
making input_event independent from time_t(after evdev has converted to
input_value, it’s easy to do that), but that also imply userspace
must change their code to fit this change. If changing userspace code is
a mandatory option, why not to force them do a complete conversion?

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