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.web08.12828.1663684507474417562 for ; Tue, 20 Sep 2022 07:35:07 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=sOz0KB0j; 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 E2C47B81A0F for ; Tue, 20 Sep 2022 14:35:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2FFD7C43140 for ; Tue, 20 Sep 2022 14:35:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1663684503; bh=MurCiHhgzr6aFLBpx8Sg9E5JwRuQX/bTqiJT7gYl/CM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=sOz0KB0jbHXRJR6zRsE+Xb6KimHrAK6lH2VdqK+JOu4HCe2sTOqQ11fIxvAKZlaiZ qHrEk1mXM+7/wjyYdUk1El41+A0lOUOcAV4LlzKG2yhBkMGX/HdaROyeRettT+exBM OLcDYtfogxurgJDPvTnXkV/tdGYrFXT16NCz6FGlv/o/bKadNN+Ir0KSU+dOE7DaRF VroZ5DPmk1eXX4cDYlyuoKL0pEVsOnzS2orYwSk+tgvyi2jlFOHn7VnHUUYFWOHLxx QDOYp2gI7fT2z9s0Tda0tw7IuxNlihzyqDJMd2LWkd87I5obA1awAdMwojf+WurV20 WGDeVzn6POoxg== Received: by mail-lj1-f178.google.com with SMTP id z20so3267977ljq.3 for ; Tue, 20 Sep 2022 07:35:03 -0700 (PDT) X-Gm-Message-State: ACrzQf08qhsOsPFSPj7Usn5RoaWMJt3kssssntYNu1tV7EJNnE1c+Ahe gveNCZziMG95nmm52Kn7YA16HKzVmX168qt9n9k= X-Google-Smtp-Source: AMsMyM5Y5KPdllO4o0swd40ehPMcPlK44m9u8fGGO/mUILBm2foF4sHsnyp7nnwnpOgwmjWp1xoAGJOuzW/BlcHE2dY= X-Received: by 2002:a2e:7314:0:b0:26a:ca18:60eb with SMTP id o20-20020a2e7314000000b0026aca1860ebmr6575998ljc.69.1663684501038; Tue, 20 Sep 2022 07:35:01 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Ard Biesheuvel" Date: Tue, 20 Sep 2022 16:34:49 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] measurement to command-line/initrd for loading kernel via -kernel option To: jejb@linux.ibm.com Cc: "Lu, Ken" , "Xu, Min M" , Daniel Kiper , "devel@edk2.groups.io" , Ard Biesheuvel , "Aktas, Erdem" , "Yao, Jiewen" , Gerd Hoffmann , Peter Jones Content-Type: text/plain; charset="UTF-8" On Tue, 20 Sept 2022 at 15:44, James Bottomley wrote: > > [pjones added because he's done a huge amount of work to get shim to > measure stuff correctly] > On Tue, 2022-09-20 at 13:24 +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. In grub boot, it is grub2. Because the number of > > > consumer like Linux kernel could 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 grub and OVMF, correct? I think it is OK even do twice > > measurements on cmdline 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=4c76565b6cb885b7e144dc27f3612066844e2d19 > > Wait, we have two separate cases: when the kernel boots via grub, which > is not direct boot and grub measures eveything and when we do direct > boot and grub is not involved. Ideally, we should be able to get to a > stable PCR8,9 for measurement, but grub isn't hugely helpful there > since it dumps every grub command into the PCRs so direct boot can > never match that whatever the EFI stub does. The TCG spec isn't very > helpful on some things, but it is very clear that once you've measured > something, you don't measure it again, so we do want to avoid measuring > the same thing twice. > Of course, in a vertically integrated boot stack design, you would never measure the same thing twice. However, we have created such a spectacular mess for ourselves, with loaders that call load/startimage, loaders that call loadimage but not startimage, loaders that call neither, loaders that measure the initrd and command line but not the kernel, loaders that measure everything,, loaders that only are broken unless they were invoked by shim etc etc, that we simply cannot rely on anything from the EFI stub's point of view. So to me, measuring the initrd and command line from the EFI stub seems like a reasonable (if somewhat belt-and-braces) approach in this case. > > > > > 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 > > CONFIG_INITRAMFS_SOURCE, such as > > https://blog.decentriq.com/swiss-cheese-to-cheddar-securing-amd-sev-snp-early-boot-2/ > > for this corner case, especially for confidential container use case > > without grub. > > Well, you know, when you talk of the devil he bites your heels ... > > Part of the problem is that if you look at the protocol, the LoadImage > measurement seems not to measure the command line. If we can fix that, > then we can get something that will work both with direct boot (cmdline > is passed to the image) as well as direct executions of the kernel from > the EFI shell. I think that's what we should aim for. It would be too > disruptive now to try to get grub also to measure thisorrectly. > > I think the key is agreeing with TCG that the argument list of an > executable, loaded by LoadImage should be measured separately. There > are parts of the spec that hint at this, but by and large it seems to > assume that the measurement of the boot volume entry (which does > contain the command line [usually empty] is sufficient). > I think this is something that should be fixed. Measuring the Boot#### variable that the BDS chose to boot instead of what LoadImage() actually consumes seems like a huge oversight to me.