Received: by 2002:a05:7208:9594:b0:7e:5202:c8b4 with SMTP id gs20csp279793rbb; Fri, 23 Feb 2024 23:31:23 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCXICcwrIk7tTcXdPYxsLGmERp9/JQ3dm37J6Z6mZ7g+dpsYPcb8dY49iFhcKLd6pOVHI4hcBOGylbdUrva1FBxuS3NNmgS72+X3azIgDg== X-Google-Smtp-Source: AGHT+IGVkYbJLjjkXoGaScWG47UYYLC+frQvjiYGikhEhDT3pqZb1v95MXh3KtAQbhywvLaV1T4G X-Received: by 2002:a05:6a21:1518:b0:1a0:c99a:a5b with SMTP id nq24-20020a056a21151800b001a0c99a0a5bmr2316903pzb.20.1708759882755; Fri, 23 Feb 2024 23:31:22 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708759882; cv=pass; d=google.com; s=arc-20160816; b=dStJJ53xqWWkS0+N04GIq7SnCCt0cwTiLaEIuuq09c+W4B7oLzyRWXw7XHF00wtpOr nOm0bMy0SExmRmCSyfTFLxfViQEY0ZcXw8fWqcYzibpiA5xjS5zqbMRkt0OTJewq5Uw4 7NVCdZCfaa/T9TPdHfiLDED8/zQkdAdsdNhqIwiyF6bWeD4To3ybFGXhN8yvgPwRLZTo /wEJjKO3sjpncuc9Z5BO/nJKkx1ylcyhb5XV9RqmSrx0TsumnBWtAdTZVEL/9lxiqsWT mSSOUvj4lu9j9dUIEPKSTmHEiDXqWtXYWaYmG/CzZ56kdiT0c+BxE0NeeI1+E69HkFp8 2CJA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id:dkim-signature; bh=mI2t9WYwrLSqxFLkWDnylDj0J2R6iFxqmmfMHRtXEnY=; fh=RLfEU3EVI8Zj4xf6NftA9y22yPgM7OH8JrANIVSpRIQ=; b=AzFkIznBiIYpET/INnJFET1hISzJfDi4/xEV0KP10qCHkya+Opldd/AXKRCu9QZsGW kQcnM8BIThXnXBcyClz/N7sdErTo4CVVVGwdE308yJXjP+nQf4MJLdmxM6tU4FQdivQz 9LgzFOURi6ghrHy17HQXK8RaPiAT9dG6UvW8oABxY3MkkSjtiSETYC8Cl1nGIWExoB0P lkdBosReLWDDgtKHbVxBQAh6VBXIIm7p3Msk01CDSar58gbt5b3B1ifiH3ogRs0n3XUl 22Gg3ghOvw7j+mEpiq3UrIMyTKUiCuiOHFdgiDg5zy40Mn2aPw/LqkdNv+oLzYSuYWrS JGJA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=m9BvGJeZ; arc=pass (i=1 dkim=pass dkdomain=intel.com dmarc=pass fromdomain=linux.intel.com); spf=pass (google.com: domain of linux-kernel+bounces-79500-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-79500-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id n3-20020a63ee43000000b005dc952f426asi520288pgk.850.2024.02.23.23.31.22 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 23 Feb 2024 23:31:22 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-79500-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=m9BvGJeZ; arc=pass (i=1 dkim=pass dkdomain=intel.com dmarc=pass fromdomain=linux.intel.com); spf=pass (google.com: domain of linux-kernel+bounces-79500-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-79500-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 66C4528437F for ; Sat, 24 Feb 2024 07:31:22 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A1D8A1401A; Sat, 24 Feb 2024 07:31:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="m9BvGJeZ" Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1A0A68487; Sat, 24 Feb 2024 07:31:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.14 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708759873; cv=none; b=X1wCtNpcOhmgbDmk3ieg7ArvwcRuGnSQ0DHYJfpDPHIdsiAGuCg+kwezrwnMpQcUxtMbxUxtn3u02Lfsizw/ag+T+xVjR1UnkIct/A9wCNLWkaxDMCPCkIiy+k7YxJDR8mS+XZkU50gG/brpLa/GR2RcLUJVIHv0U1Enqrhwcdk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708759873; c=relaxed/simple; bh=buu8SVznffYLooKd5ucCOXhekw/UjP+3E944rGDQ+L8=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Gkb9c/p/V4LQCH2LXG7RuF4wa44jaT979TX/7LzvEHd0kSI+iPgHTk7QYo29I8n70r0d3ysOGMJeb8CrA3TP79MF+spvBqsdLC6zA6r5bOVrfNWtk2CWZG+RIk7PyJpvtqZfomb38R2Zs07pxwLjh5ObHfyKIC09Ejp9WhlcMOQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=m9BvGJeZ; arc=none smtp.client-ip=198.175.65.14 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1708759872; x=1740295872; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=buu8SVznffYLooKd5ucCOXhekw/UjP+3E944rGDQ+L8=; b=m9BvGJeZNCEHXs0XeE0lJ893NEld56Hc8Qfo3vE+1HattXi6WyEYasj2 iIFZM0Gc1R1spChZSdYgFXEn450gZE01fCndmDyB+eEm7GEmHHDba1LQz 8eBFsder0y148MqqB9Q4MD0YDBSf0P5wU56edlgxjl3zyiOniNPFgQqGq U/bVWnncJETPIjCm+3UEUnyuOUPvAnP+nMCO9og0r6TFq8hpkHBJ5k74n b4dyVlN3OHhPZzJYJ/lD030pZFsdCdO7HOPFepnFqRjUdxt1jaJmQwxDZ IVEpv51ZwjvJkS6TteLAVsG5H/GEJ0m3OyIetNUbxSotYZhQjrT5S1Y20 w==; X-IronPort-AV: E=McAfee;i="6600,9927,10993"; a="6908083" X-IronPort-AV: E=Sophos;i="6.06,181,1705392000"; d="scan'208";a="6908083" Received: from fmviesa001.fm.intel.com ([10.60.135.141]) by orvoesa106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Feb 2024 23:31:11 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,181,1705392000"; d="scan'208";a="37150062" Received: from bafghani-mobl.amr.corp.intel.com (HELO [10.255.231.229]) ([10.255.231.229]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Feb 2024 23:31:11 -0800 Message-ID: <3b8113ac-e44c-4b11-b494-9e473352037a@linux.intel.com> Date: Fri, 23 Feb 2024 23:31:10 -0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/2] efi/libstub: Add get_event_log() support for CC platforms Content-Language: en-US To: Ilias Apalodimas Cc: Ard Biesheuvel , linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org References: <20240215030002.281456-1-sathyanarayanan.kuppuswamy@linux.intel.com> <20240215030002.281456-3-sathyanarayanan.kuppuswamy@linux.intel.com> <7feb889f-f78e-4caa-a2f4-9d41acf6ca76@linux.intel.com> From: Kuppuswamy Sathyanarayanan In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 2/23/24 5:24 AM, Ilias Apalodimas wrote: > Apologies for the late reply, > > > On Mon, 19 Feb 2024 at 09:34, Kuppuswamy Sathyanarayanan > wrote: >> Hi Ilias, >> >> On 2/18/24 11:03 PM, Ilias Apalodimas wrote: >>> On Thu, 15 Feb 2024 at 05:02, Kuppuswamy Sathyanarayanan >>> wrote: >>>> To allow event log info access after boot, EFI boot stub extracts >>>> the event log information and installs it in an EFI configuration >>>> table. Currently, EFI boot stub only supports installation of event >>>> log only for TPM 1.2 and TPM 2.0 protocols. Extend the same support >>>> for CC protocol. Since CC platform also uses TCG2 format, reuse TPM2 >>>> support code as much as possible. >>>> >>>> Link: https://uefi.org/specs/UEFI/2.10/38_Confidential_Computing.html#efi-cc-measurement-protocol [1] >>>> Signed-off-by: Kuppuswamy Sathyanarayanan >>> [...] >>> >>>> +void efi_retrieve_eventlog(void) >>>> +{ >>>> + efi_physical_addr_t log_location = 0, log_last_entry = 0; >>>> + efi_guid_t cc_guid = EFI_CC_MEASUREMENT_PROTOCOL_GUID; >>>> + efi_guid_t tpm2_guid = EFI_TCG2_PROTOCOL_GUID; >>>> + int version = EFI_TCG2_EVENT_LOG_FORMAT_TCG_2; >>>> + efi_tcg2_protocol_t *tpm2 = NULL; >>>> + efi_cc_protocol_t *cc = NULL; >>>> + efi_bool_t truncated; >>>> + efi_status_t status; >>>> + >>>> + status = efi_bs_call(locate_protocol, &tpm2_guid, NULL, (void **)&tpm2); >>>> + if (status == EFI_SUCCESS) { >>>> + status = efi_call_proto(tpm2, get_event_log, version, &log_location, >>>> + &log_last_entry, &truncated); >>>> + >>>> + if (status != EFI_SUCCESS || !log_location) { >>>> + version = EFI_TCG2_EVENT_LOG_FORMAT_TCG_1_2; >>>> + status = efi_call_proto(tpm2, get_event_log, version, >>>> + &log_location, &log_last_entry, >>>> + &truncated); >>>> + if (status != EFI_SUCCESS || !log_location) >>>> + return; >>>> + } >>>> + >>>> + efi_retrieve_tcg2_eventlog(version, log_location, log_last_entry, >>>> + truncated); >>>> + return; >>>> + } >>>> + >>>> + status = efi_bs_call(locate_protocol, &cc_guid, NULL, (void **)&cc); >>>> + if (status == EFI_SUCCESS) { >>>> + version = EFI_CC_EVENT_LOG_FORMAT_TCG_2; >>>> + status = efi_call_proto(cc, get_event_log, version, &log_location, >>>> + &log_last_entry, &truncated); >>>> + if (status != EFI_SUCCESS || !log_location) >>>> + return; >>>> + >>>> + efi_retrieve_tcg2_eventlog(version, log_location, log_last_entry, >>>> + truncated); >>>> + return; >>>> + } >>>> +} >>> [...] >>> >>> I haven't looked into CC measurements much, but do we always want to >>> prioritize the tcg2 protocol? IOW if you have firmware that implements >>> both, shouldn't we prefer the CC protocol for VMs? >> According the UEFI specification, sec "Conidential computing", if a firmware implements >> the TPM, then it should be used and CC interfaces should not be published. So I think >> we should check for TPM first, if it does not exist then try for CC. > Ok thanks, that makes sense. That document also says the services > should be implemented on a virtual firmware. > I am unsure at the moment though if it's worth checking that and > reporting an error otherwise. Thoughts? IMO, it is not fatal for the firmware to implement both protocols. Although, it violates the specification, does it makes sense to return error and skip measurements? I think for such case, we can add a warning and proceed with TPM if it exists. > > Thanks > /Ilias >> https://uefi.org/specs/UEFI/2.10/38_Confidential_Computing.html#confidential-computing >> >>> Thanks >>> /Ilias >> -- >> Sathyanarayanan Kuppuswamy >> Linux Kernel Developer >> -- Sathyanarayanan Kuppuswamy Linux Kernel Developer