On Tue, Mar 09, 2021 at 07:45:55PM +0100, Thomas Frauendorfer wrote: > 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.
Thanks for your clarification. Yes, granted that chainloader could be a potential vehicle to bypass the the verification in the future sbat revocation is a thing we have to keep in mind and discuss in the future. But given we are still relying on the key revocation mechanism currently for this second round of boothole security update, in that the verification of chainloaded image remain covered by shim lock (vendor_dbx) properly. It is therefore unexpect to see chainloader to be rejected at this moment for this round of security update by the upstream. I hope this also makes my point clear. And last I would like to take the opportunity to thank all who worked on this securiy update. It is tremendous ! Thanks, Michael > _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
