Should I enable secure boot after installation of Linux

B

Banky

Member
Joined
Oct 15, 2024
Messages
45
Reaction score
39
Credits
363
Yeah so having to disable secure boot to install Ubuntu on this device, so should I enable secure boot again after installation? I'm sure someone is gone tell me it's my choice but would it be wise to enable or just leave it alone as disabled? Thanks fellas..........
 


Usually not. There is a boot shim that gets installed during the initial installation.
It checks to see if secure boot is enabled or not.

Most always, if you have secure boot disabled during install, the non-secure boot shim gets installed.
If you re-enable secure boot, it likely won't work.

This is easy to test. Enable it and see if it works.
If not, just go back into the BIOS and turn it off again.
 
dos2unix said:
Usually not. There is a boot him that gets installed during the initial installation.
It checks to see if secure boot is enabled or not.

Most always, if you have secue boot disabled during install, the non-secure boot shim gets installed.
If you re-enable secure boot, it likely won't work.

This is easy to test. Enable it and see if it works.
If not, just go back into the BIOS and turn it off again.
Click to expand...
Roja that cap. I'm going to give it a whirl.... Appreciate it.......
 
Not all distributions are secure boot compatible, so check yours is first, then decide if you need secure boot, I have read many articles the past year, some say yes you need it even in Linux, some [slightly more] say you don't need it, so it becomes a personal choice, my choice is I do not have it on any of my machines
 
I use Secure Boot. It verifies that I'm booting what I say I'm booting. So, there's that...

It doesn't do anything more than that. Assuming you're booting what you installed, you'll never hear a peep from it. It may add a millisecond or two to the boot process. I'm okay with that.

Edited to Add: As mentioned above, you really need to enable it before you do the installation. I don't think it's going to be easy/realistic after installation but I haven't tried that.
 
Secure Boot checks the cryptographic signature in the operating system's bootloader to see if it matches a registered key in the UEFI firmware. If a match is found, the boot process proceeds. If Secure Boot cannot verify the boot loader, the system will generate an error and the boot process will halt. Most of today's computers are configured with UEFI firmware.

Administrators can use a Linux distribution in a Hyper-V VM as long as the digital signature of the distribution's boot loader corresponds with a cryptographic key in the UEFI firmware. Currently, the following Linux versions can use Secure Boot in Hyper-V generation 2 VMs

Debian 7.0 and later.
Fedora version 18 and later.
OpenSUSE version 12.3 and later.
Oracle Linux 7.0 and later.
Red Hat Enterprise Linux (RHEL) 7.0 and later.
SUSE Linux Enterprise Server (SLES) 12 and later.
Ubuntu 16.04 and later.

There may be more to this list - these are the ones I know of
 
A very few of our members have played around with UEFI's SecureBoot option, and, indeed; some of them say they like the extra "feeling of security" it gives them. Others say they find it introduces extra complications in getting Puppy up-and-running, so they've gone back to the old methods.

Me, both of my rigs have UEFI. But I can't be arsed with it, for the simple reason that Puppy is

  • Unbelievably easy - and quick! - to back-up, and
  • You can "lose" any session whenever you want to at shutdown, simply by deciding whether to save it or not

It's a personal decision. I simply can't be bothered with all that malarkey. I'm a single user, running a bunch of personal, customized hobbyist distros. Why on EARTH do I need to verify that.....to myself?

It's entirely up to the individual as to whether it's enabled (or not). As yet, it's not "compulsory", so we DO still have choice in the matter.


Mike. o_O
 
Last edited:
Not all distro's support this, but you'll usually see something like this.

root@fedora:/boot# ls -l /boot/efi/EFI/fedora/
total 6688
-rwx------. 1 root root 110 Mar 18 2024 BOOTX64.CSV
-rwx------. 1 root root 159 Nov 13 15:09 grub.cfg
-rwx------. 1 root root 6707 Oct 11 15:36 grub.cfg.rpmsave
-rwx------. 1 root root 4066624 Nov 20 16:00 grubx64.efi
-rwx------. 1 root root 848080 Mar 18 2024 mmx64.efi
-rwx------. 1 root root 949424 Mar 18 2024 shim.efi
-rwx------. 1 root root 949424 Mar 18 2024 shimx64.efi

dnf5 info shim

shim-unsigned-x64.x86_64: First-stage UEFI bootloader
shim-x64.x86_64: First-stage UEFI bootloader

The unsigned one gets installed if secure boot is turned off. By default the "signed" one gets installed
if secure is turned on.

I have noticed one debian based distro at least, will let you turn secure boot off after everything is installed.
However it won't let you install any packages, unless you turn it back on.
 
Here's the thing: Normally the distributions won't ship unsigned and signed components. If a binary is signed but no one checks the signature, it will work anyway.

Edit: Stood corrected by the prior comment. Which logic they follow to install the unsigned shim is something I don't know -- fedora has always been installing the signed one for me regardless the status of the secure boot activation, in three different computers. Maybe is for some weird legacy situations?

So:

  • if you enable secure boot and the computer boots, it means that all the necessary components with regards to the shims comments above are present. I have installed several systems where enabling the secure boot afterwards will work.
  • If it doesn't boot, then you can go back and disable it: failing to boot under secure boot won't delete any of your files.

After booting with secure boot enabled, check for modules that have been rejected by the kernel --if there are any, that means that they are not signed. But you can sign them yourself.
 
Last edited:
gvisoc said:
Which logic they follow to install the unsigned shim is something I don't know -- fedora has always been installing the signed one for me regardless the status of the secure boot activation, in three different computers. Maybe is for some weird legacy situations?
Click to expand...

Are they all the same size? The file name is the same on all my systems. But they are different sizes.
 
I don't know, honestly. It's been a while since I last disabled secure boot. If I can fix the computer whose CPU apparently died a few weeks ago I may try on that one, as it's the oldest computer I've got.
 
If you enable secure boot after kali linux installation the kali linux will not boot because kali linux bootloader and kernal are not signed by default with secure boot while you are in uefi mood
and if you leave it disable and at start up usb enters it will tries to boot from usb and it will currupt your kali linux os installed on intrnal drive
 
Secure Boot was designed by you know who...to stop people installing Linux Distros on the computer the user owns.
1734304839029.gif


Secure Boot is always disabled on my Towers Motherboard which is UEFI...otherwise I can't install Mint.
1734305543713.gif
 
That's not entirely true; many manufacturers are involved in Secure Boot from its inception, and Linux was there from its very early beginning.

What Microsoft did was to require Secure Boot enabled by default and Microsoft signing keys to be included in all Windows 8 certified machines. That led a lot of folks, including myself, to think it was a lock-in strategy, because at that time very few distributions were supporting it, and the notice came before having a consensus with the manufacturers for Secure Boot to be able to be disabled. Luckily for all, everything turned out to be OK.

@bob466 Linux Mint supports Secure Boot since 21.3, so you may not need to disable it if you don't want: https://www.linuxmint.com/rel_virginia_whatsnew.php
 
The reason I have secure boot disabled is because I read that certain processors were vulnerable with secure boot enabled.

I don't know the accuracy of the links I posted or if the vulnerabilities have been patched.

Silent Threat Unveiled: The UEFI Firmware Vulnerability (CVE-2024-0762) – Nagomi Security

nagomi.security nagomi.security

thehackernews.com

Researchers Uncover UEFI Vulnerability Affecting Multiple Intel CPUs

Discover the critical UEFI firmware flaw affecting Intel processors. Learn how to secure your devices against potential cyber threats.
thehackernews.com thehackernews.com
 
The Duck said:
The reason I have secure boot disabled is because I read that certain processors were vulnerable with secure boot enabled.
Click to expand...

Even if some vulnerabilities exist, it's harder to compromise a machine with secure boot than it is to compromise a machine without secure boot.

Think of it as no body armor vs at least level 3 body armor. While level 3 isn't going to stop a round from an AK, it's going to stop you from any (reasonable) pistol caliber. It's not perfect but it's better than relying on your manly chest or jean jacket, both of which won't even stop a .22LR.
 
Last edited:
I’m happy to try, actually, but it may take me a while over the summer break.
 
KGIII said:
Even if some vulnerabilities exist, it's harder to compromise a machine without secure boot than it is to compromise a machine with secure boot.
Click to expand...
I think you wrote it the other way around. Event if some vulnerabilities existed, wouldn’t it be easier to compromise a machine without secure boot?
 
You must log in or register to reply here.

Members online

Total: 636 (members: 5, guests: 631)

Latest posts

Top