A while ago, I had to disable Secure Boot in UEFI in order to install a third-party driver.

Now that this third-party driver isn't required anymore (due to kernel updates), I have uninstalled it.

Having removed that unsigned driver, I thought it might be a good idea now to enable Secure Boot again. Is it? Or could malware have caused damage in the meantime, e.g. adding new Secure Boot keys, so that Secure Boot is not "secure" anymore after it has been disabled once?

  • @ElderGeek Thanks! This question assumes that it is. Otherwise, this question is futile, of course.
    – caw
    Nov 21, 2016 at 17:58
  • @ElderGeek : Generally it is a matter of opinion in the case of Linux systems. Both ways are more or less secure, so it is up to every user to decide which option to choose. Most important is to select the correct boot loader for making the system bootable when changing the boot version (please see my answer). :)
    – cl-netbox
    Nov 21, 2016 at 18:45
  • @ElderGeek : That's what I meant - "Re-enabling Secure boot in and of itself doesn't present any additional risk ...", so the user is safe to turn it back on again when he wants to do it. :)
    – cl-netbox
    Nov 22, 2016 at 7:28
  • @ElderGeek Thanks! The question was not whether "[r]e-enabling Secure boot in and of itself [...] present[s] any additional risk" but rather whether disabling it in the first places presents any security risk that renders re-enabling it later useless (due to potential modifications to keys, etc. done by malware in the meantime).
    – caw
    Nov 23, 2016 at 0:42
  • @ElderGeek As per bugs.launchpad.net/ubuntu/+source/grub2/+bug/1401532 the main issue with Secure Boot seems to have been fixed now. That means Secure Boot does not silently fall back to loading unsigned kernels anymore.
    – caw
    Apr 8, 2017 at 16:40

2 Answers 2


Yes, you can safely re-enable Secure Boot. It is very unlikely that something has been damaged.
Afterwards change the default boot loader from grubx64.efi to shimx64.efi in BIOS | UEFI.
Otherwise Ubuntu tries to boot with the unsigned boot loader - which of course does not work.
Alternatively you can do it before changing the Secure Boot settings with built-in efibootmgr:

To list the currently active boot loader files - execute this command : sudo efibootmgr -v
Change the boot order by running sudo efibootmgr -o XXXX,YYYY (X,Y = entry number)
In case shimx64.efi is not listed, you can add it by executing (X = disk | Y = EFI partition) :
sudo efibootmgr -c -w -d /dev/sdXY -p 1 -L "ubuntu" -l '\EFI\ubuntu\shimx64.efi

  • Thanks for your answer! Do I really have to change the boot loader? I've never touched that setting at all, and running sudo efibootmgr -v tells me that ubuntu HD(1,GPT,...)/File(\EFI\ubuntu\shimx64.efi) is the first entry in the boot order. So shouldn't I be able to switch Secure Boot on and off without changing the boot loader?
    – caw
    Nov 21, 2016 at 19:27
  • @caw Yes, you can (if it fails to boot you can always turn it off again), but honestly there's no Ubuntu benefit ATM...
    – Elder Geek
    Nov 22, 2016 at 2:54
  • 1
    @caw : As the output of sudo efibootmgr -v shows that shimx64.efi already is the first entry in the boot order, you don't have to change anything regarding the boot loader when you switch on Secure Boot. :)
    – cl-netbox
    Nov 22, 2016 at 7:19

I wouldn't bother. Re-enabling Secure boot won't improve your Ubuntu security in any measurable way (although if it makes you feel better, I don't perceive any harm in doing so).

If you do want to re-enable it you should subscribe to this bug and wait until the bug is fixed as prior to that you are accomplishing nothing from an Ubuntu perspective.

Edit: The aforementioned bug has been reported fixed as of 30 Mar 2017 17:45:23 in the package grub2 - 2.02~beta3-4ubuntu2

and also in the package grub2-signed - 1.80 as of 04 Apr 2017 10:28:34

The deb file (created for Zesty) is available here. Since you are running Xenial, it might be safest to wait for a package developed specifically for your release (or at the very least create a current backup ) to avoid any unexpected consequences brought about by installing a .deb designed for Zesty on a Xenial system.

  • Thanks for pointing to the bug report that I should subscribe to. However, I'm a bit confused because you said Secure Boot doesn't improve security in any (measurable) way and is just for a "good feeling". I assume you base that statement on the existence of that bug described in the report. Is that true? So if that bug is fixed, it will provide measurable advantages to security, right?
    – caw
    Nov 23, 2016 at 0:44
  • What I said was I wouldn't bother as re-enabling it currently won't have the effect you seem to desire. It would seem that if the bug is fixed, loading an unsigned kernel without warning will no longer be a concern. If/when this is the case there are still no guarantees. Nothing can prevent operator error for example, and you are still placing your trust in those who built and signed the kernel.
    – Elder Geek
    Nov 23, 2016 at 13:57
  • The bug in question has apparently been fixed now: bugs.launchpad.net/ubuntu/+source/grub2/+bug/1401532 That would mean Secure Boot does not silently fall back to loading unsigned kernels anymore. Thus, Secure Boot should be an effective security measure with Ubuntu now.
    – caw
    Apr 8, 2017 at 16:43
  • @caw Yes, a fix has been released for Zesty. See my updated answer.
    – Elder Geek
    Apr 8, 2017 at 21:58
  • 1
    There's news again in that issue, this time bad news: The status has been reverted from "Fix Released" to "Triaged", which is explained here. A little messy!
    – caw
    Apr 11, 2017 at 1:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.