On Tue, 20 Sept 2022 at 15:24, Lu, Ken <ken...@intel.com> wrote: > > > > Hi Ard, I think it better let creator to measure instead of consumer to > > > measure > > like today's implementation in grub[1]. The creator here means who > > load/create > > it. In direct boot, it is OVMF read kernel command line and initrd image. > > In grub > > boot, it is grub2. Because the number of consumer like Linux kernel could > > be > > more than 1, but the creator is single. > > > > I agree with this in principle. > > So you are not against to do measurement in loader like current does in grub > and OVMF, correct? I think it is OK even do twice measurements on cmdline and > initrd for the corner case. > In past month, I just submit patch in grub to do CC measurement at > https://git.savannah.gnu.org/cgit/grub.git/commit/?id=4c76565b6cb885b7e144dc27f3612066844e2d19 >
Not fundamentally, no. But between the measurement of the image itself (which the firmware should do) and the measurement of the initrd and command line (which the EFI stub will do), I'm not sure there is that much left. In general, I think the combinatorial explosion of CC attestation protocols multiplied by the number of boot stages and loaders is going to be a concern. We really need some abstractions here. > > However, there are corner cases that we would like > > to cover, such as booting Linux from the EFI shell. > > I remember Bottomley or someone mentioned to use CONFIG_CMDLINE and > CONFIG_INITRAMFS_SOURCE, such as > https://blog.decentriq.com/swiss-cheese-to-cheddar-securing-amd-sev-snp-early-boot-2/ > for this corner case, especially for confidential container use case without > grub. > > Or in general, any loader that > > knows how to load an image and pass a command line, but may not be aware of > > whether or which flavor of measured boot is being used by the platform. > > > > This is headache.... but if loader do not know, why kernel know? How to > guarantee both loader and kernel know for consistent measurement results? > > > > In another side, "EFI stub" is bind to EFI boot protocol and "EFI handover > > protocol" is deprecated in grub 2.06[2]. (CC to Daniel). > > > > > > > Apologies, I don't understand this sentence. > > May be I am wrong. I mean whether "EFI stub" code is only valid for "EFI > handover protocol", or is it also valid for Linux 32bit/64bit boot? See > https://www.kernel.org/doc/html/latest/x86/boot.html > If it is only valid for "EFI handover protocol", then it is deprecated. No it is not deprecated. The EFI handover protocol uses LoadImage() but not StartImage(). Instead, it jumps directly to an alternative entrypoint in the image which has a Linux/x86 specific prototype, and passes additional data. > So "EFI stub" code for measurement will not work for Linux 32bit/64bit boot. No you misunderstood. The EFI stub is an integral part of the boot flow. The only thing we deprecated is invoking it without going through StartImage(). -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#94000): https://edk2.groups.io/g/devel/message/94000 Mute This Topic: https://groups.io/mt/93737108/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
