> > So there are two types loaders: > > 1. QemuKernelLoaderFsDxe - this way just put kernel/initrd blob into a FS > for any future's usage, may be continue boot or not. > > 2. QemuLoadKernelImage, - this is consumed by TryRunningQemuKernel() > - standard Qemu direct boot path > > Nope. QemuLoadKernelImage loads the linux kernel from the virtual filesystem > created by QemuKernelLoaderFsDxe. And for the initrd it'll just pass > 'inittd=initrd' and the stub loads it. > > We have two variants: > GenericQemuLoadImageLib - supports efi stub only > X86QemuLoadImageLib - has fallback code paths for the legacy > pre-efi-stub boot protocol (guess that > is the one grub has deprecated for 2.06). > > So, yes, with the legacy protocol there is no stub which can measure things, > but > for the snake of confidential computing we can completely ignore that. > Kernels > which are *that* old certainly will not have support for SEV / TDX ... >
Thanks Hoffman. Hmm.. GenericQemuLoadImageLib sound like is used by ArmVirtQemu.dsc, OvmfXen.dsc, AmdSevX64.dsc,..... But X86QemuLoadImageLib is used by OvmfPkgX64.dsc and Intel TDX~~ Headache.... do you want use GenericQemuLoadImageLib to replace X86 one for OvmfPkgX64.dsc also? But either in GenericQemuLoadImageLib, it can do measurement for command line and initrd, correct? > take care, > Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#94009): https://edk2.groups.io/g/devel/message/94009 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] -=-=-=-=-=-=-=-=-=-=-=-
