On Mon, Mar 8, 2021 at 5:59 AM Michael Chang via Grub-devel <grub-devel@gnu.org> wrote: > > 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 <mch...@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 ?
As far as I understand it there is one thing to keep in mind when using chainloader with the upcoming shim: If a new vulnerability is discovered in Grub any time in the future, then the SBAT revocation has to be done for the Shim, not Grub. Then a new Shim would need to blacklist all vulnerable Grub versions that were signed with the embedded key. This is because a new, fixed Grub would still load the vulnerable Grub through chainloader and Shim would accept it because it does not check the SBAT section on that verification path. Of course the revocation can be handled on a per distribution / product basis. But this is probably something to discuss on the shim review board. _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
