linux-kernel - Re: element sizes in input

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: <ZYEFCHBC75rjCE0n@google.com>
Date: Mon, 18 Dec 2023 18:50:48 -0800
From: Dmitry Torokhov <dmitry.torokhov@...il.com>
To: Antonios Salios <antonios@....re>, Arnd Bergmann <arnd@...db.de>,
	Deepa Dinamani <deepa.kernel@...il.com>
Cc: rydberg@...math.org, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org, Jan Henrik Weinstock <jan@....re>,
	Lukas Jünger <lukas@....re>
Subject: Re: element sizes in input_event struct on riscv32

Hi Antonious,

On Thu, Dec 14, 2023 at 11:11:18AM +0100, Antonios Salios wrote:
> Hi all.
> 
> I'm having trouble getting evdev to run in a simulated Buildroot
> environment on riscv32. Evtest (and the x11 driver) seems to be
> receiving garbage data from input devices.
> 
> Analyzing the input_event struct shows that the kernel uses 32-bit (aka
> __kernel_ulong_t) values for __sec & __usec.
> Evtest on the other hand interprets these variables as 64-bit time_t
> values in a timeval struct, resulting in a mismatch between the kernel
> and userspace.
> 
> What would be the correct size for these values on a 32-bit
> architecture that uses 64-bit time_t values?

I think there is misunderstanding - we do not have *2* 64-bit values on
32-but architectures. Here is what was done:

commit 152194fe9c3f03232b9c0d0264793a7fa4af82f8
Author: Deepa Dinamani <deepa.kernel@...il.com>
Date:   Sun Jan 7 17:44:42 2018 -0800

    Input: extend usable life of event timestamps to 2106 on 32 bit systems

    The input events use struct timeval to store event time, unfortunately
    this structure is not y2038 safe and is being replaced in kernel with
    y2038 safe structures.

    Because of ABI concerns we can not change the size or the layout of
    structure input_event, so we opt to re-interpreting the 'seconds' part
    of timestamp as an unsigned value, effectively doubling the range of
    values, to year 2106.

    Newer glibc that has support for 32 bit applications to use 64 bit
    time_t supplies __USE_TIME_BITS64 define [1], that we can use to present
    the userspace with updated input_event layout. The updated layout will
    cause the compile time breakage, alerting applications and distributions
    maintainers to the issue. Existing 32 binaries will continue working
    without any changes until 2038.

    Ultimately userspace applications should switch to using monotonic or
    boot time clocks, as realtime clock is not very well suited for input
    event timestamps as it can go backwards (see a80b83b7b8 "Input: evdev -
    add CLOCK_BOOTTIME support" by by John Stultz). With monotonic clock the
    practical range of reported times will always fit into the pair of 32
    bit values, as we do not expect any system to stay up for a hundred
    years without a single reboot.

    [1] https://sourceware.org/glibc/wiki/Y2038ProofnessDesign

I'll let Arnd and Deepa to comment further.

Thanks.

-- 
Dmitry