Hi, Not related with the previous discussion but just for your information. The rm_work.bbclass has an exception for the kernel recipes [1]. So I don't understand why we can't do the same for the make-mod-scripts who is the twin brother of all these kernel recipes.
[1] https://git.openembedded.org/openembedded-core/tree/meta/classes/rm_work.bbclass#n168 Jose Bruce Ashfield <bruce.ashfi...@gmail.com> escreveu no dia quarta, 19/04/2023 à(s) 14:59: > On Wed, Apr 19, 2023 at 9:52 AM Jose Quaresma <quaresma.j...@gmail.com> > wrote: > > > > > > > > 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. > > There's no side effects to the tool itself (outside of the normal "the > binary is a bit larger", etc, it is some of the other utilities that > are causing issues. > > > > >> > >> > >> 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. > > The only thing missing is libcrypto (from my checking), so it doesn't > look like we'd need any more than that. But yes, it would be expected > we'd have to bring in all the requirements (but many of the common > ones are already provided by the default native environment). > > Bruce > > > > > 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 > > > > -- > - 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 (#180230): https://lists.openembedded.org/g/openembedded-core/message/180230 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] -=-=-=-=-=-=-=-=-=-=-=-
