public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@orcam.me.uk>
To: Alan Modra <amodra@gmail.com>
Cc: binutils@sourceware.org, Chenghua Xu <paul.hua.gm@gmail.com>
Subject: Re: Protect mips_hi16_list from fuzzed debug info
Date: Fri, 10 Feb 2023 18:13:05 +0000 (GMT)	[thread overview]
Message-ID: <alpine.DEB.2.21.2302100003240.11790@angie.orcam.me.uk> (raw)
In-Reply-To: <Y+THcAUEcYwNiphe@squeak.grove.modra.org>

On Thu, 9 Feb 2023, Alan Modra wrote:

> > Two consecutive entries must come from a single .rel.* section or they 
> > wouldn't be consecutive (there's no relationship between different .rel.* 
> > sections).
> 
> Yes, but see the comment before _bfd_mips_elf_hi16_reloc
> 
>    The ABI requires that the *LO16 immediately follow the *HI16.
>    However, as a GNU extension, we permit an arbitrary number of
>    *HI16s to be associated with a single *LO16.  This significantly
>    simplies the relocation handling in gcc.

 Yes, I am aware of this GNU extension, but it does not change anything 
for this consideration.  There's just meant not to be any predefined HI16 
value at the beginning of any relocation section (IOW any initial orphan 
LO16 reloc has to resolve with the high part of the addend implied zero).

> >  That sounds like a plan to me, but it's unrealistic for me to commit to 
> > it in the next two days (and then I head out to California for a week).
> 
> Patch attached.  Note the FIXME.

 I think there's no need to bail out on unmatched HI16 relocs.  These 
relocs are used with the LUI instruction as the first part of an address 
load sequence.  If the low part is never referred, then the address will 
not have been fully loaded anyway, so such code won't do anything harmful.  

 I think such orphan HI16 relocs used to appear in harmless leftovers from 
optimised code with certain versions of GCC, so adding such an error would 
cause a regression as such code wouldn't link anymore.  I wouldn't add any 
extra error cases here beyond what we might already have.

 I'll have a look into this issue and dive into code to better understand 
it once I'm back from California.  I'll try to address the RELA side too.

 Thank you for your patches and your involvement with this issue, really 
appreciated.  And as I say, more proper support is required with the MIPS 
target given it's still commercially active.  It's not like say VAX, which 
only has a bunch of enthusiasts to fiddle with.

  Maciej

  reply	other threads:[~2023-02-10 18:13 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-06 12:33 Alan Modra
2023-02-07 14:11 ` Maciej W. Rozycki
2023-02-08  0:32   ` Alan Modra
2023-02-08 23:28     ` Maciej W. Rozycki
2023-02-09  0:29       ` Alan Modra
2023-02-09  1:26         ` Maciej W. Rozycki
2023-02-09 10:14           ` Alan Modra
2023-02-10 18:13             ` Maciej W. Rozycki [this message]
2023-05-20 11:41             ` Alan Modra
2023-05-20 11:44               ` coff-mips refhi list Alan Modra
2023-05-23 21:19               ` Protect mips_hi16_list from fuzzed debug info Maciej W. Rozycki

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=alpine.DEB.2.21.2302100003240.11790@angie.orcam.me.uk \
    --to=macro@orcam.me.uk \
    --cc=amodra@gmail.com \
    --cc=binutils@sourceware.org \
    --cc=paul.hua.gm@gmail.com \
    /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).