linux-kernel - Re: [PATCH v3 01/17] y2038: asm-generic: Extend sysvipc data structures

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: <CAKCAbMiaX31mpfEMRQrQbPO+kTfowA6=_KhBSs56=zZ1s0aXhw@mail.gmail.com>
Date:   Thu, 19 Apr 2018 11:30:34 -0400
From:   Zack Weinberg <zackw@...ix.com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     y2038@...ts.linaro.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-api@...r.kernel.org,
        GNU C Library <libc-alpha@...rceware.org>,
        Martin Schwidefsky <schwidefsky@...ibm.com>
Subject: Re: [PATCH v3 01/17] y2038: asm-generic: Extend sysvipc data structures

On Thu, Apr 19, 2018 at 10:37 AM, Arnd Bergmann <arnd@...db.de> wrote:
> Most architectures now use the asm-generic copy of the sysvipc data
> structures (msqid64_ds, semid64_ds, shmid64_ds), which use 32-bit
> __kernel_time_t on 32-bit architectures but have padding behind them to
> allow extending the type to 64-bit.
>
> Unfortunately, that fails on all big-endian architectures, which have the
> padding on the wrong side. As so many of them get it wrong, we decided to
> not bother even trying to fix it up when we introduced the asm-generic
> copy. Instead we always use the padding word now to provide the upper
> 32 bits of the seconds value, regardless of the endianess.
>
> A libc implementation on a typical big-endian system can deal with
> this by providing its own copy of the structure definition to user
> space, and swapping the two 32-bit words before returning from the
> semctl/shmctl/msgctl system calls.

This seems generally like a sound approach, but I need to ask whether
any of the structures involved can ever appear in a sendmsg() control
message (that is, in the data pointed to by msg_control), or an
AF_NETLINK message, or any other situation where the kernel
communicates a structured message of arbitrary size to user space or
vice versa.  libc can't munge those messages, because new message
types can be added faster than libc can keep up with them, and because
I/O primitives like sendmsg() generally aren't allowed to allocate
arbitrarily-large scratch buffers.

zw