Bug 1173158 - CONFIG_MODULE_SIG=y
CONFIG_MODULE_SIG=y
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Distribution
Classification: openSUSE
Component: Kernel
Leap 15.2
Other Other
: P2 - High : Normal (vote)
: ---
Assigned To: openSUSE Kernel Bugs
E-mail List
https://bugzilla.suse.com/show_bug.cg...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2020-06-19 11:55 UTC by Ludwig Nussel
Modified: 2020-08-22 23:03 UTC (History)
16 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ludwig Nussel 2020-06-19 11:55:51 UTC
The 15.2 kernel has CONFIG_MODULE_SIG=y enabled. Correct me if I'm wrong but that means the NVidia driver won't work with secure boot enabled, right? Users would have to go to the BIOS and disable secure boot. A step that was not required in any openSUSE before, right?

Do we really want that? If so, requires explicit documentation IMO.
Comment 1 Ludwig Nussel 2020-06-19 11:58:29 UTC
(see bug 1173115) for another side effect
Comment 2 Takashi Iwai 2020-06-19 12:51:55 UTC
It must work with the 3rd party modules, too.  We've used this option for SLE kernels for many years, and TW is with this option already for some time, too.

Feel free to reopen if you really encounter the problem with the 3rd party modules.
Comment 3 Ludwig Nussel 2020-06-19 12:57:20 UTC
I do not have a system to test this with. That's why I'm asking for confirmation. Googling showed forum posts that recommended turning of secure boot but then for TW we make no promises for NVidia either. This document found by Google from NVidia instructions talk about signing kernel modules: https://download.nvidia.com/XFree86/Linux-x86/319.23/README/installdriver.html

There doesn't seem to be code in the NVidia driver packages doing such things (unless I don't see it). So how does this work?
Comment 4 Stefan Dirsch 2020-06-19 14:42:05 UTC
Indeed our NVIDIA packages do not support secureboot. Never did. It surprised me, but I can't remember any customer ever requesting this.

And it would be rather hard to implement it, since the kernel module is built on the target system during installation/update of the "KMP". So one would need to generate an additional Key on the target system and sign the module with that key during build.
Comment 5 Stefan Dirsch 2020-06-19 14:42:38 UTC
For me it seems simply nobody is using secureboot ...
Comment 6 Ludwig Nussel 2020-06-19 16:13:37 UTC
Any Windows 10 PC you buy nowadays has secure boot enabled by default. Normally there is no reason turn it off for openSUSE as our bootloader and kernel is signed by MS. So far on openSUSE we did not require kernel module signing exactly for the reason to allow having custom modules like the NVidia driver.
If we decide to change that on upgrade it deserves documenting.
Comment 7 Ludwig Nussel 2020-06-19 16:16:18 UTC
(In reply to Stefan Dirsch from comment #4)
> Indeed our NVIDIA packages do not support secureboot. Never did. It
> surprised me, but I can't remember any customer ever requesting this.
> 
> And it would be rather hard to implement it, since the kernel module is
> built on the target system during installation/update of the "KMP". So one
> would need to generate an additional Key on the target system and sign the
> module with that key during build.

Technically it shouldn't be a big problem to do as part of those scripts I supose. The infrastructure is already there after all. Just needs some effort to actually implement. It's possible to schedule a custom key for inclusion on next boot (see bug#1173115).
Comment 8 Takashi Iwai 2020-06-19 16:31:31 UTC
Hrm, that's bad, I thoguht that we had a kind of automatic key enrollment for Nvidia in the past, at least at the beginning of the Secure Boot support.

The problem isn't too serious on TW because the TW kernel (i.e. the upstream kernel) still has no strict lockdown.  SLE / Leap kernel has a stricter lockdown, so it can be an actual problem.  It might be a problem on TW as well once when the upstream accepts the more lockdown.

IOW, it's not only about CONFIG_MODULE_SIG.  Rather the key point is whether the kernel has a lockdown feature for the unsigned module or not.
Comment 9 Stefan Dirsch 2020-06-19 17:00:35 UTC
(In reply to Ludwig Nussel from comment #7)
> (In reply to Stefan Dirsch from comment #4)
> > Indeed our NVIDIA packages do not support secureboot. Never did. It
> > surprised me, but I can't remember any customer ever requesting this.
> > 
> > And it would be rather hard to implement it, since the kernel module is
> > built on the target system during installation/update of the "KMP". So one
> > would need to generate an additional Key on the target system and sign the
> > module with that key during build.
> 
> Technically it shouldn't be a big problem to do as part of those scripts I
> supose. The infrastructure is already there after all. Just needs some
> effort to actually implement. It's possible to schedule a custom key for
> inclusion on next boot (see bug#1173115).

If you believe it's easy send me a patch. For me it won't be easy at all. The build scripts are non-interactive, so I don't see where one can add the user interaction for accepting to add a generated custom key. I don't know anything about an existing infrastructure for doing this and I don't understand the comments in #1173115 at all.
Comment 10 Stefan Dirsch 2020-06-19 17:06:52 UTC
(In reply to Takashi Iwai from comment #8)
> Hrm, that's bad, I thoguht that we had a kind of automatic key enrollment
> for Nvidia in the past, at least at the beginning of the Secure Boot support.

No. We never had. I remember discussing years ago, that it would be good to have it, but it never was implemented. And IIRC we would also have needed additionally functionality outside of the NVIDIA packages for key generation, etc.... 

And then I never got a report, that things wouldn't work, so I suggested nobody is using Secure boot.
Comment 11 Michal Kubeček 2020-06-22 09:29:38 UTC
Have you really checked that we actually have a problem with unsigned modules?

We have

  CONFIG_MODULE_SIG=y
  CONFIG_MODULE_SIG_FORCE=n

in Leap 15.2 kernel and the help text for CONFIG_MODULE_SIG_FORCE says

    Reject unsigned modules or signed modules for which we don't have a
    key.  Without this, such modules will simply taint the kernel.

so that loading an unsigned module (or module signed with an unknown key)
should taint the kernel and write a warning into kernel log but the module
should load anyway.
Comment 12 Ludwig Nussel 2020-06-22 09:36:06 UTC
No as I wrote in comment#3 I do not have system to test this. I noticed the difference in kernel config due to bug#1173115 that's why I raised this. If the system behaves as you describe there are no further concerns from my side.
Comment 14 Stefan Dirsch 2020-06-22 09:49:29 UTC
(In reply to Ludwig Nussel from comment #12)
> No as I wrote in comment#3 I do not have system to test this. I noticed the
> difference in kernel config due to bug#1173115 that's why I raised this. If
> the system behaves as you describe there are no further concerns from my
> side.

I fully agree!
Comment 15 Lubos Kocman 2020-06-22 11:55:15 UTC
Release notes record https://github.com/openSUSE/release-notes-openSUSE/pull/96
Comment 16 Lubos Kocman 2020-06-22 22:02:35 UTC
Marking as a feature communicated via release-notes.
Comment 19 Martin Wilck 2020-06-24 10:30:56 UTC
(In reply to Stefan Dirsch from comment #18)
> > It's indeed not easy. We could use a key stored in a standard location on
> > the user's system. However, at the very least the build procedure should
> > allow to enter the pass phrase for the key in a secure manner. Otherwise the
> > secret key would need to be stored unencrypted on the target system, which
> > would forfeit the use of secure boot, or a locked-down kernel, almost
> > entirely.
> 
> I haven't looked deeper into this, but this were my first thoughts as well.
> I think the idea was to sign the module with the first boot after installing
> it in a still to be developed interactive mode. Technical ideas. No idea. 

You can't sign the module during boot. All you can do is enroll the key with which the module was signed into MOK. The signature must be made while the module is built, or thereafter. Once the key is enrolled, and you always sign self-build modules with the same key, you don't need to enroll again (but you must sign every single .ko file you build).

> > Alternatively, there could be a way to transform the Nvidia pseudo-KMP into
> > a real KMP *by the user*. The user could run this procedure on some
> > particularly protected system, and distribute the generated KMP plus the
> > associated cert to the systems in his data center.
> 
> Which then may break with the first kernel update. Yes, a kernel update
> triggers a rebuild and reinstallation of the module.

I didn't make myself clear. That "real KMP" I talked about would not trigger the rebuild. It would rather rely on KABI, like real KMPs do. If the KABI changes, the "real KMP" would need to be rebuilt. I'd hope that wouldn't happen too often, at least not on Leap.
Comment 20 Michal Kubeček 2020-06-24 10:46:24 UTC
(In reply to Martin Wilck from comment #19)
> I didn't make myself clear. That "real KMP" I talked about would not trigger
> the rebuild. It would rather rely on KABI, like real KMPs do. If the KABI
> changes, the "real KMP" would need to be rebuilt. I'd hope that wouldn't
> happen too often, at least not on Leap.

We do not check kABI in Leap kernel branches like we do in SLE but as
openSUSE-15.2 shares the codebase (same tarball and patches) with SLE15-SP2,
the risk of breaking kABI in a way that would cause trouble is relatively low.
It would have to be a kABI breakage that would only manifest in parts of the
code which are built in openSUSE-15.2 but not SLE15-SP2.
Comment 21 Stefan Dirsch 2020-06-24 11:11:38 UTC
(In reply to Martin Wilck from comment #19)
> (In reply to Stefan Dirsch from comment #18)
> > > It's indeed not easy. We could use a key stored in a standard location on
> > > the user's system. However, at the very least the build procedure should
> > > allow to enter the pass phrase for the key in a secure manner. Otherwise the
> > > secret key would need to be stored unencrypted on the target system, which
> > > would forfeit the use of secure boot, or a locked-down kernel, almost
> > > entirely.
> > 
> > I haven't looked deeper into this, but this were my first thoughts as well.
> > I think the idea was to sign the module with the first boot after installing
> > it in a still to be developed interactive mode. Technical ideas. No idea. 
> 
> You can't sign the module during boot. All you can do is enroll the key with
> which the module was signed into MOK. The signature must be made while the
> module is built, or thereafter. Once the key is enrolled, and you always
> sign self-build modules with the same key, you don't need to enroll again
> (but you must sign every single .ko file you build).

Thanks for the comment. That's what I meant. ;-) 

> > > Alternatively, there could be a way to transform the Nvidia pseudo-KMP into
> > > a real KMP *by the user*. The user could run this procedure on some
> > > particularly protected system, and distribute the generated KMP plus the
> > > associated cert to the systems in his data center.
> > 
> > Which then may break with the first kernel update. Yes, a kernel update
> > triggers a rebuild and reinstallation of the module.
> 
> I didn't make myself clear. That "real KMP" I talked about would not trigger
> the rebuild. It would rather rely on KABI, like real KMPs do. If the KABI
> changes, the "real KMP" would need to be rebuilt. I'd hope that wouldn't
> happen too often, at least not on Leap.

Thanks. That's what I already understood. But we don't guarantee kABI compatibility on Leap. ;-)
Comment 22 Stefan Dirsch 2020-06-24 11:13:35 UTC
(In reply to Michal Kubeček from comment #20)
> (In reply to Martin Wilck from comment #19)
> > I didn't make myself clear. That "real KMP" I talked about would not trigger
> > the rebuild. It would rather rely on KABI, like real KMPs do. If the KABI
> > changes, the "real KMP" would need to be rebuilt. I'd hope that wouldn't
> > happen too often, at least not on Leap.
> 
> We do not check kABI in Leap kernel branches like we do in SLE but as
> openSUSE-15.2 shares the codebase (same tarball and patches) with SLE15-SP2,
> the risk of breaking kABI in a way that would cause trouble is relatively
> low.
> It would have to be a kABI breakage that would only manifest in parts of the
> code which are built in openSUSE-15.2 but not SLE15-SP2.

Yeah. Just double-checked. Seems we only rebuild the kernel module on Tumbleweed. ;-)
Comment 23 Ludwig Nussel 2020-06-24 11:32:19 UTC
(In reply to Martin Wilck from comment #17)
> It's indeed not easy. We could use a key stored in a standard location on
> the user's system. However, at the very least the build procedure should
> allow to enter the pass phrase for the key in a secure manner. Otherwise the
> secret key would need to be stored unencrypted on the target system, which
> would forfeit the use of secure boot, or a locked-down kernel, almost
> entirely.

Right now we are loading unsigned modules so there is not much of a difference to that. In the worst case if storing the private key really is a concern, a new one could be created for each rebuild of the ko and the private key deleted afterwards. Sure, that means enrolling the key on reboot then. If one really decides to play that secure boot game it's a matter of picking your poison basically :-)
Comment 24 Martin Wilck 2020-06-24 11:37:21 UTC
(In reply to Ludwig Nussel from comment #23)

> Right now we are loading unsigned modules so there is not much of a
> difference to that. 

Yes it is, it's pretending to be safe while it's not. You may argue the same holds for SB in general, but hey, unencrypted secret keys on the disk of the system they're supposed to protect should be a no-go in any case.

> In the worst case if storing the private key really is a
> concern, a new one could be created for each rebuild of the ko and the
> private key deleted afterwards.

That I'd really call the worst case. The whole MOK concept only makes sense if you generate a key that you intend to trust, and keep that key reasonably safe. If you're not willing to do that, you'll be better off by just disabling secure boot (or use unsigned modules).
Comment 25 Ludwig Nussel 2020-06-24 11:57:16 UTC
(In reply to Martin Wilck from comment #24)
> > In the worst case if storing the private key really is a
> > concern, a new one could be created for each rebuild of the ko and the
> > private key deleted afterwards.
> 
> That I'd really call the worst case. The whole MOK concept only makes sense
> if you generate a key that you intend to trust, and keep that key reasonably
> safe. If you're not willing to do that, you'll be better off by just
> disabling secure boot (or use unsigned modules).

I'm not disagreeing. The options for an out of the box experience with secure boot + proprietary kernel modules that doesn't suck are limited though. As I said, pick your poison. If mok wanting to import keys on kernel updates once per month is annoying (how annoying highly depends on the UI we offer though), users will ask dr google who would then hopefully point to an article on the opensuse wiki explaining alternatives such as turning off secure boot, not using the nvidia driver or configuring some fancy secret key retrieval script.
That's still better than the kernel silently (yes, logging into dmesg is still pretty silent) not loading the kernel module resulting in a crashing X or so.
Comment 26 Martin Wilck 2020-06-24 13:24:14 UTC
I've spent years of my professional life building KMPs with proprietary modules *and* secure boot support. It can be done, and it's possible to make it work almost hassle-free for end users. Granted, I had the bonus that my signing key was pre-loaded in the BIOS of the servers my former employer sold. But that's just a single, once-in-a-system-lifetime MOK operation away.

For NVidia, it "just" takes someone willing to take the legal risk of distributing the drivers in proper KMP format.
Comment 27 Ludwig Nussel 2020-06-24 13:41:03 UTC
(In reply to Martin Wilck from comment #26)
> For NVidia, it "just" takes someone willing to take the legal risk of
> distributing the drivers in proper KMP format.

That is out of question AFAIK. It was decided years ago that SUSE will not act against upstream kernel PoV on the matter.
Comment 30 Jiri Slaby 2020-06-25 07:27:15 UTC
(In reply to Martin Wilck from comment #26)
> sold. But that's just a single, once-in-a-system-lifetime MOK operation away.

The upstream kernel does not verify module signatures against MOK keys. You need a non-upstream patch:
  patches.suse/KEYS-Make-use-of-platform-keyring-for-module-signatu.patch
for that. Leap indeed inherits it from SLE, TW doesn't have it...

So TW should keep MODULE_SIG as I don't want to lose the ability to check if modules are genuine. If you ask me, I would not set SIG_FORCE to allow loading of other modules (like nvidia, but there are many others, like those built by myself). Loading such a module properly taints the kernel which is good.

For Leap, I have no opinion.
Comment 31 Jiri Slaby 2020-06-25 07:33:22 UTC
(In reply to Ludwig Nussel from comment #1)
> (see bug 1173115) for another side effect

It's not about signed modules, AFAICT -- mokutil loads to MOK a key the kernel is signed by.
Comment 32 Jiri Slaby 2020-06-25 07:34:27 UTC
FTR, the bug 1082905 was opened to turn MODULE_SIG in master+stable on.
Comment 33 Wolfgang Bauer 2020-07-08 16:45:15 UTC
FYI, there is a bug report about a not working nvidia driver with Secure Boot enabled in Leap 15.2 now.

See bug#1173682 .
Comment 34 Stefan Dirsch 2020-07-08 22:44:04 UTC
Oh. Wonderful! The only thing we now can do is document it in the release notes. Anyone planning to use nvidia driver should disable secure boot before installing Leap 15.2. Users updating their secure boot Leap 15.1 system are somewhat lost. They may try to use nouveau driver or keep running an openSUSE Leap 15.1. kernel. Sigh.

(In reply to Michal Kubeček from comment #11)
> Have you really checked that we actually have a problem with unsigned
> modules?

Unfortunately nobody did at that time. :-(

> We have
> 
>   CONFIG_MODULE_SIG=y
>   CONFIG_MODULE_SIG_FORCE=n
> 
> in Leap 15.2 kernel and the help text for CONFIG_MODULE_SIG_FORCE says
> 
>     Reject unsigned modules or signed modules for which we don't have a
>     key.  Without this, such modules will simply taint the kernel.
> 
> so that loading an unsigned module (or module signed with an unknown key)
> should taint the kernel and write a warning into kernel log but the module
> should load anyway.

Obviously this turned out to be fake news. :-(
Comment 35 Martin Wilck 2020-07-08 23:42:57 UTC
(In reply to Stefan Dirsch from comment #34)

> Obviously this turned out to be fake news. :-(

And we also got it wrong in the release notes :-((

> https://doc.opensuse.org/release-notes/x86_64/openSUSE/Leap/15.2/#sec.driver.sig

I have to confess I didn't test this myself, and what Michal said matched my shady memories how it used to behave when I last tried (+4y ago).
Comment 36 Martin Wilck 2020-07-08 23:46:12 UTC
From bug 1173682, comment 0:

> Lockdown: modprobe: unsigned module loading is restricted; see man kernel_lockdown.7

Is this perhaps caused by recent lockdown patches? Is that the reason why it doesn't behave the way we were used to?
Comment 37 Michal Kubeček 2020-07-08 23:57:00 UTC
(In reply to Martin Wilck from comment #36)
> Is this perhaps caused by recent lockdown patches? Is that the reason why it
> doesn't behave the way we were used to?

Not so recent, actually. The lockdown backport was merged into SLE15-SP2
branch on November 27th and into openSUSE-15.2 one day later.
Comment 38 Stefan Dirsch 2020-07-09 02:20:16 UTC
(In reply to Martin Wilck from comment #35)
> And we also got it wrong in the release notes :-((
> 
> > https://doc.opensuse.org/release-notes/x86_64/openSUSE/Leap/15.2/#sec.driver.sig

> "Importantly, this affects NVIDIA or AMD graphics drivers from the manufacturer's repositories"

This sounds very confusing. As if AMD and NVIDIA would provide signed kernel modules. They don't. They only provide a binary part, which gets built/linked against a glue layer source during installation. 

> "Kernel Module Packages (KMPs) from the official openSUSE repositories are not affected, because the modules they contain
>  are signed with the openSUSE key."

Do we offer any openSUSE KMPs other than the one for NVIDIA? I doubt. And the NVIDIA one is very special, because everything is build/linked on the target system for legal reasons. Or are openSUSE Community repos not considered official? Could be ...

> "Kernel modules that are not signed will be treated as being “tainted”. Loading them will result in a warning message, but
>  they will function."

now proved to be a wrong assumption :-( 

> I have to confess I didn't test this myself, and what Michal said matched my
> shady memories how it used to behave when I last tried (+4y ago).

I haven't tested this either unfortunately. :-(
Comment 39 Stefan Dirsch 2020-07-09 02:33:10 UTC
(In reply to Michal Kubeček from comment #37)
> (In reply to Martin Wilck from comment #36)
> > Is this perhaps caused by recent lockdown patches? Is that the reason why it
> > doesn't behave the way we were used to?
> 
> Not so recent, actually. The lockdown backport was merged into SLE15-SP2
> branch on November 27th and into openSUSE-15.2 one day later.

Not that old. We would need a kernel build before this happened to see whether the lockdown is the culprit here. 

And if it is I would expect - even if there would an agreement to remove this feature (very unlikely?) - it won't be doable any longer with thousands of patches sitting on top of it meanwhile ...
Comment 40 Stefan Dirsch 2020-07-09 02:43:12 UTC
(In reply to Takashi Iwai from comment #8)
> The problem isn't too serious on TW because the TW kernel (i.e. the upstream
> kernel) still has no strict lockdown.  SLE / Leap kernel has a stricter
> lockdown, so it can be an actual problem.  It might be a problem on TW as
> well once when the upstream accepts the more lockdown.

Seems we didn't listen closely to Takashi. :-( Can we have "less" lockdown, please? ;-)

> IOW, it's not only about CONFIG_MODULE_SIG.  Rather the key point is whether
> the kernel has a lockdown feature for the unsigned module or not.

Hmm. Is this configurable?
Comment 42 Michal Kubeček 2020-07-09 08:00:28 UTC
One thing we should keep in mind is that secure boot, i.e. making sure only
properly signed kernel is loaded, makes very little sense if we then allow
loading any strange module into it. It could be even considered a security
vulnerability.

So rather than asking for "less lockdown" (for everyone), I would suggest to
look for a (secure enough) way to opt out from strict checking that people
who want to run NVidia modules on systems with secure boot could do. One
obvious idea is a command line parameter - but that is also obviously wrong.
Do we have some option to pass parameters "from outside"? Could e.g. EFI
variables be used for this? Adding Joey Lee who did the lockdown backport
and knows way more about how it works.

Ther preferrable (if viable) solution should still be having the NVidia
modules signed, even if with a key that is kept on the system itself (which
is, naturally, also questionable from security point of view). AFAIK the
module consists of two parts, "GPL wrapper" and the actual driver which has
kernel incompatible license; does it suffice to sign the "GPL wrapper"?
Some other out of tree modules, e.g. host modules for VMware Workstation,
go this way: if you have secure boot, you need to sign the modules after you
build them.
Comment 44 Martin Wilck 2020-07-09 08:28:14 UTC
(In reply to Michal Kubeček from comment #42)

> Ther preferrable (if viable) solution should still be having the NVidia
> modules signed, even if with a key that is kept on the system itself (which
> is, naturally, also questionable from security point of view).

Indeed, I'd say it's not much better than allowing unsigned modules in the first place.

> AFAIK the
> module consists of two parts, "GPL wrapper" and the actual driver which has
> kernel incompatible license; does it suffice to sign the "GPL wrapper"?

Unless I'm very mistaken, the full module has to be signed. Otherwise circumvention of the lockdown feature would be just too easy. In theory the firmware loading mechanism could be abused to load a binary blob, but the Nvidia driver doesn't do that, and I guess lockdown would prevent this mechanism somehow, too.

> Some other out of tree modules, e.g. host modules for VMware Workstation,
> go this way: if you have secure boot, you need to sign the modules after you
> build them.

Heck, I really don't understand why this has to be done differently for almost every module. 

      *SUSE has an excellent technology to solve this problem.*

It is called "Kernel Module Packages", most of it has been designed and engineered at SUSE, and it has well-established processes behind it (Solid Driver). SUSE is better at this than any other Linux distro I'm aware of.

The only issue with KPMs in this context is that we can't use OBS to create *proprietary* KMPs for legal reasons, and can't distribute them on our servers. The obvious solution would be to have some external entity (preferably NVidia itself) set up an OBS instance, enabled for module signing, and a key. They don't have to do the KMP engineering themselves if they lack the ability, we'd find someone to do it for them. They'd just have to throw the spec file at their private OBS instance, build, and create a repo.
Comment 45 Martin Wilck 2020-07-09 08:38:58 UTC
While I think the KMP solution is The Right Thing (TM), it is obviously not viable short-term. Here's an idea what we can do quickly:

 - create a new kernel flavor, call it "nolockdown" or whatever, that loosens lockdown features enough to load NVidia and other proprietary drivers.
 - sign this flavor with a different key, which is not allowed on SB systems by default. People who want to use that key would need to set it up using mokutil. that would be a one-time measure, as opposed to having to provide keys with every driver rebuild.
 - that kernel package could be accompanied by an EULA file explaining why it exists and what the security implications are.

Advantages:

 * It allows leaving the secure boot setting on in the BIOS (might be mandated by another OS on the system, or other policies).
 * It satisfies the security requirement that enabling it requires an explicit action of the user in the UEFI environment ("physical presence" - well).
 * It's far better than adding a "nolockdown" kernel command line parameter from a security PoV.
 * Security-wise, people using this kernel would be as "good" as Leap 15.1 users, possibly a little better off.
 * It's less hassle for users than having to create and deploy keys themselved, possibly repeatedly.
 * It should be pretty quick to implement, no re-engineering of NVidia drivers needed.
Comment 46 Michal Kubeček 2020-07-09 08:56:24 UTC
(In reply to Ludwig Nussel from comment #43)
> https://media.giphy.com/media/3oEjHMBUxwVJ9iu5JS/giphy.gif

Could you be more specific?
Comment 47 Michal Kubeček 2020-07-09 09:11:01 UTC
(In reply to Martin Wilck from comment #45)
>  - sign this flavor with a different key, which is not allowed on SB systems
> by default. People who want to use that key would need to set it up using
> mokutil. that would be a one-time measure, as opposed to having to provide
> keys with every driver rebuild.

I'm not sure if our setup is able to use different keys for different flavors
or if it can be taught to with reasonable effort. We would need someone
familiar with the implementation to answer this.
Comment 48 Martin Wilck 2020-07-09 09:17:13 UTC
(In reply to Michal Kubeček from comment #47)

> I'm not sure if our setup is able to use different keys for different flavors
> or if it can be taught to with reasonable effort. We would need someone
> familiar with the implementation to answer this.

Perhaps we could build that flavor in a different project?
Comment 49 Joey Lee 2020-07-09 10:15:02 UTC
(In reply to Michal Kubeček from comment #11)
> Have you really checked that we actually have a problem with unsigned
> modules?
> 
> We have
> 
>   CONFIG_MODULE_SIG=y
>   CONFIG_MODULE_SIG_FORCE=n
> 
> in Leap 15.2 kernel and the help text for CONFIG_MODULE_SIG_FORCE says
> 
>     Reject unsigned modules or signed modules for which we don't have a
>     key.  Without this, such modules will simply taint the kernel.
> 
> so that loading an unsigned module (or module signed with an unknown key)
> should taint the kernel and write a warning into kernel log but the module
> should load anyway.

For upstream kernel, yes! But on SLE and LEAP (inherit from SLE), kernel has a SUSE patch that it enable SIG_FORCE when secure boot be enabled.
Comment 50 Stefan Dirsch 2020-07-09 10:43:58 UTC
(In reply to Joey Lee from comment #49)
> (In reply to Michal Kubeček from comment #11)
> > Have you really checked that we actually have a problem with unsigned
> > modules?
> > 
> > We have
> > 
> >   CONFIG_MODULE_SIG=y
> >   CONFIG_MODULE_SIG_FORCE=n
> > 
> > in Leap 15.2 kernel and the help text for CONFIG_MODULE_SIG_FORCE says
> > 
> >     Reject unsigned modules or signed modules for which we don't have a
> >     key.  Without this, such modules will simply taint the kernel.
> > 
> > so that loading an unsigned module (or module signed with an unknown key)
> > should taint the kernel and write a warning into kernel log but the module
> > should load anyway.
> 
> For upstream kernel, yes! But on SLE and LEAP (inherit from SLE), kernel has
> a SUSE patch that it enable SIG_FORCE when secure boot be enabled.

LOL. So let's revert this, so we're back to the behaviour we've agreed on here before. Sorry, guys. But we can't silently do such a fundamental change without announcing it at least a release before (I would suggest sle16/Leap 16.x for such a change). I'm not aware of any Feature ticket or bug to make it impossible to load unsigned modules either. I asked for such tickets. Nobody could give me a reference for such a ticket ...
Comment 51 Stefan Dirsch 2020-07-09 10:49:38 UTC
For now we can add to Release Notes and openSUSE WIKI how to sign a kernel module on a secure boot system. Of course this needs to be redone with each kernel update ...
Comment 52 Stefan Dirsch 2020-07-09 10:50:05 UTC
reopen ...
Comment 53 Michal Kubeček 2020-07-09 10:58:26 UTC
(In reply to Stefan Dirsch from comment #50)
> LOL.

I already asked you once (in private) to behave constructively in bugzilla.
Clearly it fell to deaf ears.

> I'm not aware of any Feature ticket or bug to make it impossible to load
> unsigned modules either. I asked for such tickets. Nobody could give me
> a reference for such a ticket ...

jsc#SLE-9870 for one
Comment 54 Joey Lee 2020-07-09 10:59:40 UTC
(In reply to Joey Lee from comment #49)
> (In reply to Michal Kubeček from comment #11)
> > Have you really checked that we actually have a problem with unsigned
> > modules?
> > 
> > We have
> > 
> >   CONFIG_MODULE_SIG=y
> >   CONFIG_MODULE_SIG_FORCE=n
> > 
> > in Leap 15.2 kernel and the help text for CONFIG_MODULE_SIG_FORCE says
> > 
> >     Reject unsigned modules or signed modules for which we don't have a
> >     key.  Without this, such modules will simply taint the kernel.
> > 
> > so that loading an unsigned module (or module signed with an unknown key)
> > should taint the kernel and write a warning into kernel log but the module
> > should load anyway.
> 
> For upstream kernel, yes! But on SLE and LEAP (inherit from SLE), kernel has
> a SUSE patch that it enable SIG_FORCE when secure boot be enabled.

(In reply to Joey Lee from comment #49)
> (In reply to Michal Kubeček from comment #11)
> > Have you really checked that we actually have a problem with unsigned
> > modules?
> > 
> > We have
> > 
> >   CONFIG_MODULE_SIG=y
> >   CONFIG_MODULE_SIG_FORCE=n
> > 
> > in Leap 15.2 kernel and the help text for CONFIG_MODULE_SIG_FORCE says
> > 
> >     Reject unsigned modules or signed modules for which we don't have a
> >     key.  Without this, such modules will simply taint the kernel.
> > 
> > so that loading an unsigned module (or module signed with an unknown key)
> > should taint the kernel and write a warning into kernel log but the module
> > should load anyway.
> 
> For upstream kernel, yes! But on SLE and LEAP (inherit from SLE), kernel has
> a SUSE patch that it enable SIG_FORCE when secure boot be enabled.

The LOCK_DOWN_IN_EFI_SECURE_BOOT=n can be used to disable the connection between secure boot with kernel lock down mode. But that means we must maintain a Leap flavor kernel config.
Comment 55 Martin Wilck 2020-07-09 11:08:40 UTC
(In reply to Joey Lee from comment #54)

> The LOCK_DOWN_IN_EFI_SECURE_BOOT=n can be used to disable the connection
> between secure boot with kernel lock down mode. But that means we must
> maintain a Leap flavor kernel config.

Right, see comment 45. If we follow that route, we should review in some more detail which lockdown-related settings we want to change.

Also, we'd want to use a different signature for that kernel. Otherwise, the "nolockdown" kernel would just be the malware writers' method of choice to persistently subvert otherwise secure systems.
Comment 56 Stefan Dirsch 2020-07-09 11:26:18 UTC
(In reply to Michal Kubeček from comment #53)
> I already asked you once (in private) to behave constructively in bugzilla.
> Clearly it fell to deaf ears.

I apologize. It wasn't my intention.

> > I'm not aware of any Feature ticket or bug to make it impossible to load
> > unsigned modules either. I asked for such tickets. Nobody could give me
> > a reference for such a ticket ...
> 
> jsc#SLE-9870 for one

Thanks. I'm missing a discussion there which implications (benefits, possible regressions) this patch may have to our products, let alone it would have been mentioned that it would prevent the loading of unsigned modules. Sigh.
Comment 57 Joey Lee 2020-07-09 11:37:31 UTC
(In reply to Joey Lee from comment #49)
> (In reply to Michal Kubeček from comment #11)
> > Have you really checked that we actually have a problem with unsigned
> > modules?
> > 
> > We have
> > 
> >   CONFIG_MODULE_SIG=y
> >   CONFIG_MODULE_SIG_FORCE=n
> > 
> > in Leap 15.2 kernel and the help text for CONFIG_MODULE_SIG_FORCE says
> > 
> >     Reject unsigned modules or signed modules for which we don't have a
> >     key.  Without this, such modules will simply taint the kernel.
> > 
> > so that loading an unsigned module (or module signed with an unknown key)
> > should taint the kernel and write a warning into kernel log but the module
> > should load anyway.
> 
> For upstream kernel, yes! But on SLE and LEAP (inherit from SLE), kernel has
> a SUSE patch that it enable SIG_FORCE when secure boot be enabled.

Sorry! I want to update the above comment.

The SUSE patch be applied on old SLE kernel. For any new kernel after v5.2-rc1, Mimi Zohar's IMA patch puts the same logic to mainline kernel:

commit 8db5da0b8618df79eceea99672e205d4a2a6309e
Author: Mimi Zohar <zohar@linux.ibm.com>
Date:   Sun Jan 27 19:03:45 2019 -0500

    x86/ima: require signed kernel modules

    Have the IMA architecture specific policy require signed kernel modules
    on systems with secure boot mode enabled; and coordinate the different
    signature verification methods, so only one signature is required.

    Requiring appended kernel module signatures may be configured, enabled
    on the boot command line, or with this patch enabled in secure boot
    mode.  This patch defines set_module_sig_enforced().

    To coordinate between appended kernel module signatures and IMA
    signatures, only define an IMA MODULE_CHECK policy rule if
    CONFIG_MODULE_SIG is not enabled.  A custom IMA policy may still define
    and require an IMA signature.

    Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
    Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
    Acked-by: Jessica Yu <jeyu@kernel.org>

But the logic only works with CONFIG_IMA_ARCH_POLICY=y. We didn't enable it on SLE/openSUSE. Which means that the SIG_FORCE should not be enabled when secure boot on SLE15-SP2 or LEAP 15.2.

On SLE15-SP2, the integrity lock-down mode be enabled when secure boot enabled. It only enable MODULE_SIG but I didn't see MODULE_SIG_FORCE.

I will use qemu-OVMF to look at the behavior again.
Comment 58 Joey Lee 2020-07-09 15:41:29 UTC
(In reply to Joey Lee from comment #57)
[...snip]
> 
> The SUSE patch be applied on old SLE kernel. For any new kernel after
> v5.2-rc1, Mimi Zohar's IMA patch puts the same logic to mainline kernel:
> 
> commit 8db5da0b8618df79eceea99672e205d4a2a6309e
> Author: Mimi Zohar <zohar@linux.ibm.com>
> Date:   Sun Jan 27 19:03:45 2019 -0500
> 
>     x86/ima: require signed kernel modules
[...snip]
> 
> But the logic only works with CONFIG_IMA_ARCH_POLICY=y. We didn't enable it
> on SLE/openSUSE. Which means that the SIG_FORCE should not be enabled when
> secure boot on SLE15-SP2 or LEAP 15.2.
> 
> On SLE15-SP2, the integrity lock-down mode be enabled when secure boot
> enabled. It only enable MODULE_SIG but I didn't see MODULE_SIG_FORCE.
> 
> I will use qemu-OVMF to look at the behavior again.

I just used the qemu-OVMF to confirm the behavior of MODULE_SIG_FORCE on SLE15-SP2:

- When secure boot be disabled:
  A unsigned kernel module can be loaded but it will taint kernel.

- When secure boot enabled.
  Unsigned kernel module can NOT be loaded, got permission deny.
  e.g.
    linux-npj3:~/tmp # insmod acer-wmi.ko
    insmod: ERROR: could not insert module acer-wmi.ko: Operation not permitted

     [   73.282012] Lockdown: insmod: unsigned module loading is restricted; see man kernel_lockdown.7

After the lock-down patch set be merged to mainline. The logic of sig_force is more complicated because IMA involved. There have three ways to set the sig_force:

 - CONFIG_MODULE_SIG_FORCE=y
    Static kernel config for always deny unsigned module. SLE/Leap disabled CONFIG_MODULE_SIG_FORCE.

 - CONFIG_IMA_ARCH_POLICY=y + Secure_Boot_ON
   IMA architecture specific policy be set, and the secure boot be enabled. Then  sig_force will be set. SLE/Leap disabled CONFIG_IMA_ARCH_POLICY.

 - When kernel is in Lock-down mode (INTEGRITY or CONFIDENTIALITY mode)
   SLE/Leap will lock-down on INTEGRITY mode when secure boot be enabled because we applied patch and set LOCK_DOWN_IN_EFI_SECURE_BOOT=y.
   When kernel is in lock-down mode, the sig_force will be set.

For disabling sig_force, either we set LOCK_DOWN_IN_EFI_SECURE_BOOT=n in Leap kernel config. Or end user choice to disable secure boot in firmware.
Comment 59 Joey Lee 2020-07-09 15:54:01 UTC
(In reply to Martin Wilck from comment #45)
> While I think the KMP solution is The Right Thing (TM), it is obviously not
> viable short-term. Here's an idea what we can do quickly:
> 
>  - create a new kernel flavor, call it "nolockdown" or whatever, that
> loosens lockdown features enough to load NVidia and other proprietary
> drivers.
>  - sign this flavor with a different key, which is not allowed on SB systems
> by default. People who want to use that key would need to set it up using
> mokutil. that would be a one-time measure, as opposed to having to provide
> keys with every driver rebuild.

Yes, I think this is the key point. User should enroll the nolockdown kernel key by them self because shim will not embeds this "nolockdown kernel key". Microsoft will not sign that shim.

>  - that kernel package could be accompanied by an EULA file explaining why
> it exists and what the security implications are.
> 
> Advantages:
> 
>  * It allows leaving the secure boot setting on in the BIOS (might be
> mandated by another OS on the system, or other policies).
>  * It satisfies the security requirement that enabling it requires an
> explicit action of the user in the UEFI environment ("physical presence" -
> well).
>  * It's far better than adding a "nolockdown" kernel command line parameter
> from a security PoV.
>  * Security-wise, people using this kernel would be as "good" as Leap 15.1
> users, possibly a little better off.
>  * It's less hassle for users than having to create and deploy keys
> themselved, possibly repeatedly.
>  * It should be pretty quick to implement, no re-engineering of NVidia
> drivers needed.
Comment 60 Michal Kubeček 2020-07-09 18:55:25 UTC
(In reply to Joey Lee from comment #59)
> Yes, I think this is the key point. User should enroll the nolockdown kernel
> key by them self because shim will not embeds this "nolockdown kernel key".
> Microsoft will not sign that shim.

That's a relevant point. Just to be sure I understand: we would have exactly
the same problem if we disabled LOCK_DOWN_IN_EFI_SECURE_BOOT in Leap 15.2
kernel-default and kernel-preempt, wouldn't we?

Also, I didn't check the code but would LOCK_DOWN_IN_EFI_SECURE_BOOT affect
kABI?

But even if we could afford it, I'm still not convinced we should because the
way I see it, such change would make secure boot essentially useless.
Comment 61 Martin Wilck 2020-07-09 20:53:12 UTC
(In reply to Joey Lee from comment #59)
> Yes, I think this is the key point. User should enroll the nolockdown kernel
> key by them self because shim will not embeds this "nolockdown kernel key".

That's not a big problem. The situation would be the same as we have today with TW and Leap 15.1. The deployment of the new key via mokutil is pretty streamlined and yet safe.

> Microsoft will not sign that shim.

The shim shipped by openSUSE *is* signed by Microsoft, despite the fact that no openSUSE kernel released in the last few years had the lockdown feature. Or am I getting that wrong?

(In reply to Michal Kubeček from comment #60)
> But even if we could afford it, I'm still not convinced we should because the
> way I see it, such change would make secure boot essentially useless.

You're probably aware that opinions on this subject differ strongly, even among the experts. While I tend to agree in principle, please let's realize that until a few days ago, no Leap 15 kernel was enforcing signed modules. We might all have our secure boot chain subverted years ago, and never noticed. IOW, secure boot has always been "useless" on Leap. openSUSE can only improve in this area.
Comment 62 Martin Wilck 2020-07-09 21:41:46 UTC
FTR, this is how Ubuntu handles it:

https://askubuntu.com/questions/1048135/how-can-i-install-nvidia-drivers-on-ubuntu-18-04-with-secure-boot

Contrary to what I believed so far, Ubuntu does support lockdown, and seems to have devised a method to provide a key ("password") during driver build, which must then be enrolled with mokutil.

This appears to be similar to the "temporary key" method we discussed before. I think we (SUSE) *could* do better, but apparently Ubuntu users are satisfied with what Ubuntu provides, which is arguably much more user friendly then what we currently have.
Comment 63 Ludwig Nussel 2020-07-10 07:02:27 UTC
(In reply to Michal Kubeček from comment #46)
> (In reply to Ludwig Nussel from comment #43)
> > https://media.giphy.com/media/3oEjHMBUxwVJ9iu5JS/giphy.gif
> 
> Could you be more specific?

I opened this bug specifically to verify the behavior wrt the NVidia driver. All we got was opinions but nobody bothering to actually check the behavior in practice before it was too late.
Comment 64 Ludwig Nussel 2020-07-10 07:09:16 UTC
(In reply to Martin Wilck from comment #61)
> [...]
> The shim shipped by openSUSE *is* signed by Microsoft, despite the fact that
> no openSUSE kernel released in the last few years had the lockdown feature.
> Or am I getting that wrong?

Partially. Shim is signed by MS but does not trust the openSUSE key by default. First boot of an openSUSE system requires the user to ack use of the key:
https://openqa.opensuse.org/tests/1328156#step/bootloader_uefi/1

As such the openSUSE key never promised anything. Therefore doesn't make sense to enforce stricter rules based on that key.
Comment 65 Joey Lee 2020-07-10 09:44:28 UTC
(In reply to Michal Kubeček from comment #60)
> (In reply to Joey Lee from comment #59)
> > Yes, I think this is the key point. User should enroll the nolockdown kernel
> > key by them self because shim will not embeds this "nolockdown kernel key".
> > Microsoft will not sign that shim.
> 
> That's a relevant point. Just to be sure I understand: we would have exactly
> the same problem if we disabled LOCK_DOWN_IN_EFI_SECURE_BOOT in Leap 15.2
> kernel-default and kernel-preempt, wouldn't we?
> 

I just checked Leap 15.2 kernel. The behavior is the same with SLE15-SP2. When the LOCK_DOWN_IN_EFI_SECURE_BOOT be disable, unsigned kernel module can be loaded but it taints kernel.

> Also, I didn't check the code but would LOCK_DOWN_IN_EFI_SECURE_BOOT affect
> kABI?
> 

The LOCK_DOWN_IN_EFI_SECURE_BOOT just set kernel to INTEGRITY lock-down mode. It should not change kABI:

#ifdef CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT
        if (efi_enabled(EFI_SECURE_BOOT)) 
                security_lock_kernel_down("EFI Secure Boot mode", LOCKDOWN_INTEGRITY_MAX);
#endif  

I will push kernel to our build service to confirm.

> But even if we could afford it, I'm still not convinced we should because the
> way I see it, such change would make secure boot essentially useless.

I understood. But... openSUSE user want to use NV driver. 

As Martin's suggestion, we can maintain a unlockdown kernel flavor for openSUSE. If end user want to use unsigned module but he doesn't want to disable secure boot, then he can choice to enroll the unlockdown kernel key to MOK for using unlockdown kernel.
Comment 66 Michal Kubeček 2020-07-10 10:10:37 UTC
(In reply to Joey Lee from comment #65)
> (In reply to Michal Kubeček from comment #60)
> > That's a relevant point. Just to be sure I understand: we would have exactly
> > the same problem if we disabled LOCK_DOWN_IN_EFI_SECURE_BOOT in Leap 15.2
> > kernel-default and kernel-preempt, wouldn't we?
> 
> I just checked Leap 15.2 kernel. The behavior is the same with SLE15-SP2.
> When the LOCK_DOWN_IN_EFI_SECURE_BOOT be disable, unsigned kernel module can
> be loaded but it taints kernel.

By "the same problem" I rather meant the problem with Microsoft signing the
shim. But I guess comment 64 answers that concern.

> > But even if we could afford it, I'm still not convinced we should because
> > the way I see it, such change would make secure boot essentially useless.
> 
> I understood. But... openSUSE user want to use NV driver. 

Some openSUSE users do (and none of them bothered to test a pre-release
snapshot in the 7 months between lockdown merge and GMC and report problems).
I'm rather reluctant to turn secure boot to a Potemkin Village for everyone
just to make life of those users as easy as possible. That's why I would
prefer a solution not requiring us to disable the lockdown by default.

> As Martin's suggestion, we can maintain a unlockdown kernel flavor for
> openSUSE. If end user want to use unsigned module but he doesn't want to
> disable secure boot, then he can choice to enroll the unlockdown kernel key
> to MOK for using unlockdown kernel.

A special "unlocked" flavor is not perfect but it still sounds better than
disabling LOCK_DOWN_IN_EFI_SECURE_BOOT in standard -default / -preempt kernel
packages. Let's just hope we won't have to do two of them.
Comment 67 Martin Wilck 2020-07-10 13:30:58 UTC
(In reply to Ludwig Nussel from comment #64)

> First boot of an openSUSE system requires the user to ack use of
> the key:
> https://openqa.opensuse.org/tests/1328156#step/bootloader_uefi/1

Sure, and that's how it would be with the non-locked-down kernel in the future, too.

> As such the openSUSE key never promised anything. Therefore doesn't make
> sense to enforce stricter rules based on that key.

If you continue that line of thought, Microsoft should never have signed the openSUSE shim (and not any other Linux shims with mokutil support), because shim can be (and actually has been on thousands of systems) configured to trust a key that "never promised anything", which translates to "is useless" for the purpose of SB. If this stuff was taken as seriously as we once feared, the openSUSE key would be in the UEFI dbx (blackist) by now.

But the frequently expressed fear that MS might revoke Linux distribution's keys because of lack of compliance seems to be FUD anyway (https://lwn.net/Articles /751123/).
Comment 68 Martin Wilck 2020-07-10 13:32:28 UTC
(In reply to Michal Kubeček from comment #66)

> A special "unlocked" flavor is not perfect but it still sounds better than
> disabling LOCK_DOWN_IN_EFI_SECURE_BOOT in standard -default / -preempt kernel
> packages. Let's just hope we won't have to do two of them.

As NVidia matters most for desktop installations, perhaps we should base the unlocked flavor on -preempt?
Comment 71 Stefan Dirsch 2020-07-10 14:00:01 UTC
Well, I'm not sure whether it's the best idea to introduce another kernel flavor - just for that. And most likely temporary just for Leap 15.2. How to get rid of it again later?Provides/Obsoletes? But that's just from our maintenancs view ...

More importantly. What would be the benefit for the customer? He/she would still run into the same issue, that the desktop no longer starts after installing the nvidia driver (having performed this with -default kernel and -default nvidia KMP). Then one needs to figure out (somehow on another system with a brower) that one needs to switch to a different kernel flavor,  and trying to do this installation on the Linux console. Many already will have failed completely at this point due to our wonderful ncurses YaST frontend. Some may still manage that, might be able to reboot this new kernel flavor, start the desktop with nouveau or fbdev driver, unselect the -default NVIDIA KMP flavor and select the other NVIDIA KMP flavor in graphical YaST, which then hopefully will work after another reboot.

I would prefer having the lockdown feature changed in a way, that unsigned modules can be loaded again. *And* implement things in a proper way
for the next Leap release, i.e. open feature requests to add infrastructure to our system, which makes it possible for developers and users to sign 
self-built kernel modules easily and enroll the required MOK keys or whatever it is called correctly. We may need changes even for YaST for this, definitely base system it seems.

And the first thing we should provide to our users, who are in big trouble now, is a HOWTO which describes how to sign their kernel modules and add the MOK stuff. Any volunteers? And yes, I would be worst choice doing this. I'm absolutely clueless what secureboot concerns, so I would need to spend days for doing this and half of it would be either wrong or so insecure, so that the security team would need to kill me. ;-)
Comment 73 Gary Ching-Pang Lin 2020-07-13 07:58:01 UTC
While branching a nolockdown kernel may work, I wonder how to configure the key signing. Currently all packages under the same project share the same signing key, and if we add a nolockdown flavor to Leap:15.2 or Leap:15.3, then build service has to sign it with a separate key. This is probably not working with the current key setup. A possible solution is to build the nolockdown kernel in a separate project. It could work but add the maintenance effort.
Comment 74 Stefan Dirsch 2020-07-13 10:04:49 UTC
(In reply to Takashi Iwai from comment #8)
> The problem isn't too serious on TW because the TW kernel (i.e. the upstream
> kernel) still has no strict lockdown.  SLE / Leap kernel has a stricter
> lockdown, so it can be an actual problem.  It might be a problem on TW as
> well once when the upstream accepts the more lockdown.
> 
> IOW, it's not only about CONFIG_MODULE_SIG.  Rather the key point is whether
> the kernel has a lockdown feature for the unsigned module or not.

So I tried to use a TW kernel in order to verify, if it's the kernel lockdown setting of Leap 15.2 in contrast to the its setting on TW. Result is that the kernel cannot be loaded at all with secure boot on. Is this the expected behaviour of TW, that we don't support secure boot at al with TW? I was using the current kernel of Devel:Kernel:master project in our internal buildservice. I expect the same issue with the kernel built in a TW project.
I doubt that we let sign all of our TW kernels once or twice a week with each TW release, right?

The error message when trying to load the kernel on a secure boot system is:

Loading Linux 5.8.0-rc4-2.g006adcb-default ...
error: bad shim signature
Loading initial ramdisk ...
error: you need to load the kernel first.

Press any key to continue...
Comment 75 Martin Wilck 2020-07-13 10:13:47 UTC
(In reply to Stefan Dirsch from comment #74)
> Is this the
> expected behaviour of TW, that we don't support secure boot at al with TW?

I thought it worked as Ludwig described in comment 64. At installation time, the %post script runs "mokutil --import" for the kernel's key. At the following reboot, the UEFI MOK manager application should prompt you whether you want to add the key.

Is your system missing mokutil, maybe?
Comment 76 Stefan Dirsch 2020-07-13 10:44:03 UTC
(In reply to Martin Wilck from comment #75)
> I thought it worked as Ludwig described in comment 64. At installation time,
> the %post script runs "mokutil --import" for the kernel's key. At the
> following reboot, the UEFI MOK manager application should prompt you whether
> you want to add the key.
> 
> Is your system missing mokutil, maybe?

Ah. You're right I was asked once suddently after reboot to enter MOK management. There I saw the options (currently reproducing this):

Continue
Enroll MOK
Enroll Key from Disk
Enroll Hash from Disk

First time I wasn't sure what to chose, so went on with Continue. Now I'm trying with "Enroll MOK". But I get asked for a password, which
I don't know of course ... then unfortunately the machine turned off suddenly. After turning it on I see

Continue
*Reset* MOK
Enroll Key from Disk
Enroll Hash from Disk

Now I selected "Reset MOK". Seems this was wrong. machine reoboots and longer asks questions. ;-)
Comment 77 Stefan Dirsch 2020-07-13 11:01:25 UTC
Ok. Finally managed to enroll the MOK. You need to define the password yourself. LOL. No explanation, nothing at this dialogue. And indeed kernel can be loaded in secureboot mode and the unsigned nvdiia kernel module can be loaded and works.

# dmesg
[...]
[    8.061921] nvidia: loading out-of-tree module taints kernel.
[    8.061929] nvidia: module license 'NVIDIA' taints kernel.
[    8.061930] Disabling lock debugging due to kernel taint
[    8.139965] nvidia: module verification failed: signature and/or required key  missing - tainting kernel
[...]

So this is how we expected/hoped to behave our Leap 15.2 kernel, if I understood this correctly. So that would be one possible workaround for
our affected users to switch to TW kernel and nvidia TW repository.
Comment 78 Martin Wilck 2020-07-13 11:12:38 UTC
%post runs "mokutil --import --root-pw" which should use the root password.
From mokutil(1):

      -P, --root-pw
              Use the root password hash from /etc/shadow

Side note: Aan attacker who has gained root could also change the root password. But he'd have a hard time entering it at the UEFI prompt unless he also gained control over the BMC.
Comment 79 Stefan Dirsch 2020-07-13 11:22:14 UTC
LOL. Indeed I tried the root password - pure coincidently. I could have tried  any other and would have given up immediately, since no explanation was given which one to use.
Comment 80 Martin Wilck 2020-07-13 14:19:07 UTC
(In reply to Stefan Dirsch from comment #79)
> LOL. Indeed I tried the root password - pure coincidently. I could have
> tried  any other and would have given up immediately, since no explanation
> was given which one to use.

There's no doubt that this UI needs improvement.
Comment 81 Stefan Dirsch 2020-07-13 14:29:00 UTC
Hmm. I even don't know, where this UI comes from. Is this from us or some UEFI magic from the hardware vendor itself?
Comment 82 Martin Wilck 2020-07-13 14:45:20 UTC
/usr/share/efi/x86_64/MokManager.efi

It's part of the "shim" package, which we take from upstream (originally Red Hat), with a few minor patches from us.
Comment 83 Stefan Dirsch 2020-07-13 15:13:09 UTC
Indeed an UEFI program in our shim. Who knows. That might need to be re-signed by MS for any change needed ...
Comment 84 Martin Wilck 2020-07-13 15:46:01 UTC
(In reply to Stefan Dirsch from comment #83)
> Indeed an UEFI program in our shim. Who knows. That might need to be
> re-signed by MS for any change needed ...

No, that applies to shim.efi only, you can see that in the spec file. I think this is simply area that hasn't received lots of developer attention.
Comment 100 Stefan Dirsch 2020-07-16 21:27:27 UTC
Secureboot support is now enabled in our nvidia driver packages, which should be available soon via NVIDIA's repository.

I would like to thank Takashi, Ludwig, Martin W. for proposals, feedback and testing! It made things a loteasier for me!
Comment 102 Reinhold Patzer 2020-08-08 13:17:10 UTC
After some searching, I found the page https://en.opensuse.org/SDB:NVIDIA_drivers#Secureboot and, below the blue image, the text

In case you miss the timeout for certificate enrollment after first reboot, you can easily import again the certificate by running the following command:

# mokutil --import /var/lib/nvidia-pubkeys/MOK-nvidia-gfxG0<X>-<driver_version>-<kernel_flavor>.der --root-pw

Then reoboot the machine and enroll the certificate as described before. 

My problem is: the directory /var/lib/nvidia-pubkeys doesn't exist on my system.
I deleted the Nvidia drivers and installed them again, but the directory still
isn't there.

What can I do?

(After upgrading from 15.1 to 15.2)
Comment 103 Takashi Iwai 2020-08-10 12:01:25 UTC
(In reply to Reinhold Patzer from comment #102)
> My problem is: the directory /var/lib/nvidia-pubkeys doesn't exist on my
> system.
> I deleted the Nvidia drivers and installed them again, but the directory
> still
> isn't there.

Did you enable the secure boot already at *installing* the Nvidia package?

The recent support of secure boot in Nvidia package is enabled only if the system is already in secure boot mode at installing the package and running its post-install script.  Then the one-time cert above will be generated.

So, try to re-install the Nvidia package while you already enable secure boot on BIOS.
Comment 104 Reinhold Patzer 2020-08-11 21:49:39 UTC
Thank you, Takashi Iwai, for replying soon.

Unfortunately, I still can't solve the driver signing
problem.

I ask myself: Why must the kernel check certificates if
secureboot isn't enabled?

Here is what I've done so far with some
system info that might be helpful

Mainboard: MSI X399 with Ryzen Threadripper 1950 X
BIOS: AMI (X399 SLI PLUS (MS-7B09) VA.6 BIOS Release)

Graphics card: MSI GTX 1050 Ti

BIOS Settings:
Security: No TPM Module present
BIOS type: UEFI
No specific option to enable secureboot was found

I looked at the manual again and found the following:
 > Secure Boot
Sets the Windows secure boot to prevent the unauthorized accessing.
Press Enter to enter the sub-menu. This sub-menu will appear when
Windows 10 WHQL Support is enabled.

But I intentionally don't enable WHQL Support, because if it is
enabled, boot display is disabled. With "disabled", I mean the
screen is completely black.
I see neither BIOS boot, nor BIOS setup nor opensuse boot menu:
it boots right into the first opensuse boot manager entry,
without any chance to intervene.

BIOS Boot Menu:
2 lines for opensuse:
opensuse (some more text)
opensuse-secureboot (some more text)
more lines for Ubuntu and Windows 10

I did choose the opensuse-secureboot to boot

Install-Log for installing NVIDIA-Drivers (after deleting them):
>>>>>>>>>
Downloading nvidia-gfxG05-kmp-default (download size 11,39 MiB)
Downloading nvidia-glG05 (download size 26,31 MiB)
Downloading nvidia-computeG05 (download size 18,47 MiB)
Downloading x11-video-nvidiaG05 (download size 76,84 MiB)
Installing nvidia-gfxG05-kmp-default-450.57_k5.3.18_lp152.19-lp152.38.1.x86_64.rpm (installed size 62,49 MiB)
Installing nvidia-glG05-450.57-lp152.38.1.x86_64.rpm (installed size 126,27 MiB)
Installing nvidia-computeG05-450.57-lp152.38.1.x86_64.rpm (installed size 120,96 MiB)
Installing x11-video-nvidiaG05-450.57-lp152.38.1.x86_64.rpm (installed size 265,56 MiB)
<<<<<<<<<
some window with a message .....%post....... showed up for some time

still, no /var/lib/nvidia-pubkeys directory exists
Comment 105 Takashi Iwai 2020-08-12 06:49:30 UTC
Before installing Nvidia package, check whether you're certainly in Secure Boot mode via mokutil (run as root):
  # mokutil --sb-state

If it shows enabled, try installing nvidia packages again.
Comment 106 Tripple Moon 2020-08-12 11:31:31 UTC
I recently switched (still trying) to openSUSE, see https://forums.opensuse.org/showthread.php/542653-Fresh-install-on-ASUS-X99-PRO-USB3-1-Motherboard

And i am installing with SecureBoot *enabled* for both Leap 15.2 and Tumbleweed.
I am also unable to locate '/var/lib/nvidia-pubkeys'.
Furthermore even while using Kubuntu i never got the MokManager screens, in that distro version i had to manually add the kernel-module signing key's certificate to the MokList using KeyTool from efitools after having found and copied the cert to a place accessible from the tool. (eg: the ESP)

In my case, and most likely most users, it is not just a problem of the nvidia drivers but is a common problem for *any* proprietary kernel driver the user needs for it's Hardware.
Fe. i need both the nvidia and broadcom drivers as mentioned in that forum thread.

I understand the difficult choice of using SB or not irt kernel-modules, but it is *needed* for proper hardware functionality when you want SB enabled.

IMHO the way *ubuntu does it, while working and easy to use, is insecure in practice if you want strict compliance with the SB specs.
Because it drops a key file on the machine that can be accessed by fraudulent code.

I would suggest an enhanced mechanism to physically separate the kernel-module signing key from the running machine in a distribution-agnostic thus general enough way.
May i suggest to put this key in /KMSK (Short for Kernel Module Signing Keys) which needs to be manually mounted by the physical-user at moment that it is actually needed, and auto-unmounted afterwards with a small but enough delay to allow multiple module signing.
That mount point can then be mounted from an USB-Stick, NFS, etc which is a choice made by that physical-user and thus in most cases an external medium.
I say in most cases, because one could also use a shadow-mount to point it to a local directory which is on the same machine (encrypted or not) and can be used for VM testing etc...
It will also enable people to use their own keys that are trusted by their hardware.
This key can be automatically created on installation/request if the user has none yet.

And final note:
May i also suggest to use this layout (https://forums.opensuse.org/showthread.php/542653-Fresh-install-on-ASUS-X99-PRO-USB3-1-Motherboard?p=2954479#post2954479) for the shim install?
It will ease testing of different versions of openSUSE (any distro in fact) in the long run without any conflicts wrt UEFI booting.
We should all, IMHO, drop grub and move on to loaders like Systemd-boot and the like which are meant for UEFI booting and easier to configure...
Comment 107 Tripple Moon 2020-08-12 11:42:33 UTC
Oh PS:
Why isn't the dkms package installed by default when installing openSUSE?
I would say it is required to be able to install any kernel-modules/drivers that are compiled on the machine at their install time.
No matter if the user is in UEFI-SB mode or not.
(You would also need the sbsigntools package to actually sign them after a fresh build)
Comment 108 Tripple Moon 2020-08-12 11:48:20 UTC
PPS:
I was wondering what this prompt was that i only saw *one* time: https://openqa.opensuse.org/tests/1328156#step/bootloader_uefi/1
Is there any way to revoke this choice, or is it only used by the current opensuse-shim?
I could not find any spot this choice was stored in...
Comment 109 Takashi Iwai 2020-08-12 11:54:58 UTC
Note that the Tumbleweed Nvidia KMP doesn't sign modules because TW kernel has no strict lock down against unsigned modules (it follows the current upstream state).  The whole one-time cert is applied only to Leap 15.2 KMP.

Did you really install the latest Leap 15.2 KMP on the system that was already Secure Boot enabled?  Check mokutils output, and try it again with the very latest Nviidia KMP.

If you try again and still fail, please give the detailed log.  Otherwise it's hard to analyze.
Comment 110 Martin Wilck 2020-08-12 14:11:54 UTC
(In reply to Reinhold Patzer from comment #104)

> I ask myself: Why must the kernel check certificates if
> secureboot isn't enabled?

Kernel module signature checking is an independent feature that goes along well with secure boot. That doesn't mean it is, or should be, tied to SB.
Various circumstances can cause the kernel to treat missing or bad module signatures as fatal errors; SB is one of them, because it enables "integrity" lockdown mode. Check the contents of /sys/kernel/security/lockdown to see if lockdown is enabled on your system.

However, I don't see any evidence in your posts on this bug that the issue you're seeing is related to signature checking. 

> [ ... BIOS setup options, Windows WHQL ... ]

If you find your BIOS setup options illogical, misleading, and too Windows-focused, you're not alone. Please talk to your HW vendor.

> I see neither BIOS boot, nor BIOS setup nor opensuse boot menu:
> it boots right into the first opensuse boot manager entry,
> without any chance to intervene.

That's normal behavior. The EFI boot manager has a default entry, which is immediately booted when set. You have to hit a key (usually F12) during boot to enter the BIOS boot menu.

> I did choose the opensuse-secureboot to boot

To be clear: that doesn't mean this option enables secure boot. It just takes the necessary steps for booting _when secure boot is enabled in the BIOS_. You can only enable or disable secure boot in the BIOS.

> still, no /var/lib/nvidia-pubkeys directory exists

I don't understand what you need it for. You are not using secure boot.
Comment 111 Martin Wilck 2020-08-12 14:42:54 UTC
(In reply to Tripple Moon from comment #106)

> In my case, and most likely most users, it is not just a problem of the
> nvidia drivers but is a common problem for *any* proprietary kernel driver
> the user needs for it's Hardware.
> Fe. i need both the nvidia and broadcom drivers as mentioned in that forum
> thread.

True, NVidia is just an example, albeit by far the most demanded.
Steffen has done a great job packagaging the NVidia driver with all the necessary magic in place to make this work. Someone (you?) could use that as a template to create a driver package for the Broadcom driver.

> IMHO the way *ubuntu does it, while working and easy to use, is insecure in
> practice if you want strict compliance with the SB specs.
> Because it drops a key file on the machine that can be accessed by
> fraudulent code.

It has nothing to do with the specs, it's plain insecure. However I gather that it's at least protected by a password. So it's basically up to the user, protecting the key with a strong pass phrase would be sufficient for most environments.

> I would suggest an enhanced mechanism to physically separate the
> kernel-module signing key from the running machine in a
> distribution-agnostic thus general enough way.

If such a mechanism existed, distros would certainly be interested in adopting it. If you scroll up, you may see that we have been discussing it already (comment 17 ff.). It requires considerable effort, though, and has complex legal implications.

> May i suggest to put this key in /KMSK (Short for Kernel Module Signing
> Keys) 
> ...
> It will also enable people to use their own keys that are trusted by their
> hardware.

That's one idea, and it's not totally new. Similar ideas are discussed once in a while e.g. for storing keys for encrypted storage. IMO it's not safer than using a strong passphrase. If you store the keys on the medium with empty pass phrase, it's actually less secure. Other people prefer other means such as smart cards, the TPM, you name it. It's really hard to make everyone happy.

> May i also suggest to use this layout ... for the shim install?

It won't be heared. This bug is about secure boot and NVidia drivers. Please stay on topic.

(In reply to Tripple Moon from comment #107)
> Why isn't the dkms package installed by default when installing openSUSE?

Because it's not required for running openSUSE. We try to keep the default installation lean, and not everyone requires 3rd-party drivers. That said, KMPs are way superior to anything built with DKMS.

(In reply to Tripple Moon from comment #108)
> Is there any way to revoke this choice, or is it only used by the current
> opensuse-shim?

Yes. "mokutil --list-enrolled" shows currently enrolled certificates in the MoK. "mokutil --delete" will create a MoK request to delete this key. You have to reboot and enter mokmanager to confirm.
Comment 112 Tripple Moon 2020-08-13 06:52:34 UTC
(In reply to Takashi Iwai from comment #109)
> Note that the Tumbleweed Nvidia KMP doesn't sign modules because TW kernel
> has no strict lock down against unsigned modules (it follows the current
> upstream state).  The whole one-time cert is applied only to Leap 15.2 KMP.
> 
> Did you really install the latest Leap 15.2 KMP on the system that was
> already Secure Boot enabled?  Check mokutils output, and try it again with
> the very latest Nviidia KMP.
> 
> If you try again and still fail, please give the detailed log.  Otherwise
> it's hard to analyze.

To keep this thread on topic please see: https://bugzilla.opensuse.org/show_bug.cgi?id=1175210
Comment 113 Tripple Moon 2020-08-13 07:06:33 UTC
(In reply to Martin Wilck from comment #111)
> (In reply to Tripple Moon from comment #108)
> > Is there any way to revoke this choice, or is it only used by the current
> > opensuse-shim?
> 
> Yes. "mokutil --list-enrolled" shows currently enrolled certificates in the
> MoK. "mokutil --delete" will create a MoK request to delete this key. You
> have to reboot and enter mokmanager to confirm.

If it is only enrolled in the MokList of the current boot then there is no problem at all.
But when i boot into KeyTool from my own boot menu i don't see any key from openSUSE in the MokList, so where is this choice stored?

How does one enter the MokManager at boot time using the openSUSE shim?
Comment 114 Gary Ching-Pang Lin 2020-08-13 07:46:29 UTC
(In reply to Tripple Moon from comment #113)
> (In reply to Martin Wilck from comment #111)
> > (In reply to Tripple Moon from comment #108)
> > > Is there any way to revoke this choice, or is it only used by the current
> > > opensuse-shim?
> > 
> > Yes. "mokutil --list-enrolled" shows currently enrolled certificates in the
> > MoK. "mokutil --delete" will create a MoK request to delete this key. You
> > have to reboot and enter mokmanager to confirm.
> 
> If it is only enrolled in the MokList of the current boot then there is no
> problem at all.
> But when i boot into KeyTool from my own boot menu i don't see any key from
> openSUSE in the MokList, so where is this choice stored?
> 
> How does one enter the MokManager at boot time using the openSUSE shim?

"mokutil --import" will create an EFI variable called MokNew. When shim detects the existence of MokNew, it loads MokManager for the further process.
Comment 115 Tripple Moon 2020-08-13 08:23:34 UTC
(In reply to Gary Ching-Pang Lin from comment #114)
> (In reply to Tripple Moon from comment #113)
> > (In reply to Martin Wilck from comment #111)
> > > (In reply to Tripple Moon from comment #108)
> > > > Is there any way to revoke this choice, or is it only used by the current
> > > > opensuse-shim?
> > > 
> > > Yes. "mokutil --list-enrolled" shows currently enrolled certificates in the
> > > MoK. "mokutil --delete" will create a MoK request to delete this key. You
> > > have to reboot and enter mokmanager to confirm.
> > 
> > If it is only enrolled in the MokList of the current boot then there is no
> > problem at all.
> > But when i boot into KeyTool from my own boot menu i don't see any key from
> > openSUSE in the MokList, so where is this choice stored?
> > 
> > How does one enter the MokManager at boot time using the openSUSE shim?
> 
> "mokutil --import" will create an EFI variable called MokNew. When shim
> detects the existence of MokNew, it loads MokManager for the further process.

I understand that method all too well, but the problem is that on my machine "mokutil --import" does not work properly and gives an error.
At least that is what happened while i was using Kubuntu and i had to manually add the certificate to the MokList using KeyTool.efi from the efitools package/repo (I compiled on my own machine from sources)

But you still have not answered the last 2 questions in that reply.
1. "so where is this choice stored?" Meaning the choice to accept the opensuse certificate.
2. "How does one enter the MokManager at boot time using the openSUSE shim?"
Comment 116 Tripple Moon 2020-08-13 08:33:18 UTC
To be absolutely clear:
I am *NOT* talking about where the certificate is stored (because thats obviously in the MokList), i am asking where the *one time choice* to accept the OpenSUSE certificate is stored.
Because i only got that one time when i started to test openSUSE, and never got it on repeated re-installs of both Leap and Tumbleweed...
Comment 117 Marcus Meissner 2020-08-13 08:41:19 UTC
This choice is done once and is stored in UEFI BIOS variables.
Comment 118 Tripple Moon 2020-08-13 09:10:12 UTC
(In reply to Marcus Meissner from comment #117)
> This choice is done once and is stored in UEFI BIOS variables.

This is like trying to pull needles out of a haystack...
*which* UEFI variable because I wasn't able to find it...

Anyway now while working under a temporary install of Tumbleweed i see:
> find /sys/firmware/efi -iname \*suse\*
/sys/firmware/efi/efivars/use_openSUSE_cert-605dab50-e046-4300-abb6-3dd810dd8b23
/sys/firmware/efi/vars/use_openSUSE_cert-605dab50-e046-4300-abb6-3dd810dd8b23
> xxd /sys/firmware/efi/efivars/use_openSUSE_cert-605dab50-e046-4300-abb6-3dd810dd8b23
00000000: 0600 0000 01                             .....

Thanks...
Comment 119 Gary Ching-Pang Lin 2020-08-13 09:28:05 UTC
(In reply to Tripple Moon from comment #115)
> (In reply to Gary Ching-Pang Lin from comment #114)
> > (In reply to Tripple Moon from comment #113)
> > > (In reply to Martin Wilck from comment #111)
> > > > (In reply to Tripple Moon from comment #108)
> > > > > Is there any way to revoke this choice, or is it only used by the current
> > > > > opensuse-shim?
> > > > 
> > > > Yes. "mokutil --list-enrolled" shows currently enrolled certificates in the
> > > > MoK. "mokutil --delete" will create a MoK request to delete this key. You
> > > > have to reboot and enter mokmanager to confirm.
> > > 
> > > If it is only enrolled in the MokList of the current boot then there is no
> > > problem at all.
> > > But when i boot into KeyTool from my own boot menu i don't see any key from
> > > openSUSE in the MokList, so where is this choice stored?
> > > 
> > > How does one enter the MokManager at boot time using the openSUSE shim?
> > 
> > "mokutil --import" will create an EFI variable called MokNew. When shim
> > detects the existence of MokNew, it loads MokManager for the further process.
> 
> I understand that method all too well, but the problem is that on my machine
> "mokutil --import" does not work properly and gives an error.
Is there any error message?

> At least that is what happened while i was using Kubuntu and i had to
> manually add the certificate to the MokList using KeyTool.efi from the
> efitools package/repo (I compiled on my own machine from sources)
> 
> But you still have not answered the last 2 questions in that reply.
> 1. "so where is this choice stored?" Meaning the choice to accept the
> opensuse certificate.
It means the certificate built in shim. When you choose "yes", shim stores 1 to an EFI variable, use_openSUSE_cert, and won't bother you again. It can be removed with "mokutil --revoke-cert".

> 2. "How does one enter the MokManager at boot time using the openSUSE shim?"
By design, shim launches MokManager only when there is a request for it. If you really want to launch MokManager directly, disable Secure Boot and load MokManager.efi directly from the firmware could be choice. Or, you can manually create a boot entry for MokManager. E.g:

 # efibootmgr -c -d /dev/sda -p 1 -l "\EFI\opensuse\MokManager.efi" -L "MokManager"

Note: Here I assumes that ESP is sda1.
Comment 120 Tripple Moon 2020-08-13 09:35:09 UTC
Seeing:
> cat /sys/firmware/efi/vars/use_openSUSE_cert-605dab50-e046-4300-abb6-3dd810dd8b23/attributes 
> > EFI_VARIABLE_BOOTSERVICE_ACCESS
> > EFI_VARIABLE_RUNTIME_ACCESS
> l /sys/firmware/efi/efivars/use_openSUSE_cert-605dab50-e046-4300-abb6-3dd810dd8b23
> > -rw-r--r-- 1 root root 5 Aug 13 08:45 /sys/firmware/efi/efivars/use_openSUSE_cert-605dab50-e046-4300-abb6-3dd810dd8b23

Am i correct that the following will revoke that choice, so it will be asked again after booting with an openSUSE shim?
 > echo 0 >/sys/firmware/efi/efivars/use_openSUSE_cert-605dab50-e046-4300-abb6-3dd810dd8b23
Or is there more involved to it?
Perhaps one needs to completely remove the variable from the UEFI, in which case how would a user do that?

Because accepting something like this should also have a way to revoke if one does not wish to continue using openSUSE...
(Which IMHO would be a bad choice but anyway you guys get what i mean)
Comment 121 Tripple Moon 2020-08-13 09:41:06 UTC
@Gary Ching-Pang Lin, please see comment #116

@ 2. Answer:
Ok so it is impossible to invoke the MokManager using the shim, that's what i asked for.
IIRC the base shim should have a way to invoke the MokManager it uses when you press a key during boot, but according to your answer that functionality would have been removed from the openSUSE shim.

No big deal because as you showed we can create our own boot entry using efibootmgr ;)
Thanks...
Comment 122 Tripple Moon 2020-08-13 09:43:57 UTC
(In reply to Gary Ching-Pang Lin from comment #119)
> (In reply to Tripple Moon from comment #115)
> > I understand that method all too well, but the problem is that on my machine
> > "mokutil --import" does not work properly and gives an error.
> Is there any error message?

I would be happy to try if i had a certificate to try with xD
Comment 123 Gary Ching-Pang Lin 2020-08-13 09:55:19 UTC
(In reply to Tripple Moon from comment #120)
> Seeing:
> > cat /sys/firmware/efi/vars/use_openSUSE_cert-605dab50-e046-4300-abb6-3dd810dd8b23/attributes 
> > > EFI_VARIABLE_BOOTSERVICE_ACCESS
> > > EFI_VARIABLE_RUNTIME_ACCESS
> > l /sys/firmware/efi/efivars/use_openSUSE_cert-605dab50-e046-4300-abb6-3dd810dd8b23
> > > -rw-r--r-- 1 root root 5 Aug 13 08:45 /sys/firmware/efi/efivars/use_openSUSE_cert-605dab50-e046-4300-abb6-3dd810dd8b23
> 
> Am i correct that the following will revoke that choice, so it will be asked
> again after booting with an openSUSE shim?
>  > echo 0
> >/sys/firmware/efi/efivars/use_openSUSE_cert-605dab50-e046-4300-abb6-
> 3dd810dd8b23
It won't work.

> Or is there more involved to it?
> Perhaps one needs to completely remove the variable from the UEFI, in which
> case how would a user do that?
> 
use_openSUSE_cert is just a mirror of openSUSE_Verify, a BootService variable.
Please use "mokutil --revoke-cert".

> Because accepting something like this should also have a way to revoke if
> one does not wish to continue using openSUSE...
> (Which IMHO would be a bad choice but anyway you guys get what i mean)
Comment 124 li Ray 2020-08-13 10:02:23 UTC
(In reply to Reinhold Patzer from comment #104)
> Thank you, Takashi Iwai, for replying soon.
> 
> Unfortunately, I still can't solve the driver signing
> problem.
> 
> I ask myself: Why must the kernel check certificates if
> secureboot isn't enabled?
> 
> Here is what I've done so far with some
> system info that might be helpful
> 
> Mainboard: MSI X399 with Ryzen Threadripper 1950 X
> BIOS: AMI (X399 SLI PLUS (MS-7B09) VA.6 BIOS Release)
> 
> Graphics card: MSI GTX 1050 Ti
> 
> BIOS Settings:
> Security: No TPM Module present
> BIOS type: UEFI
> No specific option to enable secureboot was found
> 
> I looked at the manual again and found the following:
>  > Secure Boot
> Sets the Windows secure boot to prevent the unauthorized accessing.
> Press Enter to enter the sub-menu. This sub-menu will appear when
> Windows 10 WHQL Support is enabled.
> 
> But I intentionally don't enable WHQL Support, because if it is
> enabled, boot display is disabled. With "disabled", I mean the
> screen is completely black.
> I see neither BIOS boot, nor BIOS setup nor opensuse boot menu:
> it boots right into the first opensuse boot manager entry,
> without any chance to intervene.
> 
> BIOS Boot Menu:
> 2 lines for opensuse:
> opensuse (some more text)
> opensuse-secureboot (some more text)
> more lines for Ubuntu and Windows 10
> 
> I did choose the opensuse-secureboot to boot
> 
> Install-Log for installing NVIDIA-Drivers (after deleting them):
> >>>>>>>>>
> Downloading nvidia-gfxG05-kmp-default (download size 11,39 MiB)
> Downloading nvidia-glG05 (download size 26,31 MiB)
> Downloading nvidia-computeG05 (download size 18,47 MiB)
> Downloading x11-video-nvidiaG05 (download size 76,84 MiB)
> Installing
> nvidia-gfxG05-kmp-default-450.57_k5.3.18_lp152.19-lp152.38.1.x86_64.rpm
> (installed size 62,49 MiB)
> Installing nvidia-glG05-450.57-lp152.38.1.x86_64.rpm (installed size 126,27
> MiB)
> Installing nvidia-computeG05-450.57-lp152.38.1.x86_64.rpm (installed size
> 120,96 MiB)
> Installing x11-video-nvidiaG05-450.57-lp152.38.1.x86_64.rpm (installed size
> 265,56 MiB)
> <<<<<<<<<
> some window with a message .....%post....... showed up for some time
> 
> still, no /var/lib/nvidia-pubkeys directory exists

Met the same issue with you, has no /var/lib/nvidia-pubkeys dir.
Mine problem was I added the local repo from cuda rpm which has a driver inside. Then when I installed x11-video-nvidiaG04(yes, mine is 04), it actually installed the driver from local repo which I believe is not customized for Suse Leap 15.2, thus there is no such dir created for it.

So I uninstalled this driver and removed the local repo from Zypper, removed everything related with cuda, did a reboot. 

Then install the package directly from remote NVIDIA repo, then reboot and followed the steps in https://en.opensuse.org/SDB:NVIDIA_drivers#Secureboot
and it works as a charm now.
Comment 125 Tripple Moon 2020-08-13 10:35:10 UTC
(In reply to Gary Ching-Pang Lin from comment #123)
> (In reply to Tripple Moon from comment #120)
> > Or is there more involved to it?
> > Perhaps one needs to completely remove the variable from the UEFI, in which
> > case how would a user do that?
> > 
> use_openSUSE_cert is just a mirror of openSUSE_Verify, a BootService
> variable.
> Please use "mokutil --revoke-cert".
> 
> > Because accepting something like this should also have a way to revoke if
> > one does not wish to continue using openSUSE...
> > (Which IMHO would be a bad choice but anyway you guys get what i mean)

Again, i have no certificate to revoke or remove from the MokList when accessing the MokList outside opensuse.
"mokutil --revoke-cert" would need a certificate as argument to revoke, which in this case would be the one hardcoded inside the shim of opensuse...
Plus that is only about the certificate to trust, *not* the choice to accept it...
Anyway, this discussion has trailed off the topic enough and im dropping it...
If i ever need to remove that choice i will manually delete the UEFI-variable "use_openSUSE_cert" and/or "openSUSE_Verify" using other tools outside of suse...
(In worst case remove the CMOS battery and do a complete reset of the hardware.)
What a mess...
Comment 126 Martin Wilck 2020-08-13 11:05:26 UTC
(In reply to Tripple Moon from comment #125)

> "mokutil --revoke-cert" would need a certificate as argument to revoke,

it doesn't.
Comment 131 Gary Ching-Pang Lin 2020-08-14 02:33:52 UTC
(In reply to Tripple Moon from comment #122)
> (In reply to Gary Ching-Pang Lin from comment #119)
> > (In reply to Tripple Moon from comment #115)
> > > I understand that method all too well, but the problem is that on my machine
> > > "mokutil --import" does not work properly and gives an error.
> > Is there any error message?
> 
> I would be happy to try if i had a certificate to try with xD

You can pick one pem file in /etc/ssl/certs/ and convert it into DER format with openssl:

 $ openssl x509 -in <pem file> -outform DER -out cert.der

Then try mokutil with it:

 # mokutil --import cert.der --root-pw

This just creates the request so the key is not enrolled yet. Just don't enroll the key once you reach MokManager.

Check the request:

 # mokutil --list-new

Remove the request:

 # mokutil --revoke-import
Comment 134 Tripple Moon 2020-08-14 09:52:30 UTC
(In reply to Gary Ching-Pang Lin from comment #131)
> Then try mokutil with it:
> 
>  # mokutil --import cert.der --root-pw
Thanks for the help effort, i might as well try it on this Tumbleweed install im writing from and show results.
I still had a DER encoded certificate that was used in my Kubuntu setup before my switch to suse.
This certificate was *successfully* used to automatically sign kernel modules on that system while i was still running Kubuntu.
It is no longer enrolled on my system, but can be when needed from my backup.
> > mokutil --import MOK.der --root-pw; echo $?
> Failed to enroll new keys
> 255
> > openssl x509 -text -noout -inform der -in MOK.der
> Certificate:
>     Data:
>         Version: 3 (0x2)
>         Serial Number:
>             20:20:07:07:08:09:46:5f:04:2d:ca
>         Signature Algorithm: sha256WithRSAEncryption
>         Issuer: CN = Secure Boot Module Signature key (OEM-MOK), O = TriMoon Inc., OU = Certs
>         Validity
>             Not Before: Jul  7 08:09:46 2020 GMT
>             Not After : Jul  7 08:09:46 2050 GMT
>         Subject: CN = Secure Boot Module Signature key (OEM-MOK), O = TriMoon Inc., OU = Certs
>         Subject Public Key Info:
>             Public Key Algorithm: rsaEncryption
>                 RSA Public-Key: (2048 bit)
>                 Modulus:
>                     XXXXXX
>                 Exponent: 65537 (0x10001)
>         X509v3 extensions:
>             X509v3 Subject Key Identifier: 
>                 7B:43:DC:5C:FF:86:D6:18:4B:AE:7B:25:48:0A:A9:1B:57:84:C6:D9
>             X509v3 Authority Key Identifier: 
>                 keyid:7B:43:DC:5C:FF:86:D6:18:4B:AE:7B:25:48:0A:A9:1B:57:84:C6:D9
> 
>             X509v3 Basic Constraints: critical
>                 CA:FALSE
>             X509v3 Extended Key Usage: 
>                 Code Signing, 1.3.6.1.4.1.2312.16.1.2
>             Netscape Comment: 
>                 OpenSSL Generated Certificate
>     Signature Algorithm: sha256WithRSAEncryption
>          XXXXXX
> > mokutil --list-new
> nothing shown...
Comment 135 Tripple Moon 2020-08-14 10:11:06 UTC
FYI, in kubuntu this command failed also and i had to manually add the certificate to the MokList using KeyTool.efi while outside kubuntu.
Comment 136 Martin Wilck 2020-08-14 10:15:08 UTC
(In reply to Tripple Moon from comment #134)

> > > mokutil --import MOK.der --root-pw; echo $?
> > Failed to enroll new keys
> > 255

Could you run this command under "strace -ttt -f -s 128" please, and provide the
strace output?
Comment 137 Tripple Moon 2020-08-14 10:21:43 UTC
(In reply to Martin Wilck from comment #111)
> (In reply to Tripple Moon from comment #106)
> > May i suggest to put this key in /KMSK (Short for Kernel Module Signing
> > Keys) 
> > ...
> > It will also enable people to use their own keys that are trusted by their
> > hardware.
> 
> That's one idea, and it's not totally new. Similar ideas are discussed once
> in a while e.g. for storing keys for encrypted storage. IMO it's not safer
> than using a strong passphrase. If you store the keys on the medium with
> empty pass phrase, it's actually less secure. Other people prefer other
> means such as smart cards, the TPM, you name it. It's really hard to make
> everyone happy.
Good ideas never need to be new or unique, in fact im glad others having suggested the same in past without my knowledge ;)
> 
> > May i also suggest to use this layout ... for the shim install?
> 
> It won't be heared. This bug is about secure boot and NVidia drivers. Please
> stay on topic.
Could you please direct me how to create an issue in such a way that it will be noticed for the SHIM in suse?
Because there is no component for SHIM that i could see...
Comment 138 Tripple Moon 2020-08-14 10:23:50 UTC
(In reply to Martin Wilck from comment #136)
> (In reply to Tripple Moon from comment #134)
> 
> > > > mokutil --import MOK.der --root-pw; echo $?
> > > Failed to enroll new keys
> > > 255
> 
> Could you run this command under "strace -ttt -f -s 128" please, and provide
> the
> strace output?
Im in a hurry in RL, so excuse the plain paste

> strace -ttt -f -s 128 mokutil --import MOK.der --root-pw; echo $?
1597400557.575009 execve("/usr/bin/mokutil", ["mokutil", "--import", "MOK.der", "--root-pw"], 0x7fff0c6e9f98 /* 56 vars */) = 0
1597400557.575430 brk(NULL)             = 0x55e95acca000
1597400557.575496 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
1597400557.575582 openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
1597400557.575654 fstat(3, {st_mode=S_IFREG|0644, st_size=124163, ...}) = 0
1597400557.575718 mmap(NULL, 124163, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fe293bd6000
1597400557.575769 close(3)              = 0
1597400557.575819 openat(AT_FDCWD, "/usr/lib64/libcrypto.so.1.1", O_RDONLY|O_CLOEXEC) = 3
1597400557.575870 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0@\10\0\0\0\0\0@\0\0\0\0\0\0\0\360}.\0\0\0\0\0\0\0\0\0@\08\0\t\0@\0\34\0\33\0\1\0\0\0\4\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0x!\10\0\0\0\0\0x!\10\0\0\0\0\0\0\20\0\0\0\0\0\0\1\0\0\0\5\0\0\0"..., 832) = 832
1597400557.575923 fstat(3, {st_mode=S_IFREG|0755, st_size=3048688, ...}) = 0
1597400557.575970 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fe293bd4000
1597400557.576019 mmap(NULL, 3069288, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fe2938e6000
1597400557.576064 mprotect(0x7fe293969000, 2318336, PROT_NONE) = 0
1597400557.576114 mmap(0x7fe293969000, 1720320, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x83000) = 0x7fe293969000
1597400557.576167 mmap(0x7fe293b0d000, 593920, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x227000) = 0x7fe293b0d000
1597400557.576213 mmap(0x7fe293b9f000, 196608, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2b8000) = 0x7fe293b9f000
1597400557.576263 mmap(0x7fe293bcf000, 17768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fe293bcf000
1597400557.576316 close(3)              = 0
1597400557.576370 openat(AT_FDCWD, "/usr/lib64/libefivar.so.1", O_RDONLY|O_CLOEXEC) = 3
1597400557.576424 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240D\0\0\0\0\0\0@\0\0\0\0\0\0\0\300e\2\0\0\0\0\0\0\0\0\0@\08\0\t\0@\0\33\0\32\0\1\0\0\0\4\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\2302\0\0\0\0\0\0\2302\0\0\0\0\0\0\0\20\0\0\0\0\0\0\1\0\0\0\5\0\0\0"..., 832) = 832
1597400557.576478 fstat(3, {st_mode=S_IFREG|0755, st_size=158848, ...}) = 0
1597400557.576527 mmap(NULL, 161720, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fe2938be000
1597400557.576571 mmap(0x7fe2938c2000, 81920, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x4000) = 0x7fe2938c2000
1597400557.576617 mmap(0x7fe2938d6000, 20480, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x18000) = 0x7fe2938d6000
1597400557.576660 mmap(0x7fe2938db000, 45056, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1c000) = 0x7fe2938db000
1597400557.576714 close(3)              = 0
1597400557.576759 openat(AT_FDCWD, "/usr/lib64/libcrypt.so.1", O_RDONLY|O_CLOEXEC) = 3
1597400557.576812 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@ \0\0\0\0\0\0@\0\0\0\0\0\0\0000\21\3\0\0\0\0\0\0\0\0\0@\08\0\t\0@\0\33\0\32\0\1\0\0\0\4\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\310\26\0\0\0\0\0\0\310\26\0\0\0\0\0\0\0\20\0\0\0\0\0\0\1\0\0\0\5\0\0\0"..., 832) = 832
1597400557.576862 fstat(3, {st_mode=S_IFREG|0755, st_size=202736, ...}) = 0
1597400557.576908 mmap(NULL, 238280, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fe293883000
1597400557.576952 mmap(0x7fe293885000, 86016, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7fe293885000
1597400557.576999 mmap(0x7fe29389a000, 106496, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17000) = 0x7fe29389a000
1597400557.577044 mmap(0x7fe2938b4000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x30000) = 0x7fe2938b4000
1597400557.577093 mmap(0x7fe2938b6000, 29384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fe2938b6000
1597400557.577144 close(3)              = 0
1597400557.577192 openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
1597400557.577245 read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0n\2\0\0\0\0\0@\0\0\0\0\0\0\0\10\353\37\0\0\0\0\0\0\0\0\0@\08\0\f\0@\0D\0C\0\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0\240\2\0\0\0\0\0\0\240\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0"..., 832) = 832
1597400557.577294 fstat(3, {st_mode=S_IFREG|0755, st_size=2096136, ...}) = 0
1597400557.577343 mmap(NULL, 1860456, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fe2936bc000
1597400557.577389 mmap(0x7fe2936e1000, 1363968, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x25000) = 0x7fe2936e1000
1597400557.577437 mmap(0x7fe29382e000, 307200, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x172000) = 0x7fe29382e000
1597400557.577481 mmap(0x7fe293879000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1bc000) = 0x7fe293879000
1597400557.577530 mmap(0x7fe29387f000, 13160, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fe29387f000
1597400557.577579 close(3)              = 0
1597400557.577628 openat(AT_FDCWD, "/lib64/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
1597400557.577692 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0000\21\0\0\0\0\0\0@\0\0\0\0\0\0\0\250P\0\0\0\0\0\0\0\0\0\0@\08\0\t\0@\0\36\0\35\0\1\0\0\0\4\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0p\17\0\0\0\0\0\0p\17\0\0\0\0\0\0\0\20\0\0\0\0\0\0\1\0\0\0\5\0\0\0"..., 832) = 832
1597400557.577744 fstat(3, {st_mode=S_IFREG|0755, st_size=22568, ...}) = 0
1597400557.577794 mmap(NULL, 20624, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fe2936b6000
1597400557.577842 mmap(0x7fe2936b7000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0x7fe2936b7000
1597400557.577892 mmap(0x7fe2936b9000, 4096, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7fe2936b9000
1597400557.577939 mmap(0x7fe2936ba000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7fe2936ba000
1597400557.577994 close(3)              = 0
1597400557.578041 openat(AT_FDCWD, "/lib64/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
1597400557.578090 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 |\0\0\0\0\0\0@\0\0\0\0\0\0\0xH\2\0\0\0\0\0\0\0\0\0@\08\0\v\0@\0$\0#\0\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0h\2\0\0\0\0\0\0h\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0"..., 832) = 832
1597400557.578139 fstat(3, {st_mode=S_IFREG|0755, st_size=151928, ...}) = 0
1597400557.578186 mmap(NULL, 135600, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fe293694000
1597400557.578230 mmap(0x7fe29369b000, 65536, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x7000) = 0x7fe29369b000
1597400557.578278 mmap(0x7fe2936ab000, 20480, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17000) = 0x7fe2936ab000
1597400557.578323 mmap(0x7fe2936b0000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b000) = 0x7fe2936b0000
1597400557.578371 mmap(0x7fe2936b2000, 12720, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fe2936b2000
1597400557.578422 close(3)              = 0
1597400557.578474 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fe293692000
1597400557.578530 mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fe29368f000
1597400557.578580 arch_prctl(ARCH_SET_FS, 0x7fe29368f740) = 0
1597400557.578688 mprotect(0x7fe293879000, 12288, PROT_READ) = 0
1597400557.578765 mprotect(0x7fe2936b0000, 4096, PROT_READ) = 0
1597400557.578818 mprotect(0x7fe2936ba000, 4096, PROT_READ) = 0
1597400557.578871 mprotect(0x7fe2938b4000, 4096, PROT_READ) = 0
1597400557.578946 mprotect(0x7fe2938db000, 4096, PROT_READ) = 0
1597400557.579226 mprotect(0x7fe293b9f000, 180224, PROT_READ) = 0
1597400557.579285 mprotect(0x55e959ca1000, 4096, PROT_READ) = 0
1597400557.579334 mprotect(0x7fe293c1f000, 4096, PROT_READ) = 0
1597400557.579381 munmap(0x7fe293bd6000, 124163) = 0
1597400557.579442 set_tid_address(0x7fe29368fa10) = 28574
1597400557.579485 set_robust_list(0x7fe29368fa20, 24) = 0
1597400557.579536 rt_sigaction(SIGRTMIN, {sa_handler=0x7fe29369b690, sa_mask=[], sa_flags=SA_RESTORER|SA_SIGINFO, sa_restorer=0x7fe2936a8260}, NULL, 8) = 0
1597400557.579590 rt_sigaction(SIGRT_1, {sa_handler=0x7fe29369b730, sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART|SA_SIGINFO, sa_restorer=0x7fe2936a8260}, NULL, 8) = 0
1597400557.579645 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
1597400557.579695 prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
1597400557.579775 access("/sys/firmware/efi/efivars/", F_OK) = 0
1597400557.579843 statfs("/sys/firmware/efi/efivars/", {f_type=EFIVARFS_MAGIC, f_bsize=4096, f_blocks=0, f_bfree=0, f_bavail=0, f_files=0, f_ffree=0, f_fsid={val=[0, 0]}, f_namelen=255, f_frsize=4096, f_flags=ST_VALID|ST_NOSUID|ST_NODEV|ST_NOEXEC|ST_RELATIME}) = 0
1597400557.579982 brk(NULL)             = 0x55e95acca000
1597400557.580027 brk(0x55e95aceb000)   = 0x55e95aceb000
1597400557.580081 futex(0x7fe293bd1f48, FUTEX_WAKE_PRIVATE, 2147483647) = 0
1597400557.580133 futex(0x7fe2936bb048, FUTEX_WAKE_PRIVATE, 2147483647) = 0
1597400557.580287 openat(AT_FDCWD, "/usr/lib64/.libcrypto.so.1.1.hmac", O_RDONLY) = -1 ENOENT (No such file or directory)
1597400557.580353 futex(0x7fe293bd1e10, FUTEX_WAKE_PRIVATE, 2147483647) = 0
1597400557.580398 futex(0x7fe293bcedc8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
1597400557.580443 futex(0x7fe293bd1e0c, FUTEX_WAKE_PRIVATE, 2147483647) = 0
1597400557.580487 futex(0x7fe293bd1e08, FUTEX_WAKE_PRIVATE, 2147483647) = 0
1597400557.580531 futex(0x7fe293bd16e0, FUTEX_WAKE_PRIVATE, 2147483647) = 0
1597400557.581336 futex(0x7fe293bd1e04, FUTEX_WAKE_PRIVATE, 2147483647) = 0
1597400557.581416 openat(AT_FDCWD, "/proc/sys/crypto/fips_enabled", O_RDONLY) = -1 ENOENT (No such file or directory)
1597400557.581576 access("/usr/lib64/.libcrypto.so.1.1.hmac", F_OK) = -1 ENOENT (No such file or directory)
1597400557.581652 geteuid()             = 0
1597400557.581734 openat(AT_FDCWD, "/sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c", O_RDONLY) = 3
1597400557.581796 clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
1597400557.581902 read(3, "\6\0\0\0", 4) = 4
1597400557.582079 clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
1597400557.582177 read(3, "\1", 4096)   = 1
1597400557.582319 read(3, "", 4095)     = 0
1597400557.582461 close(3)              = 0
1597400557.582493 stat("MOK.der", {st_mode=S_IFREG|0755, st_size=996, ...}) = 0
1597400557.582529 geteuid()             = 0
1597400557.582559 openat(AT_FDCWD, "/sys/firmware/efi/efivars/MokNew-605dab50-e046-4300-abb6-3dd810dd8b23", O_RDONLY) = 3
1597400557.582594 clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
1597400557.582677 read(3, "", 4)        = 0
1597400557.582778 clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
1597400557.582860 read(3, "", 4096)     = 0
1597400557.582958 close(3)              = 0
1597400557.582987 openat(AT_FDCWD, "MOK.der", O_RDONLY) = 3
1597400557.583019 read(3, "0\202\3\3400\202\2\310\240\3\2\1\2\2\v  \7\7\10\tF_\4-\3120\r\6\t*\206H\206\367\r\1\1\v\5\0000\\1301\6\3U\4\3\f*Secure Boot Module Signature key (OEM-MOK)1\0250\23\6\3U\4\n\f\fTriMoon Inc.1\0160\f\6\3U\4\v"..., 996) = 996
1597400557.583055 futex(0x7fe293bd1d5c, FUTEX_WAKE_PRIVATE, 2147483647) = 0
1597400557.583169 geteuid()             = 0
1597400557.583199 openat(AT_FDCWD, "/sys/firmware/efi/efivars/PK-8be4df61-93ca-11d2-aa0d-00e098032b8c", O_RDONLY) = 4
1597400557.583236 clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
1597400557.583320 read(4, "'\0\0\0", 4) = 4
1597400557.583442 clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
1597400557.583527 read(4, "\241Y\300\245\344\224\247J\207\265\253\25\\+\360rv\3\0\0\0\0\0\0Z\3\0\0\2210\5;\237l\314\4\261\254\342\245\36;\345\3650\202\3F0\202\2.\240\3\2\1\2\2\20SA\340\25\304:\370\250H6\271\245\377i\24\2100\r\6\t*\206H\206\367\r\1\1\v\5\0000-1+0)\6\3U\4\3\23\"ASUSTeK MotherBoard PK Ce"..., 4096) = 886
1597400557.583649 read(4, "", 3210)     = 0
1597400557.583766 close(4)              = 0
1597400557.583797 geteuid()             = 0
1597400557.583826 openat(AT_FDCWD, "/sys/firmware/efi/efivars/KEK-8be4df61-93ca-11d2-aa0d-00e098032b8c", O_RDONLY) = 4
1597400557.583859 clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
1597400557.583942 read(4, "'\0\0\0", 4) = 4
1597400557.584071 clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
1597400557.584152 read(4, "\241Y\300\245\344\224\247J\207\265\253\25\\+\360ry\3\0\0\0\0\0\0]\3\0\0\2210\5;\237l\314\4\261\254\342\245\36;\345\3650\202\3I0\202\0021\240\3\2\1\2\2\0201\36F\305\26\0\241\244@\361\301P\342\27\302q0\r\6\t*\206H\206\367\r\1\1\v\5\0000.1,0*\6\3U\4\3\23#ASUSTeK MotherBoard KEK C"..., 4096) = 3573
1597400557.584274 read(4, "", 523)      = 0
1597400557.584390 close(4)              = 0
1597400557.584418 geteuid()             = 0
1597400557.584447 openat(AT_FDCWD, "/sys/firmware/efi/efivars/db-d719b2cb-3d3a-4596-a3bc-dad00e67656f", O_RDONLY) = 4
1597400557.584479 clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
1597400557.584561 read(4, "'\0\0\0", 4) = 4
1597400557.584677 clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
1597400557.584761 read(4, "\241Y\300\245\344\224\247J\207\265\253\25\\+\360r\202\3\0\0\0\0\0\0f\3\0\0\2210\5;\237l\314\4\261\254\342\245\36;\345\3650\202\3R0\202\2:\240\3\2\1\2\2\20\332\203\271\220B.\274\214D\37\215\213\3\232e\2420\r\6\t*\206H\206\367\r\1\1\v\5\000011/0-\6\3U\4\3\23&ASUSTeK MotherBoard SW Ke"..., 4096) = 4096
1597400557.584880 read(4, "\0000\35\6\3U\35\16\4\26\4\24\251)\29\216\26\304\227x\315\220\371\236O\232\341|U\257S0\31\6\t+\6\1\4\1\2027\24\2\4\f\36\n\0S\0u\0b\0C\0A0\v\6\3U\35\17\4\4\3\2\1\2060\17\6\3U\35\23\1\1\377\4\0050\3\1\1\3770\37\6\3U\35#\4\0300\26\200\24\325\366V\313\217\350\242\\bh\321=\224\220[\327\316\232\30\3040V\6\3U\35"..., 4096) = 2226
1597400557.584996 read(4, "", 1870)     = 0
1597400557.585107 close(4)              = 0
1597400557.585136 geteuid()             = 0
1597400557.585165 openat(AT_FDCWD, "/sys/firmware/efi/efivars/MokListRT-605dab50-e046-4300-abb6-3dd810dd8b23", O_RDONLY) = 4
1597400557.585198 clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
1597400557.585280 read(4, "\6\0\0\0", 4) = 4
1597400557.585444 clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
1597400557.585527 read(4, "&\26\304\301LP\222@\254\251A\3716\223C(L\0\0\0\0\0\0\0000\0\0\0P\253]`F\340\0C\253\266=\330\20\335\213#\217\344{\204\205\275\235\247K\310p\3349Z\243\366\274\314zK\230{\256\2\247\n\232Cbj+\4&\26\304\301LP\222@\254\251A\3716\223C(L\0\0\0\0\0\0\0000\0\0\0P\253]`F\340\0C\253\266=\330\20\335\213#\rxn\315\264\7\273w"..., 4096) = 1416
1597400557.585708 read(4, "", 2680)     = 0
1597400557.585870 close(4)              = 0
1597400557.585899 geteuid()             = 0
1597400557.585927 openat(AT_FDCWD, "/sys/firmware/efi/efivars/MokNew-605dab50-e046-4300-abb6-3dd810dd8b23", O_RDONLY) = 4
1597400557.585960 clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
1597400557.586042 read(4, "", 4)        = 0
1597400557.586141 clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
1597400557.586222 read(4, "", 4096)     = 0
1597400557.586306 close(4)              = 0
1597400557.586335 close(3)              = 0
1597400557.586379 openat(AT_FDCWD, "/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
1597400557.586423 fstat(3, {st_mode=S_IFREG|0644, st_size=2221, ...}) = 0
1597400557.586456 read(3, "#\n# /etc/nsswitch.conf\n#\n# An example Name Service Switch config file. This file should be\n# sorted with the most-used services "..., 4096) = 2221
1597400557.586499 read(3, "", 4096)     = 0
1597400557.586527 close(3)              = 0
1597400557.586559 openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
1597400557.586593 fstat(3, {st_mode=S_IFREG|0644, st_size=124163, ...}) = 0
1597400557.586623 mmap(NULL, 124163, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fe293bd6000
1597400557.586655 close(3)              = 0
1597400557.586690 openat(AT_FDCWD, "/lib64/libnss_compat.so.2", O_RDONLY|O_CLOEXEC) = 3
1597400557.586723 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 \"\0\0\0\0\0\0@\0\0\0\0\0\0\0\10\253\0\0\0\0\0\0\0\0\0\0@\08\0\t\0@\0\36\0\35\0\1\0\0\0\4\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\30\23\0\0\0\0\0\0\30\23\0\0\0\0\0\0\0\20\0\0\0\0\0\0\1\0\0\0\5\0\0\0"..., 832) = 832
1597400557.586756 fstat(3, {st_mode=S_IFREG|0755, st_size=45704, ...}) = 0
1597400557.586787 mmap(NULL, 42912, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fe293684000
1597400557.586817 mmap(0x7fe293686000, 24576, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7fe293686000
1597400557.586856 mmap(0x7fe29368c000, 4096, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x8000) = 0x7fe29368c000
1597400557.586887 mmap(0x7fe29368d000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x8000) = 0x7fe29368d000
1597400557.586927 close(3)              = 0
1597400557.586978 mprotect(0x7fe29368d000, 4096, PROT_READ) = 0
1597400557.587013 munmap(0x7fe293bd6000, 124163) = 0
1597400557.587064 openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
1597400557.587098 fstat(3, {st_mode=S_IFREG|0644, st_size=124163, ...}) = 0
1597400557.587129 mmap(NULL, 124163, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fe293bd6000
1597400557.587159 close(3)              = 0
1597400557.587193 openat(AT_FDCWD, "/lib64/tls/haswell/x86_64/libnss_nis.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
1597400557.587226 stat("/lib64/tls/haswell/x86_64", 0x7ffd2671e280) = -1 ENOENT (No such file or directory)
1597400557.587256 openat(AT_FDCWD, "/lib64/tls/haswell/libnss_nis.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
1597400557.587288 stat("/lib64/tls/haswell", 0x7ffd2671e280) = -1 ENOENT (No such file or directory)
1597400557.587318 openat(AT_FDCWD, "/lib64/tls/x86_64/libnss_nis.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
1597400557.587349 stat("/lib64/tls/x86_64", 0x7ffd2671e280) = -1 ENOENT (No such file or directory)
1597400557.587377 openat(AT_FDCWD, "/lib64/tls/libnss_nis.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
1597400557.587406 stat("/lib64/tls", 0x7ffd2671e280) = -1 ENOENT (No such file or directory)
1597400557.587435 openat(AT_FDCWD, "/lib64/haswell/x86_64/libnss_nis.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
1597400557.587464 stat("/lib64/haswell/x86_64", 0x7ffd2671e280) = -1 ENOENT (No such file or directory)
1597400557.587493 openat(AT_FDCWD, "/lib64/haswell/libnss_nis.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
1597400557.587523 stat("/lib64/haswell", 0x7ffd2671e280) = -1 ENOENT (No such file or directory)
1597400557.587551 openat(AT_FDCWD, "/lib64/x86_64/libnss_nis.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
1597400557.587581 stat("/lib64/x86_64", 0x7ffd2671e280) = -1 ENOENT (No such file or directory)
1597400557.587610 openat(AT_FDCWD, "/lib64/libnss_nis.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
1597400557.587641 stat("/lib64", {st_mode=S_IFDIR|0755, st_size=3142, ...}) = 0
1597400557.587673 openat(AT_FDCWD, "/usr/lib64/tls/haswell/x86_64/libnss_nis.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
1597400557.587703 stat("/usr/lib64/tls/haswell/x86_64", 0x7ffd2671e280) = -1 ENOENT (No such file or directory)
1597400557.587732 openat(AT_FDCWD, "/usr/lib64/tls/haswell/libnss_nis.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
1597400557.587761 stat("/usr/lib64/tls/haswell", 0x7ffd2671e280) = -1 ENOENT (No such file or directory)
1597400557.587789 openat(AT_FDCWD, "/usr/lib64/tls/x86_64/libnss_nis.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
1597400557.587819 stat("/usr/lib64/tls/x86_64", 0x7ffd2671e280) = -1 ENOENT (No such file or directory)
1597400557.587847 openat(AT_FDCWD, "/usr/lib64/tls/libnss_nis.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
1597400557.587878 stat("/usr/lib64/tls", 0x7ffd2671e280) = -1 ENOENT (No such file or directory)
1597400557.587907 openat(AT_FDCWD, "/usr/lib64/haswell/x86_64/libnss_nis.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
1597400557.587936 stat("/usr/lib64/haswell/x86_64", 0x7ffd2671e280) = -1 ENOENT (No such file or directory)
1597400557.587965 openat(AT_FDCWD, "/usr/lib64/haswell/libnss_nis.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
1597400557.587994 stat("/usr/lib64/haswell", 0x7ffd2671e280) = -1 ENOENT (No such file or directory)
1597400557.588023 openat(AT_FDCWD, "/usr/lib64/x86_64/libnss_nis.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
1597400557.588053 stat("/usr/lib64/x86_64", 0x7ffd2671e280) = -1 ENOENT (No such file or directory)
1597400557.588081 openat(AT_FDCWD, "/usr/lib64/libnss_nis.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
1597400557.588111 stat("/usr/lib64", {st_mode=S_IFDIR|0755, st_size=98974, ...}) = 0
1597400557.588142 munmap(0x7fe293bd6000, 124163) = 0
1597400557.588184 openat(AT_FDCWD, "/etc/shadow", O_RDONLY|O_CLOEXEC) = 3
1597400557.588223 lseek(3, 0, SEEK_CUR) = 0
1597400557.588252 fstat(3, {st_mode=S_IFREG|0640, st_size=1002, ...}) = 0
1597400557.588282 mmap(NULL, 1002, PROT_READ, MAP_SHARED, 3, 0) = 0x7fe293c1e000
1597400557.588312 lseek(3, 1002, SEEK_SET) = 1002
1597400557.588348 munmap(0x7fe293c1e000, 1002) = 0
1597400557.588376 close(3)              = 0
1597400557.588414 openat(AT_FDCWD, "/sys/firmware/efi/efivars/MokNew-605dab50-e046-4300-abb6-3dd810dd8b23", O_RDONLY) = 3
1597400557.588449 fstat(3, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
1597400557.588479 ioctl(3, FS_IOC_GETFLAGS, 0x7ffd2671ece0) = 0
1597400557.588509 ioctl(3, FS_IOC_SETFLAGS, 0x7ffd2671ec70) = 0
1597400557.588538 openat(AT_FDCWD, "/sys/firmware/efi/efivars/MokNew-605dab50-e046-4300-abb6-3dd810dd8b23", O_WRONLY) = 4
1597400557.588570 fstat(4, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
1597400557.588598 write(4, "\7\0\0\0\241Y\300\245\344\224\247J\207\265\253\25\\+\360r\20\4\0\0\0\0\0\0\364\3\0\0P\253]`F\340\0C\253\266=\330\20\335\213#0\202\3\3400\202\2\310\240\3\2\1\2\2\v  \7\7\10\tF_\4-\3120\r\6\t*\206H\206\367\r\1\1\v\5\0000\\1301\6\3U\4\3\f*Secure Boot Module Signatu"..., 1044) = -1 EINVAL (Invalid argument)
1597400557.588662 ioctl(3, FS_IOC_SETFLAGS, 0x7ffd2671ece0) = 0
1597400557.588690 close(4)              = 0
1597400557.588717 close(3)              = 0
1597400557.588747 write(2, "Failed to enroll new keys\n", 26Failed to enroll new keys
) = 26
1597400557.588854 exit_group(-1)        = ?
1597400557.589022 +++ exited with 255 +++
255
Comment 139 Martin Wilck 2020-08-14 11:08:12 UTC
> 1597400557.588598 write(4, "\7\0\0\0\241Y\300\245\344\224\247J\207\265\253\25\\+\360r\20\4\0\0\0\0\0\0\364\3\0\0P\253]`F\340\0C\253\266=\330\20\335\213#0\202\3\3400\202\2\310\240\3\2\1\2\2\v  \7\7\10\tF_\4-\3120\r\6\t*\206H\206\367\r\1\1\v\5\0000\\1301\6\3U\4\3\f*Secure Boot Module Signatu"..., 1044) = -1 EINVAL (Invalid argument)

Hmm, that looks strange. I can only see two error conditions returning EINVAL in efivarfs_file_write(), and both seem not to be met.

Gary, can you have a look, too?
Comment 140 Jiri Slaby 2020-08-14 11:29:00 UTC
(In reply to Martin Wilck from comment #139)
> Hmm, that looks strange. I can only see two error conditions returning
> EINVAL in efivarfs_file_write(), and both seem not to be met.

Note hat efivar_entry_set_get_size returns EINVAL in some cases too.
Comment 141 Martin Wilck 2020-08-14 13:11:20 UTC
(In reply to Jiri Slaby from comment #140)
> Note hat efivar_entry_set_get_size returns EINVAL in some cases too.

Thanks, I misread the error code mangling in efivarfs_file_write()...

>  * Returns 0 on success, -EINVAL if the variable data is invalid,
>  * -ENOSPC if the firmware does not have enough available space, or a
>  * converted EFI status code if either of set_variable() or
>  * get_variable() fail.

And here we have "EFI_INVALID_PARAMETER" mapped to -EINVAL. Which could thus basically mean anything :-/.

From the fact that the same operation failed under kubuntu as well (comment 135), we might infer that the EFI layer rejects the users's certificate for some reason.
Comment 142 Tripple Moon 2020-08-14 13:55:06 UTC
(In reply to Martin Wilck from comment #141)
> From the fact that the same operation failed under kubuntu as well (comment
> 135), we might infer that the EFI layer rejects the users's certificate for
> some reason.

Excatly, no idea if it is specific to my motherboard's UEFI implementation or that it is stricter as "most" others wrt to this subject.
Because i am able to add certificates to the MokList using the KeyTool.efi from efitools while outside any OS...
I have a hunch that shim plays a big role in the restriction of this as it won't allow to execute of another efi binary after the first one.
eg: Start "KeyTool.efi" through shim, then try to execute "HashTool.efi" and the like from the menu presented all give errors...
Comment 143 Tripple Moon 2020-08-14 14:01:26 UTC
To be clear the certs that are used while using KeyTool.efi are the same, so the problem is not the certificate(s) themself.
Comment 144 Martin Wilck 2020-08-14 14:07:31 UTC
(In reply to Tripple Moon from comment #143)
> To be clear the certs that are used while using KeyTool.efi are the same, so
> the problem is not the certificate(s) themself.

Weird. A bug in the BIOS EFI runtime?
Comment 145 Tripple Moon 2020-08-14 15:00:53 UTC
(In reply to Martin Wilck from comment #144)
> (In reply to Tripple Moon from comment #143)
> > To be clear the certs that are used while using KeyTool.efi are the same, so
> > the problem is not the certificate(s) themself.
> 
> Weird. A bug in the BIOS EFI runtime?

No idea, I use a ASUS X99-PRO/USB3.1 Motherboard with BIOS 3902.
https://www.asus.com/Motherboards/X99PROUSB_31/

The last time i tried to update the bios, the bios file was not accepted by the flash util from the bios, most likely a bad file.
(Because the download was a zipped version 'X99-PRO-USB31-ASUS-4101.zip' which gave no errors while unpacking)
Comment 146 Martin Wilck 2020-08-14 15:27:52 UTC
I'm unsure how to proceed further here. Hope Gary can make more out of it.
Comment 147 Gary Ching-Pang Lin 2020-08-17 03:58:41 UTC
Since the error in mokutil has nothing to do with CONFIG_MODULE_SIG, I created another bug entry (bsc#1175325) for it. Please continue the discussion in that bug entry.
Comment 148 Tripple Moon 2020-08-17 07:55:53 UTC
(In reply to Gary Ching-Pang Lin from comment #147)
> Since the error in mokutil has nothing to do with CONFIG_MODULE_SIG, I
> created another bug entry (bsc#1175325) for it. Please continue the
> discussion in that bug entry.

Agreed because although it made the real problem surface, they are not directly related to each other.
The real problem is the interaction between mokutil and shim IMHO...
Comment 149 Stefan Dirsch 2020-08-22 23:03:57 UTC
So, back from vacation after 3 weeks. No idea why this bug is still open. The guy who reopened this bug (comment #104) never answered Takashi's question in comment #105. And Tripple Moon got his extra bug. Closing again as fixed.