Bug 925479

there are some candidates:

commit b0191b238e32268bb3b48b43928c8af3cf509eea
Author: Lee, Chun-Yi <jlee@suse.com>
Date:   Sat Jan 31 00:09:27 2015 +0800

    KEYS: close race between key lookup and freeing (bnc#912202).


commit 8a264a3b8772215f544b1d362967927515249279
Author: Michal Marek <mmarek@suse.cz>
Date:   Tue Dec 17 21:14:03 2013 +0100

    Port module signing changes from SLE11-SP3 (fate#314508)

(this is in the  13.2 kernel update we are currently qaing ... michal?)

The recent commit taken from SLE11-SP3 tries to convert *.crt files to *.x509, and avoid auto-generating the key.  But openSUSE has no keys set up:

[  393s] + for f in '/home/abuild/rpmbuild/SOURCES/*.crt'
[  393s] + test -e /home/abuild/rpmbuild/SOURCES/_projectcert.crt
[  393s] + out=_projectcert.crt
[  393s] + out=_projectcert.x509
[  393s] + openssl x509 -inform PEM -in /home/abuild/rpmbuild/SOURCES/_projectcert.crt -outform DER -out _projectcert.x509
[  394s] + touch x509.genkey
....

So it takes only the project default *.crt, no UEFI certificate.

(In reply to Takashi Iwai from comment #5)

> So it takes only the project default *.crt, no UEFI certificate.

What is the expected run-time effect of that ?

I am asking since - according to our test procedure for secure booting - secure-boot was reported as still working.

(In reply to Heiko Rommel from comment #6)
> (In reply to Takashi Iwai from comment #5)
> 
> > So it takes only the project default *.crt, no UEFI certificate.
> 
> What is the expected run-time effect of that ?
> 
> I am asking since - according to our test procedure for secure booting -
> secure-boot was reported as still working.

My wild guess is that it's just because you imported the same signature at the very first installation.  Or I might miss something obvious...

Joey must have a better clue.  Joey, could you check it?

The error -19 is ENODEV. It caused by asymmetric key type didn't build in to openSUSE kernel, but system keyring codes in kernel found a embedded key and try to using asymmetric key type to parse it, so no key type fail!

This issue exposed a couple of things need to think:

 - First: Looks SYSTEM_TRUSTED_KEYRING kernel config should select ASYMMETRIC_KEY_TYPE. I will send patch to upstream to add the changes in init/Kconfig

 - Second: the SYSTEM_TRUSTED_KEYRING a.k.a. system kerying  is used by: MODULE_SIG, IMA, PKCS7(new), KEXEC_BZIMAGE_VERIFY_SIG(new),
   none of above functions enabled on openSUSE 13.2. So, we should think may disable SYSTEM_TRUSTED_KEYRING from openSUSE kernel.

 - Third: Per dmesg, looks load_system_certificate_list() codes found a embedded key in kernel binary then tried to parser it. If we don't need kernel module sign or IMA. Maybe we can remove the embedded key in kernel.


I will disable SYSTEM_TRUSTED_KEYRING in openSUSE 13.2 and openSUSE Factory until we enable IMA or kexec binary verification in future openSUSE version.

Experiencing the same bug with the recent kernel-desktop-3.16.7-13.2 update.

(In reply to e p from comment #10)
> Experiencing the same bug with the recent kernel-desktop-3.16.7-13.2 update.

Me too. (Mainboard ASRock 960GM/U3S3 FX)

*** Bug 926972 has been marked as a duplicate of this bug. ***

(In reply to Philipp - from comment #11)
> (In reply to e p from comment #10)
> > Experiencing the same bug with the recent kernel-desktop-3.16.7-13.2 update.
> 
> Me too. (Mainboard ASRock 960GM/U3S3 FX)

This message must appear on every machine no which variant is.  And, it's harmless, after all.  So, don't worry.

(In reply to Joey Lee from comment #9)
> I will disable SYSTEM_TRUSTED_KEYRING in openSUSE 13.2 and openSUSE Factory
> until we enable IMA or kexec binary verification in future openSUSE version.

Yeah, I agree with it.  The current situation with an error message just confuses users.

As a result of the issue my nvidia driver will not load anymore. They seem related to these: 

https://ask.fedoraproject.org/en/question/29067/problem-loading-in-kernel-x509-certificate-129/

http://superuser.com/questions/788401/adding-x-509-certificate-to-uefi-secure-boot-database 

So more annoying than just a console message during boot. . .

The same with nvidia - X fails to start. Great to have this on stable branch ;)
Any workaround?

X failing to start with nvidia drivers after updating the kernel has nothing to do with the problem with the x.509 certificate.

It's a different bug, a big one I think. After updating the kernel the previously installed binary from nvidia no longer works, because it needs some on-machine compilation process to link module against the new kernel and install it properly.

Just re-install the nvidia rpm packages and it should work again.

Opensuse guys.. how do you expect a normal user to react when after appliying an update and rebooted their systems as indicated, they stand up in front of a text terminal? They're not supposed to know what's happening, and how to solve it.

Quite frustrating don't you think so?

Updating the kernel should have in consideration if the user has nvidia drivers installed, or broadcom wl, or any other drivers which can lead to such a situation, and do an automatic re-installation of those packages, or at last, alert the user of what's gonna happen.

Best regards.

(In reply to stephan stephan from comment #15)
> As a result of the issue my nvidia driver will not load anymore. They seem
> related to these: 
> 
> https://ask.fedoraproject.org/en/question/29067/problem-loading-in-kernel-
> x509-certificate-129/
> 
> http://superuser.com/questions/788401/adding-x-509-certificate-to-uefi-
> secure-boot-database 
> 
> So more annoying than just a console message during boot. . .

The -129 error is EKEYREJECTED, it's not the same with the -29 on this issue. 

The kernel module signature verification function disabled by openSUSE community, so there should not have such error on openSUSE.

Before v3.13 kernel, the -129 error may caused by certificate date check, that's already removed by 124df9260 patch since v3.13.

In driver verify process, the -129 error means the hash value in digest doesn't match with the hash that we calculated in verification process. That may caused by the certificate doesn't match with the sign key of driver. 

Simply said, 2 cases. Both of them should not happened on openSUSE 13.2:

 - If you see "EFI: Problem loading in-kernel X.509 certificate (-129)"
   That should not happened after v3.13 kerel, please try newer kernel. If you sill found -129 when loading in-kernel certificate, please file bug to kernel upstream.

 - If you see -129 when loading driver, then please check does appropriate certificate already enrolled to db or mok.

(In reply to Joey Lee from comment #18)
[snip]
> The -129 error is EKEYREJECTED, it's not the same with the -29 on this issue
                                                             ^^^^
                                                             -19, sorry for typo

(In reply to Andrey Polunkin from comment #16)
> The same with nvidia - X fails to start.

https://bugzilla.opensuse.org/show_bug.cgi?id=927018

> Any workaround?

Rebuild driver for new kernel or boot previous version. If you do not know how to rebuild - remove RPM and reinstall.

Disable CONFIG_SYSTEM_TRUSTED_KEYRING in kernel config files for openSUSE-13.2, master (Factory) and stable (Tumbleweed):

openSUSE 13.2:

commit 55df6c23cae67820332ec0854288bf0ae5a3f51c
Author: Lee, Chun-Yi <jlee@suse.com>
Date:   Tue Apr 14 12:18:10 2015 +0800

    Update config files. (boo#925479)
    
    Do not set CONFIG_SYSTEM_TRUSTED_KEYRING until we need it in future
    openSUSE version:
    e.g. MODULE_SIG, IMA, PKCS7(new), KEXEC_BZIMAGE_VERIFY_SIG(new)


stable (Tumbleweed):

commit 74c332ba11409dc319e7ed43fbf41416eabe8534
Author: Lee, Chun-Yi <jlee@suse.com>
Date:   Tue Apr 14 12:39:50 2015 +0800

    Update config files. (boo#925479)
    
    Do not set CONFIG_SYSTEM_TRUSTED_KEYRING until we need it in future
    openSUSE version:
    e.g. MODULE_SIG, IMA, PKCS7(new), KEXEC_BZIMAGE_VERIFY_SIG(new)


master (Factory):

commit 5c4d917abf1a10aa0303223a027597bca837e4af
Author: Lee, Chun-Yi <jlee@suse.com>
Date:   Tue Apr 14 14:32:12 2015 +0800

    Update config files. (boo#925479)
    
    Do not set CONFIG_SYSTEM_TRUSTED_KEYRING until we need it in future
    openSUSE version:
    e.g. MODULE_SIG, IMA, PKCS7(new), KEXEC_BZIMAGE_VERIFY_SIG(new)

(In reply to Andrei Borzenkov from comment #20)
> (In reply to Andrey Polunkin from comment #16)
> > The same with nvidia - X fails to start.
> 
> https://bugzilla.opensuse.org/show_bug.cgi?id=927018
> 
> > Any workaround?
> 
> Rebuild driver for new kernel or boot previous version. If you do not know
> how to rebuild - remove RPM and reinstall.

Please note that the NVIDIA (3rd party) drivers suffer from an unrelated problem which might be impacting your case - see https://bugzilla.suse.com/show_bug.cgi?id=925437

Set this issue to FIXED.

CONFIG_SYSTEM_TRUSTED_KEYRING disabled in kernel config files for openSUSE-13.2, master (Factory) and stable (Tumbleweed). Please feel free to reopen this issue if you still see problem in new kernel.

I got the same message after ugrading to the new kernel version yesterday (13th April) - 3.16.7-17-desktop
Problem loading in-kernel X.509 certificate (-19)

Furthermore I got a x windows problem after the kernel upgrade - NVIDIA graphic drivers not starting properly (this never happened before after kernel upgrades)
This problem could be solved by refreshing the NVIDIA driver installation via YaST.

Thanks Alexander,
   but i'm not a smart user :-(
How can i "Refresh the NVIDIA driver installation via YaST"?

I started Yast -> Software management -> Search Nvidia and i found
i    X11-videonvidia-G02
i    xf86-video-nouveau
i    xf86-video-nv

Actually i was using the first one.

As possible actions i find:
toggle
Install
delete
update
Taboo
lock

Do i have to delete driver and install it again?

By the way, can i remove NV and Nouveau drivers?

bye, andrea

(In reply to Andrea Celli from comment #25)
> Thanks Alexander,
>    but i'm not a smart user :-(
> How can i "Refresh the NVIDIA driver installation via YaST"?
> 
> I started Yast -> Software management -> Search Nvidia and i found
> i    X11-videonvidia-G02
> i    xf86-video-nouveau
> i    xf86-video-nv
> 
> Actually i was using the first one.
> 
> As possible actions i find:
> toggle
> Install
> delete
> update
> Taboo
> lock
> 
> Do i have to delete driver and install it again?
> 
> By the way, can i remove NV and Nouveau drivers?
> 
> bye, andrea

Hi Andrea,

first of all I was lucky that some low resolution X windows system popped up instead of NVIDIA. Therefore I was still able to use the graphical YaST UI.
Furthermore you seem to have an older NVIDIA version than I have.

I selected in YaST to display the software source NVIDIA and then selected "update" for all as installed listed rpms. 
This should also be possible with the text version of YaST. 

If this doesn't work, delete the NVIDIA and check whether it then starts with NV or Noveau.

Best regards,

Alexander

JFY, i removed the current 13.2 kernel update from the server.

it will be replaced with a newer one with this issue not appearing.

(In reply to Alexander König from comment #24)
> I got the same message after ugrading to the new kernel version yesterday
> (13th April) - 3.16.7-17-desktop
> Problem loading in-kernel X.509 certificate (-19)
> 
> Furthermore I got a x windows problem after the kernel upgrade - NVIDIA
> graphic drivers not starting properly (this never happened before after
> kernel upgrades)
> This problem could be solved by refreshing the NVIDIA driver installation
> via YaST.

Typo error: not 3.16.7-17-desktop but 3.16.7-13-desktop

Update to 3.16.7-21-desktop on 13.2 required refreshment of NVIDIA driver - I had the 3.16.7-13-desktop kernel installed and my NVIDIA module refreshed for that