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 79D523858D28 for ; Sat, 26 Mar 2022 16:33:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 79D523858D28 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 A37503022F37; Sat, 26 Mar 2022 17:33:27 +0100 (CET) Received: by reform (Postfix, from userid 1000) id B004F2E8105D; Sat, 26 Mar 2022 17:33:26 +0100 (CET) Date: Sat, 26 Mar 2022 17:33:26 +0100 From: Mark Wielaard To: Luca Boccassi Cc: elfutils-devel@sourceware.org, Tom Stellard Subject: Re: [PATCH v2] libebl: recognize FDO Packaging Metadata ELF note Message-ID: References: <20211119003127.466778-1-luca.boccassi@gmail.com> <20211121194318.105654-1-luca.boccassi@gmail.com> <40a5de54f089f344697ece88e11eb41e526462ac.camel@gmail.com> <17e1d554c9a52598d2c7d27e7a40f17381285ba5.camel@klomp.org> <20220324231438.350551-1-mark@klomp.org> <3ad724af194ed4b05d539f0807d77ae7955371df.camel@debian.org> <77321d756629343a321f4e011e52d1a1fcdd7302.camel@klomp.org> <723cfa8d317969f3ea48947da2cd9c3051cbb937.camel@debian.org> <79cab1ec6a8a5556f65e7a2ba0d7f8125a1db865.camel@klomp.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-9.5 required=5.0 tests=BAYES_00, GIT_PATCH_0, JMQ_SPF_NEUTRAL, 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: Sat, 26 Mar 2022 16:33:31 -0000 Hi Luca, On Fri, Mar 25, 2022 at 02:55:14PM +0000, Luca Boccassi wrote: > On Fri, 2022-03-25 at 15:47 +0100, Mark Wielaard wrote: > > > We have completely overlooked that, the note is created by a linker > > > script, which is generated at build time by this: > > > > > > https://github.com/systemd/package-notes/blob/main/generate-package-notes.sh#L254 > > > > > > (well an older version in Fedora, but similar enough) > > > > Yeah, that is definitely wrong. ELF is very careful about endianess. I > > have a patch that detects it and works around it. But it is somewhat > > ugly and has to work very low-level. So I am not sure I really want it. > > Maybe I just apply it as a temporary workaround just for Fedora. But if > > other distros have used such a script to generate package notes they > > are also broken. > > > > diff --git a/libelf/gelf_getnote.c b/libelf/gelf_getnote.c > > [...] > > @@ -73,6 +74,22 @@ gelf_getnote (Elf_Data *data, size_t offset, GElf_Nhdr *result, > >   offset = 0; > >        else > >   { > > + /* Workaround FDO package notes on big-endian systems, > > + getting namesz and descsz wrong. Detect it by getting > > + a bad namesz, descsz and byte swapped n_type for > > + NT_FDO_PACKAGING_METADATA. */ > > + if (unlikely (n->n_type == bswap_32 (NT_FDO_PACKAGING_METADATA) > > + && n->n_namesz > data->d_size > > + && n->n_descsz > data->d_size)) > > + { > > + /* n might not be writable, use result and redirect n. */ > > + *result = *n; > > + result->n_type = bswap_32 (n->n_type); > > + result->n_namesz = bswap_32 (n->n_namesz); > > + result->n_descsz = bswap_32 (n->n_descsz); > > + n = result; > > + } > > + > > Thanks, but I don't think it's necessary to apply that just now - this > is a bug and I'll get a fix in the script first in the next couple > days, and then I'll chat with the Fedora dev working on this about what > to do regarding existing binaries. I did apply it to the Fedora package already: https://src.fedoraproject.org/rpms/elfutils/blob/rawhide/f/elfutils-0.186-fdo-swap.patch Without it almost all of the selftests fail. And it seems a lot of binaries on Fedora have already been compiled with this bogus ELF notes in it. The trouble with that is that the notes themselves are bad (the sizes are garbage, so anything trying to parse them will fail and will be unable to parse any notes in the same segement. > > Note that Tom (on CC) submitted an IMHO much saner way to generate the > > package notes using simple assembly which would have gotten all this > > correct automagically. > > https://src.fedoraproject.org/fork/tstellar/rpms/package-notes/c/25687ec2d8a4262d5ba5c55d35d68a994b892910 > > > > I see you rejected that, but please reconsider. Just hardcoding some > > byte values really is broken. > > The reality of having to deal with thirty thousand different build > system, integrated with different tools, and different packaging > systems, with different build scripts, on different distros, means that > ease of integration trumps over everything else. There are packages out > there using build systems that you couldn't even imagine in your worst > nightmares :-) I can imagine that, but to be honest I think that is precisely because you are using a linker script. Best would be to make sure there is native support in the linker for this, just like linkers have native support for build-ids. Otherwise linking in a simple assembly generated note seems a good idea. Linker scripts seem the most fragile. But if you insist using linker script please use the proper BYTE, SHORT, LONG directives to store the ELF note structure values, instead of a stream of BYTEs, so the linker can take care of the correct value (endianness) representation for the target arch. Cheers, Mark