You are not logged in.

#1 2014-01-14 21:03:04

date
Member
Registered: 2014-01-14
Posts: 1

Trying to get Secure Boot to work with no luck. Any advice?

Hi,

I have a new Thinkpad T440s which I have been able to install Fedora, Ubuntu, and OpenSUSE on in Secure Boot mode just fine. I have also installed ArchLinux successfully on other systems (though not Secure Boot). What I haven't been able to do is install Arch on this laptop so Secure Boot works.

Where I'm at:

Basic Arch install with 512M EF00 EFI System partition created with gdisk, with rest a root partition. Efivars mounted fine (were already mounted), installed and set up gummiboot, no errors.

Booting EFI Shell from archiso, "bcfg boot dump" shows the "Linux Boot Manager" entry and DevPath to \EFI\gummiboot\gummibootx64.efi, and it shows up in the laptop's boot menu ok.

However, what happens when I try to boot that, I get a box with title "Secure Boot" with text "Image failed to verify with *ACCESS DENIED*. Press any key to continue." with an OK button.

That's it. I've read and read and searched in vain for solutions to no avail. Reinstall and trying GRUB both didn't help.

Should I give up on Secure Boot with Arch (don't want to), or is there something I'm missing?

Thanks!
Eric

Offline

#2 2014-03-28 00:58:34

kjw
Member
Registered: 2014-03-19
Posts: 4

Re: Trying to get Secure Boot to work with no luck. Any advice?

I am really hoping that you found the menu option in the BIOS that disables SecureBoot. My T440s has one, buried in the security tab somwhere.

Offline

#3 2014-03-28 07:48:46

Head_on_a_Stick
Member
From: Asteroid B-612
Registered: 2014-02-20
Posts: 3,660
Website

Re: Trying to get Secure Boot to work with no luck. Any advice?

Secure Boot require a lot of setting up & is complicated --- see this for an overview...
For now, best to disable secure boot from your BIOS options & just use the basic UEFI mode without secure boot.
wink


_0_
__0
000

Offline

#4 2014-03-29 13:59:41

srs5694
Member
From: Woonsocket, RI
Registered: 2012-11-06
Posts: 719
Website

Re: Trying to get Secure Boot to work with no luck. Any advice?

Linux with Secure Boot requires a special boot program that runs before your standard boot loader (or manager). Two are available in the Linux world: Shim and PreLoader. The former is used by default by Fedora, OpenSUSE, Ubuntu, and probably some others. It requires that subsequent boot loaders (usually GRUB, but it can be rEFInd or something else) be signed with a cryptographic key. In many cases, the Linux kernel must also be signed with such a key. Note that gummiboot is incompatible with Shim. PreLoader is used by the Arch installer and it works a bit differently; instead of signing boot loaders with a key, PreLoader requires that follow-on programs and kernels have their hashes registered in the firmware. This is easier to do on a one-time basis but requires frequent additions in the long term (since every kernel will have to be hashed and registered). PreLoader also works with gummiboot.

Another option, which is much harder to implement, is to replace the Secure Boot keys that come with the computer with your own key. You can then sign your boot loaders and/or kernels with your own key, bypassing the need for Shim or Preloader.

Thus, you have four choices:

  • Disable Secure Boot.

  • Install Shim, create your own Secure Boot key, and sign your copy of your boot loader/manager (which must not be gummiboot) and every kernel you install with the key.

  • Install PreLoader and use its HashTool support program to register your boot loader/manager and your kernels with the firmware.

  • Replace the Microsoft keys on the computer with your own keys, which you must then use to sign your boot loader/manager and every kernel you boot.

For more information, see the link that Head_on_a_Stick provided, which is to a page that I wrote on the subject.

Offline

#5 2014-04-04 11:01:57

Infinity
Member
From: EU
Registered: 2013-12-16
Posts: 18

Re: Trying to get Secure Boot to work with no luck. Any advice?

srs5694 wrote:

Another option, which is much harder to implement, is to replace the Secure Boot keys that come with the computer with your own key. You can then sign your boot loaders and/or kernels with your own key, bypassing the need for Shim or Preloader.

Thanks, this is an important piece of information I was looking for.
So technically you can install your own keys, and sign the boot stuff with one of them. This will theoretically prevent an attacker from replacing and/or modifying a part of the boot procedure, and run malicious code. However what if an attacker was to also replace the secure boot keys with his own, and sign the malicious kernel with it? Is there a way to prevent secure boot keys from modification, once they are installed?

Offline

#6 2014-04-04 12:19:01

progandy
Member
Registered: 2012-05-17
Posts: 2,146

Re: Trying to get Secure Boot to work with no luck. Any advice?

Infinity wrote:
srs5694 wrote:

Another option, which is much harder to implement, is to replace the Secure Boot keys that come with the computer with your own key. You can then sign your boot loaders and/or kernels with your own key, bypassing the need for Shim or Preloader.

Thanks, this is an important piece of information I was looking for.
So technically you can install your own keys, and sign the boot stuff with one of them. This will theoretically prevent an attacker from replacing and/or modifying a part of the boot procedure, and run malicious code. However what if an attacker was to also replace the secure boot keys with his own, and sign the malicious kernel with it? Is there a way to prevent secure boot keys from modification, once they are installed?

In a proper security model, the certificates are stored in the EFI flash-rom. Then you set up an EFI password which is needed to change EFI settings like the certificates, secure boot, and boot order. This password is also stored in EFI flash storage. This is pretty secure since you need special hardware to modify the data in the flash chips.
The default secure boot setup with microsoft root keys works the same, it is just microsoft who ultimately controls what you can boot. Microsoft then allows shim, shim stores and reads its own certificates from the EFI flash and then checks and allows gummiboot, refind or a kernel. Replacing the root certificate makes you the sole person responsible for the boot process.

Last edited by progandy (2014-04-04 12:19:37)

Online

#7 2014-04-10 18:25:17

Infinity
Member
From: EU
Registered: 2013-12-16
Posts: 18

Re: Trying to get Secure Boot to work with no luck. Any advice?

progandy wrote:

In a proper security model, the certificates are stored in the EFI flash-rom. Then you set up an EFI password which is needed to change EFI settings like the certificates, secure boot, and boot order. This password is also stored in EFI flash storage. This is pretty secure since you need special hardware to modify the data in the flash chips.

Let me guess... SOIC-8 clips, a SPI programmer like BusPirate, and flashrom. I have all three.

Offline

#8 2014-04-10 18:46:22

progandy
Member
Registered: 2012-05-17
Posts: 2,146

Re: Trying to get Secure Boot to work with no luck. Any advice?

Infinity wrote:
progandy wrote:

In a proper security model, the certificates are stored in the EFI flash-rom. Then you set up an EFI password which is needed to change EFI settings like the certificates, secure boot, and boot order. This password is also stored in EFI flash storage. This is pretty secure since you need special hardware to modify the data in the flash chips.

Let me guess... SOIC-8 clips, a SPI programmer like BusPirate, and flashrom. I have all three.

If someone has hardware access, he could also replace the whole mainboard, so you'll have to use e.g. a lockbox to prevent physical access to the data.
So: Encrypt your disk, sign your unencrypted boot files, protect EFI modifications with a password, lock critical hardware away. Only expose well-defined interfaces.
... Oh, and protect cables against hardware keyloggers, regularily remove the camera above your keyboard, keep away microphones which could identify keystrokes, ...
PS: I believe we are a bit OT here.

Online

Board footer

Powered by FluxBB