linux-kernel - Re: [PATCH] uapi: futex: Add a futex syscall

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] [day] [month] [year] [list]

Date:   Thu, 21 Oct 2021 08:13:03 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Alistair Francis <alistair23@...il.com>
Cc:     Arnd Bergmann <arnd@...db.de>,
        Alistair Francis <alistair.francis@...nsource.wdc.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Alistair Francis <alistair.francis@....com>
Subject: Re: [PATCH] uapi: futex: Add a futex syscall

On Mon, Oct 18, 2021 at 5:41 AM Alistair Francis <alistair23@...il.com> wrote:

(sorry I missed this part of your reply earlier, just saw the new version of the
patch and wondered what had happened to my feedback)

> On Fri, Oct 15, 2021 at 6:24 PM Arnd Bergmann <arnd@...db.de> wrote:
> > On Fri, Oct 15, 2021 at 2:59 AM Alistair Francis
> >
> > I think it would be nicer to use a transparent union like
> >
> > typedef union __attribute__((__transparent_inion__)) {
> >         struct timespec *timeout;
> >         u_int32_t nr_requeue;
> > } __futex_arg4;
> >
> > which would let us provide a single function for both variants.
> > The main downside is that this relies on a GCC extension, but I
> > don't expect that to be a problem since any code using this is
> > already nonportable.
>
> I don't love this. Relying on a GCC extension doesn't seem like a great idea.

I see that even glibc uses __transparent_union__, though they have
a fallback for incompatible compilers in there, which we could
duplicate if necessary. I would expect that the kernel headers already
have a number of gcc extensions in them elsewhere.

> As well as that we need to split the types out to check the timeout
> value, and I'm not sure of how we could do that. We could have a
> switch case on the futex op, but that seems likely to get out of sync.

This is a good point. It would be ok if we could guarantee that
no new futex operations are added in the future and all new work
is on futex2(), but we probably don't want to make that a hard
requirement.

Another option would be to add the new wrappers into the
existing uapi/linux/futex.h header instead of a new header.
This is also not great, but it would have the advantage of
having the full list of operations in the same file.

        Arnd