From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-f51.google.com (mail-ej1-f51.google.com [209.85.218.51]) by sourceware.org (Postfix) with ESMTPS id ED5C53858D28 for ; Sat, 26 Mar 2022 16:57:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org ED5C53858D28 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=debian.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ej1-f51.google.com with SMTP id yy13so20890798ejb.2 for ; Sat, 26 Mar 2022 09:57:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version; bh=vJVXomYy4zriAqQ0q3o1DYWXJsbcl+msPgDtzGv8iig=; b=Dogt0+pReylvOpCrSePhHvq6CzoEX9NFofdQ8MxsJZJ1ArtKDrV2377DaSSkfk3g9N ZxEew9Wpr3PPjxbrh5+JYpOlgkVP6AVq1b5QpjA+QmXbZm6PAeG9oX3HajPCGLYlW/sy iCry1urj4IinhxTa8Cx1hezpPOacov1ihM2zZs338Y7cBCdJSA1RuiWcCC0aEiLxRv1w il1OQWlCUU1aWdx5Q5MZzMRPgpvi1E3IrBO2/8XjSad3LRD3BCpA0jDX+TfAgMuM4BZu VBZ9F4sG98KwuLRuwxsF48RBwssqTjWuwBqvXot1ez9KsFvyW0HRjLxPWEXppcxSRgPS K2Zw== X-Gm-Message-State: AOAM531GtVa6fQ1i4HegU4gSpuj6l0SFy2xC6JTtJ/UEsmKZng2IqOOO YLfFzGmSDmBlvqmL+anepI0= X-Google-Smtp-Source: ABdhPJzLW4sVlc9GO3fNGI4J8hsDRGrMXHvT7JkoYUuuFuV6Tl/sKRJHn2MicBUv1TJvo5xlsQvsiw== X-Received: by 2002:a17:907:7289:b0:6df:9746:e7c4 with SMTP id dt9-20020a170907728900b006df9746e7c4mr18558422ejc.497.1648313854794; Sat, 26 Mar 2022 09:57:34 -0700 (PDT) Received: from localhost ([2a01:4b00:f41a:3600:df86:cebc:8870:2184]) by smtp.gmail.com with ESMTPSA id gn33-20020a1709070d2100b006dfcce8be86sm3735631ejc.225.2022.03.26.09.57.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 26 Mar 2022 09:57:33 -0700 (PDT) Message-ID: Subject: Re: [PATCH v2] libebl: recognize FDO Packaging Metadata ELF note From: Luca Boccassi To: Mark Wielaard Cc: elfutils-devel@sourceware.org, Tom Stellard Date: Sat, 26 Mar 2022 16:57:32 +0000 In-Reply-To: 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> Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-bF2jB5X+TQYA8ZHpCT8D" User-Agent: Evolution 3.44.0-1 MIME-Version: 1.0 X-Spam-Status: No, score=-7.3 required=5.0 tests=BAYES_00, BODY_8BITS, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, GIT_PATCH_0, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, 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:57:40 -0000 --=-bF2jB5X+TQYA8ZHpCT8D Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, 2022-03-26 at 17:33 +0100, Mark Wielaard wrote: > Hi Luca, >=20 > 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: > > > >=20 > > > > https://github.com/systemd/package-notes/blob/main/generate-package= -notes.sh#L254 > > > >=20 > > > > (well an older version in Fedora, but similar enough) > > >=20 > > > 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. > > >=20 > > > 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, > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0offset =3D 0; > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0else > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0{ > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /* Workaround FDO p= ackage notes on big-endian systems, > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 g= etting namesz and descsz wrong. Detect it by > > > getting > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 a= bad namesz, descsz and byte swapped n_type for > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 N= T_FDO_PACKAGING_METADATA.=C2=A0 */ > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (unlikely (n->n_= type =3D=3D bswap_32 > > > (NT_FDO_PACKAGING_METADATA) > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0&& = n->n_namesz > data->d_size > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0&& = n->n_descsz > data->d_size)) > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 /* n might not be writable, use result and redirect > > > n.=C2=A0 */ > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 *result =3D *n; > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 result->n_type =3D bswap_32 (n->n_type); > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 result->n_namesz =3D bswap_32 (n->n_namesz); > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 result->n_descsz =3D bswap_32 (n->n_descsz); > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 n =3D result; > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 } > > > + > >=20 > > 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. >=20 > 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. Thank you - if we end up rebuilding s390x I'll let you know. The current segment is clearly bogus, so I'll suggest we do that once the script is fixed (working on that). > > > 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/2568= 7ec2d8a4262d5ba5c55d35d68a994b892910 > > >=20 > > > I see you rejected that, but please reconsider. Just hardcoding > > > some > > > byte values really is broken. > >=20 > > 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 :-) >=20 > 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. >=20 > 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. Generating a binary is actually harder, we tried that first, there is just too much variation and completely wonky build systems out there. Already working on the updated script, the native type is exactly the approach I was taking, this works fine on a Debian machine on s390x (and also on x86_64), eg: - BYTE(0x04) BYTE(0x00) BYTE(0x00) BYTE(0x00) /* Length of Owner inc= luding NUL */ - BYTE(0x47) BYTE(0x00) BYTE(0x00) BYTE(0x00) /* Length of Value inc= luding NUL */ - BYTE(0x7e) BYTE(0x1a) BYTE(0xfe) BYTE(0xca) /* Note ID */ + LONG(0x04) /* Length of Owner inc= luding NUL */ + LONG(0x0047) /* Length of Value inc= luding NUL */ + LONG(0xcafe1a7e) /* Note ID */ The rest of the fields are C strings so no change needed, I believe. Does this look right to you as well? --=20 Kind regards, Luca Boccassi --=-bF2jB5X+TQYA8ZHpCT8D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEErCSqx93EIPGOymuRKGv37813JB4FAmI/RfwACgkQKGv37813 JB63Cg//c3OIGb/OJhwDmE+Zgsk7GD1ZCQBnClr6zsP6OLH+59tRhz4PQZmh84Aa iLExZ+OqOnggFKGthyL3SXlSbPedH6leYfeaKocp17N0MLh3+Ud11L/Qr4VklBuU bY9xuWBf+lZ589k63csQWHkxu+aejSDi4FznlSJsCnb+MSPnxABjRizyrR9cgwxu cXrJVsemQes1D0ZIKPnGvNBSbY+dBNw9oA36em6D9PD5jvbD0koiDMYXhffhxxwz 7epe1EMFrFfiHwVNkBUQXdaBDxpl8W+aniUO7YcauqOs6rznqcJR8cH/ffnxK+Wj lKzVCIN2mh0onI4jyDpKWsDN/hjX1dBwlqqoZhvcfpen7ogE8SjfPq3f+wwrJIgr EYylBtfUGuwkzJyYWMIR/68ttV/i91thFafT2w2wcMLAGdgrF/1dT+KnKLuxImfF EnHlhgv+vtdgDLOm/tVEIAq+zXHABCjQlh4MZfGBAk/hnEfzuJhlQ/yV9+BIFpvv JG3oekbHUITIF8sx9N5suVFHsgWk40KZHhGPPhcl60amdnyUtH+7mulGESeBTkwo NMOwc1VstVODO9GMCtrgnOy/QZbWeE7mUzYyKNCcFLUTSpNTDnvRDkxX25ALrrdI 0Gh9W51rCxYBvQF8AHwfY2oNrlOU3kvcUNktehne2gzVyJAucI8= =U8oH -----END PGP SIGNATURE----- --=-bF2jB5X+TQYA8ZHpCT8D--