http://bugzilla.opensuse.org/show_bug.cgi?id=1159531 http://bugzilla.opensuse.org/show_bug.cgi?id=1159531#c1 Dominique Leuenberger changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P1 - Urgent CC| |dleuenberger@suse.com Flags| |SHIP_STOPPER+ --- Comment #1 from Dominique Leuenberger --- With thus bug, we can't with good conscious release a new Tumbleweed snapshot. Without feedback by EOD 20191219 I will revert the kernel back to 5.3.x in openSUSE:Factory to resume the rolling nature of the distro (2 snapshots discarded: 1217 and 1218) -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1159531 Takashi Iwai changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jlee@suse.com, | |jslaby@suse.com, | |tiwai@suse.com -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1159531 Jiri Kosina changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|kernel-maintainers@forge.pr |jbohac@suse.com |ovo.novell.com | -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1159531 http://bugzilla.opensuse.org/show_bug.cgi?id=1159531#c2 --- Comment #2 from Joey Lee --- (In reply to Dominique Leuenberger from comment #0)

## Observation [...snip] ## Reproducible

Fails since (at least) Build [20191217](https://openqa.opensuse.org/tests/1116837)

There have "auth-skid nonmatch" warning in the log: 09:20:07 <2> +0x30d0b : digest ok [ 46.993433] PKCS7: Sig 1: X.509 chain contains auth-skid nonmatch (1->1) [ 46.994295] kexec_file: kernel signature verification failed (-129). 09:20:07 <2> util_run+0xb8 : exec: kexec -a -l /download/file_0017 --initrd=/download/file_0018 --append='initrd=initrd splash=silent install=http://download.opensuse.org/tumbleweed/repo/oss/ Y2DE kexec=0' = 255 The issuer_check_skid case in pkcs7_verify_one()->pkcs7_verify_sig_chain() is in "Verify the internal certificate chain" failed. But I do not see changes in this code path between v5.3 and v5.4. The public_key_verify_signature() function should be success before kernel runs into pkcs7_verify_sig_chain(). Did our kernel be signed success? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1159531 http://bugzilla.opensuse.org/show_bug.cgi?id=1159531#c5 --- Comment #5 from Joey Lee --- (In reply to Dominique Leuenberger from comment #3)

(In reply to Joey Lee from comment #2)

...

(In reply to Dominique Leuenberger from comment #0)

...

## Observation [...snip] ## Reproducible

Fails since (at least) Build [20191217](https://openqa.opensuse.org/tests/1116837)

There have "auth-skid nonmatch" warning in the log:

09:20:07 <2> +0x30d0b : digest ok [ 46.993433] PKCS7: Sig 1: X.509 chain contains auth-skid nonmatch (1->1) [ 46.994295] kexec_file: kernel signature verification failed (-129). 09:20:07 <2> util_run+0xb8 : exec: kexec -a -l /download/file_0017 --initrd=/download/file_0018 --append='initrd=initrd splash=silent install=http://download.opensuse.org/tumbleweed/repo/oss/ Y2DE kexec=0' = 255

The issuer_check_skid case in pkcs7_verify_one()->pkcs7_verify_sig_chain() is in "Verify the internal certificate chain" failed. But I do not see changes in this code path between v5.3 and v5.4.

The public_key_verify_signature() function should be success before kernel runs into pkcs7_verify_sig_chain(). Did our kernel be signed success?

As the regular uefi boot seems to be all right, I'd guess yes, the kernel signing was successful:

When booting with UEFI secure boot, booting kernel be verified by shim boot loader. The crash kernel be verified by kexec in Linux kernel. It's different code base.

https://openqa.opensuse.org/tests/1117864#step/bootloader_uefi/1

Max pointed out these kernel options:

- Security - SECURITY_LOCKDOWN_LSM=y - SECURITY_LOCKDOWN_LSM_EARLY=y - LOCK_DOWN_KERNEL_FORCE_NONE=y - IMA_DEFAULT_HASH_SHA512=n - IMA_APPRAISE_MODSIG=y - RANDOM_TRUST_BOOTLOADER=y - KEXEC_SIG=y - KEXEC_SIG_FORCE=n - KEXEC_BZIMAGE_VERIFY_SIG=y

on my 5.3 Tumbleweed install, KEXEC_SIG is not set (probably did not exist in 5.3?)

Yes, KEXEC_SIG be introduced since v5.4 kernel. Which means that the crash kernel of TW may never be verified by kexec until v5.4. Is it possible to enable dynamic debugging? Just adding the following kernel parameter for booting, then capture dmesg: ddebug_query='file crypto/asymmetric_keys/pkcs7_verify.c +p' -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1159531 http://bugzilla.opensuse.org/show_bug.cgi?id=1159531#c8 --- Comment #8 from Joey Lee --- (In reply to Joey Lee from comment #2)

(In reply to Dominique Leuenberger from comment #0)

...

## Observation [...snip] ## Reproducible

Fails since (at least) Build [20191217](https://openqa.opensuse.org/tests/1116837)

There have "auth-skid nonmatch" warning in the log:

09:20:07 <2> +0x30d0b : digest ok [ 46.993433] PKCS7: Sig 1: X.509 chain contains auth-skid nonmatch (1->1) [ 46.994295] kexec_file: kernel signature verification failed (-129). 09:20:07 <2> util_run+0xb8 : exec: kexec -a -l /download/file_0017 --initrd=/download/file_0018 --append='initrd=initrd splash=silent install=http://download.opensuse.org/tumbleweed/repo/oss/ Y2DE kexec=0' = 255

The issuer_check_skid case in pkcs7_verify_one()->pkcs7_verify_sig_chain() is in "Verify the internal certificate chain" failed. But I do not see changes in this code path between v5.3 and v5.4.

The public_key_verify_signature() function should be success before kernel runs into pkcs7_verify_sig_chain(). Did our kernel be signed success?

Sorry for I was wrong, the public_key_verify_signature() is success. But the pkcs7_verify_sig_chain() verification is failed. The built-in certificate be loaded success by kernel when booting: [ 2.841526] Loaded X.509 cert 'openSUSE Secure Boot Signkey: 0332fa9cbf0d88bf21924b0de82a09a54d5defc8' Base on the code in pkcs7_verify_one(), kernel found the key (I think the built-in key) that it matches with the pkcs7 signature information on crash kernel. The strange thing is that the signature pass the verification with the built-in kerenl. But the further pkcs7_verify_sig_chain() step is failed in found_issuer_check_skid case. Can anyone help to attach the certificate of "openSUSE Secure Boot Signkey" please? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1159531 http://bugzilla.opensuse.org/show_bug.cgi?id=1159531#c11 --- Comment #11 from Joey Lee --- (In reply to Jiri Bohac from comment #7)

I installed 5.4.5-1.g47eef04-default on my desktop, so my kernel is now compiled with the signature verification.

Sorry for I didn't see that you reproduced issue by openSUSE signed kernel. Then we must compare issuer+serialNumber and the keyIdentifier of the certificate of openSUSE Secure Boot Signkey and also the openSUSE CA. Because in 4573b64a31cd8cb patch description: If the latter doesn't match the subjectKeyIdentifier of the parent certificate, EKEYREJECTED is returned. Can anyone attached openSUSE secure boot sign key certificate and also openSUSE CA please? Then we can use openssl to compare them: openssl x509 -in xxx.crt -inform DER -noout -text | less I reassigned this issue to me. I will look at it tomorrow. Thanks a lot! -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1159531 http://bugzilla.opensuse.org/show_bug.cgi?id=1159531#c12 --- Comment #12 from Dominique Leuenberger --- The used certificate is packaged inside the kernel-default package as published in Tumbleweed. i.e. /etc/uefi/certs/188EA6FA.crt The used CA is packaged in shim, also published in tW /etc/uefi/certs/4659838C.crt -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1159531 http://bugzilla.opensuse.org/show_bug.cgi?id=1159531#c14 --- Comment #14 from Dominique Leuenberger --- Created attachment 826494 --> http://bugzilla.opensuse.org/attachment.cgi?id=826494&action=edit Subject: CN = openSUSE Secure Boot CA, -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1159531 http://bugzilla.opensuse.org/show_bug.cgi?id=1159531#c17 --- Comment #17 from Joey Lee --- (In reply to Dominique Leuenberger from comment #13)

Created attachment 826493 [details] Subject: CN = openSUSE Secure Boot Signkey

OK! I know what's happened now. The serial number of "openSUSE Secure Boot Signkey" should does _NOT_ equal to the serial number his parent CA, "openSUSE Secure Boot CA". Otherwise the kernel will confused with signkey and CA, then runs into the verification of Authority Key Identifier/Subject Key Identifier that it causes verification failed. Base on rfc5280 (X.509) spec, the "Serial Number" must be unique: -------------------------- 4.1.2.2. Serial Number The serial number MUST be a positive integer assigned by the CA to each certificate. It MUST be unique for each certificate issued by a given CA (i.e., the issuer name and serial number identify a unique certificate). CAs MUST force the serialNumber to be a non-negative integer. ------------------------- openSUSE Secure Boot CA 4659838C.crt Serial Number: 1 (0x1) openSUSE Secure Boot Signkey 188EA6FA.crt Serial Number: 1 (0x1) <=== should not duplicate with CA or another other certificate which signed by the same CA. It must be 2 or 3 or even more... SLE keys: SUSE Linux Enterprise Secure Boot CA BCA4E38E.crt Serial Number: 1 (0x1) SUSE Linux Enterprise Secure Boot Signkey 91A3B0B5.crt Serial Number: 2 (0x2) We need security team's help to update the openSUSE sign key for increasing the Serial Number. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1159531 Marcus Meissner changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mls@suse.com Flags| |needinfo?(mls@suse.com) -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1159531 http://bugzilla.opensuse.org/show_bug.cgi?id=1159531#c22 --- Comment #22 from Joey Lee --- (In reply to Dominique Leuenberger from comment #21)

(In reply to Joey Lee from comment #17)

...

OK! I know what's happened now. The serial number of "openSUSE Secure Boot Signkey" should does _NOT_ equal to the serial number his parent CA, "openSUSE Secure Boot CA". Otherwise the kernel will confused with signkey and CA, then runs into the verification of Authority Key Identifier/Subject Key Identifier that it causes verification failed.

Base on rfc5280 (X.509) spec, the "Serial Number" must be unique:

-------------------------- 4.1.2.2. Serial Number

The serial number MUST be a positive integer assigned by the CA to each certificate. It MUST be unique for each certificate issued by a given CA (i.e., the issuer name and serial number identify a unique certificate). CAs MUST force the serialNumber to be a non-negative integer. -------------------------

That's frankly not how I interpret this RFC. IMHO, the RFC claims that the CN/Serial COMBO must be unique, but not that none of the CAs signees can have a serial number of the same value (that would be even close to impossible to guarantee, since the serial number of the CA can change and could in the future conflict with any of the sigs it ever signed)

What must not happen though is that a CA creates a new certificate with the same CN AND the same serial number as it already did in the past.

Practically I still suggest that serial number should be unique. It's better for more strict checking on some tools. e.g. The mozilla NSS database also rejected for enrolling openSUSE CA/signkey : # create a NSS database $ mkdir db $ certutil -N -d db --empty-password $ ls 188EA6FA-opensuse-signkey.crt 4659838C-opensuse-ca.crt db # add openSUSE CA $ certutil -A -i 4659838C-opensuse-ca.crt -d db -n "CN=openSUSE CA" -t "u,u,u"Notice: Trust flag u is set automatically if the private key is present. # add openSUSE Signkey $ certutil -A -i 188EA6FA-opensuse-signkey.crt -d db -n "CN=openSUSE Signkey" -t "u,u,u" Notice: Trust flag u is set automatically if the private key is present. certutil: could not decode certificate: SEC_ERROR_REUSED_ISSUER_AND_SERIAL: You are attempting to import a cert with the same issuer/serial as an existing cert, but that is not the same cert. The NSS also confused for openSUSE CA and signkey. Gary Lin found this situation before the SLE signkey's serial number be changed. So, a unique serial number is better for decoding by different tools. It's not hard to us (SUSE) for assigning unique serial number because we should not update/create certificates often. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1159531 Mircea Kitsune changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sonichedgehog_hyperblast00@ | |yahoo.com -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1159531 http://bugzilla.opensuse.org/show_bug.cgi?id=1159531#c24 Dominique Leuenberger changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |spamme@ecybernard.com --- Comment #24 from Dominique Leuenberger --- *** Bug 1160167 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1159531 http://bugzilla.opensuse.org/show_bug.cgi?id=1159531#c27 Anony Mous changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |xorbe@yahoo.com --- Comment #27 from Anony Mous ---

it now uses a random serial number. Does that solve this issue?

Is it possible to randomly generate serial number = 1 though? Which would fail, if I understand correctly. You need to make sure the random value doesn't conflict. -- You are receiving this mail because: You are on the CC list for the bug.