From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20750 invoked by alias); 19 Jul 2019 18:35:47 -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 20738 invoked by uid 89); 19 Jul 2019 18:35:47 -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=-7.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy= X-Spam-Status: No, score=-7.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,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: vmicros1.altlinux.org Received: from vmicros1.altlinux.org (HELO vmicros1.altlinux.org) (194.107.17.57) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 19 Jul 2019 18:35:45 +0000 Received: from mua.local.altlinux.org (mua.local.altlinux.org [192.168.1.14]) by vmicros1.altlinux.org (Postfix) with ESMTP id 357F272CA65; Fri, 19 Jul 2019 21:35:43 +0300 (MSK) Received: by mua.local.altlinux.org (Postfix, from userid 508) id 277F77CC774; Fri, 19 Jul 2019 21:35:43 +0300 (MSK) Date: Fri, 19 Jul 2019 18:35:00 -0000 From: "Dmitry V. Levin" To: Mark Wielaard Cc: elfutils-devel@sourceware.org, Florian Weimer , Panu Matilainen Subject: Re: [PATCH] elfclassify tool Message-ID: <20190719183542.GB29323@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> <84da918d32c57e6f16fbcf1c854b375111dbdcb5.camel@wildebeest.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="TRYliJ5NKNqkz5bu" Content-Disposition: inline In-Reply-To: <84da918d32c57e6f16fbcf1c854b375111dbdcb5.camel@wildebeest.org> X-IsSubscribed: yes X-SW-Source: 2019-q3/txt/msg00066.txt.bz2 --TRYliJ5NKNqkz5bu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 3000 On Fri, Jul 19, 2019 at 04:21:53PM +0200, Mark wrote: > 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. >=20 > I didn't know. Is this really common? I don't think it is very common, but the mistake is very easy to make (-Wl,-soname,lib.so) and it doesn't really break anything. Apparently, some projects apply the same linker flags that add DT_SONAME to all generated files. > 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 >=20 > 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] > [...] >=20 > 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 >=20 > 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. Yes, the checks above has_soname are much more definitive. > So, I don't think the code is wrong. We might want to tweak the comment > a bit though, to make it less definitive? What I'm saying is that has_soname is just a hint which is probably even less reliable than has_program_interpreter. --=20 ldv --TRYliJ5NKNqkz5bu Content-Type: application/pgp-signature; name="signature.asc" Content-length: 801 -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJdMg1+AAoJEAVFT+BVnCUI8nEP/0P/B+CvpAnUpuPXLPR2SiV5 J0TbPPvz0fhwoOvh17dZOdzMz6lVfFIvTEhYYJ3SrSg8fzqgADYCYjQ9+FzfHPCd /S9w0J8Rthcen6tHksVa+86AzHoBqW1gEE0LHebSrFXRZ9CCI16Z5QC5rtyaIaQg UsMH884ggNb/piovffIwsTWrXDKoMtj23Fzm+ItAiS1+j2srpec8pVppAX07tUXM sAXuol1berLPGyg5Ef3sbjoTZZ92Nn05BZ0t02YocDkQQ2s6RR+DpcQPRN7qcEw7 zHoewwhevYUJqa6LMzdPzqAmePw4poN8uEUkx+I78+27/hQayDXCL34F9l+C+hhp kkT7NDGk826rhsIa5yVkO+TJkT62kq1XXBIeUczNnZRtvuacZ6MQ2/Uiu8yALsIj r+UmgF3za5NvOtYUah/cXR7AscJh2NKQb+FkTKX74BqLhgTB4jkz4GycKNaabzLq se1TVjBQav99iFIOOfjZnb1AfCudmLrEFs+2yQ5wLgDz9nmqtKctvM+qvamitqp6 hIrCdlUF+odH4WTWFub41ktTnJaBvBDY4EmU9ZwSQ1fM6zJioUY6l54ojvwII/DY 6KA+otXxYea0wyGYauohtbLzYGMQUIIkcezV0rnE7NqQ7ZQbxPbgLKtIu61wPVcb XSM2A8zVfy3J1Qv0O1Sy =GKBJ -----END PGP SIGNATURE----- --TRYliJ5NKNqkz5bu--