From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f42.google.com (mail-ej1-f42.google.com [209.85.218.42]) by mx.groups.io with SMTP id smtpd.web09.5625.1663925680982533878 for ; Fri, 23 Sep 2022 02:34:41 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@linaro.org header.s=google header.b=Ys1ugGkf; spf=pass (domain: linaro.org, ip: 209.85.218.42, mailfrom: ilias.apalodimas@linaro.org) Received: by mail-ej1-f42.google.com with SMTP id sb3so26647660ejb.9 for ; Fri, 23 Sep 2022 02:34:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date; bh=bU8XeioU/lvtjai21NqjUh3wl/GWf7dpnMZXT13ZXuE=; b=Ys1ugGkf1SrkAANCiUR5g3A7w6xrSzY+xdRjOVfmlR68BCeOHc6qZVebl6wBpDqOMR M0NcB4XHHDz3ARu/KZQeE4kms2dGaBDIgTButPHUvkEQPz15tTLa03gZvPtBpWVCARn9 ruuWTUsMNCgdl8qM6PUGQajMePcWJENoj3tPd6wpnRIj9idiZSryAToCvk8CUizxml7g g37WL/LsM+fqzo4HchYPkdfGH8jY6uSac10uIGcjyX88km3pi+/Akp03cM1RjY73vkYu SJR9TnhGqKqNeD8x9ARt1W30RMIaguyhvTxcXgvl/F4o2Nqn6oUdHWrM+j6jWOwrjM74 kAFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date; bh=bU8XeioU/lvtjai21NqjUh3wl/GWf7dpnMZXT13ZXuE=; b=NQ0ZMACisxCilQT8pwz/hkRkhiMolF+9f4AeuSWVjiaTRB+Rl33BItVnJsXN2QRbPB XgyrpKTAPBna7n6EadQBvUZ6ohvEefVEOA7kN1s2pSgAQbfbRidbUg+V4dnhAedXQJuS 1i82WGaCF/4RfuiZFR177My1fRRqaBg8+VOV3wRuiZ3ntd2R93IUkxhYiXnb3qza7P0y u15u6oU54ihI9jdhbjwXth/ZTHdnkQkHxDYMk/PdrMwcnt/BvIVyw0koPKcthgS5g4oI PzqvByCuezX7lkP1AStmRl+kDa4H7/YukeB/tofAKaczWJWAJmq8WZdU2TCvE1msYnGF Omhg== X-Gm-Message-State: ACrzQf05yLvZU24ZdepetCu4IEVcAglatEOnWU8ytPsIvxN1tKJxJT93 Kmo/UIPi7e4fPMKjmVbz8xPvJj2q7ZmcE95l X-Google-Smtp-Source: AMsMyM6Kvq46Pttl+WHNFzH3dHs9IRkwaDlE/Xd+CtWUrY575SlclzM38eD9oDhT+OaCbkSAEf0H4g== X-Received: by 2002:a17:907:d94:b0:782:65af:9442 with SMTP id go20-20020a1709070d9400b0078265af9442mr5199771ejc.637.1663925679399; Fri, 23 Sep 2022 02:34:39 -0700 (PDT) Return-Path: Received: from hades ([46.103.15.185]) by smtp.gmail.com with ESMTPSA id i14-20020a50fc0e000000b0044792480994sm5176100edr.68.2022.09.23.02.34.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 23 Sep 2022 02:34:38 -0700 (PDT) Date: Fri, 23 Sep 2022 12:34:36 +0300 From: "Ilias Apalodimas" To: devel@edk2.groups.io, ardb@kernel.org Cc: Gerd Hoffmann , "Lu, Ken" , "Xu, Min M" , Daniel Kiper , 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: References: <20220920132027.y4yz4ugghpilqplx@sirius.home.kraxel.org> <20220920141823.byhnbirfnl777jql@sirius.home.kraxel.org> <20220921071409.5oziya6kcfvkkkp7@sirius.home.kraxel.org> <20220921122706.itqekzbwmjt6brns@sirius.home.kraxel.org> MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi all, Sorry for being late to the party. Ard cc'ed me in a prior mail, but that got lost along the way On Wed, Sep 21, 2022 at 05:41:14PM +0200, Ard Biesheuvel wrote: > On Wed, 21 Sept 2022 at 14:27, Gerd Hoffmann wrote: > > > > On Wed, Sep 21, 2022 at 11:24:11AM +0000, Lu, Ken wrote: > > > > > > > > > But either in GenericQemuLoadImageLib, it can do measurement for > > > > command line and initrd, correct? > > > > > > > > Yes, it could. But why given that the linux kernel efi stub measures anyway? > > > > > If the final decision is the measurement should be done by efi stub in > > > Linux kernel. > > > > The reference should be the workflow when you boot linux from efi shell > > or using a BootNNNN entry. Which I think is: > > > > (1) linux kernel is loaded + measured via Loadimage(). > > (2) linux kernel is started via efi stub entry point. > > (3) linux kernel efi stub loads and measures the initrd. > > > > Not fully sure about the command line measurement, IIRC Ard described > > that in one of the replies. > > > > If the image was booted from a BootNNNN entry, the entire variable > will be measured into the TPM, including the load options aka command > line. > > If you use the shell or another loader that has no explicit awareness > of secure boot or measured boot, the load options are not measured at > all. > As others mentioned before me, I think the proposal here is reasonable. Yes the TCG spec tries to avoid measuring things twice, but the reality is that if we do so we'll probably end up with binaries or config options not being measured depending on how the OS booted. On top of that the efi-stub measures the contents of the initramfs and the LoadOptions in PCR9, which is meant to be used by the OS. That should give enough freedom to people when deciding which PCRs to use on sealing etc. > > > Do we also need remove today's measurement in Grub (I > > > have submitted some patch for TDX in grub...)? > > > > Those patches are perfectly fine, tpm measurement and tdx measurement > > should be consistent. In case the grub measurement workflow needs > > changes to avoid double measurements (not sure this is actually the > > case) those changes should apply to both tpm and tdx. > > > > Agreed. I think the decision what to measure and what not to measure > is orthogonal to the type of measured boot that is being used. I'd like to take the opportunity here and explain what happens on the efi-stub measurements. GRUB uses the EV_IPL type for the eventlog. This event was marked as deprecated in older versions of the spec. However on the latest versions that changed and it now says: - "May be used by Boot Manager Code to measure events. The contents of the event field are specified by the caller." Since it mentions "boot manager" and the efi-stub is an OS loader, we used EV_EVENT_TAG for the initrd contents and the LoadOptions. The description for that type is: - "Used for PCRs defined for OS and application usage. Defined for use by Host Platform Operating System or Software", which is a closer match. On top of that the opaque EV_EVENT_TAG event is a bit cleaner and allows us to mark events using its u32 tagged EventID and it easily extended for any future measurements we want to add. However when I re-read the event description there's a confusing sentence on it's description saying "The digests field MUST contain the tagged hash of the event data for each bank.". This contradicts the TCG_PCR_EVENT2 Structure description for the digests field, as it allows you to measure either the event data or external data. It also means that when measuring the initrd we'll end up with an > 80mb event data, which is silly. Anyone knows if that's a typo on the spec? Or as we abusing EV_EVENT_TAG? Thanks /Ilias > > > > According to Bottomley, the same measurement should not be done twice. > > > > Yes, this is the way it should be, although the current state of affairs > > is a bit messy and I think we are a bit away from that ideal. > > > > > Or only the one who use GenericQemuLoadImageLib, will give the Linux > > > kernel efi stub for measure? > > > > I think we don't have to do anything special in GenericQemuLoadImageLib > > because the lib uses Loadimage() which should handle measurement. > > > > > > >