[Bug 1869187] Re: mokutil ignores timeout parameter
Matthieu Clemenceau
1869187 at bugs.launchpad.net
Fri Jul 24 13:52:48 UTC 2020
** Description changed:
+ This section is for Bionic SRU purpose
+
+ [Impact]
+ Because mokutil ignores the timeout parameter in /usr/sbin/update-secureboot-policy
+ it becomes impossible to sign dkms-built modules with secure boot enable
+
+ [Test Case]
+ With a bionic with secureboot enabled (tested in a VM)
+ Make sure Secure Boot is enable (should return : SecureBoot enabled)
+ # mokutil --sb-state
+
+ Then install a dkms driver
+ # sudo apt install fwts-efi-runtime-dkms
+ This should prompt mok manager menu to setup Secure Boot password
+ The key details will be under
+ # mokutil --list-new
+ # reboot
+
+ Without the patch nothing happen upon reboot. System boots fully
+ and the driver isn't installed
+
+ With the solution installed, a menu will pop up on reboot to enroll the key
+ Once the key is enrolled it will show up under
+ # mokutil --list-enrolled
+
+
+ [Regression Potential]
+ This change is fairly minimal and has been shipping with Focal.
+ Possible regression could involve inability to sign other drivers.
+
+ End SRU
+ ------
+
Version info:
Description: Ubuntu Focal Fossa (development branch)
Release: 20.04
Done upgrade and dist-upgrade on March 26th, just before reporting this.
mokutil:
- Installed: 0.3.0+1538710437.fb6250f-1
+ Installed: 0.3.0+1538710437.fb6250f-1
dkms:
- Installed: 2.8.1-5ubuntu1
+ Installed: 2.8.1-5ubuntu1
shim-signed:
- Installed: 1.41+15+1552672080.a4a1fbe-0ubuntu1
+ Installed: 1.41+15+1552672080.a4a1fbe-0ubuntu1
Dell precision M3800, secure boot on (obviously)
The backstory of it, is that in development version of 20.04 it became impossible to sign dkms-built modules with secure-boot enabled. The ncurses-based interfaces opens normally and prompts for the password twice (as usual), but after reboot the key-enrollment menu does not appear. After comparing all the packages involved into this process with the ones from 19.04, I managed to pinpoint the culprit, namely:
/usr/sbin/update-secureboot-policy, lines 111 and 120 call mokutil with timeout parameter.
Removing that argument like this:
111c111
< printf '%s\n%s\n' "$key" "$again" | mokutil --enable-validation >/dev/null || true
---
> printf '%s\n%s\n' "$key" "$again" | mokutil --timeout -1 --enable-validation >/dev/null || true
120c120
< printf '%s\n%s\n' "$key" "$again" | mokutil --import "$SB_KEY" >/dev/null || true
---
> printf '%s\n%s\n' "$key" "$again" | mokutil --timeout -1 --import "$SB_KEY" >/dev/null || true
fixes the problem, yet to me it does not eliminate its root cause.
Picking up those trails, I decided to fiddle with mokutil itself. In my case, adding any --timeout param (not only -1, but any integer really) triggers it to display help/usage message, nothing more. For that reason I am quite convinced that my actions related to update-secureboot-policy script are merely a workaround, while mokutil is the actual source of the problem.
-
- I am fully aware, that: https://bugs.launchpad.net/ubuntu/+source/shim-signed/+bug/1856422 is a design decision, and I know why it was introduced. Yet, in case of my machine (several other ones to be checked soon) it breaks the signing process completely.
+ I am fully aware, that: https://bugs.launchpad.net/ubuntu/+source/shim-
+ signed/+bug/1856422 is a design decision, and I know why it was
+ introduced. Yet, in case of my machine (several other ones to be checked
+ soon) it breaks the signing process completely.
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: mokutil 0.3.0+1538710437.fb6250f-1
ProcVersionSignature: Ubuntu 5.4.0-18.22-generic 5.4.24
Uname: Linux 5.4.0-18-generic x86_64
ApportVersion: 2.20.11-0ubuntu21
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Thu Mar 26 12:08:06 2020
InstallationDate: Installed on 2020-03-16 (9 days ago)
InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Alpha amd64 (20200316)
SourcePackage: mokutil
UpgradeStatus: No upgrade log present (probably fresh install)
** Description changed:
- This section is for Bionic SRU purpose
-
- [Impact]
+ This section is for Bionic SRU purpose
+
+ [Impact]
Because mokutil ignores the timeout parameter in /usr/sbin/update-secureboot-policy
- it becomes impossible to sign dkms-built modules with secure boot enable
-
- [Test Case]
- With a bionic with secureboot enabled (tested in a VM)
- Make sure Secure Boot is enable (should return : SecureBoot enabled)
- # mokutil --sb-state
-
- Then install a dkms driver
- # sudo apt install fwts-efi-runtime-dkms
- This should prompt mok manager menu to setup Secure Boot password
- The key details will be under
- # mokutil --list-new
- # reboot
-
- Without the patch nothing happen upon reboot. System boots fully
- and the driver isn't installed
-
- With the solution installed, a menu will pop up on reboot to enroll the key
- Once the key is enrolled it will show up under
- # mokutil --list-enrolled
-
-
- [Regression Potential]
- This change is fairly minimal and has been shipping with Focal.
- Possible regression could involve inability to sign other drivers.
-
- End SRU
- ------
+ it becomes impossible to sign dkms-built modules with secure boot enable
+
+ [Test Case]
+ With a bionic with secureboot enabled (tested in a VM)
+ Make sure Secure Boot is enable (should return : SecureBoot enabled)
+ # mokutil --sb-state
+
+ Then install a dkms driver
+ # sudo apt install fwts-efi-runtime-dkms
+ This should prompt mok manager menu to setup Secure Boot password
+ The key details will be under
+ # mokutil --list-new
+ # reboot
+
+ Without the patch nothing happen upon reboot. System boots fully
+ and the driver isn't installed
+
+ With the solution installed, a menu will pop up on reboot to enroll the key
+ Once the key is enrolled it will show up under
+ # mokutil --list-enrolled
+
+ [Regression Potential]
+ This change is fairly minimal and has been shipping with Focal.
+ Possible regression could involve inability to sign other drivers.
+
+ [Other Info]
+ It appears the issue describe here happens in bionic-proposed rather than bionic-updates. This is resolved with shim-signed 1.37~18.04.6
+
+ End SRU
+ ------
Version info:
Description: Ubuntu Focal Fossa (development branch)
Release: 20.04
Done upgrade and dist-upgrade on March 26th, just before reporting this.
mokutil:
Installed: 0.3.0+1538710437.fb6250f-1
dkms:
Installed: 2.8.1-5ubuntu1
shim-signed:
Installed: 1.41+15+1552672080.a4a1fbe-0ubuntu1
Dell precision M3800, secure boot on (obviously)
The backstory of it, is that in development version of 20.04 it became impossible to sign dkms-built modules with secure-boot enabled. The ncurses-based interfaces opens normally and prompts for the password twice (as usual), but after reboot the key-enrollment menu does not appear. After comparing all the packages involved into this process with the ones from 19.04, I managed to pinpoint the culprit, namely:
/usr/sbin/update-secureboot-policy, lines 111 and 120 call mokutil with timeout parameter.
Removing that argument like this:
111c111
< printf '%s\n%s\n' "$key" "$again" | mokutil --enable-validation >/dev/null || true
---
> printf '%s\n%s\n' "$key" "$again" | mokutil --timeout -1 --enable-validation >/dev/null || true
120c120
< printf '%s\n%s\n' "$key" "$again" | mokutil --import "$SB_KEY" >/dev/null || true
---
> printf '%s\n%s\n' "$key" "$again" | mokutil --timeout -1 --import "$SB_KEY" >/dev/null || true
fixes the problem, yet to me it does not eliminate its root cause.
Picking up those trails, I decided to fiddle with mokutil itself. In my case, adding any --timeout param (not only -1, but any integer really) triggers it to display help/usage message, nothing more. For that reason I am quite convinced that my actions related to update-secureboot-policy script are merely a workaround, while mokutil is the actual source of the problem.
I am fully aware, that: https://bugs.launchpad.net/ubuntu/+source/shim-
signed/+bug/1856422 is a design decision, and I know why it was
introduced. Yet, in case of my machine (several other ones to be checked
soon) it breaks the signing process completely.
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: mokutil 0.3.0+1538710437.fb6250f-1
ProcVersionSignature: Ubuntu 5.4.0-18.22-generic 5.4.24
Uname: Linux 5.4.0-18-generic x86_64
ApportVersion: 2.20.11-0ubuntu21
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Thu Mar 26 12:08:06 2020
InstallationDate: Installed on 2020-03-16 (9 days ago)
InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Alpha amd64 (20200316)
SourcePackage: mokutil
UpgradeStatus: No upgrade log present (probably fresh install)
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to mokutil in Ubuntu.
Matching subscriptions: mokutil-bugs
https://bugs.launchpad.net/bugs/1869187
Title:
mokutil ignores timeout parameter
Status in mokutil package in Ubuntu:
Confirmed
Status in shim-signed package in Ubuntu:
Fix Released
Status in mokutil source package in Bionic:
New
Status in shim-signed source package in Bionic:
New
Status in mokutil source package in Eoan:
Won't Fix
Status in shim-signed source package in Eoan:
Won't Fix
Status in mokutil source package in Focal:
Confirmed
Status in shim-signed source package in Focal:
Fix Released
Bug description:
This section is for Bionic SRU purpose
[Impact]
Because mokutil ignores the timeout parameter in /usr/sbin/update-secureboot-policy
it becomes impossible to sign dkms-built modules with secure boot enable
[Test Case]
With a bionic with secureboot enabled (tested in a VM)
Make sure Secure Boot is enable (should return : SecureBoot enabled)
# mokutil --sb-state
Then install a dkms driver
# sudo apt install fwts-efi-runtime-dkms
This should prompt mok manager menu to setup Secure Boot password
The key details will be under
# mokutil --list-new
# reboot
Without the patch nothing happen upon reboot. System boots fully
and the driver isn't installed
With the solution installed, a menu will pop up on reboot to enroll the key
Once the key is enrolled it will show up under
# mokutil --list-enrolled
[Regression Potential]
This change is fairly minimal and has been shipping with Focal.
Possible regression could involve inability to sign other drivers.
[Other Info]
It appears the issue describe here happens in bionic-proposed rather than bionic-updates. This is resolved with shim-signed 1.37~18.04.6
End SRU
------
Version info:
Description: Ubuntu Focal Fossa (development branch)
Release: 20.04
Done upgrade and dist-upgrade on March 26th, just before reporting this.
mokutil:
Installed: 0.3.0+1538710437.fb6250f-1
dkms:
Installed: 2.8.1-5ubuntu1
shim-signed:
Installed: 1.41+15+1552672080.a4a1fbe-0ubuntu1
Dell precision M3800, secure boot on (obviously)
The backstory of it, is that in development version of 20.04 it became impossible to sign dkms-built modules with secure-boot enabled. The ncurses-based interfaces opens normally and prompts for the password twice (as usual), but after reboot the key-enrollment menu does not appear. After comparing all the packages involved into this process with the ones from 19.04, I managed to pinpoint the culprit, namely:
/usr/sbin/update-secureboot-policy, lines 111 and 120 call mokutil with timeout parameter.
Removing that argument like this:
111c111
< printf '%s\n%s\n' "$key" "$again" | mokutil --enable-validation >/dev/null || true
---
> printf '%s\n%s\n' "$key" "$again" | mokutil --timeout -1 --enable-validation >/dev/null || true
120c120
< printf '%s\n%s\n' "$key" "$again" | mokutil --import "$SB_KEY" >/dev/null || true
---
> printf '%s\n%s\n' "$key" "$again" | mokutil --timeout -1 --import "$SB_KEY" >/dev/null || true
fixes the problem, yet to me it does not eliminate its root cause.
Picking up those trails, I decided to fiddle with mokutil itself. In my case, adding any --timeout param (not only -1, but any integer really) triggers it to display help/usage message, nothing more. For that reason I am quite convinced that my actions related to update-secureboot-policy script are merely a workaround, while mokutil is the actual source of the problem.
I am fully aware, that: https://bugs.launchpad.net/ubuntu/+source
/shim-signed/+bug/1856422 is a design decision, and I know why it was
introduced. Yet, in case of my machine (several other ones to be
checked soon) it breaks the signing process completely.
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: mokutil 0.3.0+1538710437.fb6250f-1
ProcVersionSignature: Ubuntu 5.4.0-18.22-generic 5.4.24
Uname: Linux 5.4.0-18-generic x86_64
ApportVersion: 2.20.11-0ubuntu21
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Thu Mar 26 12:08:06 2020
InstallationDate: Installed on 2020-03-16 (9 days ago)
InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Alpha amd64 (20200316)
SourcePackage: mokutil
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mokutil/+bug/1869187/+subscriptions
More information about the foundations-bugs
mailing list