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:   Wed, 6 Oct 2021 09:59:59 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Richard Palethorpe <rpalethorpe@...e.com>
Cc:     Arnd Bergmann <arnd@...db.de>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Stefano Garzarella <sgarzare@...hat.com>,
        Arseny Krasnov <arseny.krasnov@...persky.com>,
        Colin Ian King <colin.king@...onical.com>,
        Norbert Slusarek <nslusarek@....net>,
        Andra Paraschiv <andraprs@...zon.com>,
        Deepa Dinamani <deepa.kernel@...il.com>,
        Willem de Bruijn <willemb@...gle.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Networking <netdev@...r.kernel.org>, rpalethorpe@...hiejp.com
Subject: Re: [PATCH] vsock: Handle compat 32-bit timeout

On Wed, Oct 6, 2021 at 9:48 AM Richard Palethorpe <rpalethorpe@...e.com> wrote:
>
> Allow 32-bit timevals to be used with a 64-bit kernel.
>
> This allows the LTP regression test vsock01 to run without
> modification in 32-bit compat mode.
>
> Fixes: fe0c72f3db11 ("socket: move compat timeout handling into sock.c")
> Signed-off-by: Richard Palethorpe <rpalethorpe@...e.com>
>
> ---
>
> This is one of those fixes where I am not sure if we should just
> change the test instead. Because it's not clear if someone is likely
> to use vsock's in 32-bit compat mode?

We try very hard to ensure that compat mode works for every interface,
so it should be fixed in the kernel. Running compat mode is common
on memory-restricted machines, e.g. on cloud platforms and on deeply
embedded systems.

However, I think fixing the SO_VM_SOCKETS_CONNECT_TIMEOUT
to support 64-bit timeouts would actually be more important here. I think
what you need to do is to define the macro the same way
as the SO_TIMESTAMP one:

#define SO_RCVTIMEO (sizeof(time_t) == sizeof(__kernel_long_t) ? \
             SO_RCVTIMEO_OLD : SO_RCVTIMEO_NEW)
#define SO_TIMESTAMP (sizeof(time_t) == sizeof(__kernel_long_t) ? \
             SO_TIMESTAMP_OLD : SO_TIMESTAMP_NEW)
...

to ensure that user space picks an interface that matches the
user space definition of 'struct timeval'.

Your change looks correct otherwise, but I think you should first
add the new interface for 64-bit timeouts, since that likely changes
the code in a way that makes your current patch no longer the
best way to write it.

       Arnd

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ