Bruce Ashfield <bruce.ashfi...@gmail.com> escreveu no dia terça, 18/04/2023
à(s) 22:12:
> On Tue, Apr 18, 2023 at 5:04 PM Richard Purdie
> <richard.pur...@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.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).
>
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
>
--
Best regards,
José Quaresma
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#180223):
https://lists.openembedded.org/g/openembedded-core/message/180223
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]
-=-=-=-=-=-=-=-=-=-=-=-
