From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id 69531385DC02 for ; Tue, 29 Mar 2022 07:42:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 69531385DC02 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: from reform (deer0x11.wildebeest.org [172.31.17.147]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 9C1FD3043192; Tue, 29 Mar 2022 09:42:03 +0200 (CEST) Received: by reform (Postfix, from userid 1000) id 0D0D42E8219D; Tue, 29 Mar 2022 09:42:03 +0200 (CEST) Date: Tue, 29 Mar 2022 09:42:02 +0200 From: Mark Wielaard To: Dirk =?iso-8859-1?Q?M=FCller?= Cc: elfutils-devel@sourceware.org Subject: Re: [PATCH] Avoid dlopen on debuginfod-client when not configured Message-ID: References: <20220328213641.8667-1-dirk@dmllr.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20220328213641.8667-1-dirk@dmllr.de> X-Spam-Status: No, score=-9.8 required=5.0 tests=BAYES_00, GIT_PATCH_0, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: elfutils-devel@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Elfutils-devel mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2022 07:42:08 -0000 Hi Dirk, On Mon, Mar 28, 2022 at 11:36:41PM +0200, Dirk Müller wrote: > Loading debuginfod-client is expensive, especially when > FIPS is enabled, as it goes through time intensive self-checks > on load. I assume this is because debuginfod-client loads and initializes libcurl, which triggers crypto checks for https support? > Avoid dlopen() when no debuginfo url is set. The patch itself looks right. But I am slightly afraid this (theoretically?) will break some programs which set DEBUGINFOD_URLS themselves. We currently have no other way to make libdwfl use debuginfod-client. Thoughts? Cheers, Mark > Signed-off-by: Dirk Müller > --- > libdwfl/ChangeLog | 5 +++++ > libdwfl/debuginfod-client.c | 12 +++++++++++- > 2 files changed, 16 insertions(+), 1 deletion(-) > > diff --git a/libdwfl/ChangeLog b/libdwfl/ChangeLog > index 9c5c8517..1ec13f30 100644 > --- a/libdwfl/ChangeLog > +++ b/libdwfl/ChangeLog > @@ -1,3 +1,8 @@ > +2022-03-28 Dirk Müller > + > + * debuginfod-client.c (__libdwfl_debuginfod_init): Skip dlopen > + if debuginfod url is unset. > + > 2022-02-18 Mark Wielaard > > * image-header.c (__libdw_image_header): Assign header values for > diff --git a/libdwfl/debuginfod-client.c b/libdwfl/debuginfod-client.c > index 99b66b6e..af9d1363 100644 > --- a/libdwfl/debuginfod-client.c > +++ b/libdwfl/debuginfod-client.c > @@ -101,7 +101,17 @@ __libdwfl_debuginfod_end (debuginfod_client *c) > void __attribute__ ((constructor)) > __libdwfl_debuginfod_init (void) > { > - void *debuginfod_so = dlopen(DEBUGINFOD_SONAME, RTLD_LAZY); > + void *debuginfod_so; > + > + /* Is there any server we can query? If not, don't do any work, > + just return with ENOSYS. Don't even access the cache. */ > + char *urls_envvar = getenv(DEBUGINFOD_URLS_ENV_VAR); > + if (urls_envvar == NULL || urls_envvar[0] == '\0') > + { > + return; > + } > + > + debuginfod_so = dlopen(DEBUGINFOD_SONAME, RTLD_LAZY); > > if (debuginfod_so != NULL) > { > -- > 2.35.1 >