linux-kernel - Re: vdso-related userspace crashes on 5.5 mips64

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: <CAHmME9qg8+xdM7Uo=XydwsOV27BWYK8fV44oimqiosBvH_-UDg@mail.gmail.com>
Date:   Tue, 24 Dec 2019 14:37:09 +0100
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     Paul Burton <paulburton@...nel.org>
Cc:     linux-mips@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
        Arnd Bergmann <arnd@...db.de>,
        Vincenzo Frascino <vincenzo.frascino@....com>,
        Christian Brauner <christian.brauner@...onical.com>
Subject: Re: vdso-related userspace crashes on 5.5 mips64

More details forthcoming, but I just bisected this to:

commit 942437c97fd9ff23a17c13118f50bd0490f6868c (refs/bisect/bad)
Author: Arnd Bergmann <arnd@...db.de>
Date:   Mon Jul 15 11:46:10 2019 +0200

   y2038: allow disabling time32 system calls

   At the moment, the compilation of the old time32 system calls depends
   purely on the architecture. As systems with new libc based on 64-bit
   time_t are getting deployed, even architectures that previously supported
   these (notably x86-32 and arm32 but also many others) no longer depend on
   them, and removing them from a kernel image results in a smaller kernel
   binary, the same way we can leave out many other optional system calls.

   More importantly, on an embedded system that needs to keep working
   beyond year 2038, any user space program calling these system calls
   is likely a bug, so removing them from the kernel image does provide
   an extra debugging help for finding broken applications.

   I've gone back and forth on hiding this option unless CONFIG_EXPERT
   is set. This version leaves it visible based on the logic that
   eventually it will be turned off indefinitely.

   Acked-by: Christian Brauner <christian.brauner@...ntu.com>
   Signed-off-by: Arnd Bergmann <arnd@...db.de>