From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by mx.groups.io with SMTP id smtpd.web08.12085.1663681440699163464 for ; Tue, 20 Sep 2022 06:44:01 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@ibm.com header.s=pp1 header.b=lnxg0n3Z; spf=pass (domain: linux.ibm.com, ip: 148.163.158.5, mailfrom: jejb@linux.ibm.com) Received: from pps.filterd (m0098417.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 28KDVHAN016980; Tue, 20 Sep 2022 13:43:59 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : subject : from : reply-to : to : cc : date : in-reply-to : references : content-type : content-transfer-encoding : mime-version; s=pp1; bh=w8gu0l0vWYg3M42MPaySHST9K60GVuRcfYn7h0pjG6s=; b=lnxg0n3ZbyD7ebAdJRtxZY+AuiLxw9CbkGLsM0LLoDWTl4LG31lvY1CpSADjje7p2K5O Oa5dE47t5BecD0yUFqBHqBPenXzHYUaUHDK8ptwlR7olHIzIUCu0X05NOCdvlT1WbPjC QpQWjbBTcjQhid9mcrJGT69Fc5nH3aMxE6UUujVaCuFg4yL9KjeblV9KlBjZDTKplvUh 5loM+h4mFzLao3qUCKfXwEJm7EZMONUl/qP1nSLWbcILt+nBEDDf4vc4abd5+l0o0K5T iGm4dHA5uckQ6AglIgez6F/gKCG2Vw6uhTqzzILxXdYdSPFCdiDorhuqPmecGgYSz08+ AQ== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3jqefqgm1a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 20 Sep 2022 13:43:59 +0000 Received: from m0098417.ppops.net (m0098417.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 28KDWJM1019639; Tue, 20 Sep 2022 13:43:59 GMT Received: from ppma01dal.us.ibm.com (83.d6.3fa9.ip4.static.sl-reverse.com [169.63.214.131]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3jqefqgm0p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 20 Sep 2022 13:43:58 +0000 Received: from pps.filterd (ppma01dal.us.ibm.com [127.0.0.1]) by ppma01dal.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 28KDaL6n029730; Tue, 20 Sep 2022 13:43:57 GMT Received: from b03cxnp08026.gho.boulder.ibm.com (b03cxnp08026.gho.boulder.ibm.com [9.17.130.18]) by ppma01dal.us.ibm.com with ESMTP id 3jn5v9ryx4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 20 Sep 2022 13:43:57 +0000 Received: from b03ledav004.gho.boulder.ibm.com (b03ledav004.gho.boulder.ibm.com [9.17.130.235]) by b03cxnp08026.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 28KDhwk451642726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 20 Sep 2022 13:43:58 GMT Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1B2ED7805E; Tue, 20 Sep 2022 14:03:12 +0000 (GMT) Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DD89B7805C; Tue, 20 Sep 2022 14:03:08 +0000 (GMT) Received: from [172.16.61.179] (unknown [9.160.38.126]) by b03ledav004.gho.boulder.ibm.com (Postfix) with ESMTP; Tue, 20 Sep 2022 14:03:08 +0000 (GMT) Message-ID: Subject: Re: [edk2-devel] measurement to command-line/initrd for loading kernel via -kernel option From: "James Bottomley" Reply-To: jejb@linux.ibm.com To: "Lu, Ken" , Ard Biesheuvel Cc: "Xu, Min M" , Daniel Kiper , "devel@edk2.groups.io" , Ard Biesheuvel , "Aktas, Erdem" , "Yao, Jiewen" , Gerd Hoffmann , Peter Jones Date: Tue, 20 Sep 2022 14:43:50 +0100 In-Reply-To: References: User-Agent: Evolution 3.34.4 X-TM-AS-GCONF: 00 X-Proofpoint-GUID: orMPjI5alpcc0Tj1YPojqyXqlNlAFA5d X-Proofpoint-ORIG-GUID: 5hCkJwmRDNcbsS7Zn-BGzFR7DegYtmV8 X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.528,FMLib:17.11.122.1 definitions=2022-09-20_04,2022-09-20_02,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 adultscore=0 mlxlogscore=999 impostorscore=0 suspectscore=0 spamscore=0 phishscore=0 mlxscore=0 lowpriorityscore=0 bulkscore=0 malwarescore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2209130000 definitions=main-2209200079 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit [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. > > > 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). James