update-secureboot-policy runs at startup and burns CPU

[Jacob Cram]

I am running Ubuntu 18.04 on a lenovo Thinkpad T490s. I enabled full disk encryption when I installed Ubuntu. I found that the computer ran hot and that a process was always running and using 50% of the available CPU, presumably taking one core. That process was

`/usr/bin/perl -w /usr/share/debconf/frontend /usr/sbin/update-secureboot-policy --enroll-key`

This process appears to be the same as the one described in this stack exchange post

https://superuser.com/questions/1493050/update-secureboot-policy-enroll-key-running-on-every-new-startup-eating-reso

I found that, as suggested by user931000 I could disable Secure Boot in UEFI settings to fix the behavior. I am not sure if this poses any security risk however, and find that secure boot has a way of turning itself on, at least with updates that I installed today on 31 January 2020. I think this is a bug and that CPU hogging processes should not run every time out of the box.

This issue might be related to this other issue, for which a fix is apparently released, but which doesn't appear to be helping in my case.
https://bugs.launchpad.net/ubuntu/+source/shim-signed/+bug/1673817

1) Ubuntu 18.04.4 LTS
2) Don't know the relevant package
3) I expect that Ubuntu should start up and run without a process burning all of the CPU, even if I enable disk encryption, and even if secureboot is enabled.
4) I have to choose between having a CPU hogging process turn on every time, turning off Secure Boot (while continuing to turn it off when updates re-turn off secure boot) and not encrypting my hard drive.

[Ubuntu Foundations Team Bug Bot (crichton)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1861530/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

[Steve Langasek (vorlon)]

Thanks for reporting this bug and helping to improve Ubuntu.

The normal point at which this command would be run is as part of the package update process from a running session, under apt. Do you remember being prompted on a previous package manager run to set a password for registering your machine-owner key in firmware?

To diagnose why this is running at startup, it would be helpful to see the heirarchy of processes before this command (so 'pstree' or similar). That should also give us information about the environment it's running in, to determine why it's in a busy loop.

While disabling Secure Boot in your firmware will work around this runtime error, it does weaken the security of your system and is not recommended as a long-term solution.

My guess at what's happening here is that since you have dkms module packages installed but the binaries from them have not been successfully installed for the current kernel, dkms is trying to build these at boot, sign them, and enroll the key in firmware; but the enrollment fails due to lack of frontend.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.