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
next prev parent 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).