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

[Michael Chang]

On Fri, Mar 05, 2021 at 01:49:00PM +0000, Dimitri John Ledkov wrote:
> 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.

Can't this be done in shim and shim_lock itself ? It should be able to
discern that the .sbat is missing and therefore skip vendor-db. For the
linux distribution they should only take care rotating out their signing
keys for this boothole2 update and use shim_lock to reject degrarded
pre-boothole2 grub release.

Or did I miss anything here ?

> 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.

The exit approach appears to be very fragile here, as it is very unclear
about what the firmware would act upon that. We would expect it to be
next boot entry from the boot order list, among them basically can be
anything if any boot vars changed in the meanwhile.

I even have noticed that at times the boot order list is disregarded
after exit performed. The qemu+aavmf would always bring up uiapp to
display uefi boot menu in it's reaction to exit.

> 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.

Why not consider the idea of returning to shim and pointing it the next
image to boot ? This way we wouldn't have to touch the existing boot
entries, and also avoid the problem that efi boot manager may not be
able to verify the image signed by MOK ...

> 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.

Please continue the chainloader support, it is really really important
feature in many ways. Especially for arm, there's quite a lot of them
are shipping with ephemeral boot variables, and thus chainloading from
grub is the only way if they have to launch secondary boot images.

And I believe there are much more cases that require efi chainloader to
work. It is a real ship stopper IMHO if it stopped to work.

Thanks,
Michael


> 
> 
> > > 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.
>