help-grub
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Verify the signature of OSes (for SB)


From: Andrei Borzenkov
Subject: Re: Verify the signature of OSes (for SB)
Date: Wed, 22 Nov 2023 13:36:34 +0300

On Wed, Nov 22, 2023 at 1:26 PM Federico Angelilli via Support
requests for the GRand Unified Bootloader <help-grub@gnu.org> wrote:
>
> Thank you, I totally missed that since I used Sasaki's guide.
>
> Could you please confirm if this is the behavior of shim or I have 
> misunderstood something?
> 1) boot to the shim instead of grub (the shim is certified by microsoft)
> 2) boot to grub from the shim (verified using machine owner keys)
> 3) use grub with sbat or windows
>
> But, if this is correct I see a problem. Since I already modified my platform 
> keys I don't really care if the shim is certified by microsoft. Since the 
> uefi loader only verifies the first thing that load (shim if using shim or 
> the signed grub in my case), I expect to be a way to verify a bootable disk 
> after the uefi firmware hands over control to the bootloader.

What is "bootable disk"?

> I don't know if what I said really made sense, but maybe there could be a 
> grub module that checks the signature of kernels just like the firmware does?
>

Yes, there is. And it is using shim services. How many more times do
we need to repeat it?

> Also, now it occurs to me that I signed the kernel but not the kernel 
> modules, and theoretically the kernel should load only signed modules under 
> sb (right?).
>

Kernel supports module signing, but to my best knowledge lockdown
patches are not yet upstream so it is independent of Secure Boot
state. Distributions (like Ubunutu or SUSE) do add patches to their
kernels to enforce loading of only signed modules if Secure Boot is
enabled as well as to import certificates for module verification from
UEFI/MOK.

> So perhaps this entire problem can't be resolved only with a shim?
>
> Regards,
> Federico
>
> On November 22, 2023 10:59:12 AM GMT+01:00, Adam Vodopjan 
> <adam.vodopjan@gmail.com> wrote:
> >There is a dedicated page in the wiki
> >
> >https://wiki.gentoo.org/wiki/Shim
> >
> >
> >On 22/11/2023 07:06, Federico Angelilli wrote:
> >> Hello,
> >> Thanks for responding.
> >>
> >> I am quite sure I am not using a shim lock at all. I simply signed with 
> >> the uefi key the grub image. How would I go about installing a shim? And 
> >> is it necessary?
> >>
> >> Thanks,
> >> Federico
> >>
> >> Ps: I followed a guide on gentoo's wiki
> >>
> >>
> >> On November 22, 2023 12:23:07 AM GMT+01:00, Adam Vodopjan 
> >> <adam.vodopjan@gmail.com> wrote:
> >>
> >>     On 22/11/2023 00:25, Federico Angelilli wrote:
> >>
> >>         Hello, A few months ago I decided to turn on secure boot on my 
> >> dual os desktop, mainly due to some SB related shenanigans in Windows 11. 
> >> After a (fairly long) session of trial and error, I finally got everything 
> >> to work like this: 1) Whenever my kernel is built (I'm using a custom 
> >> kernel) sign it with the right SB key 2) When updating grub, sign it with 
> >> the SB key as well Everything now works: I can boot with SB enabled to 
> >> grub, then I can either choose to use the linux signed kernel or the 
> >> windows chainloader. Except for a small detail: I can boot even from the 
> >> unsigned kernels. While I first thought of it as an error on my 
> >> configuration, I turned out to be a shortcoming in grub itself (as far as 
> >> I understand), that simply cannot verify sb signatures on its own.
> >>
> >>     Have you got shim installed? IIRC grub uses some shim's service to 
> >> verify kernels. So under SB you should boot into shim, not into grub 
> >> directly. There is also the --disable-shim-lock option in grub-mkimage. 
> >> Mby that's your case.
> >>
> >>         So, how can I set up grub in a way that I can: 1) boot with secure 
> >> boot enable to the grub menu 2) only boot from entries that are signed 
> >> themselves Thanks, Federico
> >>
> >



reply via email to

[Prev in Thread] Current Thread [Next in Thread]