On Mon, Apr 17, 2023 at 6:31 PM Jose Quaresma <quaresma.j...@gmail.com> wrote:
>
>
>
> Richard Purdie <richard.pur...@linuxfoundation.org> escreveu no dia segunda, 
> 17/04/2023 à(s) 20:51:
>>
>> On Sun, 2023-04-16 at 12:30 +0200, Christoph Lauer wrote:
>> > From: Christoph Lauer <christoph.la...@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.la...@xtronic.de>
>> > ---
>> >  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=${STAGING_KERNEL_BUILDDIR} $t
>> >       done
>> >  }
>> > +
>> > +# keep native libraries required for module signing
>> > +RM_WORK_EXCLUDE_ITEMS += "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.

There would very likely be different issues if the scripts were
generated and then packaged as a native tool / package. Since they are
so tightly coupled to the kernel. We'd just trade one set of issues
for another (out of sync artifacts, etc).

I'm going to hack on this a bit.

That being said, I've never done any module signing .. since I don't
need it in my development workflow.

Is there a canonical guide to getting it setup so I can test my static
link and relocated artifacts fixes ? is it with meta-integrity and the
kernel-modsign bbclass ?

Bruce


Bruce

>
>>
>> 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
>>
>>
>>
>>
>>
>
>
> --
> Best regards,
>
> José Quaresma
>
> 
>


--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#180200): 
https://lists.openembedded.org/g/openembedded-core/message/180200
Mute This Topic: https://lists.openembedded.org/mt/98296212/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to