From: "Gerd Hoffmann" <kraxel@redhat.com>
To: "Lu, Ken" <ken.lu@intel.com>
Cc: Ard Biesheuvel <ardb@kernel.org>,
"Xu, Min M" <min.m.xu@intel.com>,
Daniel Kiper <daniel.kiper@oracle.com>,
"devel@edk2.groups.io" <devel@edk2.groups.io>,
Ard Biesheuvel <ardb+tianocore@kernel.org>,
"Aktas, Erdem" <erdemaktas@google.com>,
James Bottomley <jejb@linux.ibm.com>,
"Yao, Jiewen" <jiewen.yao@intel.com>
Subject: Re: [edk2-devel] measurement to command-line/initrd for loading kernel via -kernel option
Date: Tue, 20 Sep 2022 16:18:23 +0200 [thread overview]
Message-ID: <20220920141823.byhnbirfnl777jql@sirius.home.kraxel.org> (raw)
In-Reply-To: <DM6PR11MB3674A579D2F63A8A26F4E1F1984C9@DM6PR11MB3674.namprd11.prod.outlook.com>
On Tue, Sep 20, 2022 at 01:38:05PM +0000, Lu, Ken 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.
> >
> > Nope. OVMF just places kernel, initrd and cmdline images into a virtual
> > filesystem (see QemuKernelLoaderFsDxe), so the linux kernel efi stub is able to
> > load things using the efi file protocol.
>
> 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 ...
take care,
Gerd
next prev parent reply other threads:[~2022-09-20 14:18 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-17 2:52 measurement to command-line/initrd for loading kernel via -kernel option Min Xu
2022-09-18 12:52 ` Ard Biesheuvel
2022-09-19 2:13 ` [edk2-devel] " Min Xu
2022-09-19 6:58 ` Ard Biesheuvel
2022-09-20 0:20 ` Min Xu
2022-09-20 12:29 ` Ard Biesheuvel
2022-09-20 12:55 ` Lu, Ken
2022-09-20 13:03 ` Ard Biesheuvel
2022-09-20 13:24 ` Lu, Ken
2022-09-20 13:43 ` James Bottomley
2022-09-20 14:34 ` Ard Biesheuvel
2022-09-20 14:51 ` Ard Biesheuvel
2022-09-20 15:14 ` Lu, Ken
2022-09-20 13:20 ` Gerd Hoffmann
2022-09-20 13:38 ` Lu, Ken
2022-09-20 14:18 ` Gerd Hoffmann [this message]
2022-09-20 14:30 ` Lu, Ken
2022-09-21 7:14 ` Gerd Hoffmann
2022-09-21 11:24 ` Lu, Ken
2022-09-21 12:27 ` Gerd Hoffmann
2022-09-21 15:41 ` Ard Biesheuvel
2022-09-23 9:34 ` Ilias Apalodimas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220920141823.byhnbirfnl777jql@sirius.home.kraxel.org \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox