This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/23296] Data race in setting function descriptor during lazy binding
- From: "dave.anglin at bell dot net" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Mon, 18 Jun 2018 21:10:28 +0000
- Subject: [Bug libc/23296] Data race in setting function descriptor during lazy binding
- Auto-submitted: auto-generated
- References: <bug-23296-131@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=23296
--- Comment #7 from dave.anglin at bell dot net ---
On 2018-06-18 4:17 PM, carlos at redhat dot com wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=23296
>
> --- Comment #6 from Carlos O'Donell <carlos at redhat dot com> ---
> (In reply to Carlos O'Donell from comment #5)
>> (In reply to John David Anglin from comment #1)
>>> 2) Even if we could detect the case where the function descriptor has been
>>> updated between the loading of the ip and gp values, there's no way to find
>>> the function descriptor and correct the ip value.
>> Ah, this is the problem then, you have only the relocated gp, and you need
>> the reloc itself to compute ip, and the gp is not enough information.
> No... wait a minute.
>
> We do all the work in elf_machine_runtime_setup to set these up?
>
> For PLT relocs we walk all the jmprel relocs and setup the reloc offset.
>
> So to fix this at additional per-thread cost in lazy binding, we could just do
> the work all over again for the specific thread?
>
>
> 249 /* Process all the relocs, now that we know the GOT... */
> 250 for (iplt = jmprel; iplt < end_jmprel; iplt += sizeof (Elf32_Rela))
> 251 {
> 252 reloc = (const Elf32_Rela *) iplt;
> 253 r_type = ELF32_R_TYPE (reloc->r_info);
> 254 r_sym = ELF32_R_SYM (reloc->r_info);
> 255
> 256 if (__builtin_expect (r_type == R_PARISC_IPLT, 1))
> 257 {
> 258 fptr = (struct fdesc *) (reloc->r_offset + l_addr);
>
> Here we would compare fptr to the plt entry we're trying to update.
Unfortunately, we don't have fptr. We have got, gp and l. This gives
jmprel and end_jmprel
but I don't think gp is sufficient to find the reloc.
We have rp. With that, we can find the original branch but it would be
tough to find the fptr
as the tramp currently clobbers r20 to r22. It doesn't need to clobber
r22 but that doesn't
help much.
Dave
--
You are receiving this mail because:
You are on the CC list for the bug.