So, I tried doing a 'make O=... allmodconfig', with a setup where the uid of
the build process had write permission to the O= directory, but intentionally
did *not* have write permission to the source tree (so they couldn't mess up
the tree - I got tired of having to repeatedly do 'make mrproper' because of
pilot error)
allmodconfig gave me a .config that had:
CONFIG_MODULE_SIG_FORMAT=y
CONFIG_MODULE_SIG=y
CONFIG_MODULE_SIG_FORCE=y
CONFIG_MODULE_SIG_ALL=y
CONFIG_MODULE_SIG_SHA1=y
# CONFIG_MODULE_SIG_SHA224 is not set
# CONFIG_MODULE_SIG_SHA256 is not set
# CONFIG_MODULE_SIG_SHA384 is not set
# CONFIG_MODULE_SIG_SHA512 is not set
CONFIG_MODULE_SIG_HASH="sha1"
CONFIG_IMA_APPRAISE_REQUIRE_MODULE_SIGS=y
CONFIG_MODULE_SIG_KEY="certs/signing_key.pem"
What i *expected* was that multiple builds with different O= would each
generate themselves a unique signing key and put it in their own O= directory
and stay out of each other's way.
What actually happened:
EXTRACT_CERTS /usr/src/linux-next/"certs/signing_key.pem"
At main.c:142:
- SSL error:0200100D:system library:fopen:Permission denied: ../crypto/bio/bss_file.c:69
- SSL error:2006D002:BIO routines:BIO_new_file:system lib: ../crypto/bio/bss_file.c:78
extract-cert: /usr/src/linux-next/certs/signing_key.pem: Permission denied
make[2]: *** [/usr/src/linux-next/certs/Makefile:106: certs/signing_key.x509] Error 1
make[1]: *** [/usr/src/linux-next/Makefile:1847: certs] Error 2
make[1]: Leaving directory '/usr/src/linux-next/out/arm64'
make: *** [Makefile:215: __sub-make] Error 2
It tried to put the key into the source tree rather than the build tree.
Before I try to code up a fix for this, is this intentionally designed
behavior, or have I just managed to trip over a rarely-tested corner case?
Valdis Klētnieks <[email protected]> wrote:
> What i *expected* was that multiple builds with different O= would each
> generate themselves a unique signing key and put it in their own O= directory
> and stay out of each other's way.
Hmmm... Works for me. I use separate build dirs all the time.
What version of the kernel are you using and what's the build command line -
in particular the full O= option?
David
On Thu, 11 Mar 2021 09:34:01 +0000, David Howells said:
> Valdis Klētnieks <[email protected]> wrote:
>
> > What i *expected* was that multiple builds with different O= would each
> > generate themselves a unique signing key and put it in their own O= directory
> > and stay out of each other's way.
>
> Hmmm... Works for me. I use separate build dirs all the time.
>
> What version of the kernel are you using and what's the build command line -
> in particular the full O= option?
This is linux-next as of yesterday. For testing, I've been using:
LANG=C make O=/tmp/arm64 V=1 ARCH=arm64 ASFLAGS='-mcpu=all' CROSS_COMPILE=/opt/aarch64/bin/aarch64-linux-gnu- certs/
and it insists on trying to make the certs in /usr/src/linux-next rather than /tmp/arm64:
make -f /usr/src/linux-next/scripts/Makefile.build obj=certs \
single-build= \
need-builtin=1 need-modorder=1
scripts/extract-cert /usr/src/linux-next/"certs/signing_key.pem" certs/signing_key.x509
At main.c:142:
- SSL error:0200100D:system library:fopen:Permission denied: ../crypto/bio/bss_file.c:69
- SSL error:2006D002:BIO routines:BIO_new_file:system lib: ../crypto/bio/bss_file.c:78
extract-cert: /usr/src/linux-next/certs/signing_key.pem: Permission denied
make[2]: *** [/usr/src/linux-next/certs/Makefile:106: certs/signing_key.x509] Error 1
make[1]: *** [/usr/src/linux-next/Makefile:1847: certs] Error 2
make[1]: Leaving directory '/tmp/arm64'
make: *** [Makefile:215: __sub-make] Error 2
Is it possible that it works for you because although you have
separate build dirs, it's still able to write to the source tree?
I wonder... Can you grab branch keys-cve-2020-26541-branch from:
https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/
and try that? If that breaks, can you try dropping the top four commits?
David
On Thu, 11 Mar 2021 10:49:14 +0000, David Howells said:
> I wonder... Can you grab branch keys-cve-2020-26541-branch from:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/
>
> and try that? If that breaks, can you try dropping the top four commits?
[/usr/src/linux-next] git checkout keys-cve-2020-26541-branch
Checking out files: 100% (13062/13062), done.
Previous HEAD position was b01d57bfdc41 Add linux-next specific files for 20210310
Branch 'keys-cve-2020-26541-branch' set up to track remote branch 'keys-cve-2020-26541-branch' from 'linux-fs'.
Switched to a new branch 'keys-cve-2020-26541-branch'
That still didn't work, and dropping off the 4 commits from Eric Snowberg
didn't change things.
I checked out next-20210310, did a 'make mrproper', and tested as the
owner of the source tree rather than as a different user...
LANG=C make O=/tmp/test-as-owner V=1 ARCH=arm64 ASFLAGS='-mcpu=all' CROSS_COMPILE=/opt/aarch64/bin/aarch64-linux-gnu- certs/
make -f /usr/src/linux-next/scripts/Makefile.build obj=certs \
single-build= \
need-builtin=1 need-modorder=1
scripts/extract-cert /usr/src/linux-next/"certs/signing_key.pem" certs/signing_key.x509
Extracted cert: /CN=Build time autogenerated kernel key
/opt/aarch64/bin/aarch64-linux-gnu-gcc (...) -o certs/system_keyring.o /usr/src/linux-next/certs/system_keyring.c
And the files ended up where they belonged:
ls -l /tmp/test-as-owner/certs/
total 72
-rw-r--r-- 1 source source 1288 Mar 11 06:33 blacklist_nohashes.o
-rw-r--r-- 1 source source 18496 Mar 11 06:33 blacklist.o
-rw-r--r-- 1 source source 542 Mar 11 06:33 built-in.a
-rw-r--r-- 1 source source 5856 Mar 11 06:33 common.o
-rw-r--r-- 1 source source 0 Mar 11 06:33 modules.order
-rw-r--r-- 1 source source 1184 Mar 11 06:33 revocation_certificates.o
-rw-r--r-- 1 source source 1357 Mar 11 06:33 signing_key.x509
-rw-r--r-- 1 source source 6888 Mar 11 06:33 system_certificates.o
-rw-r--r-- 1 source source 17504 Mar 11 06:33 system_keyring.o
-rw-r--r-- 1 source source 0 Mar 11 06:33 x509_certificate_list
-rw-r--r-- 1 source source 0 Mar 11 06:33 x509_revocation_list
So there's something weird going on with scripts/extract-cert when running
as a userid other than the owner of the source tree.. I wonder if it's actually
an OpenSSL issue...
I'll look at it some more later today...
Valdis Klētnieks <[email protected]> wrote:
> So there's something weird going on with scripts/extract-cert when running
> as a userid other than the owner of the source tree.. I wonder if it's
> actually an OpenSSL issue...
I cloned next-20210311 as one user then built it as another user using:
LANG=C nice -19 make O=/data/git/next-20210311-build -j8 allmodconfig
LANG=C nice -19 make O=/data/git/next-20210311-build -j8
It built with no problems. The building user definitely can't create/modify
files in the source directory.
Interestingly, the following line in the output from mine:
EXTRACT_CERTS certs/signing_key.pem
doesn't show the full path as it does in yours:
EXTRACT_CERTS /usr/src/linux-next/"certs/signing_key.pem"
but I don't know why. There are some odd quotes in your line also which may
be related to the problem. The relevant config line looks the same:
CONFIG_MODULE_SIG_KEY="certs/signing_key.pem"
I'll have to try with the aarch64 build, see if it's something in that that's
the problem.
David
David Howells <[email protected]> wrote:
> I'll have to try with the aarch64 build, see if it's something in that that's
> the problem.
That works too... kind of. Building in the certs/ dir is fine - and all the
cert generation and extraction is done in the expected place, but the link
fails with errors like:
aarch64-linux-gnu-ld: arch/arm64/kernel/paravirt.o: relocation R_AARCH64_ABS32 against `__crc_pv_ops' can not be used when making a shared object
arch/arm64/kernel/paravirt.o:(__patchable_function_entries+0x0): dangerous relocation: unsupported relocation
arch/arm64/kernel/paravirt.o:(__patchable_function_entries+0x8): dangerous relocation: unsupported relocation
arch/arm64/kernel/paravirt.o:(__patchable_function_entries+0x10): dangerous relocation: unsupported relocation
arch/arm64/kernel/paravirt.o:(__patchable_function_entries+0x18): dangerous relocation: unsupported relocation
...
David
On Thu, 11 Mar 2021 12:04:19 +0000, David Howells said:
> EXTRACT_CERTS /usr/src/linux-next/"certs/signing_key.pem"
>
> but I don't know why. There are some odd quotes in your line also which may
> be related to the problem. The relevant config line looks the same:
>
> CONFIG_MODULE_SIG_KEY="certs/signing_key.pem"
Aha. I figured it out.
If you have a *totally* clean source tree, 'make -O' works for all users.
If you have in the past done a build in the tree, and then done a 'make mrproper'
to clean it out so 'make -O' doesn't complain, it fails because it
finds an *old* certs/signing_key.pem in /usr/src/linux-next and tries to
put the new generated files in the same directory.
So the root cause was: 'make mrproper doesn't clean certs/' out enough,
and this chunk of certs/Makefile
# If CONFIG_MODULE_SIG_KEY isn't a PKCS#11 URI, depend on it
ifeq ($(patsubst pkcs11:%,%,$(firstword $(MODULE_SIG_KEY_FILENAME))),$(firstword $(MODULE_SIG_KEY_FILENAME)))
X509_DEP := $(MODULE_SIG_KEY_SRCPREFIX)$(MODULE_SIG_KEY_FILENAME)
endif
MODULE_SIG_KEY_SRCPREFIX was where my /usr/src/linux-next was coming from...
I admit not being sure how (or if) this should be fixed
Valdis Klētnieks <[email protected]> wrote:
> So the root cause was: 'make mrproper doesn't clean certs/' out enough,
> and this chunk of certs/Makefile
> ...
> I admit not being sure how (or if) this should be fixed
It's tricky because CONFIG_MODULE_SIG_KEY may not point to a file, let alone a
file that was autogenerated - it can be given a PKCS#11 URI, for instance. I
had to put in the autogeneration based on a magic config string value to stop
randconfig blowing up - but it only does the autogeneration if you don't put
in your own file there before building.
Possibly I can add something like:
clean-files := signing_key.pem x509.genkey
inside the
ifeq ($(CONFIG_MODULE_SIG_KEY),"certs/signing_key.pem")
...
endif
section.
David
On Fri, 12 Mar 2021 09:01:36 +0000, David Howells said:
> Possibly I can add something like:
>
> clean-files := signing_key.pem x509.genkey
>
> inside the
>
> ifeq ($(CONFIG_MODULE_SIG_KEY),"certs/signing_key.pem")
> ...
> endif
Would that remove them on a 'make clean', or only a 'make mrproper'?
The latter sounds like the correct solution to me, as the signing key should
have (roughly) the same lifetime rules as the .config file.
Valdis Klētnieks <[email protected]> wrote:
> > Possibly I can add something like:
> >
> > clean-files := signing_key.pem x509.genkey
> >
> > inside the
> >
> > ifeq ($(CONFIG_MODULE_SIG_KEY),"certs/signing_key.pem")
> > ...
> > endif
>
> Would that remove them on a 'make clean', or only a 'make mrproper'?
> The latter sounds like the correct solution to me, as the signing key should
> have (roughly) the same lifetime rules as the .config file.
It would appear that it works on neither. Neither of them seem to have any
CONFIG_xxx symbols set.
How about the attached patch?
David
---
commit 95897dc8dc13ad13c637a477a1ead9b63ff1fafa
Author: David Howells <[email protected]>
Date: Fri Mar 12 10:48:25 2021 +0000
certs: Clean up signing_key.pem and x509.genkey on make mrproper
Autogenerated signing_key.pem and x509.genkey files aren't removed from the
build certs/ directory when "make mrproper" is run. This is somewhat
deliberate since the "file" is specified by the CONFIG_MODULE_SIG_KEY
string option and may not be in the build tree - and may not even be a
filename, but rather a PKCS#7 URI (also the config variables doesn't seem
to be set when cleaning).
Fix this by unconditionally listing signing_key.pem and x509.genkey for
removal from the build certs/ directory - which will just do nothing if
they're not there, and shouldn't remove signing keys that are configured to
be elsewhere.
Note that this will permanently erase the autogenerated private key, so
anyone that is relying on it still being around after doing make mrproper
will no longer find it.
Fixes: cfc411e7fff3 ("Move certificate handling to its own directory")
Reported-by: Valdis Klētnieks <[email protected]>
Signed-off-by: David Howells <[email protected]>
Link: https://lore.kernel.org/r/134696.1615510534@turing-police/ [1]
diff --git a/certs/Makefile b/certs/Makefile
index f4c25b67aad9..2ae1dd518bc7 100644
--- a/certs/Makefile
+++ b/certs/Makefile
@@ -104,3 +104,5 @@ targets += signing_key.x509
$(obj)/signing_key.x509: scripts/extract-cert $(X509_DEP) FORCE
$(call if_changed,extract_certs,$(MODULE_SIG_KEY_SRCPREFIX)$(CONFIG_MODULE_SIG_KEY))
endif # CONFIG_MODULE_SIG
+
+clean-files += signing_key.pem x509.genkey
* Ingo Molnar <[email protected]> wrote:
>
> * David Howells <[email protected]> wrote:
>
> > Valdis Klētnieks <[email protected]> wrote:
> >
> > > So the root cause was: 'make mrproper doesn't clean certs/' out enough,
> > > and this chunk of certs/Makefile
> > > ...
> > > I admit not being sure how (or if) this should be fixed
> >
> > It's tricky because CONFIG_MODULE_SIG_KEY may not point to a file, let alone a
> > file that was autogenerated - it can be given a PKCS#11 URI, for instance. I
> > had to put in the autogeneration based on a magic config string value to stop
> > randconfig blowing up - but it only does the autogeneration if you don't put
> > in your own file there before building.
> >
> > Possibly I can add something like:
> >
> > clean-files := signing_key.pem x509.genkey
> >
> > inside the
> >
> > ifeq ($(CONFIG_MODULE_SIG_KEY),"certs/signing_key.pem")
> > ...
> > endif
> >
> > section.
>
> Note that this bug is now upstream in Linus's tree and has broken
> the deb-pkg distro kernel build method.
>
> Would be nice to make 'make mrproper' work again.
Correction - there appears to be something else going on, but the
error messages are similar:
At main.c:291:
- SSL error:02001002:system library:fopen:No such file or directory: ../crypto/bio/bss_file.c:69
- SSL error:2006D080:BIO routines:BIO_new_file:no such file: ../crypto/bio/bss_file.c:76
sign-file: debian/linux-image/lib/modules/5.12.0-custom/kernel/arch/x86/crypto/aegis128-aesni.ko: No such file or directory
At main.c:291:
The error messages look pretty obscure to me. :-/
Thanks,
Ingo
* David Howells <[email protected]> wrote:
> Valdis Klētnieks <[email protected]> wrote:
>
> > So the root cause was: 'make mrproper doesn't clean certs/' out enough,
> > and this chunk of certs/Makefile
> > ...
> > I admit not being sure how (or if) this should be fixed
>
> It's tricky because CONFIG_MODULE_SIG_KEY may not point to a file, let alone a
> file that was autogenerated - it can be given a PKCS#11 URI, for instance. I
> had to put in the autogeneration based on a magic config string value to stop
> randconfig blowing up - but it only does the autogeneration if you don't put
> in your own file there before building.
>
> Possibly I can add something like:
>
> clean-files := signing_key.pem x509.genkey
>
> inside the
>
> ifeq ($(CONFIG_MODULE_SIG_KEY),"certs/signing_key.pem")
> ...
> endif
>
> section.
Note that this bug is now upstream in Linus's tree and has broken
the deb-pkg distro kernel build method.
Would be nice to make 'make mrproper' work again.
Thanks,
Ingo
* Ingo Molnar <[email protected]> wrote:
> Correction - there appears to be something else going on, but the
> error messages are similar:
>
> At main.c:291:
> - SSL error:02001002:system library:fopen:No such file or directory: ../crypto/bio/bss_file.c:69
> - SSL error:2006D080:BIO routines:BIO_new_file:no such file: ../crypto/bio/bss_file.c:76
> sign-file: debian/linux-image/lib/modules/5.12.0-custom/kernel/arch/x86/crypto/aegis128-aesni.ko: No such file or directory
> At main.c:291:
>
> The error messages look pretty obscure to me. :-/
I didn't find any stray build files left in the tree, so 'make mrproper'
is innocent I believe.
I ended up with the config tweak below to get the kernel package to build,
which is not an ideal solution. :-/
Let me know if you'd like me to send you the .config and/or any diagnostic
messages or other details.
Thanks,
Ingo
diff --git a/.config.kepler.ubuntu b/.config.kepler.ubuntu
index 01347a220e54..846a956fcdbd 100644
--- a/.config.kepler.ubuntu
+++ b/.config.kepler.ubuntu
@@ -880,9 +880,8 @@ CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
# CONFIG_MODVERSIONS is not set
CONFIG_MODULE_SRCVERSION_ALL=y
-CONFIG_MODULE_SIG=y
-# CONFIG_MODULE_SIG_FORCE is not set
-CONFIG_MODULE_SIG_ALL=y
+# CONFIG_MODULE_SIG is not set
+# CONFIG_MODULE_SIG_ALL is not set
# CONFIG_MODULE_SIG_SHA1 is not set
# CONFIG_MODULE_SIG_SHA224 is not set
# CONFIG_MODULE_SIG_SHA256 is not set
@@ -10177,11 +10176,7 @@ CONFIG_SECURITY_APPARMOR_HASH_DEFAULT=y
# CONFIG_SECURITY_LOADPIN is not set
CONFIG_SECURITY_YAMA=y
CONFIG_SECURITY_SAFESETID=y
-CONFIG_SECURITY_LOCKDOWN_LSM=y
-CONFIG_SECURITY_LOCKDOWN_LSM_EARLY=y
-CONFIG_LOCK_DOWN_KERNEL_FORCE_NONE=y
-# CONFIG_LOCK_DOWN_KERNEL_FORCE_INTEGRITY is not set
-# CONFIG_LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY is not set
+# CONFIG_SECURITY_LOCKDOWN_LSM is not set
# CONFIG_SECURITY_LANDLOCK is not set
CONFIG_INTEGRITY=y
CONFIG_INTEGRITY_SIGNATURE=y
* Ingo Molnar <[email protected]> wrote:
>
> * Ingo Molnar <[email protected]> wrote:
>
> > Correction - there appears to be something else going on, but the
> > error messages are similar:
> >
> > At main.c:291:
> > - SSL error:02001002:system library:fopen:No such file or directory: ../crypto/bio/bss_file.c:69
> > - SSL error:2006D080:BIO routines:BIO_new_file:no such file: ../crypto/bio/bss_file.c:76
> > sign-file: debian/linux-image/lib/modules/5.12.0-custom/kernel/arch/x86/crypto/aegis128-aesni.ko: No such file or directory
> > At main.c:291:
> >
> > The error messages look pretty obscure to me. :-/
>
> I didn't find any stray build files left in the tree, so 'make mrproper'
> is innocent I believe.
>
> I ended up with the config tweak below to get the kernel package to build,
> which is not an ideal solution. :-/
>
> Let me know if you'd like me to send you the .config and/or any diagnostic
> messages or other details.
Update: I now have a config that builds & boots fine, and I've done a
.config bisection to figure out which config option combination breaks the
build, which turned out to be the new MODULE_COMPRESS options:
--- .config.good.002 2021-05-10 14:34:48.932206255 +0200
+++ .config.bad.002 2021-05-10 14:40:48.587450742 +0200
@@ -899,8 +899,8 @@ CONFIG_MODULE_SIG_ALL=y
# CONFIG_MODULE_SIG_SHA384 is not set
CONFIG_MODULE_SIG_SHA512=y
CONFIG_MODULE_SIG_HASH="sha512"
-CONFIG_MODULE_COMPRESS_NONE=y
-# CONFIG_MODULE_COMPRESS_GZIP is not set
+# CONFIG_MODULE_COMPRESS_NONE is not set
+CONFIG_MODULE_COMPRESS_GZIP=y
# CONFIG_MODULE_COMPRESS_XZ is not set
# CONFIG_MODULE_COMPRESS_ZSTD is not set
# CONFIG_MODULE_ALLOW_MISSING_NAMESPACE_IMPORTS is not set
Setting it to gzip triggered this build bug.
Thanks,
Ingo