grub-devel
[Top][All Lists]
Advanced

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

Re: [PATCH] Add chainloaded image as shim's verifiable object


From: Dimitri John Ledkov
Subject: Re: [PATCH] Add chainloaded image as shim's verifiable object
Date: Fri, 5 Mar 2021 13:49:00 +0000

On Fri, Mar 5, 2021 at 1:34 PM Michael Chang <mchang@suse.com> wrote:
>
> On Fri, Mar 05, 2021 at 12:21:49PM +0000, Dimitri John Ledkov wrote:
> > This is not an oversight but intentional.
> >
> > Currently there is no chainloader support with SBAT as further
> > development is required to ensure policy is applied correctly. Once
> > SBAT support for chainloading is defined, it will be introduced.
>
> Hm. What I heard is that shim wouldn't enfore SBAT validation for the
> "indirect" image loaded by grub for now. So we should still able to
> boot, eg, kernel and other efi image loaded by grub which is still in
> lacking of SBAT support.
>

There is a difference between chainloading a new bootloader, or
booting a linux kernel.
When chainloading a different grub that is verified by the vendor-db
in shim, sbat should be enforced, if the current grub has sbat.
When chainloading windows bootmgr, which is signed by things in db,
sbat need not be enforced.

It is a delicate balance to strike, as otherwise one can do sbat
bypass via downgrading to older grub via chainload.

I would recommend to add windowsbootmgr efi entry, and then perform
`exit 1` such that this current shim+grub exit, and firmware goes to
load the next entry for windows. For `exit 1` support you need
https://github.com/rhboot/grub2/commit/ccce3d69ae3eacc7bdc70217304586bd7e74fe1e
too.

I understand that this is very suboptimal. I kind of wish grub2 could
generate and display EFI boot entries, and then let people select them
which would set it as BootNext and reset. Cause then one would truly
be able to jump to a specific boot menu entry from grub menu.

I also need chainloader support elsewhere, thus at the moment we are
not shipping 2.06rc1 and instead are shipping 2.04 with backports of
patches.


> > And yes it is intended to continue to allow "boot windows" as the menu
> > entry in grub.
>
> So what is recommended solution in the interim ? We just can't afford
> to release new grub version that cannot do the chainload ...
>
> Thanks,
> Michael
>
> >
> > On Fri, Mar 5, 2021 at 12:12 PM Michael Chang via Grub-devel
> > <grub-devel@gnu.org> wrote:
> > >
> > > While attempting to dual boot Microsoft Windows with efi chainloader, it
> > > failed with below error when secure boot was enabled.
> > >
> > > error ../../grub-core/kern/verifiers.c:119:verification requested but
> > > nobody cares: /EFI/Microsoft/Boot/bootmgfw.efi.
> > >
> > > It is a regression, as previously it worked without problem.
> > >
> > > It turns out chainloading image has been locked down introduced by
> > >
> > > 578c95298 kern: Add lockdown support
> > >
> > > However we should consider it as verifiable object to shim to allow
> > > booting in secure boot enabled mode. The chainloaded image could also
> > > have trusted signature signed by vendor with their pubkey cert in db.
> > > For that matters it's usage should not be locked down in secure boot,
> > > and instead use shim to validate it's signature before running it.
> > >
> > > Signed-off-by: Michael Chang <mchang@suse.com>
> > > ---
> > >  grub-core/kern/efi/sb.c   | 1 +
> > >  grub-core/kern/lockdown.c | 1 -
> > >  2 files changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/grub-core/kern/efi/sb.c b/grub-core/kern/efi/sb.c
> > > index 41dadcd14..96d237722 100644
> > > --- a/grub-core/kern/efi/sb.c
> > > +++ b/grub-core/kern/efi/sb.c
> > > @@ -129,6 +129,7 @@ shim_lock_verifier_init (grub_file_t io __attribute__ 
> > > ((unused)),
> > >      case GRUB_FILE_TYPE_BSD_KERNEL:
> > >      case GRUB_FILE_TYPE_XNU_KERNEL:
> > >      case GRUB_FILE_TYPE_PLAN9_KERNEL:
> > > +    case GRUB_FILE_TYPE_EFI_CHAINLOADED_IMAGE:
> > >        *flags = GRUB_VERIFY_FLAGS_SINGLE_CHUNK;
> > >
> > >        /* Fall through. */
> > > diff --git a/grub-core/kern/lockdown.c b/grub-core/kern/lockdown.c
> > > index 0bc70fd42..e1fd1c1e2 100644
> > > --- a/grub-core/kern/lockdown.c
> > > +++ b/grub-core/kern/lockdown.c
> > > @@ -48,7 +48,6 @@ lockdown_verifier_init (grub_file_t io __attribute__ 
> > > ((unused)),
> > >      case GRUB_FILE_TYPE_PXECHAINLOADER:
> > >      case GRUB_FILE_TYPE_PCCHAINLOADER:
> > >      case GRUB_FILE_TYPE_COREBOOT_CHAINLOADER:
> > > -    case GRUB_FILE_TYPE_EFI_CHAINLOADED_IMAGE:
> > >      case GRUB_FILE_TYPE_ACPI_TABLE:
> > >      case GRUB_FILE_TYPE_DEVICE_TREE_IMAGE:
> > >        *flags = GRUB_VERIFY_FLAGS_DEFER_AUTH;
> > > --
> > > 2.26.2
> > >
> > >
> > > _______________________________________________
> > > Grub-devel mailing list
> > > Grub-devel@gnu.org
> > > https://lists.gnu.org/mailman/listinfo/grub-devel
> >
> >
> >
> > --
> > Regards,
> >
> > Dimitri.
> >
>


-- 
Regards,

Dimitri.



reply via email to

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