From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id A76761A1E3D for ; Mon, 10 Oct 2016 07:16:34 -0700 (PDT) Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga105.fm.intel.com with ESMTP; 10 Oct 2016 07:16:34 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,324,1473145200"; d="scan'208";a="18032219" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by fmsmga006.fm.intel.com with ESMTP; 10 Oct 2016 07:16:34 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 10 Oct 2016 07:16:34 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.15]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.96]) with mapi id 14.03.0248.002; Mon, 10 Oct 2016 22:16:31 +0800 From: "Zhang, Chao B" To: winddy , edk2-devel CC: winddy_zhang Thread-Topic: [edk2] [EDK2 tcg2] TCG2 variable TCG2_DEVICE_DETECTION_NAME does not work as expected? Thread-Index: AQHSIi+20f+AeCN50Ea7GF6qBBT1VqChudsQ Date: Mon, 10 Oct 2016 14:16:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_IC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMWEwOTAxODMtNzExZi00OWFhLTg1NGEtZDQxMzNmYzc0YmNiIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IjRLWEhmOTAwQ1lWcVBiWGxra2Y3SXk1NXRyTFBmQ0h6bWxuZ1lLc3N1Wnc9In0= x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Subject: Re: [EDK2 tcg2] TCG2 variable TCG2_DEVICE_DETECTION_NAME does not work as expected? X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 14:16:34 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Winddy: UEFI TCG/TCG2 solution is designed to make one BIOS image workable with e= ither TPM1.2 or TPM2.0. According to TCG2 spec explanation about TBB/TCB (the platform hardware, co= nnection between CPU, Chipset & TPM etc.) should always be secure and never be compromised. So here, the TPM chip swi= tch is not a valid case we need to handle. Thanks & Best regards Chao Zhang -----Original Message----- From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of wind= dy Sent: Sunday, October 09, 2016 9:18 PM To: edk2-devel Cc: winddy_zhang Subject: [edk2] [EDK2 tcg2] TCG2 variable TCG2_DEVICE_DETECTION_NAME does n= ot work as expected? Hi experts,=20 Now I am studying latest tcg2 modules, and I guess there may be somethi= ng wrong with variable (TCG2_DEVICE_DETECTION_NAME, gTcg2ConfigFormSetGuid)= .=20 This variable is used to save TPM device type(TPM1.2, TPM2.0, or not pr= esent) detected at PEI. The save action is at Tcg2ConfigDriverEntryPoint(),= but this module is depended on protocol gEfiTcg2ProtocolGuid, if there is = no TPM2 present, this module will not run and the variable value keeps last= state. If I first add TPM2 device, boot once, then remove it and add TPM1.2, I= think when it resumes form S3, DetectTpmDevice() function will derictly re= turn TPM2 type, then auto detection seems wrong. So I guess we should add a new common module which has no dependence an= d its work is only to save TPM type from PCD to variable at "ReadyToBoot" e= vent.=20 If any mistake in my understanding, please let me know. Thank you. ------------------ BR winddy_zhang _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel