If this new ABI is used, then bit 1 of the *next pointer of the
user-space robust_list indicates that the futex_offset2 value should
be used in place of the existing futex_offset.
The futex interface currently has some races which can only be fixed by
API changes. I'm concerned that we sacrifice the last bit for some
rather obscure feature. What if we need that bit for fixing the
correctness issues?
That current approach is going nowhere and if we change the ABI ever then
this needs to happen with all *libc folks involved and agreeing.
Out of curiosity, what's the race issue vs. robust list which you are
trying to solve?
Sadly I'm not trying to solve them. Here's one of the issues:
<https://sourceware.org/bugzilla/show_bug.cgi?id=14485>
I think there are others, but I can't find a reference to them. If
anyone wants to work on this, I can dig out the details and ask some
folks who have looked at this in the past.
Thanks,
Florian
From: Thomas Gleixner <hidden> Date: 2019-11-05 11:56:46
On Tue, 5 Nov 2019, Florian Weimer wrote:
* Thomas Gleixner:
quoted
On Tue, 5 Nov 2019, Florian Weimer wrote:
quoted
* Shawn Landden:
quoted
If this new ABI is used, then bit 1 of the *next pointer of the
user-space robust_list indicates that the futex_offset2 value should
be used in place of the existing futex_offset.
The futex interface currently has some races which can only be fixed by
API changes. I'm concerned that we sacrifice the last bit for some
rather obscure feature. What if we need that bit for fixing the
correctness issues?
That current approach is going nowhere and if we change the ABI ever then
this needs to happen with all *libc folks involved and agreeing.
Out of curiosity, what's the race issue vs. robust list which you are
trying to solve?
That one seems more a life time problem, i.e. the mutex is destroyed,
memory freed and map address reused while another thread was not yet out of
the mutex_unlock() call. Nasty.
Thanks,
tglx
From: Carlos O'Donell <hidden> Date: 2019-11-05 14:10:47
On 11/5/19 6:56 AM, Thomas Gleixner wrote:
On Tue, 5 Nov 2019, Florian Weimer wrote:
quoted
* Thomas Gleixner:
quoted
On Tue, 5 Nov 2019, Florian Weimer wrote:
quoted
* Shawn Landden:
quoted
If this new ABI is used, then bit 1 of the *next pointer of the
user-space robust_list indicates that the futex_offset2 value should
be used in place of the existing futex_offset.
The futex interface currently has some races which can only be fixed by
API changes. I'm concerned that we sacrifice the last bit for some
rather obscure feature. What if we need that bit for fixing the
correctness issues?
That current approach is going nowhere and if we change the ABI ever then
this needs to happen with all *libc folks involved and agreeing.
Out of curiosity, what's the race issue vs. robust list which you are
trying to solve?
That one seems more a life time problem, i.e. the mutex is destroyed,
memory freed and map address reused while another thread was not yet out of
the mutex_unlock() call. Nasty.
"The kernel limits the length of the robust mutex list to 2048 entries.
This constant does not seem to be exported to user space."
FWIW, the constant is defined in the UAPI futex header.
The main concern here is not the actual number of futexes held by a task.
The real issue is that the robust list could be circular by incident or
malice and there is no way for the kernel to figure that out. That would
prevent the task from exiting and make it iterate over the list until
doomsday, i.e. a nice unpriviledged DoS.
So I fear the kernel cannot really help with this one.
Thanks,
tglx
On Tue, Nov 5, 2019 at 9:28 AM Thomas Gleixner [off-list ref] wrote:
The real issue is that the robust list could be circular by incident or
malice and there is no way for the kernel to figure that out. That would
prevent the task from exiting and make it iterate over the list until
doomsday, i.e. a nice unpriviledged DoS.
Why can't the kernel use the standard tortoise-and-hare algorithm for
detecting circular linked lists here?
zw