lcp / mokutil Goto Github PK
View Code? Open in Web Editor NEWThe utility to manipulate machine owner keys
License: GNU General Public License v3.0
mokutil's People
Contributors
Stargazers
Watchers
Forkers
mjg59 vathpela c-jheengut jiazhang0 tyhicks cyphermox tdaitx vorlonofportland joeyli faustinoaq sandy-lcq anthonywong andypost tstellar spasam martinezjavier esnowberg xnox hustliyilin k3dar rmetrich justinkb zhangwenlong8911 negadave chr15p rhboot jsetje frozencemetery yusong-gao da4089 jamestiotio lnussel sshedimokutil's Issues
What do you mean by "shim"?
"The utility to manipulate machines owner keys which managed in shim"
"mokutil is a tool to import or delete the machines owner keys (MOK) stored in the database of shim."
What do you mean by "shim"?
write a efi-shell-script to set Moknew to MokList
Hi,
I want to provisioning a pool of pc for secure boot with a minimum set of interaction.
The idea is to
- boot a linux over uefi-pxe
- import a .der key with mokutil
- reboot in to the efishell
- perform the necessary steps to write the data from Moknew to MokList via the startup.nsh.
I tried to understand the steps from MokManager.c and tried to do it with the efishell command
setvar but I wasn't successful.
Maybe someone could help me with the necessary efishell commands to write the
date from Moknew to MokList?
Don't know how to boot into MOKmanager
As the title says. A recent Ubuntu 22.04 firmware-related update prompted me to set a secure boot password via a little GUI dialog, & then reboot me into the MOK TUI, I wasn't sure what to do & so selected 'Continue boot' when I think I was actually meant to select 'Enroll' or something along those lines? As such, I have no idea if it's configured correctly. However, I've rebooted multiple times since & MOK has never come back for me to select any other options.
Any advice as to whether I'm doing this correctly would be appreciated!
Cannot remove keys from Mokutil
When I run the command mokutil --list-enroll , then mokutil --reset and reboot to remove the key from MokManager upon boot I get the error shown below:
ERROR "Failed to set variable: (0xE) Not Found"
After fully booting up the keys have not been removed.
I can't change the Secure Boot mode to enabled "Failed to delete Secure Boot state"
Hello,
I installed Ubuntu 18.04 fresh on a System on a new System. Secure Boot is showen as enabled, in the BIOs of the Computer, but as I used the sudo mokutil --sb-state to check the status it says "SecureBoot disabled".
Then I used sudo mokutil --enable-validation to change it in the MOK Menu, but after I confirmed to enable Secure Boot, I get the Message "Failed to delete Secure Boot state".
Has anyone an Idea?
with kind regards
Problem with broken /sys/firmware/efi/mok-variables/MokListRT
I had an apparently broken /sys/firmware/efi/mok-variables/MokListRT which prevented mokutil from list and deleting keys from the valid /sys/firmware/efi/vars/MokListRT-*. But shim was loading signed grub without issues, using certs from the efivar.
So I hacked on mokutil like this:
diff --git a/src/mokutil.c b/src/mokutil.c
index f9820b4..fbb40e7 100644
--- a/src/mokutil.c
+++ b/src/mokutil.c
@@ -203,7 +203,8 @@ list_keys_in_var (const char *var_name, const efi_guid_t guid)
if (ret >= 0) {
ret = list_keys (data, data_sz);
free(data);
- return ret;
+ if (ret >= 0)
+ return ret;
}
for (i = 0; i < SIZE_MAX; i++) {
@@ -545,9 +546,8 @@ is_one_duplicate (const efi_guid_t *type,
return 0;
list = build_mok_list (var_data, var_data_size, &node_num);
- if (list == NULL) {
- goto done;
- }
+ if (list == NULL)
+ return -1;
for (unsigned int i = 0; i < node_num; i++) {
efi_guid_t sigtype = list[i].header->SignatureType;
@@ -571,9 +571,7 @@ is_one_duplicate (const efi_guid_t *type,
}
}
-done:
- if (list)
- free (list);
+ free (list);
return ret;
}
which allowed to run mokutil -l and then also mokutil --delete .... After the latter was applied by shim, my /sys/firmware/efi/mok-variables/MokListRT is now fine, and I cannot reproduce the issue. The first variable was containing some data pointing to original certs by the Microsoft and/or the OEM. Unfortunately, I made no backup of it.
What could have happened? And is that change possibly valid, provide my case is something that needs to be accounted for?
terse list mode
The standard mode for listing certificates as used in eg --list-enrolled dumps something equivalent to openssl x509 -text to stdout. That's rather hard to read and also hard to grep. How about implementing a short listing with one cert per line? It could only show eg CN and fingerprint. Something like
bca4e38 SUSE Linux Enterprise Secure Boot CA
eb9d9d0 Nvidia private build
66bbf17 Local build for nvidia-gfxG05 470.141.03 on 2022-09-08
1f67329 openSUSE Secure Boot Signkey
580a6f4 Microsoft Windows Production PCA 2011
46def63 Microsoft Corporation UEFI CA 2011
4090599 SUSE Linux Enterprise Secure Boot Signkey
Estimated date for a 0.5.0 release
The last 0.4.0 release was on May, 2019 and there have been a lot of changes since then. Is there a plan to have a new release soon ?
Build fails on 32-bit architecture
When I try to build mokutil-0.3.0 on i586 with gcc 4.9.2 I get the following errors:
make all-recursive
make[1]: Entering directory '/home/live/mokutil/mokutil-0.3.0'
Making all in src
make[2]: Entering directory '/home/live/mokutil/mokutil-0.3.0/src'
gcc -DHAVE_CONFIG_H -I. -I.. -std=gnu11 -Wall -Wextra -Wcast-align -Wno-uninitialized -Wmissing-declarations -Wcast-align -Wwrite-strings -Winit-self -Wreturn-type -Werror=format-nonliteral -Werror=format-security -Wmissing-format-attribute -Werror=sign-compare -Wuninitialized -Wunused -Waggregate-return -Werror=strict-aliasing -g -O2 -MT mokutil-password-crypt.o -MD -MP -MF .deps/mokutil-password-crypt.Tpo -c -o mokutil-password-crypt.o `test -f 'password-crypt.c' || echo './'`password-crypt.c
mv -f .deps/mokutil-password-crypt.Tpo .deps/mokutil-password-crypt.Po
gcc -DHAVE_CONFIG_H -I. -I.. -std=gnu11 -Wall -Wextra -Wcast-align -Wno-uninitialized -Wmissing-declarations -Wcast-align -Wwrite-strings -Winit-self -Wreturn-type -Werror=format-nonliteral -Werror=format-security -Wmissing-format-attribute -Werror=sign-compare -Wuninitialized -Wunused -Waggregate-return -Werror=strict-aliasing -g -O2 -MT mokutil-mokutil.o -MD -MP -MF .deps/mokutil-mokutil.Tpo -c -o mokutil-mokutil.o `test -f 'mokutil.c' || echo './'`mokutil.c
mokutil.c: In function ‘issue_mok_request’:
mokutil.c:1287:34: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
if (read_size < 0 || read_size != sizes[i]) {
^
mokutil.c: In function ‘export_moks’:
mokutil.c:1648:17: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
while (offset < list[i].mok_size) {
^
cc1: some warnings being treated as errors
Makefile:386: recipe for target 'mokutil-mokutil.o' failed
make[2]: *** [mokutil-mokutil.o] Error 1
make[2]: Leaving directory '/home/live/mokutil/mokutil-0.3.0/src'
Makefile:349: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/live/mokutil/mokutil-0.3.0'
Makefile:289: recipe for target 'all' failed
make: *** [all] Error 2
Nvidia driver
Hi, I'm not that experienced and I don't know if this is the place to ask but I need help.
I updated my ubuntu installation which updated my Nvidia drivers and this time asked me about entering secure boot password. I entered a password and kept using my laptop until I restarted. I got the enroll MOK screen and I didn't know what to do and pressed continue boot. Now I have no internet with ethernet or WIFI in ubuntu and windows.
I'm trying to fix this for the past 3 days. I managed to get the internet back in ubuntu with grup pci=noear but no luck with windows.
ff20a53a mokutil: do the CA check
Why is this?
First we have
commit ff20a53
Author: Gary Lin [email protected]
Date: Thu Aug 27 14:11:56 2020 +0800
mokutil: do the CA check
Check whether th CA cert is already enrolled in the key database before
enrolling the key.
The check can be disabled with "--ignore-ca-check".
and then
commit 235e92a
Author: Gary Lin [email protected]
Date: Wed Sep 2 16:09:04 2020 +0800
mokutil: disable CA check by default
The SUSE PTF certificate is also issued by SUSE CA, so enabling CA check
by default would ignore the enrollment of the PTF certificates and the
PTF would be unloadable.
Flip "--ignore-ca-check" to "--ca-check" and set force_ca_check to 0 by
default.
which shows that the fact that the CA is enrolled is irrelevant and the kernel is not bootable anyway.
Robust API for --sb-state, --test-key and --import
It would help a lot if at least --sb-state, --test-key and --import return a code value for the outputs they have. When a machine wants to know the result it currently can only "parse" the stdout/stderr text, which can easily break if you localize it or change a single letter in it.
This request is related to this GNOME Software work; these three commands are currently used there, but extending this to other commands will surely be a plus.
The return code of the executable could be done only with an extra argument, otherwise keep the return value as is now. Something like mokutil --machine-readable --sb-state (where the --machine-readable is a bad name, there should be a fancier one for sure.
Alternatively, if you can ensure the text output as a (sort of) stable API, which will do not change in the future, neither will be localized or anything, then it can work for the time being as well.
cast-align werror on mips
mokutil.c: In function 'sb_state':
mokutil.c:1822:21: error: cast increases required alignment of target type [-Werror=cast-align]
state = (int32_t)*(uint32_t )data;
^
mokutil.c:1824:21: error: cast increases required alignment of target type [-Werror=cast-align]
state = (int32_t)(uint16_t *)data;
^
cc1: all warnings being treated as errors
reset doesn't seem to work
if I --list-enrolled and then --reset and --list-enrolled again, all the hashes I've added are still there. Not being certain how this all works, I reboot and check --list-enrolled again and all the sha256 hashes are still there. Am I doing this wrong, or is this feature broken?
mokutil manager utility never loads on reboot
Hi:
I tried this post on setting up virtualbox with secure boot enabled: https://stegard.net/2016/10/virtualbox-secure-boot-ubuntu-fail/
But on one of my ubuntu 16.04, after I finished thie step and reboot:
# mokutil --import /root/module-signing/MOK.der
input password:
input password again:
mokutil manager utility never loads on reboot. Could anyone help me figure out what happened?
I disabled fast boot with secure boot enabled.
Any plans to make new release?
After so many years I think that it would be good to make new release :)
MokManager never appears at boot on Azure with RHEL 8
We are attempting to load 3rd party drivers with SecureBoot on a RHEL 8 VM on Azure. I know this is probably not a bug with mokutil, but mokmanager never appears at boot, and the new keys are cleared. This process works just fine for us on physical servers and VMWare. But, with Azure, the serial console appears to not engage until it is too late, or otherwise interrupt the shim boot.
I have confirmed via efibootvars that a shim boot is the default. RedHat sent me some commands to extend the timeout for the boot process, but this only caused a hang for about 2 minutes after the console shows "reboot: Restarting system."
echo -en "\xff\xff" > /tmp/2bytes
efivar -f /tmp/2bytes -A 7 -w -n 605dab50-e046-4300-abb6-3dd810dd8b23-MokTimeout
mokutil --import vendorcrt.der
reboot
Just wondering if there are any possible workarounds for this issue. I am relatively certain it has to do with Azure's console.
Is it safer to fix the salt length to 16?
uint16_t
82 get_salt_size (int method) {
83 switch (method) {
84 case TRADITIONAL_DES:
85 return T_DES_SALT_MAX;
86 case EXTEND_BSDI_DES:
87 return E_BSI_DES_SALT_MAX;
88 case MD5_BASED:
89 return MD5_SALT_MAX;
90 case SHA256_BASED:
91 case SHA512_BASED:
92 return gen_salt_size(8,16);
93 case BLOWFISH_BASED:
94 return BLOWFISH_SALT_MAX;
95 }
96
97 return -1;
98 }
salt is in plaintext，Is it safer to fix the salt length to 16?
Can't remove key
Hi all, I know there is other issued about this, sadly didn't works here.
I was trying to install https://github.com/lwfinger/rtw89
Then, I put a password, but was a bad/short one, so I tried to remove it, then it started.
mokutil -l
#This will show only one key, the one I want to remove
mokutil --reset
#enter password, acepted
#reboot the pc
#Select Reset MOK in BIOS
#Accept reset MokList
#Password
#ERROR: Failed to set variable: (0XE) Not Found
#Failed to erase keys
mokutil -l #Still shows one key
Here other try:
mkdir backup
cd backup
mokutil --export
dir
> MOK-0001.der
mokutil --delete MOK-0001.der
#enter password
#reboot pc
#Select Remove MOK from bios
#Confirm deletion
#Password
#Failed to retrieve MokList
#Failed to delete keys
#restart
mokutil -l #still shows one key
I'm in Debian Bullseye 64, I have tried disabling UEFI, cleaning the keys from BIOS, but nothing works u.u.
Sorry if this is not very well written, the computer now is without internet, and some parts are from the bios, so I written most of it.
Thx!
Stuck in verbosity boot loop
Hi,
This is really hard to explain as I am new to this:
I have a Surface Book 2 and, for reasons that I won't get into, used mokutil located in the latest GParted bootable USB to turn verbosity on. Now unfortunately whenever I boot that USB drive, I get a very slow verbose output on boot. But then after awhile it just stops and reboots and now I'm stuck. I can't seem to interrupt it so that I can fully boot the GParted USB drive and turn it off again. This for occurs for all Linux distro bootable USB drives. At the moment I don't have any Linux OS installed on the SSD.
Is there anything I can do about this or am I permanently doomed?
Thanks
mokutil manager utility never loads on reboot
Hi:
As a new user of MOK, I attempted to setup without proper research. I started following this post: https://superuser.com/a/1513506
When the MOK management screen appeared, I decided I better research this more before I enroll this key. So, I chose "Continue boot" instead of "Enroll MOK". This caused me to be unable to boot the Linux side of my dual boot.
After days of research, I found this post: linux-surface/linux-surface#1256 (comment)
This allowed me to re-enable Linux boot.
I am now following this official instruction: https://github.com/linux-surface/linux-surface/wiki/Secure-Boot#using-the-provided-secure-boot-certificate
After several more days of research and trial and error, I cannot figure out how to re-enable the mokutil manager so that it displays upon the addition of a new key.
Can anyone help me figure out what happened?
Details:
fred@surface:~$ efibootmgr -v
BootCurrent: 0005
Timeout: 0 seconds
BootOrder: 0005,0004,0001,0000,0002
Boot0000* Internal Storage FvVol(a881d567-6cb0-4eee-8435-2e72d33e45b5)/FvFile(50670071-478f-4be7-ad13-8754f379c62f)SDD.
Boot0001* USB Storage FvVol(a881d567-6cb0-4eee-8435-2e72d33e45b5)/FvFile(50670071-478f-4be7-ad13-8754f379c62f)USB.
Boot0002* PXE Network FvVol(a881d567-6cb0-4eee-8435-2e72d33e45b5)/FvFile(50670071-478f-4be7-ad13-8754f379c62f)PXE.
Boot0003* SurfaceFrontPage FvVol(a881d567-6cb0-4eee-8435-2e72d33e45b5)/FvFile(4042708a-0f2d-4823-ac60-0d77b3111889)
Boot0004* Windows Boot Manager HD(1,GPT,a4a42fc0-6009-46e0-baab-d62828287113,0x800,0x82000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}....................
Boot0005* debian HD(1,GPT,a4a42fc0-6009-46e0-baab-d62828287113,0x800,0x82000)/File(\EFI\debian\shimx64.efi)
fred@surface:~$
***
fred@surface:~$ hexdump -C /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c
00000000 06 00 00 00 01 |.....|
00000005
***
fred@surface:~$ hexdump -C /sys/firmware/efi/efivars/SetupMode-8be4df61-93ca-11d2-aa0d-00e098032b8c
00000000 06 00 00 00 00 |.....|
00000005
fred@surface:~$
***
fred@surface:~$ mokutil --sb-state
SecureBoot enabled
***
root@surface:~# apt install linux-surface-secureboot-mok
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
linux-surface-secureboot-mok
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 5,616 B of archives.
After this operation, 18.4 kB of additional disk space will be used.
Get:1 https://pkg.surfacelinux.com/debian release/main amd64 linux-surface-secureboot-mok amd64 20231003-1 [5,616 B]
Fetched 5,616 B in 2s (3,179 B/s)
Selecting previously unselected package linux-surface-secureboot-mok.
(Reading database ... 109345 files and directories currently installed.)
Preparing to unpack .../linux-surface-secureboot-mok_20231003-1_amd64.deb ...
Unpacking linux-surface-secureboot-mok (20231003-1) ...
Setting up linux-surface-secureboot-mok (20231003-1) ...
The secure-boot certificate has been installed to
/usr/share/linux-surface-secureboot/surface.cer
It will now be automatically enrolled for you and guarded with the password
surface
To finish the enrollment process you need to reboot, where you will then be
asked to enroll the certificate. During the import, you will be prompted for
the password mentioned above. Please make sure that you are indeed adding
the right key and confirm by entering 'surface'.
Note that you can always manage your secure-boot keys, including the one
just enrolled, from inside Linux via the 'mokutil' tool.
***
ls -l /sys/firmware/efi/efivars/Mok*
/sys/firmware/efi/efivars/MokAuth-605dab50-e046-4300-abb6-3dd810dd8b23
/sys/firmware/efi/efivars/MokListRT-605dab50-e046-4300-abb6-3dd810dd8b23
/sys/firmware/efi/efivars/MokListTrustedRT-605dab50-e046-4300-abb6-3dd810dd8b23
/sys/firmware/efi/efivars/MokListXRT-605dab50-e046-4300-abb6-3dd810dd8b23
/sys/firmware/efi/efivars/MokNew-605dab50-e046-4300-abb6-3dd810dd8b23
/sys/firmware/efi/efivars/MokSB-605dab50-e046-4300-abb6-3dd810dd8b23
***
root@surface:~# mokutil --list-enrolled
[key 1]
SHA1 Fingerprint: 53:61:0c:f8:1f:bd:7e:0c:eb:67:91:3c:9e:f3:e7:94:a9:63:3e:cb
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
ed:54:a1:d5:af:87:48:94:8d:9f:89:32:ee:9c:7c:34
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=Debian Secure Boot CA
Validity
Not Before: Aug 16 18:09:18 2016 GMT
Not After : Aug 9 18:09:18 2046 GMT
Subject: CN=Debian Secure Boot CA
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:9d:95:d4:8b:9b:da:10:ac:2e:ca:82:37:c1:a4:
cb:4a:c3:1b:42:93:c2:7a:29:d3:6e:dd:64:af:80:
af:ea:66:a2:1b:61:9c:83:0c:c5:6b:b9:35:25:ff:
c5:fb:e8:29:43:de:ce:4b:3d:c6:12:4d:b1:ef:26:
43:95:68:cd:04:11:fe:c2:24:9b:de:14:d8:86:51:
e8:38:43:bd:b1:9a:15:e5:08:6b:f8:54:50:8b:b3:
4b:5f:fc:14:e4:35:50:7c:0b:b1:e2:03:84:a8:36:
48:e4:80:e8:ea:9f:fa:bf:c5:18:7b:5e:ce:1c:be:
2c:80:78:49:35:15:c0:21:cf:ef:66:d5:8a:96:08:
2b:66:2f:48:17:b1:e7:ec:82:8f:07:e6:ca:e0:5f:
71:24:39:50:0a:8e:d1:72:28:50:a5:9d:21:f4:e3:
61:ba:09:03:66:c8:df:4e:26:36:0b:15:0f:63:1f:
2b:af:ab:c4:28:a2:56:64:85:8d:a6:55:41:ae:3c:
88:95:dd:d0:6d:d9:29:db:d8:c4:68:b5:fc:f4:57:
89:6b:14:db:e0:ef:ee:40:0d:62:1f:ea:58:d4:a3:
d8:ba:03:a6:97:2e:c5:6b:13:a4:91:77:a6:b5:ad:
23:a7:eb:0a:49:14:46:7c:76:e9:9e:32:b4:89:af:
57:79
Exponent: 65537 (0x10001)
X509v3 extensions:
Authority Information Access:
CA Issuers - URI:https://dsa.debian.org/secure-boot-ca
X509v3 Authority Key Identifier:
6C:CE:CE:7E:4C:6C:0D:1F:61:49:F3:DD:27:DF:CC:5C:BB:41:9E:A1
Netscape Cert Type: critical
SSL Client, SSL Server, S/MIME, Object Signing, SSL CA, S/MIME CA, Object Signing CA
X509v3 Extended Key Usage:
Code Signing
X509v3 Key Usage: critical
Digital Signature, Certificate Sign, CRL Sign
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Subject Key Identifier:
6C:CE:CE:7E:4C:6C:0D:1F:61:49:F3:DD:27:DF:CC:5C:BB:41:9E:A1
Signature Algorithm: sha256WithRSAEncryption
Signature Value:
77:96:3e:47:c9:ce:09:cf:8b:89:ce:59:ed:26:0e:26:0b:b9:
ad:a9:2b:bd:a1:eb:88:79:02:ff:31:de:fe:f5:6a:07:ef:61:
13:11:70:1e:bf:9c:4e:66:6c:e1:62:12:97:01:57:65:47:dd:
4a:c6:f7:f4:de:a8:f1:13:62:cc:83:57:ac:3c:a6:91:15:af:
55:26:72:69:2e:14:cd:dd:4d:b3:d1:60:24:2d:32:4f:19:6c:
11:5e:f2:a3:f2:a1:5f:62:0f:30:ae:ad:f1:48:66:64:7d:36:
44:0d:06:34:3d:2e:af:8e:9d:c3:ad:c2:91:d8:37:e0:ee:7a:
5f:82:3b:67:8e:00:8a:c4:a4:df:35:16:c2:72:2b:4c:51:d7:
93:93:9e:ba:08:0d:59:97:f2:e2:29:a0:44:4d:ea:ee:f8:3e:
02:60:ca:15:cf:4e:9a:25:91:84:3f:b7:5a:c7:ee:bc:6b:80:
a3:d9:fd:b2:6d:7a:1e:63:14:eb:ef:f1:b0:40:25:d5:e8:0e:
81:eb:6b:f7:cb:ff:e5:21:00:22:2c:2e:9a:35:60:12:4b:5b:
5f:38:46:84:0c:06:9c:cf:72:93:62:18:ee:5c:98:d6:b3:7d:
06:25:39:95:df:4e:60:76:b0:06:7b:08:b0:6e:e3:64:9f:21:
56:ad:39:0f
***
root@surface:~# mokutil --list-new
[key 1]
SHA1 Fingerprint: 05:f6:aa:10:9c:1c:62:67:1e:75:bd:75:d3:d0:51:47:20:63:c0:81
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
43:3e:21:a6:6d:1a:2a:a6:84:02:e2:07:2d:af:4e:41:93:6a:23:3e
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=XX, L=Default City, O=Default Company Ltd, CN=linux-surface
Validity
Not Before: Jan 20 21:08:24 2020 GMT
Not After : Jan 17 21:08:24 2030 GMT
Subject: C=XX, L=Default City, O=Default Company Ltd, CN=linux-surface
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (4096 bit)
Modulus:
00:ae:18:1a:4e:2a:a3:0e:0b:17:f9:6d:f7:e2:46:
ae:99:53:18:cd:fa:f1:8d:db:e1:11:2e:c7:dc:69:
3d:c5:23:4d:99:0e:ef:18:78:d1:77:e8:ec:6a:41:
50:03:f9:ad:ab:21:69:23:0e:4f:80:7d:7d:47:69:
06:52:83:8f:06:dd:f9:18:4f:5f:e4:72:f5:f6:d1:
9d:bf:dd:e1:89:19:9b:b8:8a:65:86:67:0c:55:bd:
92:00:a6:98:fd:70:b8:33:eb:6a:40:d2:38:b5:80:
e4:90:d7:2b:dc:9b:92:c8:e1:65:f9:9c:eb:5f:64:
80:70:89:3b:96:3c:20:d2:3b:32:ab:90:9b:51:7c:
b1:2e:be:b5:99:c1:1b:e0:41:c1:cc:6d:81:20:07:
ca:51:08:27:9d:9b:e7:57:66:7a:fe:55:7a:20:1a:
71:e2:7b:52:af:9b:f0:9b:83:4a:e5:6b:8d:73:94:
59:be:dd:e8:41:a9:ff:73:81:bd:d4:96:13:71:84:
a5:03:26:03:20:a9:78:c6:a0:0c:cb:d1:5f:c6:02:
9e:61:b1:c1:dc:b2:55:57:20:8c:fa:c6:4a:7f:d7:
59:96:02:26:c7:ce:46:e6:15:e5:fc:31:f4:bc:6d:
e6:1c:b2:23:b7:a0:39:5b:bb:bb:b4:dc:68:74:6c:
28:7c:96:3c:8c:df:53:90:e8:18:16:a3:40:97:4b:
21:2a:d8:c9:9a:9f:52:f0:33:f5:a2:e7:d3:aa:2a:
36:86:42:de:42:d7:70:68:a5:27:cb:ab:18:25:4f:
71:40:2d:1e:31:7e:f9:97:fc:31:66:94:33:31:93:
39:0a:d5:5d:46:9d:2d:b7:92:e8:a8:36:fa:e0:a7:
65:0a:fa:cf:e5:3f:5e:cf:ef:be:19:4b:6a:05:d2:
72:ba:b0:76:93:b0:e6:23:a1:a6:1d:25:05:a1:d1:
6c:5d:b8:29:c8:dd:20:38:e4:f4:da:61:3a:11:91:
23:f9:12:e3:76:d3:b6:a4:65:75:6e:6c:b6:bf:bc:
e1:bf:5e:6b:f7:43:25:95:60:e1:fd:b2:28:75:71:
8f:12:85:65:31:5a:4c:fa:e0:28:06:77:90:cf:96:
c7:4b:df:6f:4b:50:a7:c7:e2:1e:c7:89:0d:52:01:
25:0c:d5:8d:07:e4:1e:03:74:30:ef:85:4f:64:85:
cc:a5:24:7a:59:41:17:07:cd:5a:cf:47:1a:3e:b1:
14:59:5b:71:c0:de:52:39:d5:cf:e1:13:04:61:94:
9d:1f:7a:13:d1:56:46:f5:c6:aa:31:41:2e:b2:fb:
18:aa:a5:a5:68:c5:bb:b5:3f:01:af:fa:df:c9:52:
92:d0:3b
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
24:EF:5C:44:44:99:BA:0A:A6:F2:A8:BE:A4:25:8F:06:5F:EA:4E:C6
X509v3 Authority Key Identifier:
24:EF:5C:44:44:99:BA:0A:A6:F2:A8:BE:A4:25:8F:06:5F:EA:4E:C6
X509v3 Basic Constraints: critical
CA:TRUE
Signature Algorithm: sha256WithRSAEncryption
Signature Value:
83:ed:ff:6e:04:d0:8c:f9:20:9d:e5:6a:2e:83:17:b6:c2:ef:
22:4d:db:61:2a:a5:22:4b:6c:86:68:9c:a3:5d:76:c7:7f:88:
69:ab:37:d9:fc:ef:d9:2c:99:49:ea:e8:c9:31:68:19:7d:11:
61:7a:b3:bf:7a:15:7d:7a:7d:6f:4c:a5:ed:82:c5:8d:b6:1b:
a9:2e:99:0c:f5:a5:c5:94:95:ac:9c:4d:ba:9e:f4:23:59:de:
34:2c:5a:c3:39:04:41:39:0d:ec:89:ee:5a:e5:ec:8d:c6:b0:
02:fe:6f:67:9d:a2:23:a2:3a:2b:6d:5a:7d:c1:53:43:b2:f7:
bf:5e:79:ee:5e:84:e3:e8:3a:d6:8d:e4:01:20:51:70:e0:36:
1a:76:dd:8a:8a:c4:c9:40:38:42:97:61:b4:bc:1d:68:a4:9a:
98:47:92:fc:79:41:14:c7:48:83:1b:17:a0:e0:49:ac:f1:13:
40:3e:27:11:f9:65:52:b5:1f:9d:4a:2a:8e:c4:c1:52:3a:f3:
80:1a:fa:81:3a:00:f5:15:e7:66:79:28:49:e4:f2:9c:49:24:
06:49:05:91:4f:2a:08:38:5e:a8:a0:dd:ae:5f:c8:ce:09:43:
81:04:c8:f0:1d:98:3c:c3:ed:24:b8:93:b6:9e:d9:32:c2:38:
eb:38:a8:e7:06:57:27:fb:28:41:96:58:cd:d0:0c:55:ee:42:
8e:4f:49:0d:7a:fa:b9:f6:31:18:48:df:bd:61:4d:6c:f2:1b:
30:46:57:1e:b5:c3:24:60:e3:5b:66:a9:e0:19:1c:c6:8b:b2:
e3:7c:06:eb:40:14:37:2b:0b:8f:ba:db:b5:f5:34:f8:8e:67:
11:0f:d9:21:ad:75:1c:b2:52:5c:51:b9:dc:a9:28:ff:01:ed:
e8:ea:7b:5b:5f:ea:e0:b9:5c:8d:9e:39:bc:6a:97:ba:25:bd:
6a:f3:f8:c0:b8:a5:f5:f8:c2:cd:f8:e5:e3:4c:f0:eb:ea:a0:
37:0b:20:29:98:56:6a:81:af:ab:5b:5d:eb:a4:46:65:86:67:
ca:85:b3:d6:85:e0:b3:4e:00:c5:30:f8:f0:d8:7e:79:ea:24:
65:8b:a5:be:31:08:85:3c:e8:1d:ed:35:e8:08:37:cc:47:c6:
0e:de:a8:dd:a4:9e:fd:6a:0b:0d:bb:f7:60:0c:ca:b0:3d:69:
11:02:29:56:14:74:74:dc:d2:34:2c:ef:c8:d5:df:67:61:c0:
94:80:ff:fc:4d:e8:6e:87:41:e0:4b:06:e9:c5:f8:31:31:3d:
9a:00:31:bc:48:47:f8:bc:e3:cc:84:aa:32:b6:9c:77:c0:14:
40:3a:de:4a:46:cc:d6:96
Previewing this post I see the new key is 4096bit, I seem to recall reading something about only using 2048bit keys.
Key was rejected by service - Secure "boots" - Debian 12 - Micro$oft
Noob here. Why can't I make the module work with secure boot enabled?
user@debian:~$ sudo modprobe rtw_8723du
[sudo] senha para user:
modprobe: ERROR: could not insert 'rtw_8723du': Key was rejected by service
user@debian:~$ sudo modinfo rtw_8723du
filename: /lib/modules/6.1.0-11-amd64/kernel/drivers/net/wireless/realtek/rtw88/rtw_8723du.ko
license: Dual BSD/GPL
description: Realtek 802.11n wireless 8723du driver
author: Hans Ulli Kroll <[email protected]>
alias: usb:v7392pD611d*dc*dsc*dp*icFFiscFFipFFin*
alias: usb:v0BDApD723d*dc*dsc*dp*icFFiscFFipFFin*
depends: rtw_usb,usbcore,rtw_8723d
retpoline: Y
name: rtw_8723du
vermagic: 6.1.0-11-amd64 SMP preempt mod_unload modversions
Note
I thought it was spoiling, it looks like other signed drivers loaded.
user@debian:~ $ sudo modprobe rtw_8723de
user@debian:~$ sudo dmesg | grep cfg80211
[ 49.694948] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[ 49.695760] cfg80211: Loaded X.509 cert '[email protected]: 577e021cb980e0e820821ba7b54b4961b8b4fadf'
[ 49.697892] cfg80211: Loaded X.509 cert '[email protected]: 3abbc6ec146e09d1b6016ab9d6cf71dd233f0328'
[ 49.698217] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
This is the entire installation procedure that has been adopted: (from here https://github.com/lwfinger/rtw88)
user@debian:~ $ sudo apt-get install make gcc linux-headers-$(uname -r) build-essential git
Lendo listas de pacotes... Pronto
Construindo árvore de dependências... Pronto
Lendo informação de estado... Pronto
make is already the newest version (4.3-4.1).
gcc is already the newest version (4:12.2.0-3).
linux-headers-6.1.0-11-amd64 is already the newest version (6.1.38-4).
build-essential is already the newest version (12.9).
git is already the newest version (1:2.39.2-1.1).
0 pacotes atualizados, 0 pacotes novos instalados, 0 a serem removidos e 0 não atualizados.
user@debian:~ $ git clone https://github.com/lwfinger/rtw88.git
Cloning into 'rtw88'...
remote: Enumerating objects: 2132, done.
remote: Counting objects: 100% (243/243), done.
remote: Compressing objects: 100% (94/94), done.
remote: Total 2132 (delta 156), reused 201 (delta 149), pack-reused 1889
Receiving objects: 100% (2132/2132), 5.98 MiB | 3.54 MiB/s, done.
Resolving deltas: 100% (1251/1251), done.
user@debian:~ $ ^[[200~cd rtw88~^C
user@debian:~ $ cd rtw88
user@debian:~ /rtw88$ make
make -C /lib/modules/6.1.0-11-amd64/build M=/home/user/rtw88 modules
make[1]: a entrar na pasta "/usr/src/linux-headers-6.1.0-11-amd64"
CC [M] /home/user/rtw88/main.o
CC [M] /home/user/rtw88/mac80211.o
CC [M] /home/user/rtw88/util.o
CC [M] /home/user/rtw88/debug.o
CC [M] /home/user/rtw88/tx.o
CC [M] /home/user/rtw88/rx.o
CC [M] /home/user/rtw88/mac.o
CC [M] /home/user/rtw88/phy.o
CC [M] /home/user/rtw88/coex.o
CC [M] /home/user/rtw88/efuse.o
CC [M] /home/user/rtw88/fw.o
CC [M] /home/user/rtw88/ps.o
CC [M] /home/user/rtw88/sec.o
CC [M] /home/user/rtw88/wow.o
CC [M] /home/user/rtw88/bf.o
CC [M] /home/user/rtw88/regd.o
CC [M] /home/user/rtw88/sar.o
LD [M] /home/user/rtw88/rtw_core.o
CC [M] /home/user/rtw88/rtw8822b.o
CC [M] /home/user/rtw88/rtw8822b_table.o
LD [M] /home/user/rtw88/rtw_8822b.o
CC [M] /home/user/rtw88/rtw8822be.o
LD [M] /home/user/rtw88/rtw_8822be.o
CC [M] /home/user/rtw88/rtw8822bu.o
LD [M] /home/user/rtw88/rtw_8822bu.o
CC [M] /home/user/rtw88/rtw8822bs.o
LD [M] /home/user/rtw88/rtw_8822bs.o
CC [M] /home/user/rtw88/rtw8822c.o
CC [M] /home/user/rtw88/rtw8822c_table.o
LD [M] /home/user/rtw88/rtw_8822c.o
CC [M] /home/user/rtw88/rtw8822ce.o
LD [M] /home/user/rtw88/rtw_8822ce.o
CC [M] /home/user/rtw88/rtw8822cu.o
LD [M] /home/user/rtw88/rtw_8822cu.o
CC [M] /home/user/rtw88/rtw8822cs.o
LD [M] /home/user/rtw88/rtw_8822cs.o
CC [M] /home/user/rtw88/rtw8723d.o
CC [M] /home/user/rtw88/rtw8723d_table.o
LD [M] /home/user/rtw88/rtw_8723d.o
CC [M] /home/user/rtw88/rtw8723de.o
LD [M] /home/user/rtw88/rtw_8723de.o
CC [M] /home/user/rtw88/rtw8723du.o
LD [M] /home/user/rtw88/rtw_8723du.o
CC [M] /home/user/rtw88/rtw8723ds.o
LD [M] /home/user/rtw88/rtw_8723ds.o
CC [M] /home/user/rtw88/rtw8821c.o
CC [M] /home/user/rtw88/rtw8821c_table.o
LD [M] /home/user/rtw88/rtw_8821c.o
CC [M] /home/user/rtw88/rtw8821ce.o
LD [M] /home/user/rtw88/rtw_8821ce.o
CC [M] /home/user/rtw88/rtw8821cs.o
LD [M] /home/user/rtw88/rtw_8821cs.o
CC [M] /home/user/rtw88/rtw8821cu.o
LD [M] /home/user/rtw88/rtw_8821cu.o
CC [M] /home/user/rtw88/pci.o
LD [M] /home/user/rtw88/rtw_pci.o
CC [M] /home/user/rtw88/sdio.o
LD [M] /home/user/rtw88/rtw_sdio.o
CC [M] /home/user/rtw88/usb.o
LD [M] /home/user/rtw88/rtw_usb.o
MODPOST /home/user/rtw88/Module.symvers
CC [M] /home/user/rtw88/rtw_8723d.mod.o
LD [M] /home/user/rtw88/rtw_8723d.ko
BTF [M] /home/user/rtw88/rtw_8723d.ko
Skipping BTF generation for /home/user/rtw88/rtw_8723d.ko due to unavailability of vmlinux
CC [M] /home/user/rtw88/rtw_8723de.mod.o
LD [M] /home/user/rtw88/rtw_8723de.ko
BTF [M] /home/user/rtw88/rtw_8723de.ko
Skipping BTF generation for /home/user/rtw88/rtw_8723de.ko due to unavailability of vmlinux
CC [M] /home/user/rtw88/rtw_8723ds.mod.o
LD [M] /home/user/rtw88/rtw_8723ds.ko
BTF [M] /home/user/rtw88/rtw_8723ds.ko
Skipping BTF generation for /home/user/rtw88/rtw_8723ds.ko due to unavailability of vmlinux
CC [M] /home/user/rtw88/rtw_8723du.mod.o
LD [M] /home/user/rtw88/rtw_8723du.ko
BTF [M] /home/user/rtw88/rtw_8723du.ko
Skipping BTF generation for /home/user/rtw88/rtw_8723du.ko due to unavailability of vmlinux
CC [M] /home/user/rtw88/rtw_8821c.mod.o
LD [M] /home/user/rtw88/rtw_8821c.ko
BTF [M] /home/user/rtw88/rtw_8821c.ko
Skipping BTF generation for /home/user/rtw88/rtw_8821c.ko due to unavailability of vmlinux
CC [M] /home/user/rtw88/rtw_8821ce.mod.o
LD [M] /home/user/rtw88/rtw_8821ce.ko
BTF [M] /home/user/rtw88/rtw_8821ce.ko
Skipping BTF generation for /home/user/rtw88/rtw_8821ce.ko due to unavailability of vmlinux
CC [M] /home/user/rtw88/rtw_8821cs.mod.o
LD [M] /home/user/rtw88/rtw_8821cs.ko
BTF [M] /home/user/rtw88/rtw_8821cs.ko
Skipping BTF generation for /home/user/rtw88/rtw_8821cs.ko due to unavailability of vmlinux
CC [M] /home/user/rtw88/rtw_8821cu.mod.o
LD [M] /home/user/rtw88/rtw_8821cu.ko
BTF [M] /home/user/rtw88/rtw_8821cu.ko
Skipping BTF generation for /home/user/rtw88/rtw_8821cu.ko due to unavailability of vmlinux
CC [M] /home/user/rtw88/rtw_8822b.mod.o
LD [M] /home/user/rtw88/rtw_8822b.ko
BTF [M] /home/user/rtw88/rtw_8822b.ko
Skipping BTF generation for /home/user/rtw88/rtw_8822b.ko due to unavailability of vmlinux
CC [M] /home/user/rtw88/rtw_8822be.mod.o
LD [M] /home/user/rtw88/rtw_8822be.ko
BTF [M] /home/user/rtw88/rtw_8822be.ko
Skipping BTF generation for /home/user/rtw88/rtw_8822be.ko due to unavailability of vmlinux
CC [M] /home/user/rtw88/rtw_8822bs.mod.o
LD [M] /home/user/rtw88/rtw_8822bs.ko
BTF [M] /home/user/rtw88/rtw_8822bs.ko
Skipping BTF generation for /home/user/rtw88/rtw_8822bs.ko due to unavailability of vmlinux
CC [M] /home/user/rtw88/rtw_8822bu.mod.o
LD [M] /home/user/rtw88/rtw_8822bu.ko
BTF [M] /home/user/rtw88/rtw_8822bu.ko
Skipping BTF generation for /home/user/rtw88/rtw_8822bu.ko due to unavailability of vmlinux
CC [M] /home/user/rtw88/rtw_8822c.mod.o
LD [M] /home/user/rtw88/rtw_8822c.ko
BTF [M] /home/user/rtw88/rtw_8822c.ko
Skipping BTF generation for /home/user/rtw88/rtw_8822c.ko due to unavailability of vmlinux
CC [M] /home/user/rtw88/rtw_8822ce.mod.o
LD [M] /home/user/rtw88/rtw_8822ce.ko
BTF [M] /home/user/rtw88/rtw_8822ce.ko
Skipping BTF generation for /home/user/rtw88/rtw_8822ce.ko due to unavailability of vmlinux
CC [M] /home/user/rtw88/rtw_8822cs.mod.o
LD [M] /home/user/rtw88/rtw_8822cs.ko
BTF [M] /home/user/rtw88/rtw_8822cs.ko
Skipping BTF generation for /home/user/rtw88/rtw_8822cs.ko due to unavailability of vmlinux
CC [M] /home/user/rtw88/rtw_8822cu.mod.o
LD [M] /home/user/rtw88/rtw_8822cu.ko
BTF [M] /home/user/rtw88/rtw_8822cu.ko
Skipping BTF generation for /home/user/rtw88/rtw_8822cu.ko due to unavailability of vmlinux
CC [M] /home/user/rtw88/rtw_core.mod.o
LD [M] /home/user/rtw88/rtw_core.ko
BTF [M] /home/user/rtw88/rtw_core.ko
Skipping BTF generation for /home/user/rtw88/rtw_core.ko due to unavailability of vmlinux
CC [M] /home/user/rtw88/rtw_pci.mod.o
LD [M] /home/user/rtw88/rtw_pci.ko
BTF [M] /home/user/rtw88/rtw_pci.ko
Skipping BTF generation for /home/user/rtw88/rtw_pci.ko due to unavailability of vmlinux
CC [M] /home/user/rtw88/rtw_sdio.mod.o
LD [M] /home/user/rtw88/rtw_sdio.ko
BTF [M] /home/user/rtw88/rtw_sdio.ko
Skipping BTF generation for /home/user/rtw88/rtw_sdio.ko due to unavailability of vmlinux
CC [M] /home/user/rtw88/rtw_usb.mod.o
LD [M] /home/user/rtw88/rtw_usb.ko
BTF [M] /home/user/rtw88/rtw_usb.ko
Skipping BTF generation for /home/user/rtw88/rtw_usb.ko due to unavailability of vmlinux
make[1]: a sair da pasta "/usr/src/linux-headers-6.1.0-11-amd64"
user@debian:~/rtw88$ sudo make sign-install
make -C /lib/modules/6.1.0-11-amd64/build M=/home/user/rtw88 modules
make[1]: a entrar na pasta "/usr/src/linux-headers-6.1.0-11-amd64"
make[1]: a sair da pasta "/usr/src/linux-headers-6.1.0-11-amd64"
...+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*..+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*....+..+...............+.......+......+...............+..+...+...............+....+......+..+.+............+........+.+.........+..+...+....+...+........+.+.....+....+.....+.......+..+.+.........+..................+.....+...+.+........+............+.........+.+...+..+......+.......+...+...+...........+.+.....+....+........+...............+......+.+...+...........+......+.........+......+.........+..........+...........+.+..+.+...............+.....+....+.....+.+............+..+...............+...+.......+...+.....+.........+.+........+....+...+...+.........+.....+..........+......+......+.....+....+......+.....+...+...+....+......+..+............+.....................+....+...+..+...+......+.+......+..+......+.+......+..................+..+...+.+.................................+........+....+...........+.......+...........+.+.........+.....+.......+..+..........+..+...+.............+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
.....+..+...+......+...+.......+......+..+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*..........+.....+...+.+...+......+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*..+....+.....+...+.+............+..+...+...+....+.....+.+.....+.+...........+...................+...+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-----
input password:
input password again:
Install rtw88 SUCCESS
user@debian:~ /rtw88$
Note
With secure boot disabled the drive works normally.
user@debian:~$ sudo dmesg | grep rtw
[ 50.040609] rtw_core: loading out-of-tree module taints kernel.
[ 50.040853] rtw_core: module verification failed: signature and/or required key missing - tainting kernel
[ 50.085018] rtw_8723du 1-4:1.2: firmware: direct-loading firmware rtw88/rtw8723d_fw.bin
[ 50.085029] rtw_8723du 1-4:1.2: Firmware version 48.0.0, H2C version 0
[ 50.508946] usbcore: registered new interface driver rtw_8723du
[ 50.515855] rtw_8723du 1-4:1.2 wlx4607b84d436b: renamed from wlan0
As for the kernel:
user@debian:~$ sudo ls /var/lib/shim-signed/mok/
MOK.der MOK.pem MOK.priv
user@debian:~$ sudo ls /boot
config-6.1.0-10-amd64 keyfile.gpg
config-6.1.0-11-amd64 lost+found
efi System.map-6.1.0-10-amd64
grub System.map-6.1.0-11-amd64
initrd.img-6.1.0-10-amd64 vmlinuz-6.1.0-10-amd64
initrd.img-6.1.0-11-amd64 vmlinuz-6.1.0-11-amd64
user@debian:/boot$ sudo sbverify --cert /var/lib/shim-signed/mok/MOK.crt /boot/vmlinuz-6.1.0-11-amd64
Can't load certificate from file '/var/lib/shim-signed/mok/MOK.crt'
40A7D7391F7F0000:error:80000002:system library:BIO_new_file:No such file or directory:../crypto/bio/bss_file.c:67:calling fopen(/var/lib/shim-signed/mok/mok.crt, r)
40A7D7391F7F0000:error:10000080:BIO routines:BIO_new_file:no such file:../crypto/bio/bss_file.c:75:
user@debian:~$ sudo modinfo /boot/vmlinuz-6.1.0-11-amd64
modinfo: ERROR: Module /boot/vmlinuz-6.1.0-11-amd64 not found.
user@debian:~$ sudo sbverify --list /boot/vmlinuz-6.1.0-11-amd64
signature 1
image signature issuers:
- /CN=Debian Secure Boot CA
image signature certificates:
- subject: /CN=Debian Secure Boot Signer 2022 - linux
issuer: /CN=Debian Secure Boot CA
signature 2
image signature issuers:
- /CN=user
image signature certificates:
- subject: /CN=user
issuer: /CN=user
user@debian:~$ sudo sbverify --list /boot/vmlinuz-6.1.0-10-amd64
signature 1
image signature issuers:
- /CN=Debian Secure Boot CA
image signature certificates:
- subject: /CN=Debian Secure Boot Signer 2022 - linux
issuer: /CN=Debian Secure Boot CA
As for wifi:
user@debian:~$ sudo modprobe rtw_8723du
modprobe: ERROR: could not insert 'rtw_8723du': Key was rejected by service
user@debian:~$ sudo modinfo rtw_8723du
filename: /lib/modules/6.1.0-11-amd64/kernel/drivers/net/weless/realtek/rtw88/rtw_8723du.ko
license: Dual BSD/GPL
description: Realtek 802.11n wireless 8723du driver
author: Hans Ulli Kroll <[email protected]>
alias: usb:v7392pD611d*dc*dsc*dp*icFFiscFFipFFin*
alias: usb:v0BDApD723d*dc*dsc*dp*icFFiscFFipFFin*
depends: rtw_usb,usbcore,rtw_8723d
retpoline: Y
name: rtw_8723du
vermagic: 6.1.0-11-amd64 SMP preempt mod_unload modversion
user@debian:~$ sudo dmesg | grep cert
[ 2.178399] Loading compiled-in X.509 certificates
[ 2.204942] Loaded X.509 cert 'Debian Secure Boot CA: 6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1'
[ 2.204969] Loaded X.509 cert 'Debian Secure Boot Signer 2022 - linux: 14011249c2675ea8e5148542202005810584b25f'
[ 2.213359] integrity: Loading X.509 certificate: UEFI:db
[ 2.213408] integrity: Loaded X.509 cert 'Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4'
[ 2.213410] integrity: Loading X.509 certificate: UEFI:db
[ 2.213435] integrity: Loaded X.509 cert 'Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e4f9ae17c55af53'
[ 2.215204] integrity: Loading X.509 certificate: UEFI:MokListRT (MOKvar table)
[ 2.215485] integrity: Loaded X.509 cert 'Debian Secure Boot CA: 6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1'
[ 2.215487] integrity: Loading X.509 certificate: UEFI:MokListRT (MOKvar table)
[ 2.215745] integrity: Loaded X.509 cert 'user: 7a9d69f5051c39fe7b84587f816603db9499cec6'
[ 2.215746] integrity: Loading X.509 certificate: UEFI:MokListRT (MOKvar table)
[ 2.216001] integrity: Loaded X.509 cert 'Custom MOK: 612c79bd5af57aebc802fb2f51dd54d4c4382d41'
[ 109.634564] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[ 109.634859] cfg80211: Loaded X.509 cert '[email protected]: 577e021cb980e0e820821ba7b54b4961b8b4fadf'
[ 109.635145] cfg80211: Loaded X.509 cert '[email protected]: 3abbc6ec146e09d1b6016ab9d6cf71dd233f0328'
[ 109.635465] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[b]I'm pretty sure it has to do with DKMS, as the Debian Wiki tutorial confused me. [/b]
Some possible causes:
- Cause:: Kernel module was at two different locations. I found this strange situation:
user@debian:~$ sudo ls /lib/modules/
6.1.0-10-amd64 6.1.0-11-amd64
user@debian:~$ sudo ls /var/lib/dkms
user@debian:~$ sudo ls /boot
config-6.1.0-10-amd64 keyfile.gpg
config-6.1.0-11-amd64 lost+found
efi System.map-6.1.0-10-amd64
grub System.map-6.1.0-11-amd64
initrd.img-6.1.0-10-amd64 vmlinuz-6.1.0-10-amd64
initrd.img-6.1.0-11-amd64 vmlinuz-6.1.0-11-amd64
user@debian:~$ sudo modprobe -v rtw_8723du
insmod /lib/modules/6.1.0-11-amd64/kernel/drivers/net/wireless/realtek/rtw88/rtw_usb.ko
modprobe: ERROR: could not insert 'rtw_8723du': Key was rejected by service
Other signated driver "de", much more estrange:
user@debian:~$ sudo modprobe -v rtw_8723de
insmod /lib/modules/6.1.0-11-amd64/kernel/drivers/net/wireless/realtek/rtw88/rtw_pci.ko
insmod /lib/modules/6.1.0-11-amd64/kernel/drivers/net/wireless/realtek/rtw88/rtw_8723de.ko
user@debian:~$ sudo modprobe -v rtw_8723de
????????????SHOW ONLY ONE TIME?????????????????????????
-
Cause: need to create a X.509 key pair (a public key and a corresponding secret key) to use as a MOK.
-
Cause: Error with DKMS
"With the current state of the DKMS package, if a user attempts to install any package that includes a third-party driver (Broadcom WiFi, VirtualBox, v4l2loobpack, etc.), the process of signing the newly built driver with a MOK key will fail silently. This means that any packages and hardware that require third-party drivers are currently unusable on a system with Secure Boot. This bug has been tested and verified to occur with the bcmwl-kernel-source package, but also is very likely to affect any other packages that use DKMS modules."
Its correct to say that "Microsoft screwed this whole MOK stuff up badly" ?
Debian Bug report logs - #989463 please align shim-signed dkms behaviour with Ubuntu
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989463
Thanks !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
random() is an insecure random number generation function
random() is an insecure random number generation function，Is there a safer solution,such as /dev/random
generate_pw_salt (char salt[], const unsigned int salt_size)
{
struct timeval tv;
char *rand_str;
int remain = salt_size;
salt[0] = '\0';
(void) gettimeofday (&tv, NULL);
srandom (tv.tv_sec ^ tv.tv_usec ^ getpid ());
do {
rand_str = l64a (random());
strncat (salt, rand_str, remain);
remain = remain - strlen(rand_str);
} while (remain > 0);
salt[salt_size] = '\0';
}
8bac3f53 mokutil: check the kernel trusted keyring by default
Why is this?
The key is enrolled with shim, not kernel.
The key built into kernel has nothing to do with keys recognized by shim.
Not enrolling the kernel key makes kernel unbootable for typical distribution kernels that are signed with a key that's also built into the kernel.
Cannot re-enable secure boot
I had disabled sometime ago secureboot to get a driver for anbox android emulator working. Now I want to re-enable secureboot. I signed the specific android .ko with kmodsign sha512 using the .priv and .der files in /var/lib/shim-signed/mok/ .
When I re-enabled secureboot in my UEFI settings then try to boot I get an 0x1a error. So I changed the mode to "Audit mode" which seems to be the secure boot check but passes through to boot anyways if it fails, for testing this stuff. its better than the tedium of disabling secure boot, then editing something in Ubuntu, then reboot, re-enable, test, ad-infinitum, etc.
Anyways so as I said, when I try to do a 'mokutil --enable-validation', set a temp password, then reboot, in the blue MOK screen when I try to change secure boot state to enabled, enter the temp password, then I get "Failed to delete secure boot state" then just give up and reboot.
Here are the outputs of two relevant files:
# hexdump -C /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c
00000000 06 00 00 00 00 |.....|
00000005
# hexdump -C /sys/firmware/efi/efivars/SetupMode-8be4df61-93ca-11d2-aa0d-00e098032b8c
00000000 06 00 00 00 01 |.....|
00000005
I had tried mokutil --reset, which seemed to work, and then resetting the db, pk, dbx, kek within my firmware. But I still get similar problem.
Need help
I need help signing a pop os and I get all the way to where I need to reboot but the mok manager doesn't load upon reboot and I'm stumped can anyone help me out
Conflicting types for efi_char16_t
When I try to compile mokutil (current master branch), it fails with the following message:
In file included from efi_hash.h:38,
from efi_hash.c:36:
mokutil.h:42:17: error: conflicting types for 'efi_char16_t'; have 'wchar_t' {aka 'int'}
42 | typedef wchar_t efi_char16_t; /* UNICODE character */
| ^~~~~~~~~~~~
In file included from /usr/include/efivar/efivar.h:21,
from efi_hash.h:36:
/usr/include/efivar/efivar-types.h:50:18: note: previous declaration of 'efi_char16_t' with type 'efi_char16_t' {aka 'short unsigned int'}
50 | typedef uint16_t efi_char16_t;
| ^~~~~~~~~~~~
make[2]: *** [Makefile:415: mokutil-efi_hash.o] Error 1
make[1]: *** [Makefile:419: all-recursive] Error 1
make: *** [Makefile:339: all] Error 2
I think it might have to do with me using musl as my libc implementation, given this bug for mokutil 0.5.0, and that I can successfully compiled it on a glibc system. In any case, the issue is that the definition is different from the definition given by efivar 38. Simply deleting the line with the conflicting definition allows me to compile mokutil without errors.
problem of failed to delete secure boot state
I use HASEE Z8 laptop.When i tried to set secure boot for kail5.10 system,i followed the guide of debian to set it,and it raised a warning: problem of failed to delete secure boot state.
I'm not sure how to fix it.
I am going to uninstall ubuntu, do I need to considering uninstall mok?
I have a laptop try ubuntu system. The drivers are not fit. And now I am trying to uninstall it, the tutorial says assign efi partition a driver name and remove the ubuntu directory, and then I can remove the whole ext partition. I am wondering do I need to do additional steps to remove mok? I have try to search on net, but answers are vague, and I didn't find docs about mok.
build problem
I have raised a issue of problem of failed to delete secure boot state ,and i tried to install latest version to fix it. And it told me that i haven't got efivar, but I'm sure I've installed it(with apt).
feature request: import pe
When writing crappy scripts to export certs using pesign, sed and openssl I realized that having a feature in mokutil that imports certs directly from a pe file would be massively helpful.
The use case is development with eg systemd-boot signed in obs.
Debug "Failed to set SHIM_VERBOSE"
Hi there,
I have an issue I have no idea where to start debugging, and I was hoping you had some hints.
When I try to install the G05 Nvidia drivers on OpenSuse Tumbleweed, trying to enroll the keys causes an error on boot and the computer restarts. The only way to "fix" this is by rolling back to a previously working snapshot. That isn't the point of my question:
If I try to enroll the keys as root, I get the following errors:
localhost:/home/cbr # mokutil --import /var/lib/nvidia-pubkeys/MOK-nvidia-gfxG05-470.199.02-54.8-default.der --root-pw
Failed to enroll new keys
localhost:/home/cbr # mokutil --set-verbosity true
Failed to set SHIM_VERBOSE
Searching for the "shim verbose" error led me to these specific lines: https://github.com/lcp/mokutil/blob/master/src/mokutil.c#L1699-L1701 .
What would be some typical reasons for setting the verbosity to fail ?
Thanks
Key was rejected by service :sob:
Why is this so difficult ?
Could someone give me a little help?
a) The toolset, notably shim, mokutil, dkms, opensll; that comes in distros, not only in Debian, as there are reports that Ubuntu and Fedora seem to be poorly implemented in relation to the linux kernel.
b) The below outlined process does not work and is there a history of bugs with DKMS or is it with the other packages? Or with packages confusion?
c) I'm trying to come up with a synthesis. It seems that I have reached an interesting point that involves system security, but I don't have the technical capacity to deal with it. I'm just an end user.
I'm using Debian 12, I want to enable secure boot and sign a wifi module.
$ uname -a
Linux host 6.1.0-13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.55-1 (2023-09-29) x86_64 GNU/LinuxBUT
- modprobe: ERROR: could not insert 'rtw_8723d': Key was rejected by service``These parameters are too advanced for me:
CONFIG_MODULE_SIG_FORCE
CONFIG_IMA_ARCH_POLICY
Here's an interesting reference:
linux-surface/linux-surface#906
Additional information:
- BUGS:
- • Debian Bug report logs - #1037146 Key was rejected by service
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037146
- • Debian Bug report logs - #1012741 Key was rejected by service
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012741
- • Debian Bug report logs - #1012816 Key was rejected by service
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012816;msg=22
- • Debian Bug report logs - #989463 please align shim-signed dkms behaviour with Ubuntu
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989463
- • Ubuntu Bug #1991725 - dkms package - fails to sign kernel modules
- https://bugs.launchpad.net/ubuntu/+source/dkms/+bug/1991725
- • Debian Bug report logs - #939392 please provide kmodsign like Ubuntu does
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939392
- • Debian Bug report logs - #928300 shim-signed: secure boot via removable media path unavailable
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928300 I made this tutorial to sign the kernel module with sign-file - I follow these steps to sign without DKMS and without script 💪
How to get WiFi Module signed for Secure Boot
Mandatory packages: openssl, sign-file and mokutil.
If you are going to compile the module in the kernel, usually the maintainer will indicate the packages to be installed beforehand. For example, you will need to install "make", "gcc", "kernel headers", "kernel build essentials", and "git".
$ sudo apt get install git make gcc build-essential linux-image-$(uname -r|sed 's,[^-]*-[^-]*-,,') linux-headers-$(uname -r|sed 's,[^-]*-[^-]*-,,')Brief - Sign with Sign-file
1- Install a driver and test without Secure Boot 2- Enable Secure Boot 3- Generate a private and public keys 5- Import 6- Reboot and Enroll 4- Sign the module with sign-file
- Check if secure boot is enabled. When Secure Boot is disabled, the shimx64.efi will just directly load the real grubx64.efi bypassing all the Secure Boot steps, including loading the MOK. With the MOK not loaded, the kernel will have no way to recognize the signature on your module as valid. And with Secure Boot disabled, a signed module with an invalid signature is rejected, while unsigned modules only get a warning and a taint mark on any future oops/panic messages.
$ sudo mokutil --sb-state
SecureBoot enabledYou can create a personal public/private RSA key pair to sign the kernel modules. You can chose to store the key/pair, for example, in the /var/lib/shim-signed/mok/ directory. Then create a new pair of private key (MOK.priv) and public key (MOK.der).
$ sudo mkdir -p /var/lib/shim-signed/mok
$ sudo openssl req -config /usr/lib/ssl/openssl.cnf -new -x509 -newkey rsa:2048 -nodes -days 36500 -outform DER -keyout "/var/lib/shim-signed/mok/MOK.priv" -out "/var/lib/shim-signed/mok/MOK.der" -subj "/CN=MODULE/"
$ ls -l /var/lib/shim-signed/mok/
total 8
-rw-r--r-- 1 root root 779 MOK.der
-rw------- 1 root root 1704 MOK.priv
$ sudo chmod 600 /var/lib/shim-signed/mok/*- Enroll the public key (MOK.der) to MOK (Machine Owner Key) by entering the command:
$ sudo mokutil --import /var/lib/shim-signed/mok/MOK.der
input password:
input password again:Recheck if your key will be prompted on next boot:
$ sudo mokutil --list-new- Reboot and Enroll
The password in this step is a temporary use password you'll only need to remember for a few minutes. Reboot the machine. When the bootloader starts, you should see a screen asking you to press a button to enter the MOK manager EFI utility. Note that any external external keyboards won't work in this step. Select Enroll MOK in the first menu, then continue, and then select Yes to enroll the keys, and re-enter the password established in previous step. Then select OK to continue the system boot.
Steps:
-> "Enroll MOK"
-> "Continue".
-> "Yes".
-> Enter the password you set up just now.
-> Select "OK" and the computer will reboot again.
There are serveral commands to verify if your key "MODULE" is loaded and enrolled
$ sudo mokutil --test-key /var/lib/shim-signed/mok/MOK.der
$ sudo dmesg | grep cert
$ sudo cat /proc/keys | grep MODULE
$ openssl x509 -in /var/lib/shim-signed/mok/MOK.der -inform DER -text -noout- Sign the module with sign-file
Use the same password you used before when setting up MOK for the BIOS to avoid confusion. Make sure you type the password carefully here with no errors, and dont get confused by it just waiting.
$ sudo su
~# read -s KBUILD_SIGN_PINNext export it and sign all modules.
$ sudo su
~# export KBUILD_SIGN_PINNOTE: KBUILD_SIGN_PIN allows a passphrase or PIN to be passed to the sign-file utility when signing kernel modules, if the private key requires such.
For sing the module, depending on your platform, the exact location of sign-file might vary. In Debian 12 (Bookworm) it was in kernel generic /usr/src/linux-kbuild-$(uname -r | cut -d . -f 1-2)/scripts/sign-file .
And where was the module installed? In /lib/modules/$(uname -r)/kernel/drivers/*.ko
$ sudo modinfo -n rtw_8723d
/lib/modules/6.1.0-13-amd64/kernel/drivers/net/wireless/realtek/rtw88/rtw_8723d.koTo sign modules (with your KBUILD_SIGN_PIN), go to the directory containing the modules, and run
$ sudo su
~# cd /lib/modules/6.1.0-13-amd64/kernel/drivers/net/wireless/realtek/rtw88/
~# /usr/src/linux-kbuild-6.1/scripts/sign-file sha256 /var/lib/shim-signed/mok/MOK.priv /var/lib/shim-signed/mok/MOK.der rtw_8723d.koOther not tested form
sudo --preserve-env=KBUILD_SIGN_PIN sh /usr/src/linux-kbuild-$(uname -r | cut -d . -f 1-2)/scripts/sign-file sha256 /var/lib/shim-signed/mok/MOK.priv /var/lib/shim-signed/mok/MOK.der $(modinfo -n rtw_8723d)Assuming you type the password correct, you wont get any errors. You should be able to now see that a module is signed. You can pick any module in that directory but as an example:
$ sudo modinfo rtw_8723d
(...)
signer: MODULE
sig_key: XX:XX:XX:XX:XX:XX:XX:XX...
sig_hashalgo: sha256
signature: XX:XX:XX:XX:XX:XX:XX:XX...
(...)NOTE: Filename may be different just use tab completion to find appropriate file to check some other name.
You could try load the modules
$ modprobe -v rtw_8723dAfter any kernel module loading failure, you should check the dmesg output: it might include a more specific error message. In this case it is likely to indicate that a module signature failed a validity check.
$ sudo dmesg --since -1mIf the modules are needed to boot your machine, make sure to update the initramfs, e.g. using
$ sudo update-initramfs -k all -uOption to Show Current Validation State
Add a --validation-state | -v command line option to show the current shim validation process state (enabled or disabled).
If I understand correctly, the validation state is different than the sb-state; sb-state can be SecureBoot enabled even if the shim validation is disabled (https://askubuntu.com/questions/831574/re-enable-secure-boot-mok-secure-boot).
Please add support for yescrypt
It seems that pam changed the default hashing algorithm to yescrypt, so the --root-pw switch doesn't work on systems using these new defaults (e.g. Debian Bullseye and probably Fedora). It would be nice if you could add support for yescrypt.
Incorrect version info printed with "-v" in 0.7.0
Hi,
I built and installed latest release v0.7.0. However, the version is not updated in configure.ac, resulting in the older version being printed when using the -v command-line option.
$ mokutil -v
0.6.0
mokutil is failing for almost all options
Only some options work like --sb-state or --list-enrolled
Sample results:
--reset
Failed to write MokAuth
Failed to issue a reset request
--password
input password:
input password again:
Failed to write MokPW: Invalid argument
--import MOK.der
input password:
input password again:
Failed to enroll new keys
Does anyone have any suggestions on what I'm doing wrong?
I have Secure Boot enabled correctly and it works but I can't use mokutil well.
I have a HP ENVY 700-310ns:
Intel i7-4790
16GB DDR3
500GB SSD
NVIDIA GeForce GTX 1050 Ti
Entrolled/Signed Nvidia Driver Not Working
I have shim installed I have Secure Boot working and I enrolled my Nvidia driver successfully using mokutil, if I try to enroll Nvidia.der (my key) again with mokutil --import, it tells me that the key is already enrolled and it is going to skip booting into Mok Util screen upon reboot. I tried deleting it and re-enrolling it, and it made no difference.
So the driver is enrolled (and a signed install has been performed e.g sudo sh ./XXXXXX.run -s --module-signing-secret-key=PATH_TO_PRIVATE_KEY --module-signing-public-key=PATH_TO_PUBLIC_KEY). However the Nvidia driver is still not loading (as evident by running nvidia-smi and it telling me it could not connect to the Nvidia driver).
I have tried re-installing it several times, and lsmod | grep nouveau shows nothing (common suggestion)
At one point it did stop showing the message in Mok Util, but nothing changed when I enrolled again, I even tried re-enrolling the hash of my kernel
I also tried using kmodsign for all the Nvidia .ko files
Could this be a bug with mokutil?
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.