[kernel-bugs] [Bug 1173158] New: CONFIG_MODULE_SIG=y
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158 Bug ID: 1173158 Summary: CONFIG_MODULE_SIG=y Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs@opensuse.org Reporter: lnussel@suse.com QA Contact: qa-bugs@suse.de CC: opensuse-releaseteam@suse.de Found By: --- Blocker: --- 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. -- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c1
--- Comment #1 from Ludwig Nussel
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c2
Takashi Iwai
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c3
Ludwig Nussel
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c4
--- Comment #4 from Stefan Dirsch
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c5
--- Comment #5 from Stefan Dirsch
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c6
--- Comment #6 from Ludwig Nussel
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c7
--- Comment #7 from Ludwig Nussel
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). -- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c8
--- Comment #8 from Takashi Iwai
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c9
--- Comment #9 from Stefan Dirsch
(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. -- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c10
--- Comment #10 from Stefan Dirsch
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. -- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
Lubos Kocman
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c15
--- Comment #15 from Lubos Kocman
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c16
Lubos Kocman
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c17
Martin Wilck
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.
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. It would be much better to have a real KMP built with binary, signed modules, like we do it for OSS KMPs on OBS. That's obviously a legal problem for us. Maybe it would be possible to do it on pacman? 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. -- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c18
--- Comment #18 from Stefan Dirsch
(In reply to Stefan Dirsch from comment #9)
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.
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.
It would be much better to have a real KMP built with binary, signed modules, like we do it for OSS KMPs on OBS. That's obviously a legal problem for us. Maybe it would be possible to do it on pacman?
Better don't talk with legal about such ideas. ;-)
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. -- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c19
--- Comment #19 from Martin Wilck
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. -- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c21
--- Comment #21 from Stefan Dirsch
(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. ;-) -- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c22
--- Comment #22 from Stefan Dirsch
(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. ;-) -- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c24
--- Comment #24 from Martin Wilck
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). -- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c25
--- Comment #25 from Ludwig Nussel
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. -- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c26
--- Comment #26 from Martin Wilck
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c27
--- Comment #27 from Ludwig Nussel
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. -- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c28
Martin Wilck
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
Stefan Dirsch
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c33
Wolfgang Bauer
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c34
--- Comment #34 from Stefan Dirsch
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. :-( -- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c100
Stefan Dirsch
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c101
--- Comment #101 from Stefan Dirsch
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c102
Reinhold Patzer
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c103
--- Comment #103 from Takashi Iwai
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. -- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c104
Reinhold Patzer
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 -- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c105
--- Comment #105 from Takashi Iwai
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c106
Tripple Moon
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c107
--- Comment #107 from Tripple Moon
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c108
--- Comment #108 from Tripple Moon
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c109
--- Comment #109 from Takashi Iwai
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c110
--- Comment #110 from Martin Wilck
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. -- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c111
Martin Wilck
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. -- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c112
--- Comment #112 from Tripple Moon
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 -- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
Tripple Moon
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c113
--- Comment #113 from Tripple Moon
(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? -- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c114
--- Comment #114 from Gary Ching-Pang Lin
(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. -- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c115
--- Comment #115 from Tripple Moon
(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?" -- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c116
--- Comment #116 from Tripple Moon
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c118
--- Comment #118 from Tripple Moon
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... -- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c119
--- Comment #119 from Gary Ching-Pang Lin
(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. -- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c120
--- Comment #120 from Tripple Moon
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) -- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c121
--- Comment #121 from Tripple Moon
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c122
--- Comment #122 from Tripple Moon
(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 are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c123
--- Comment #123 from Gary Ching-Pang Lin
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)
-- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c124
--- Comment #124 from li Ray
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. -- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c125
--- Comment #125 from Tripple Moon
(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... -- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c126
--- Comment #126 from Martin Wilck
"mokutil --revoke-cert" would need a certificate as argument to revoke,
it doesn't. -- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c131
--- Comment #131 from Gary Ching-Pang Lin
(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 -- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c134
--- Comment #134 from Tripple Moon
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...
-- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c135
--- Comment #135 from Tripple Moon
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c136
--- Comment #136 from Martin Wilck
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? -- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c137
--- Comment #137 from Tripple Moon
(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...
-- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158 http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c138 --- Comment #138 from Tripple Moon--- (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 -- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c139
Martin Wilck
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? -- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c141
--- Comment #141 from Martin Wilck
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.
-- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c142
--- Comment #142 from Tripple Moon
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... -- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c143
--- Comment #143 from Tripple Moon
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c144
--- Comment #144 from Martin Wilck
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? -- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c145
--- Comment #145 from Tripple Moon
(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) -- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158
http://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c146
--- Comment #146 from Martin Wilck
participants (1)
-
bugzilla_noreply@suse.com