On Tue, 2023-04-18 at 16:25 -0400, Bruce Ashfield wrote:
> On Mon, Apr 17, 2023 at 6:31 PM Jose Quaresma <[email protected]> wrote:
> > 
> > 
> > 
> > Richard Purdie <[email protected]> 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 <[email protected]>
> > > > 
> > > > 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 <[email protected]>
> > > > ---
> > > >  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 ?

I did think about this a bit more. It does likely depend on the version
of libcrypto from the host system as to whether it reproduces or not.
The possible solution ideas I came up with are:

a) statically link sign-file so we don't need libcrypto
b) copy the libcrypto.so into a known location in the shared workdir
(probably some new path) and then adding an RPATH/RUNPATH using chrpath
to the binary.

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#180202): 
https://lists.openembedded.org/g/openembedded-core/message/180202
Mute This Topic: https://lists.openembedded.org/mt/98296212/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to