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]
Date:   Mon, 7 Oct 2019 17:25:51 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Masahiro Yamada <yamada.masahiro@...ionext.com>
Cc:     Mauro Carvalho Chehab <mchehab@...nel.org>,
        Linux Media Mailing List <linux-media@...r.kernel.org>,
        Heiko Carstens <heiko.carstens@...ibm.com>,
        Pablo Neira Ayuso <pablo@...filter.org>,
        Sam Ravnborg <sam@...nborg.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Hans Verkuil <hverkuil@...all.nl>
Subject: Re: [RFC PATCH] media: videodev2.h: include <linux/time.h> instead of <sys/time.h>

On Mon, Oct 7, 2019 at 6:10 AM Masahiro Yamada
<yamada.masahiro@...ionext.com> wrote:
>
> Currently, linux/videodev.h is excluded from the UAPI header test since
> it is not self-contained. Building it for user-space would fail.
>

>
> Replacing <sys/time.h> with <linux/time.h> solves it, and allow more
> headers to join the UAPI header test.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@...ionext.com>
> ---
>
> I am not 100% sure about the compatibility
> between <sys/time.h> and <linux/time.h>, hence RFC.
>
> But, if they were not compatible,
> I guess it would have broken already.
>
> I CCed Arnd Bergmann, who might have a better insight.
>
> A related comment is here:
> https://lkml.org/lkml/2019/6/4/1046

I don't think this can work, there are multiple problems here:

* linux/time.h is still incompatible with sys/time.h, so any application
  tries to include both sys/time.h and linux/videodev2.h now also
  gets the compile-time error.

* The definition of 'struct timespec' in the kernel headers may in
  fact be different from the one in the libc, and we do want to use
  the one from the C library here, otherwise different parts of the
  application may use incompatible struct layouts.

Fixing this correctly depends on one of the remaining y2038
patches that we still have to revisit. There are two aspects that
we should address:

1. The v4l subsystem needs to be changed to handle both the
    old and the new 32-bit layout for timespec (and timeval). Both
    Hans and I have created patches for this in the past, but they
    were never completed and merged.

2. The definition of 'struct timespec' in the kernel headers needs
   to be removed after every user of this struct is gone from
   the kernel. In internal kernel code, the replacement is
   timespec64 or ktime_t, and in user space interfaces, the
   correct replacement is one of __kernel_timespec (the 64-bit
   version), __kernel_old_timespec (the traditional layout) or
   timespec (from the libc headers).

        Arnd

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ