From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mx.groups.io with SMTP id smtpd.web11.12668.1663683509575766853 for ; Tue, 20 Sep 2022 07:18:30 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=X4Idt1/j; spf=pass (domain: redhat.com, ip: 170.10.129.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1663683508; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=+vXhHFMtTSfArg9gBoECWgAyqBVr59XXxno3AXpjv2g=; b=X4Idt1/jck47HsyFK+NNVdEeM+byRlud/nm7fCxMZkRBCX//GOHaxvFRcLBsODPD9LgKFC 2eR4DSP0C9rF226a3gOo4TtBp75YX35YgA2qL9HRvJi4rYonhHBlVhrJDasPGbaQjOrk1o ed7LPGwH71bHb/a4ihWr/EJfZhj9mk8= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-433-uYty6tIRNYCuqhB_diiaSA-1; Tue, 20 Sep 2022 10:18:26 -0400 X-MC-Unique: uYty6tIRNYCuqhB_diiaSA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 0B4F38CB481; Tue, 20 Sep 2022 14:18:26 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.24]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A8164C15BA5; Tue, 20 Sep 2022 14:18:25 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id B6A6C180039F; Tue, 20 Sep 2022 16:18:23 +0200 (CEST) Date: Tue, 20 Sep 2022 16:18:23 +0200 From: "Gerd Hoffmann" To: "Lu, Ken" Cc: Ard Biesheuvel , "Xu, Min M" , Daniel Kiper , "devel@edk2.groups.io" , Ard Biesheuvel , "Aktas, Erdem" , James Bottomley , "Yao, Jiewen" Subject: Re: [edk2-devel] measurement to command-line/initrd for loading kernel via -kernel option Message-ID: <20220920141823.byhnbirfnl777jql@sirius.home.kraxel.org> References: <20220920132027.y4yz4ugghpilqplx@sirius.home.kraxel.org> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.8 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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