public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Xi Ruoyao <xry111@xry111.site>
To: liuzhensong <liuzhensong@loongson.cn>, binutils@sourceware.org
Cc: Chenghua Xu <xuchenghua@loongson.cn>,
	Lulu Cheng <chenglulu@loongson.cn>,  Wang Xuerui <i@xen0n.name>
Subject: Re: [PATCH 1/2] LoongArch: Avoid heap-buffer-overflow in loongarch_elf_relocate_section
Date: Thu, 15 Sep 2022 10:56:28 +0800	[thread overview]
Message-ID: <527fb03481edd9f58a938ecaf1583051cce06ac0.camel@xry111.site> (raw)
In-Reply-To: <6f3d0d05-c7a2-b4cf-2a3c-abb1f343ff86@loongson.cn>

On Thu, 2022-09-15 at 09:47 +0800, liuzhensong wrote:
> > How about this?  We don't need to write into the GOT if
> > R_LARCH_RELATIVE
> > or R_LARCH_IRELATIVE will be used:
>  > "We don't need to write into the GOT if R_LARCH_RELATIVE or 
> R_LARCH_IRELATIVE will be used:"
> 
> Not only this, you can refer to the implementation of the function 
> _bfd_elf_allocate_ifunc_dyn_relocs for details.

I don't think _bfd_elf_allocate_ifunc_dyn_relocs (or
local_allocate_ifunc_dyn_relocs for us) and
loongarch_elf_relocate_section are strictly aligned.  We need to
allocate the space for GOT entry, but no need to fill in the content if
the entry will be resolved by R_LARCH_RELATIVE or R_LARCH_IRELATIVE
because they are RELA and the "origin" value of the entry is not used
during the resolution.

By the way, the code paths for REL can be also removed from
local_allocate_ifunc_dyn_relocs because LoongArch does not use REL at
all.

And the change passes ld testsuite, the resulted ld passes glibc
testsuite.

> > 
> > diff --git a/bfd/elfnn-loongarch.c b/bfd/elfnn-loongarch.c
> > index a9bb66a1e04..1e8ecb2b8e2 100644
> > --- a/bfd/elfnn-loongarch.c
> > +++ b/bfd/elfnn-loongarch.c
> > @@ -3129,6 +3129,7 @@ loongarch_elf_relocate_section (bfd
> > *output_bfd, struct bfd_link_info *info,
> >               BFD_ASSERT (rel->r_addend == 0);
> >    
> >               bfd_vma got_off = 0;
> > +             bool fill_got_entry = true;
> >               if (h != NULL)
> >                 {
> >                   /* GOT ref or ifunc.  */
> > @@ -3141,6 +3142,10 @@ loongarch_elf_relocate_section (bfd
> > *output_bfd, struct bfd_link_info *info,
> >                   if (h->got.offset == MINUS_ONE && h->type ==
> > STT_GNU_IFUNC)
> >                     {
> >                       bfd_vma idx;
> > +
> > +                     /* An IFUNC is always resolved at runtime.  */
> > +                     fill_got_entry = false;
> > +
> >                       if (htab->elf.splt != NULL)
> >                         {
> >                           idx = (h->plt.offset - PLT_HEADER_SIZE)
> > @@ -3177,6 +3182,7 @@ loongarch_elf_relocate_section (bfd
> > *output_bfd, struct bfd_link_info *info,
> >                           rela.r_addend = relocation;
> >                           loongarch_elf_append_rela (output_bfd,
> >                                                      htab-
> > >elf.srelgot, &rela);
> > +                         fill_got_entry = false;
> >                         }
> >                       h->got.offset |= 1;
> >                     }
> > @@ -3197,12 +3203,14 @@ loongarch_elf_relocate_section (bfd
> > *output_bfd, struct bfd_link_info *info,
> >                           rela.r_addend = relocation;
> >                           loongarch_elf_append_rela (output_bfd,
> >                                                      htab-
> > >elf.srelgot, &rela);
> > +                         fill_got_entry = false;
> >                         }
> >                       local_got_offsets[r_symndx] |= 1;
> >                     }
> >                 }
> >    
> > -             bfd_put_NN (output_bfd, relocation, got->contents +
> > got_off);
> > +             if (fill_got_entry)
> > +               bfd_put_NN (output_bfd, relocation, got->contents +
> > got_off);
> >    
> >               relocation = got_off + sec_addr (got);
> >             }
> > 

-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University

  reply	other threads:[~2022-09-15  2:56 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-13 15:44 [PATCH 0/2] LoongArch: Fix two bugs breaking IFUNC in static PIE Xi Ruoyao
2022-09-13 15:44 ` [PATCH 1/2] LoongArch: Avoid heap-buffer-overflow in loongarch_elf_relocate_section Xi Ruoyao
2022-09-14  8:57   ` liuzhensong
2022-09-14 10:15     ` Xi Ruoyao
2022-09-14 11:15       ` Xi Ruoyao
2022-09-15  1:47         ` liuzhensong
2022-09-15  2:56           ` Xi Ruoyao [this message]
2022-09-15  3:54             ` liuzhensong
2022-09-15  6:13               ` Xi Ruoyao
2022-09-13 15:44 ` [PATCH 2/2] LoongArch: Fix R_LARCH_IRELATIVE insertion after elf_link_sort_relocs Xi Ruoyao
2022-09-15 13:03   ` liuzhensong
2022-09-16 20:11     ` Xi Ruoyao
2022-09-18  9:58       ` Xi Ruoyao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=527fb03481edd9f58a938ecaf1583051cce06ac0.camel@xry111.site \
    --to=xry111@xry111.site \
    --cc=binutils@sourceware.org \
    --cc=chenglulu@loongson.cn \
    --cc=i@xen0n.name \
    --cc=liuzhensong@loongson.cn \
    --cc=xuchenghua@loongson.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).