From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from angie.orcam.me.uk (angie.orcam.me.uk [78.133.224.34]) by sourceware.org (Postfix) with ESMTP id 9E54438555A0 for ; Fri, 10 Feb 2023 18:13:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9E54438555A0 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orcam.me.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=orcam.me.uk Received: by angie.orcam.me.uk (Postfix, from userid 500) id 25F6B92009C; Fri, 10 Feb 2023 19:13:05 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id 17D6692009B; Fri, 10 Feb 2023 18:13:05 +0000 (GMT) Date: Fri, 10 Feb 2023 18:13:05 +0000 (GMT) From: "Maciej W. Rozycki" To: Alan Modra cc: binutils@sourceware.org, Chenghua Xu Subject: Re: Protect mips_hi16_list from fuzzed debug info In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-1163.1 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_INFOUSMEBIZ,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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