unable to sign dkms modules due to libssl1 dependency

[samvde]

I got the following error when compiling dkms drivers on the latest surface kernel:

/lib/modules/6.1.6-surface/build/scripts/sign-file: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file

I use debian testing, and indeed they no longer ship this library. I solved it by installing libssl1.1_1.1.1n-0+deb11u3_amd64.deb as ships with bullseye.

I am not sure where sign-file comes from, but I would assume it would be best to make it compatible with libssl3.

[qzed]

Kernels are currently built on Ubuntu 20.04. We can't switch to 22.04 because that causes similar problems, just for older systems (in fact we only recently reverted such a change). At some point I'll probably have to look into building individual kernels for specific distributions, but it might take a while until I can find the time to do that.

[hax0rbana-adam]

Are there any CI jobs that build the .deb packages? I didn't see anything in the root directory that looks like it, but I'm only familiar with GitLab's CI system, not GitHub's implementation, so I may just be looking in the wrong place.

I'd be willing to contribute towards updating the automation if that would be helpful. I also run an apt repo that supports multiple versions of Debian and have some notes on that which I could share if it'd make things easier for you.

[StollD]

So our setup is a bit weird, because we only host the repository metadata ourselves, the actual packages are hosted on GitHub releases to take some load off the server.

The kernel packages are built on linux-surface. Once thats done, the CI uploads them as a GitHub release and then pushes placeholder files that link to the newly created release to the repo.

On the repo, a CI job that runs on a schedule then downloads the packages, generates / updates the repository metadata, and pushes it to a different branch. That branch is then automatically downloaded by the server and served as pkg.surfacelinux.com.

• https://github.com/linux-surface/linux-surface/tree/master/.github
• https://github.com/linux-surface/repo/blob/u/staging/.github/workflows/update.yml#L341-L515

[KaKi87]

Hi, Is there a solution that doesn't require downgrading a security-related package ? Thanks

[quo]

Can't this be solved by linking sign-file statically? E.g.:

diff --git a/scripts/Makefile b/scripts/Makefile
index fe56eeef09dd..b487bb3c7c9c 100644
--- a/scripts/Makefile
+++ b/scripts/Makefile
@@ -29,7 +29,7 @@ HOSTCFLAGS_sorttable.o = -I$(srctree)/tools/include
 HOSTLDLIBS_sorttable = -lpthread
 HOSTCFLAGS_asn1_compiler.o = -I$(srctree)/include
 HOSTCFLAGS_sign-file.o = $(shell $(HOSTPKG_CONFIG) --cflags libcrypto 2> /dev/null)
-HOSTLDLIBS_sign-file = $(shell $(HOSTPKG_CONFIG) --libs libcrypto 2> /dev/null || echo -lcrypto)
+HOSTLDLIBS_sign-file = -Wl,-Bstatic $(shell $(HOSTPKG_CONFIG) --static --libs libcrypto 2> /dev/null || echo -lcrypto) -Wl,-Bdynamic

 ifdef CONFIG_UNWINDER_ORC
 ifeq ($(ARCH),x86_64)

[qzed]

@quo Good idea, thanks! I'll give it a go in the next release.

[quo]

Look like it's causing a build failure unfortunately. :( https://github.com/linux-surface/linux-surface/actions/runs/9998610572/job/27637889211#step:7:1163

Not sure why, because it works for me locally on Debian. Maybe try removing -ldl from pkg-config output? Or adding static -lc?

[qzed]

Yeah, unfortunately I haven't had the time to look into how it could be fixed yet.

[qzed]

I think adding -lc fixed it... There's still warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking which has me worrying that the workaround doesn't work out in the end, but at least a v6.9.9 build is now running.

Edit: -lc breaks the final executable. I'll try statically linking everything for sign-file next.

[qzed]

For some reason statically linking everything works in my test container but not on github actions... there sign-file crashes with a segfault when trying to sign modules...

@quo Do you have any ideas what's going wrong?

[quo]

Explicitly linking libdl dynamically seems to work. Didn't do a thorough test, but at least it seems to fix the dlopen errors when building on Ubuntu 20.04, and the resulting executable runs on 20.04, and on recent Debian.

HOSTLDLIBS_sign-file = -Wl,-Bstatic $(shell $(HOSTPKG_CONFIG) --static --libs libcrypto | sed 's/-ldl//' 2> /dev/null || echo -lcrypto) -Wl,-Bdynamic -ldl

I think the reason my original patch works on current systems but not on 20.04, is because glibc 2.34 merged libdl into libc, and 20.04 still has 2.31.

[qzed]

Ahh, for some reason I was also testing on 22.04 and not 20.04... On 20.04 I'm able to reproduce the crash and can confirm that your patch works. Fingers crossed it works on GitHub actions now as well. Thanks!