You are not logged in.

#1 2015-03-24 23:37:53

belette
Member
Registered: 2014-11-17
Posts: 121

Secure Boot UEFI best practices - signing kernel

Hi,

I read lot of articles regarding Secure Boot.
Just want to know if someone has successfully make an Arch installation with secure boot enabled?
I have been able to boot on the Arch installation iso but I would like to know how to sign the Arch kernel after the installation?

In term of security, I have read lot of contradictory articles where secure boot is not adding a lot of security...
I have the option to disable on my BIOS, and the option to activate it + add cystom keys, I would like to be able to generate custom keys and upload into my BIOS (if this provides some enhanced security features, but I am still not sure)

Any clarification is welcomed smile

Many thanks

belette

Offline

#2 2015-03-25 19:12:11

teateawhy
Member
From: GER
Registered: 2012-03-05
Posts: 1,138
Website

Re: Secure Boot UEFI best practices - signing kernel

belette wrote:

I read lot of articles regarding Secure Boot.
In term of security, I have read lot of contradictory articles where secure boot is not adding a lot of security...

For starters, make sure to use full system encryption, it's the first step for physical security.
I think you will find the research done here
http://www.legbacore.com/Research.html
interesting.
I can't help you with getting secure boot on arch running though.

Offline

#3 2015-03-25 21:17:33

Head_on_a_Stick
Member
From: The Wirral
Registered: 2014-02-20
Posts: 8,778
Website

Re: Secure Boot UEFI best practices - signing kernel

I have tried several times now but I cannot get my signed kernel images to boot; the self-generated keys are all enrolled into my firmware AFAICT so I'm assuming it's just down to my crappy firmware...

I followed this guide in my attempts:
http://kroah.com/log/blog/2013/09/02/bo … nux-kernel


Jin, Jîyan, Azadî

Offline

#4 2015-03-30 19:38:32

mcloaked
Member
From: Yorkshire, UK
Registered: 2012-02-02
Posts: 1,279

Re: Secure Boot UEFI best practices - signing kernel


Mike C

Offline

#5 2015-03-30 21:02:06

ewaller
Administrator
From: Pasadena, CA
Registered: 2009-07-13
Posts: 20,348

Re: Secure Boot UEFI best practices - signing kernel

Head_on_a_Stick wrote:

I have tried several times now but I cannot get my signed kernel images to boot; the self-generated keys are all enrolled into my firmware AFAICT so I'm assuming it's just down to my crappy firmware...

I followed this guide in my attempts:
http://kroah.com/log/blog/2013/09/02/bo … nux-kernel

Interesting article.  I'll have to try it when my new laptop shows up (my first EFI machine)    Can you get the unsigned kernel to boot in unsecure mode as the article suggests?
From my reading of the article, it is probably best to build a custom kernel with everything it needs to boot and not use an initrd.  That is actually fairly easy to do and sounds cleaner than lashing the initrd to the side of the kernel.


Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way

Offline

#6 2015-03-30 21:13:52

Head_on_a_Stick
Member
From: The Wirral
Registered: 2014-02-20
Posts: 8,778
Website

Re: Secure Boot UEFI best practices - signing kernel

ewaller wrote:

Can you get the unsigned kernel to boot in unsecure mode as the article suggests?

I must admit that I didn't try that before...

I've just tried it now and it wouldn't boot; the PARTUUID wasn't found and there was no keyboard input which suggests that it is not loading the initial ramdisk.

I think you are right -- when I have the time I will try it with a "huge" kernel (as Slackware puts it) and no initramfs

EDIT: Tried to boot using "root=/dev/sda2" and it again dropped me to the rescue shell with no keyboard and "/dev/sda2 not found" so the initrd isn't being loaded.

I might try re-compiling the `sbsign` program; the version I have is quite old.

Last edited by Head_on_a_Stick (2015-03-30 21:35:11)


Jin, Jîyan, Azadî

Offline

#7 2015-03-30 21:44:27

ewaller
Administrator
From: Pasadena, CA
Registered: 2009-07-13
Posts: 20,348

Re: Secure Boot UEFI best practices - signing kernel

In truth, a kernel with the things you need to boot need not be "huge" .  By building a kernel that is custom to your machine, you only need the drivers to be built in to the kernel that your system needs.  Were they modules, they would have to be in the initrd anyway, along with all of the modules that others may need to boot for which your machine has no use.   Things like video drivers, files systems, and disk interfaces you don't have versus those you do.    After boot, you can still use modules that are in your root, so it is not like you need to compile everything in.  Generally, when I build a kernel I build in all of the drivers for the things that are physically part of my computer.   Things that can be attached and detached (USBs, file systems for volumes that are not in fstab, pcmcia devices, etc) are left as modules so they don't use resources when they are not being used.

Edit:  The Gentoo handbook is my go to reference on how to configure a kernel that does not require an initrd.

Last edited by ewaller (2015-03-30 21:45:34)


Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way

Offline

#8 2015-03-31 18:17:58

Head_on_a_Stick
Member
From: The Wirral
Registered: 2014-02-20
Posts: 8,778
Website

Re: Secure Boot UEFI best practices - signing kernel

Update: for anybody following this thread, ignore my nonsense in post #6 -- I was trying to boot an old signed kernel image that did not match the initrd so that's why it wasn't loading...

I have just tried with a signed copy of the current kernel & it does boot up without Secure Boot but fails with Secure Boot enabled; I tried a direct NVRAM entry (using `efibootmgr`) so there was no boot loader/manager involved.

When I have some free time, I will try again using the latest git-pull of `sbsign` and if that doesn't work I will try compiling a custom kernel image as suggested by @ewaller

Watch this space!
smile


Jin, Jîyan, Azadî

Offline

Board footer

Powered by FluxBB