From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by mx.groups.io with SMTP id smtpd.web10.11587.1663679047341835578 for ; Tue, 20 Sep 2022 06:04:07 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=DHG64++l; spf=pass (domain: kernel.org, ip: 145.40.68.75, 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 ams.source.kernel.org (Postfix) with ESMTPS id 3E74FB81D66 for ; Tue, 20 Sep 2022 13:04:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0409BC433B5 for ; Tue, 20 Sep 2022 13:04:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1663679044; bh=xgcuBZGjbvzCFmQERZTXMiy1s2i+h/fLBTGgVOjsczU=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=DHG64++l6vIYEl6brCGO8A/A/86aeW8QkPE2TngzH4qLWI5+IdemHBJncJHXwqMuC dXVGIgsnNAkAWFif2tPPMq+YMo3mF0Dvqq50Qr0XUcW7NTKylFCwdoSgo4UvCzHbEm pDsgfxsivUCdRY/K18z0z/ohdqCaDfe5TZHTOOG6IfoWDrSgJHlYObkUHJusalBvDI Y2+HCp83ZXkAwFPN35dS5jpaNu3aP6veWvBT4+MTMVPCjxzQ6r1fwHj2qPWx5veWk1 t83Md1YQx6p143JZ8L45gzEtrTQMBcTslP1tUrMuos/Vx+LowKhjyVUmqmoi34F1+E 9n3+ijE1SAXbA== Received: by mail-lf1-f44.google.com with SMTP id s6so3659352lfo.7 for ; Tue, 20 Sep 2022 06:04:03 -0700 (PDT) X-Gm-Message-State: ACrzQf28xvdf8j9lKiWqRn+fLcVmQKt8hJib9IZML4jhdYXa3aSImwnT GABbWnUn7pLiuGzhk21mVzW6Vzkjra/iX7u7iqM= X-Google-Smtp-Source: AMsMyM4UgK6Qi7fulbeP65GoyhLYtMGyB4t8w/wGVUE+GBhnUeJVD6eBL8NFJ0R6/VI1TIGq16qjof2O0r3yMnEwkDE= X-Received: by 2002:ac2:4431:0:b0:497:aaf5:83eb with SMTP id w17-20020ac24431000000b00497aaf583ebmr7931423lfl.228.1663679042032; Tue, 20 Sep 2022 06:04:02 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Ard Biesheuvel" Date: Tue, 20 Sep 2022 15:03:50 +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 14:56, Lu, Ken wrote: > > > -----Original Message----- > > From: Ard Biesheuvel > > Sent: Monday, September 19, 2022 2:59 PM > > To: Xu, Min M > > Cc: devel@edk2.groups.io; Ard Biesheuvel ; A= ktas, > > Erdem ; James Bottomley ; > > Yao, Jiewen ; Gerd Hoffmann ; = Lu, > > Ken > > Subject: Re: [edk2-devel] measurement to command-line/initrd for loadin= g > > kernel via -kernel option > > > > On Mon, 19 Sept 2022 at 04:13, Xu, Min M wrote: > > > > > > On September 18, 2022 8:52 PM, Ard Biesheuvel wrote: > > > > Hello Min Xu, > > > > > > > > On Sat, 17 Sept 2022 at 04:53, Xu, Min M wrote= : > > > > > > > > > > Hi, Ard > > > > > > > > > > I am checking the measurement behavior when loading the kernel vi= a > > > > > the > > > > QEMU -kernel option. I find it is implemented by below 2 driver/lib= : > > > > > > > > > > - OvmfPkg/QemuKernelLoaderFsDxe > > > > > > > > > > This is a separate DXE driver that exposes the virtual > > > > > SimpleFileSystem > > > > implementation that carries the kernel and initrd passed via the > > > > QEMU command line. > > > > > > > > > > - OvmfPkg/Library/X86QemuLoadImageLib > > > > > > > > > > This is the library that consumes above driver and call > > > > LoadImage/StartImage so that the kernel image gets authenticated > > > > and/or measured. > > > > > > > > > > See https://edk2.groups.io/g/devel/message/55381 > > > > > > > > > > > > > > > > > > > > I have some questions about the implementation need your help. > > > > > > > > > > 2. Kernel image is authenticated and/or measured in LoadImage. I > > > > > am > > > > wondering if =E2=80=9Ccommand line=E2=80=9D is measured as well? = =E2=80=9CCommand line=E2=80=9D can > > > > be treated as an external input and in my opinion it should be meas= ured too. > > > > > > > > > > 3. The same question to initrd. Is it measured? > > > > > > > > > > > > > The initrd is measured by the EFI stub in Linux, and we are > > > > currently adding measurement of the load options to that as well: > > > > https://lore.kernel.org/all/20220916081441.1993492-2- > > > > ilias.apalodimas@linaro.org/ > > > > > > > > The initrd is Linux specific in any case, so there, the Linux OS > > > > loader is a natural place to take care of this. The load options ar= e > > > > being added because of the oversight in the TCG spec, which only > > > > covers load options if they are part of a Boot#### option, but > > > > between > > > > LoadImage() and StartImage, you can pass any load options you want > > > > via the loaded image protocol, so it needs to be measured as well. > > > > > > > Thanks Ard for the explanation. > > > I was told that in grub boot cmd-line/initrd will be measured as well= . So my > > question is that will they be measured twice? One in grub.efi, the othe= r in efi- > > stub? > > > > > > > The EFI stub may be the only OS loader, so the EFI stub should measure = the > > command line and the initrd. > > > > Whether or not a previous loader stage exists that may or may not measu= re the > > same pieces is not for the EFI stub to reason about. And in any case, m= easuring > > the same thing twice is much less of an issue than not measuring it at = all. > > > > > My understanding is that the loader should take the responsibility to= do the > > measurement. > > > For grub boot, grub.efi is the loader so it measures kernel-image/cmd= - > > line/initrd. > > > > If the EFI stub is invoked, the EFI stub is the OS loader. We should no= t be relying > > on the presence of absence of GRUB (or shim) in the boot chain. > > > > > For direct boot, TryRunningQemuKernel() now measures kernel image (in > > CoreLoadImage). Shall it also measure cmd-line/initrd in the same time? > > > > > > > No, I don't think it should. This is why we are adding this to the EFI = stub instead. > > > > If we measure the initrd and command line in the EFI stub, we don't hav= e to > > measure it anywhere else, and we can use any generic EFI loader on a me= asured > > boot system. > > Hi Ard, I think it better let creator to measure instead of consumer to m= easure like today's implementation in grub[1]. The creator here means who l= oad/create it. In direct boot, it is OVMF read kernel command line and init= rd image. In grub boot, it is grub2. Because the number of consumer like L= inux kernel could be more than 1, but the creator is single. I agree with this in principle. However, there are corner cases that we would like to cover, such as booting Linux from the EFI shell. 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. > In another side, "EFI stub" is bind to EFI boot protocol and "EFI handove= r protocol" is deprecated in grub 2.06[2]. (CC to Daniel). > Apologies, I don't understand this sentence.