On Tue, Apr 18, 2023 at 5:04 PM Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>
> On Tue, 2023-04-18 at 16:25 -0400, Bruce Ashfield wrote:
> > On Mon, Apr 17, 2023 at 6:31 PM Jose Quaresma <quaresma.jose@gmail.com> wrote:
> > >
> > >
> > >
> > > Richard Purdie <richard.purdie@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.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>
> > > > > ---
> > > > > 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).
Maybe some new issues will come with this change but this will be more aligned with
majority of the other tools. This is something I will keep in my TODO list.
> >
> > 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 ?
Yes, I am using the kernel-modsign bbclass of meta-security.
The step to needed is add modsign in DISTRO_FUTURES and
provide the required keys setting the MODSIGN_* variable in the 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.
Agreed. I have sign-file statically building here, and it works, but
objtool is blowing up under static linking.
Building the sign-file statically looks like a good solution but I have no idea of the side effects.
If I can't break the tools into separate bits, or fix that static link
.. My other idea is the same as yours, if we copy out the .so and make
sure it is in a recognized location in the artifacts dir, we are good
to go.
But I believe that for copying it will require copying the full native sysroot dependency chain and
not only libcrypto.so.
Jose
Bruce
>
> Cheers,
>
> Richard
>
>
--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II