[Bug libc/23296] Data race in setting function descriptor during lazy binding

["carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=23296

--- Comment #4 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to dave.anglin from comment #3)
> On 2018-06-18 12:31 PM, carlos at redhat dot com wrote:
> > You have not described the race.
> >
> > Could you please describe the race in detail?
> What I believe is happening is a race in updating a function descriptor 
> between two or more
> threads during lazy binding.  It can occur due to a context switch 
> either in setting the descriptor or
> in loading the descriptor.  The gp value is stored first when a 
> descriptor is set.  It is loaded
> last in call stubs and indirect calls.  The result is 
> _dl_runtime_resolve can be called with r19 containing
> the ltp value for the descriptor instead of the reloc offset.  This 
> causes a segmentation fault in
> _dl_fixup when it happens.

Thanks, that makes it clearer.

I can't see how the store order of gp first then ip second ever really made a
difference in anything then. What does that ordering fix? Was it designed that
way to simply cause the process to enter rtld and fail? If the gp was equal to
some reloc offset then it would be an invisible failure!

My suggestion:

Make the update sequence thread-safe.

- reloc offset should be even.
- gp should be even.
- store "this is a reloc offset" in the low bit.
- alter _dl_fixup generic code to be able to cope with a sheared read of the
two words in the function descriptor. The low bit of reloc-offset is
effectively helping you keep the two words in sync (we used a common idiom for
64-bit counters constructed of two 32-bit counters in condition variables).

Like with POWER, you may need to alter binutils to reject odd reloc offsets,
and always add the '| 1' bit, and then make rtld handle that.

Thoughts?

-- 
You are receiving this mail because:
You are on the CC list for the bug.