From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 0182B383F871 for ; Mon, 4 Jan 2021 18:47:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 0182B383F871 Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-157-g72l8irrNXGdVhZJ2D-Hrg-1; Mon, 04 Jan 2021 13:47:26 -0500 X-MC-Unique: g72l8irrNXGdVhZJ2D-Hrg-1 Received: by mail-qk1-f198.google.com with SMTP id l138so23801082qke.4 for ; Mon, 04 Jan 2021 10:47:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=7m9+lOihxPsFdpZNNTiffUZw/eO0vH6S2DBK6SIh3/A=; b=k2aPEZsN2iovAgscl2nka8O465i0+WtUwF4XK0Yp74nyrATybUF7rsC/Hul1eG3ZQ5 8tquUumpphSWJFBeQv+FYyTe12KaKgqpj/3B8qL00cVOmMHdQou26di0IngOzU3ejTkO /bxLXF4VzjvwENyfs0b0bf5MwcG3IjSFtCB0I4op4L6tskWx4nKiqQf7svB8+wVQACZg dE4dZsda6Zyw5EHNZ4Mv1hcb1zJ8DR77UJMxJdV8yis32Oro9i2GY2nwo19UwSf4qSPW ZQWEp5otfB0/HYIahvHRH9+NbTRQpsrLuK+3Goh+zXfeVtwfyWGJnVqbqdEtbt+YkVbT hdbQ== X-Gm-Message-State: AOAM531yYu2QRVQEpAVFYB3Mn75fXd0UxgFMd5fsxYeIUPksB3DbPUNA JE76dSi1OKYuREA71Ajou1LtG9yQzI9iBGRy+EMuoKdQziBfsq730G9wrBfEnXxxyQyzTvHllkD lBUqaEfzISyCRki6Oh2MchwS0XGjPL8JXrAAK36a0D8eF9B4oYmLGkEpbQJ5mikwUIC09gg== X-Received: by 2002:a05:6214:58d:: with SMTP id bx13mr31396350qvb.61.1609786045664; Mon, 04 Jan 2021 10:47:25 -0800 (PST) X-Google-Smtp-Source: ABdhPJzUBAvNCBmbH8uEaLusC2N45ht+ZpDUv6tGqNc9/oGI3hg+CdAn2NkroCLeJTbFLMQ/h10w2A== X-Received: by 2002:a05:6214:58d:: with SMTP id bx13mr31396326qvb.61.1609786045362; Mon, 04 Jan 2021 10:47:25 -0800 (PST) Received: from [192.168.1.16] (198-84-214-74.cpe.teksavvy.com. [198.84.214.74]) by smtp.gmail.com with ESMTPSA id 16sm25264340qkf.112.2021.01.04.10.47.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Jan 2021 10:47:24 -0800 (PST) Subject: Re: [PATCH] x86: Check IFUNC definition in unrelocated executable [BZ #20019] To: "H.J. Lu" , libc-alpha@sourceware.org References: <20201228141102.2562718-1-hjl.tools@gmail.com> From: Carlos O'Donell Organization: Red Hat Message-ID: <0d676184-2aee-6580-7281-dbbafbe671c4@redhat.com> Date: Mon, 4 Jan 2021 13:47:23 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: <20201228141102.2562718-1-hjl.tools@gmail.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-11.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, KAM_SHORT, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2021 18:47:34 -0000 On 12/28/20 9:11 AM, H.J. Lu via Libc-alpha wrote: > Calling an IFUNC function defined in unrelocated executable may also > lead to segfault. Issue an error message when calling IFUNC function > defined in the unrelocated executable from a shared library. The logic here makes sense, but we need a stronger error message. Please review my understanding and suggested error message. Looking forward to v2. > --- > sysdeps/i386/dl-machine.h | 15 ++++++++++----- > sysdeps/x86_64/dl-machine.h | 15 ++++++++++----- > 2 files changed, 20 insertions(+), 10 deletions(-) > > diff --git a/sysdeps/i386/dl-machine.h b/sysdeps/i386/dl-machine.h > index fea9e579ec..dedda484ba 100644 > --- a/sysdeps/i386/dl-machine.h > +++ b/sysdeps/i386/dl-machine.h > @@ -337,16 +337,21 @@ elf_machine_rel (struct link_map *map, const Elf32_Rel *reloc, > { > # ifndef RTLD_BOOTSTRAP OK. Logic is in the correct place in dl-machine.h for i386. > if (sym_map != map > - && sym_map->l_type != lt_executable > && !sym_map->l_relocated) > { > const char *strtab > = (const char *) D_PTR (map, l_info[DT_STRTAB]); > - _dl_error_printf ("\ > + if (sym_map->l_type == lt_executable) > + _dl_error_printf ("\ > +%s: IFUNC symbol `%s' referenced in `%s' is defined in executable\n", > + RTLD_PROGNAME, strtab + refsym->st_name, > + map->l_name); > + else > + _dl_error_printf ("\ > %s: Relink `%s' with `%s' for IFUNC symbol `%s'\n", > - RTLD_PROGNAME, map->l_name, > - sym_map->l_name, > - strtab + refsym->st_name); > + RTLD_PROGNAME, map->l_name, > + sym_map->l_name, > + strtab + refsym->st_name); > } > # endif > value = ((Elf32_Addr (*) (void)) value) (); > diff --git a/sysdeps/x86_64/dl-machine.h b/sysdeps/x86_64/dl-machine.h > index bb93c7c6ab..fc847f4bc2 100644 > --- a/sysdeps/x86_64/dl-machine.h > +++ b/sysdeps/x86_64/dl-machine.h > @@ -314,16 +314,21 @@ elf_machine_rela (struct link_map *map, const ElfW(Rela) *reloc, > { > # ifndef RTLD_BOOTSTRAP OK. Logic is in the correct place in dl-machine.h for x86_64. > if (sym_map != map > - && sym_map->l_type != lt_executable > && !sym_map->l_relocated) > { > const char *strtab > = (const char *) D_PTR (map, l_info[DT_STRTAB]); > - _dl_error_printf ("\ > + if (sym_map->l_type == lt_executable) > + _dl_error_printf ("\ > +%s: IFUNC symbol `%s' referenced in `%s' is defined in executable\n", The message should explain the error e.g. "Such and such *must not* reference such and such." Or the message should explain how to fix the error (as the other does) e.g. "Such and such must be relinked with such and such." We have made this a hard error. An executable with immediate binding may not define an IFUNC resolver and implementation that is used from a shared library since it creates an ordering issue with the dependent libraries that use the resolution of the symbol i.e. you must initialize the executable but to do that you must initialize the libraries, but to do that you must initialize the executable etc. etc. In which case the error message could be: "%s: IFUNC symbol '%s' referenced in '%s' is defined in the executable and creates an unsatisfiable circular dependency." Note: Use '' quotes not `' since the GNU Coding standards have changed. https://www.gnu.org/prep/standards/standards.html#Quote-Characters > + RTLD_PROGNAME, strtab + refsym->st_name, > + map->l_name); > + else > + _dl_error_printf ("\ > %s: Relink `%s' with `%s' for IFUNC symbol `%s'\n", > - RTLD_PROGNAME, map->l_name, > - sym_map->l_name, > - strtab + refsym->st_name); > + RTLD_PROGNAME, map->l_name, > + sym_map->l_name, > + strtab + refsym->st_name); > } > # endif > value = ((ElfW(Addr) (*) (void)) value) (); > -- Cheers, Carlos.