From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0A52DC77B76 for ; Mon, 17 Apr 2023 22:31:43 +0000 (UTC) Received: from mail-ua1-f49.google.com (mail-ua1-f49.google.com [209.85.222.49]) by mx.groups.io with SMTP id smtpd.web11.11421.1681770699879162400 for ; Mon, 17 Apr 2023 15:31:40 -0700 Authentication-Results: mx.groups.io; dkim=fail reason="signature has expired" header.i=@gmail.com header.s=20221208 header.b=nsMXDtEA; spf=pass (domain: gmail.com, ip: 209.85.222.49, mailfrom: quaresma.jose@gmail.com) Received: by mail-ua1-f49.google.com with SMTP id x8so9952366uau.9 for ; Mon, 17 Apr 2023 15:31:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681770699; x=1684362699; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=KJvi8gC6xYCeb9ImzZ7XI9ROCgydpEHxuoACLKk27YA=; b=nsMXDtEA4IN93JEX7b7m6fe+cKHmtHw3jbrMTO6h5MvZAcSnxXzCF8704O8Z3yzpRP IxiAuH86YW5y1BOjmbcg2oZ3OmAqNBFBtRSbDwlT3uZZ0GWbfyDW7IX8UIZKerkEXG0o E1IKjCjMzubfLMtT1FGNwK5uvfxmvNb8ek/76WHAkpZ4z1OVypLLzEvVzuITsI72ADsZ QULlw0Nh/LBYMcJ+/tlyKJ40tktJRhpoNh4ip1j1hzSjfgja9GUujVTiAh6nbnrWl+T4 w3hrWrIObqRNYI8gRmswaHFR4RUIfM+e0/K53uiezDHKY8GqRWOapUvdYqk5nlSbfW/q XsAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681770699; x=1684362699; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=KJvi8gC6xYCeb9ImzZ7XI9ROCgydpEHxuoACLKk27YA=; b=ORorfhRw9XFMUwKyjRpF5opd9RJrTU/xC9F1YcIbLeF1AM4KAV688flgAwX+rGOw3/ ulZPF68WyB+jcuvQVoDx4GZgLWziMAdIgkIXKPXWcqC9y4EjeM8+1KW3aM6mGERVlA2W juj4bjhlnrhs6kf4kN0GDQunbs3mejjUVpumXQn0S/aPRbJAkUk5AwL8Irzp3/SEcLJv fO82rFPevTrWZG/h0wWUCRAzG3QwmpEkPLmx87UFafyVJ5qZDKZ4/eBDqUgY6wMMohpj NMm1BN/T+Ogt5nqXDuya5eeSSD75K5MV0dUpWQ3EUWLzB7dpdUJitV0LU1cTV7bjfqFb ieug== X-Gm-Message-State: AAQBX9ekjVuKpYm/gxRw9Krx8dTWKZPEOocOLFVHO2Mn9iTsoz1/KlBO DVkPnIWC8e4FG2ISBtJIZ1J7LOUsFWTolkKHHZQ= X-Google-Smtp-Source: AKy350Z6Fbvx7C9tm5P8MaHM++o4hJp1dhhdXex0se3wcDwza4GGZn6DbAKeIx98W+vbHB3/b6NHeuTv8Bti9XSAeIo= X-Received: by 2002:ab0:559c:0:b0:68b:9eed:1c7d with SMTP id v28-20020ab0559c000000b0068b9eed1c7dmr10402159uaa.0.1681770698713; Mon, 17 Apr 2023 15:31:38 -0700 (PDT) MIME-Version: 1.0 References: <20230416103052.28268-1-christoph.lauer@email.de> <27b6976546dae12e92dd3af28f657c02eca4afe8.camel@linuxfoundation.org> In-Reply-To: <27b6976546dae12e92dd3af28f657c02eca4afe8.camel@linuxfoundation.org> From: Jose Quaresma Date: Mon, 17 Apr 2023 23:31:27 +0100 Message-ID: Subject: Re: [OE-core] [PATCH] make-mod-scripts: preserve libraries when rm_work is used To: Richard Purdie Cc: Christoph Lauer , openembedded-core@lists.openembedded.org, Christoph Lauer Content-Type: multipart/alternative; boundary="000000000000172e1705f98fc1e0" List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Mon, 17 Apr 2023 22:31:43 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/openembedded-core/message/180169 --000000000000172e1705f98fc1e0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Richard Purdie escreveu no dia segunda, 17/04/2023 =C3=A0(s) 20:51: > On Sun, 2023-04-16 at 12:30 +0200, Christoph Lauer wrote: > > From: Christoph Lauer > > > > With rm_work active, external module signing throws an error: > > scripts/sign-file: error while loading shared libraries: libcrypto.so.3= : > cannot open shared object file: No such file or directory > > Preserve libraries that sign-file script needs during runtime. > > > > Signed-off-by: Christoph Lauer > > --- > > meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/meta/recipes-kernel/make-mod-scripts/ > make-mod-scripts_1.0.bb b/meta/recipes-kernel/make-mod-scripts/ > make-mod-scripts_1.0.bb > > index 28e0807d1d..0e24efc597 100644 > > --- a/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb > > +++ b/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb > > @@ -32,3 +32,6 @@ do_configure() { > > -C ${STAGING_KERNEL_DIR} O=3D${STAGING_KERNEL_BUILDDIR} $= t > > done > > } > > + > > +# keep native libraries required for module signing > > +RM_WORK_EXCLUDE_ITEMS +=3D "recipe-sysroot-native" > > I'm really reluctant to take this change as it isn't the way > dependencies are meant to work. > > It sounds like something in a shared workdir is depending on something > in a recipe workdir and we simply don't support that. Everything needed > should be in the shared workdir. At best this is a bandaid and there > will be other ways to make this fail such as cleaning make-mod-scripts. > The problem is because for signing the kernel modules the sign-file.c [1] is linked dynamically with openssl-native. This works when building the in tree kernel modules but will fail when we try to sing any out of tree kernel module. To sign the out of tree kernel we will use the binaries from the shared workdir but the native libcrypto.so.3 is removed by the rm_work bbclass. We need to link the sign-file statically otherwise it will not work with the rm_work bbclass. [1] https://github.com/torvalds/linux/blob/master/scripts/sign-file.c Another solution for this problem can be changing the make-mod-scripts to be a native tool and in this way they will be installed and the dependencies will be handled correctly. > I'm even less keen to take it when I think it's going to be backported > "everywhere" as if is the correct solution too. > > I don't know what the right fix is unfortunately. I'm sure people would > like me to think about it and come up with one but there are simply too > many different things people would like me to do that with and even for > me, it does take a while to work these things out. I'm just out of > bandwidth, sorry :( > It is true that it is not the correct solution but it is the most suitable in my opinion. I totally understand what you say and I'm a little sorry that I could still help in this same fix. This problem is something I would also like to fix because I am using the RM_WORK_EXCLUDE for quite some time to fix this issue on my distro. I would like to convert the make-mod-scripts to be a native tool but I haven't had time for that either. Sorry and thank you for all your dedication and help. Jose > Cheers, > > Richard > > > > -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- > Links: You receive all messages sent to this group. > View/Reply Online (#180167): > https://lists.openembedded.org/g/openembedded-core/message/180167 > Mute This Topic: https://lists.openembedded.org/mt/98296212/5052612 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [ > quaresma.jose@gmail.com] > -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- > > --=20 Best regards, Jos=C3=A9 Quaresma --000000000000172e1705f98fc1e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
Richard Purdie <richard.purdie@linuxfoundation.org&= gt; escreveu no dia segunda, 17/04/2023 =C3=A0(s) 20:51:
On Sun, 2023-04-16 at 12:30 +0200,= Christoph Lauer wrote:
> From: Christoph Lauer <christoph.lauer@xtronic.de>
>
> With rm_work active, external module signing throws an error:
> scripts/sign-file: error while loading shared libraries: libcrypto.so.= 3: cannot open shared object file: No such file or directory
> Preserve libraries that sign-file script needs during runtime.
>
> Signed-off-by: Christoph Lauer <christoph.lauer@xtronic.de>
> ---
>=C2=A0 meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.b= b | 3 +++
>=C2=A0 1 file changed, 3 insertions(+)
>
> diff --git a/meta/recipes-kernel/make-mod-scripts/make-mod-script= s_1.0.bb b/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1= .0.bb
> index 28e0807d1d..0e24efc597 100644
> --- a/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.b= b
> +++ b/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.b= b
> @@ -32,3 +32,6 @@ do_configure() {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-C ${STAGING_KER= NEL_DIR} O=3D${STAGING_KERNEL_BUILDDIR} $t
>=C2=A0 =C2=A0 =C2=A0 =C2=A0done
>=C2=A0 }
> +
> +# keep native libraries required for module signing
> +RM_WORK_EXCLUDE_ITEMS +=3D "recipe-sysroot-native"

I'm really reluctant to take this change as it isn't the way
dependencies are meant to work.

It sounds like something in a shared workdir is depending on something
in a recipe workdir and we simply don't support that. Everything needed=
should be in the shared workdir. At best this is a bandaid and there
will be other ways to make this fail such as cleaning make-mod-scripts.
=

The problem is because for signing the ker= nel modules the sign-file.c [1] is linked dynamically=C2=A0with openssl-nat= ive.=C2=A0
This works when building the in tree kernel modules bu= t will fail when we try to sing any out of=C2=A0tree kernel module.
To sign the out of=C2=A0tree kernel we will use the binaries from the sh= ared workdir but the native libcrypto.so.3=C2=A0is removed by
the= rm_work bbclass. We need to link the sign-file statically=C2=A0otherwise i= t will not work with the rm_work bbclass.
=C2=A0
[1] https://github.com/torvalds/linux/blob/master/scripts/sign-file.c
<= /div>

Another solution for this problem can be changing the make-mo= d-scripts to be a native tool and in this way
they=C2=A0will be i= nstalled and the dependencies will be handled correctly.


I'm even less keen to take it when I think it's going to be backpor= ted
"everywhere" as if is the correct solution too.

I don't know what the right fix is unfortunately. I'm sure people w= ould
like me to think about it and come up with one but there are simply too
many different things people would like me to do that with and even for
me, it does take a while to work these things out. I'm just out of
bandwidth, sorry :(

It is true that it is not the = correct solution but it is the most suitable in my opinion.
I totally un= derstand what you say=C2=A0and I'm a little sorry that I could still he= lp=C2=A0in this same fix.

This problem is somethin= g I would also like to fix because=C2=A0I am using the=C2=A0RM_WORK_EXCLUDE
for quite some=C2=A0time to fix= this issue on=C2=A0my distro.
I would like to convert the make-m= od-scripts to be a native tool=C2=A0but I haven't had time for that eit= her.

Sorry and thank you for all your dedicati= on and help.

Jose


Cheers,

Richard



-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-
Links: You receive all messages sent to this group.
View/Reply Online (#180167): https:= //lists.openembedded.org/g/openembedded-core/message/180167
Mute This Topic: https://lists.openembedded.org/mt= /98296212/5052612
Group Owner: openembedded-core+owner@lists.openembedded.org<= br> Unsubscribe: https://lists.openembedded.org/= g/openembedded-core/unsub [quaresma.jose@gmail.com]
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-



--
Best regards,

Jos=C3=A9 Quaresma
--000000000000172e1705f98fc1e0--