linux-kernel - Re: [PATCH v4 0/8] y2038 safety in v4l2

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: <CAK8P3a2EgRZ=Gv8hhZNy+NYRLH0D3-+Vfqk+KUTBEcCxVb+egw@mail.gmail.com>
Date:   Tue, 26 Nov 2019 12:13:31 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Hans Verkuil <hverkuil@...all.nl>
Cc:     Mauro Carvalho Chehab <mchehab@...nel.org>,
        Linux Media Mailing List <linux-media@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        y2038 Mailman List <y2038@...ts.linaro.org>
Subject: Re: [PATCH v4 0/8] y2038 safety in v4l2

On Mon, Nov 25, 2019 at 5:02 PM Hans Verkuil <hverkuil@...all.nl> wrote:
>
> Hi Arnd,
>
> On 11/11/19 9:38 PM, Arnd Bergmann wrote:
> > I'm in the process of finishing up the last bits on y2038-unsafe
> > code in the kernel, this series is for v4l2, which has no problem
> > with overflow, but has multiple ioctls that break with user space
> > built against a new 32-bit libc.
>
> Thank you for working on this. Much appreciated!
>
> I've reviewed this v4 series and found a few issues (mostly things
> that ended up in videodev2.h that shouldn't be there).
>
> Once a v5 is posted I'll try to test this more.

Ok, great!

>
> Is there an easy(-ish) way to test this with a time64 ABI? Do you
> have such an environment set up for testing?

If you can build your user space with musl, you can test using
a recent snapshot from http://git.musl-libc.org/cgit/musl/.

> > I'm not entirely happy with the compat-ioctl implementation that
> > adds quite a bit of code duplication, but I hope this is
> > acceptable anyway, as a better implementation would likely
> > require a larger refactoring of the compat-ioctl file, while
> > my approach simply adds support for the additional data structure
> > variants.
>
> A cleanup is indeed much more work. This y2038 code is awful, but that's
> really because the original structs are aligned in the worst possible
> way.

Ok.

         Arnd