On Wed, Apr 19, 2023 at 9:52 AM Jose Quaresma <[email protected]> wrote: > > > > Bruce Ashfield <[email protected]> escreveu no dia terça, 18/04/2023 > à(s) 22:12: >> >> On Tue, Apr 18, 2023 at 5:04 PM Richard Purdie >> <[email protected]> wrote: >> > >> > 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). > > > 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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#180224): https://lists.openembedded.org/g/openembedded-core/message/180224 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]] -=-=-=-=-=-=-=-=-=-=-=-
