linux-kernel - Re: [RFC 0/4] futex2: Add new futex interface

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]

Message-ID: <475e8c39-7d11-f80b-3b4a-e51be5d0963d@collabora.com>
Date:   Thu, 25 Jun 2020 11:38:29 -0300
From:   André Almeida <andrealmeid@...labora.com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>, krisman@...labora.com,
        Collabora kernel ML <kernel@...labora.com>,
        Darren Hart <dvhart@...radead.org>,
        Ingo Molnar <mingo@...hat.com>, pgriffais@...vesoftware.com,
        Florian Weimer <fweimer@...hat.com>,
        GNU C Library <libc-alpha@...rceware.org>,
        malteskarupke@....de, Linux API <linux-api@...r.kernel.org>
Subject: Re: [RFC 0/4] futex2: Add new futex interface

Hello Arnd,

On 6/25/20 3:48 AM, Arnd Bergmann wrote:
> On Fri, Jun 12, 2020 at 8:51 PM André Almeida <andrealmeid@...labora.com> wrote:
> 
>> - The proposed interface uses ktime_t type for absolute timeout, and I
>>   assumed that it should use values in a nsec resolution. If this is true,
>>   we have some problems with i386 ABI, please check out the
>>   COMPAT_32BIT_TIME implementation in patch 1 for more details. I
>>   haven't added a time64 implementation yet, until this is clarified.
> 
> ktime_t is not part of the uapi headers, and has always been considered
> an implementation detail of the kernel so far. I would argue it should
> stay that way. The most sensible alternatives would be to either use
> a "__u64 *timeout" argument for a relative timeout, or a
> "struct __kernel_timespec *timeout" for an absolute timeout.
> 
> old_time32_t also makes no sense for multiple reasons:
> 
> - It's another kernel internal type and not part of the uapi headers
> - your time32 call has different calling conventions from your time64
>   version, not just a different type.
> - there should be no need to add syscalls that are known to be buggy
>   when there is a replacement type that does not have that bug.
> 

Thanks for the input. As stated by tglx at [1], "supporting relative
timeouts is wrong to begin with", my next patch will use "struct
__kernel_timespec *timeout" for an absolute timeout.

>> - Is expected to have a x32 ABI implementation as well? In the case of
>>   wait and wake, we could use the same as x86_64 ABI. However, for the
>>   waitv (aka wait on multiple futexes) we would need a proper x32 entry
>>   since we are dealing with 32bit pointers.
> 
> For new syscalls, I'd actually recommend not having a separate
> entry point, but just checking 'if (in_compat_syscall())' inside of the
> implementation to pick one behavior vs the other when accessing
> the user pointers. This keeps the implementation simpler and
> avoids assigning a new x32 syscall number that would be different
> from all the other architectures.
> 

Cool, this will make the code cleaner.

>       Arnd
> 


Thanks,
	André

[1] https://lkml.org/lkml/2019/7/31/1499