From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15461 invoked by alias); 19 Jul 2019 14:21:57 -0000 Mailing-List: contact elfutils-devel-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: elfutils-devel-owner@sourceware.org Received: (qmail 15448 invoked by uid 89); 19 Jul 2019 14:21:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.3 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=HX-Languages-Length:2262, ORIGIN X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on sourceware.org X-Spam-Level: X-HELO: gnu.wildebeest.org Received: from wildebeest.demon.nl (HELO gnu.wildebeest.org) (212.238.236.112) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 19 Jul 2019 14:21:56 +0000 Received: from tarox.wildebeest.org (tarox.wildebeest.org [172.31.17.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 0BB61300073F; Fri, 19 Jul 2019 16:21:54 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id E12B44000AA8; Fri, 19 Jul 2019 16:21:53 +0200 (CEST) Message-ID: <84da918d32c57e6f16fbcf1c854b375111dbdcb5.camel@wildebeest.org> Subject: Re: [PATCH] elfclassify tool From: Mark To: "Dmitry V. Levin" , elfutils-devel@sourceware.org Cc: Florian Weimer , Panu Matilainen Date: Fri, 19 Jul 2019 14:21:00 -0000 In-Reply-To: <20190719134341.GA26346@altlinux.org> References: <87k1fz8c9q.fsf@oldenburg2.str.redhat.com> <2e6a27c552ae5e365db54ca6b432c77c9ad5b041.camel@klomp.org> <871s22yybt.fsf@oldenburg2.str.redhat.com> <8736mfzhob.fsf@oldenburg2.str.redhat.com> <20190719134341.GA26346@altlinux.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-2.el7) Mime-Version: 1.0 X-Spam-Flag: NO X-SW-Source: 2019-q3/txt/msg00065.txt.bz2 On Fri, 2019-07-19 at 16:43 +0300, Dmitry V. Levin wrote: > On Fri, Jul 19, 2019 at 02:47:09PM +0200, Mark Wielaard wrote: > [...] > > +static bool > > +is_shared (void) > > +{ > > + if (!is_loadable ()) > > + return false; > > + > > + /* The ELF type is very clear: this is an executable. */ > > + if (elf_type =3D=3D ET_EXEC) > > + return false; > > + > > + /* If the object is marked as PIE, it is definitely an > > executable, > > + and not a loadlable shared object. */ > > + if (has_pie_flag) > > + return false; > > + > > + /* Treat a DT_SONAME tag as a strong indicator that this is a > > shared > > + object. */ > > + if (has_soname) > > + return true; >=20 > I'm not sure DT_SONAME is a reliable indicator. >=20 > I've seen many cases of DT_SONAME being erroneously applied to=20 > non-libraries, e.g. lib.so was used as soname in openjdk executables. I didn't know. Is this really common? I did find one java binary on my system that indeed has this problem. $ eu-readelf -d /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.212.b04- 0.el7_6.x86_64/jre/bin/policytool Dynamic segment contains 39 entries: Addr: 0x0000000000600d88 Offset: 0x000d88 Link to section: [ 7] '.dynstr' Type Value NEEDED Shared library: [libpthread.so.0] NEEDED Shared library: [libz.so.1] NEEDED Shared library: [libX11.so.6] NEEDED Shared library: [libjli.so] NEEDED Shared library: [libdl.so.2] NEEDED Shared library: [libc.so.6] SONAME Library soname: [lib.so] RPATH Library rpath: [$ORIGIN/../lib/amd64/jli:$ORIGIN/../lib/amd64] [...] But even so eu-elfclassify still doesn't treat it as a shared library, because: $ eu-elfclassify -v --shared policytool; echo $? info: policytool: ELF kind: ELF_K_ELF (0x3) info: policytool: ELF type: ET_EXEC (0x2) info: policytool: PT_LOAD found info: policytool: allocated PROGBITS section found info: policytool: program interpreter found info: policytool: dynamic segment found info: policytool: soname found info: policytool: DT_DEBUG found 1 So other characteristics like it being ET_EXEC mark it as an executable. And I assume if it was PIE (ET_DYN) the PIE DT_FLAGS would have caught it. So, I don't think the code is wrong. We might want to tweak the comment a bit though, to make it less definitive? Cheers, Mark