From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mx.groups.io with SMTP id smtpd.web10.12967.1663685523180300579 for ; Tue, 20 Sep 2022 07:52:03 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=mtM7Ommp; spf=pass (domain: kernel.org, ip: 139.178.84.217, mailfrom: ardb@kernel.org) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 6137960A49 for ; Tue, 20 Sep 2022 14:52:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5A931C43470 for ; Tue, 20 Sep 2022 14:52:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1663685521; bh=W0RwpwlSPpKGzHuCxh9nur34FTOMGSjlKYSGZImX5oI=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=mtM7Ommpy3S4QYtDJsLZsexNNP7+1QyxNhKgnrRf9zPKMIiesktOMXeRbD3roym/z M2sF2+qgYRHejC4H02RV7UAAZDaFvPTlCtIxV2MSyYf1ZOMpG2Xbf/RVLWAlVRnFtw s3I9qxLIChv/+p7QB6YlHvZDZ0bvtLNtdLU397N9cS3gN0O2/TEWAOg6X4fJLhxasK jE5w/JmXTYDHbPDQScLAU2A1l44VeLiJT5O1tb9Tbu3TffsS1GABd9aNjjsJCq/pKh B5vJx5PajCbwG7L018KSn0VSB6RBeNAouuReCK4Q3SbXKBTHvWA7dKu9e4wVrAvz+8 jqyN3mMWGF8sw== Received: by mail-lj1-f177.google.com with SMTP id s10so3309813ljp.5 for ; Tue, 20 Sep 2022 07:52:01 -0700 (PDT) X-Gm-Message-State: ACrzQf1zB6s4L6ZAZDQLD7OyZOKh0zMqj8COgLrPlQkrQq9ozjswO2hQ TjZcZrsX0DavC82C1fDjEbFbmqGpgVMOrM+RqJg= X-Google-Smtp-Source: AMsMyM4FXunps5Dfrdco0OPnp7BLt7u0gcW8oXd1IRHxtViKlhbRNuvcdIEbRoOsO/uvl8RYl3Qa9JC4NmDxzAaWdrA= X-Received: by 2002:a2e:8349:0:b0:26c:4311:9b84 with SMTP id l9-20020a2e8349000000b0026c43119b84mr5480506ljh.152.1663685519267; Tue, 20 Sep 2022 07:51:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Ard Biesheuvel" Date: Tue, 20 Sep 2022 16:51:47 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] measurement to command-line/initrd for loading kernel via -kernel option To: "Lu, Ken" Cc: "Xu, Min M" , Daniel Kiper , "devel@edk2.groups.io" , Ard Biesheuvel , "Aktas, Erdem" , James Bottomley , "Yao, Jiewen" , Gerd Hoffmann Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 20 Sept 2022 at 15:24, 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 imag= e. In grub > > boot, it is grub2. Because the number of consumer like Linux kernel co= uld 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 g= rub and OVMF, correct? I think it is OK even do twice measurements on cmdli= ne 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=3D4c76565b6cb885b7e144dc27f= 3612066844e2d19 > 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 CONFI= G_INITRAMFS_SOURCE, such as https://blog.decentriq.com/swiss-cheese-to-ched= dar-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 awar= e 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 g= uarantee both loader and kernel know for consistent measurement results? > > > > In another side, "EFI stub" is bind to EFI boot protocol and "EFI han= dover > > 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 ht= tps://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 bo= ot. 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().