From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nayna Subject: Re: [PATCH RFC 2/2] tpm: refactor tpm2_get_tpm_pt to tpm2_getcap_cmd Date: Tue, 22 Nov 2016 14:38:21 +0530 Message-ID: <58340B05.4060702@linux.vnet.ibm.com> References: <1476008057-2395-1-git-send-email-jarkko.sakkinen@linux.intel.com> <1476008057-2395-3-git-send-email-jarkko.sakkinen@linux.intel.com> <58254759.80406@linux.vnet.ibm.com> <20161112000242.63hgv5ujmkr7hy6a@intel.com> <582D998C.40605@linux.vnet.ibm.com> <20161117174241.wvyd7g5lj4ibfnry@intel.com> <582EF011.1050007@linux.vnet.ibm.com> <20161118161224.7sq4dbcnyzumbvds@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <20161118161224.7sq4dbcnyzumbvds-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tpmdd-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Jarkko Sakkinen Cc: "moderated list:TPM DEVICE DRIVER" , open list List-Id: tpmdd-devel@lists.sourceforge.net CgpPbiAxMS8xOC8yMDE2IDA5OjQzIFBNLCBKYXJra28gU2Fra2luZW4gd3JvdGU6Cj4gT24gRnJp LCBOb3YgMTgsIDIwMTYgYXQgMDU6NDI6MDFQTSArMDUzMCwgTmF5bmEgd3JvdGU6Cj4+Cj4+Cj4+ IE9uIDExLzE3LzIwMTYgMTE6MTIgUE0sIEphcmtrbyBTYWtraW5lbiB3cm90ZToKPj4+IE9uIFRo dSwgTm92IDE3LCAyMDE2IGF0IDA1OjIwOjM2UE0gKzA1MzAsIE5heW5hIHdyb3RlOgo+Pj4KPj4+ PiBJIHRlc3RlZCB0aGlzIGZvciBjYXBhYmlsaXR5IFRQTTJfQ0FQX1BDUlMuIEl0IHNlZW1zIFRQ TTJfQ0FQX1BDUlMKPj4+PiBjYXBhYmlsaXR5IGFsd2F5cyByZXR1cm5zIGZ1bGwgUENSIGFsbG9j YXRpb24sIGFuZCBtb3JlX2RhdGEgYXMgMCwgU28sIEkKPj4+PiB0aGluayB0aGUgaWRlYSBvZiBs b29waW5nIG92ZXIgYmFzZWQgb24gbW9yZV9kYXRhIG1heSBub3Qgd29yayBmb3IgdGhpcwo+Pj4+ IGNhcGFiaWxpdHkuCj4+Pgo+Pj4gWW91IGNhbiBhbHdheXMgcmVxdWVzdCBvbmUgdmFsdWUgYXQg YSB0aW1lIHVudGlsIHRoZXJlJ3Mgbm8gbW9yZS4KPj4+Cj4+PiBJZiB5b3UgcmVxdWVzdCBOIHZh bHVlcywgZGVwZW5kaW5nIG9uIHRoZSBoYXJkd2FyZSwgdGhlIGhhcmR3YXJlIHJldHVybnMKPj4+ IHRvIHlvdSBhbnl0aGluZyBmcm9tIDEgdG8gTiB2YWx1ZXMuIElmIHlvdSBpbXBsZW1lbnQgYSBm dW5jdGlvbiB0aGF0Cj4+PiByZXF1ZXN0cyBOIHZhbHVlcyBpbiB0aGUgY29tbWFuZCwgeW91ICpt dXN0KiBoYW5kbGUgdGhlIGNhc2Ugd2hlcmUKPj4+IG1vcmVEYXRhIGlzIDEgZXZlbiBpZiB0aGUg aGFyZHdhcmUgeW91IGFyZSB0ZXN0aW5nIHRoYXQgbmV2ZXIgaGFwcGVucy4KPj4+Cj4+PiBUaGF0 J3MgdGhlIHJlYXNvbiB3aHkgSSB3b3VsZCBzdGFydCB3aXRoIGEgZnVuY3Rpb24gdGhhdCB5b3Ug cmVxdWVzdCBvbmUKPj4+IHByb3BlcnR5IG9mIG9uZSBjYXBhYmlsaXR5IGFuZCBvcHRpbWl6ZSBp dCBpbiBmdXR1cmUgaWYgaXQgZG9lc24ndCBzY2FsZQo+Pj4gZm9yIHNvbWUgd29ya2xvYWQuCj4+ Pgo+Pj4gRG8geW91IGhhdmUgYSB3b3JrbG9hZCB3aGVyZSBpdCBkb2Vzbid0IHNjYWxlPwo+Pgo+ PiBUaGFua3MgSmFya2tvIGZvciBleHBsYWluaW5nIGluIGRldGFpbC4KPj4KPj4gSWYgSSB1bmRl cnN0b29kIGNvcnJlY3RseSwgdGhlIGlkZWEgaXMgdG8gcmVxdWVzdCBmb3Igb25lIHByb3BlcnR5 IGF0IGEKPj4gdGltZSwgYW5kIGlmIHdlIG5lZWQgbXVsdGlwbGUgcHJvcGVydGllcywgdGhlbiB0 byByZXF1ZXN0IGZvciBlYWNoIG9mIHRoZW0KPj4gaW4gYSBsb29wLiBJbiBjYXNlIG9mIFRQTTJf Q0FQX1BDUlMsIHByb3BlcnR5IGlzIGFsd2F5cyB6ZXJvLiBUaGlzIGlzIGhvdyBJCj4+IGFtIGNh bGxpbmcgZ2V0Y2FwX2NtZCBmb3IgVFBNMl9DQVBfUENSUy4KPj4KPj4gdHBtMl9nZXRjYXBfY21k KGNoaXAsIFRQTTJfQ0FQX1BDUlMsIDAsICZjYXBfZGF0YSwgImdldCBhY3RpdmUgcGNyIGJhbmtz Iik7Cj4+Cj4+IE91dHB1dCA6Cj4+Cj4+IFsgICAxNy4wODE2NjVdIHRwbTogY2FwIGlkIHRvIHJl Y2VpdmUgdmFsdWUgaXMgMgo+PiBbICAgMTcuMDgxNjY2XSB0cG06IFRQTTJfQ0FQX0NPTU1BTkRT OiBtb3JlIGRhdGEgMQo+PiBbICAgMTcuMDgxNjY3XSB0cG06IDIKPj4gWyAgIDE3LjA4MTY2OF0g dHBtOiB0cG0yX2dldF9hY3RpdmVfYmFua3MgIC0tLS0tLS0+IGNhcCBpcyBUUE0yX0NBUF9QQ1JT Cj4+IFsgICAxNy4xNzE2NjVdIHRwbTogY2FwIGlkIHRvIHJlY2VpdmUgdmFsdWUgaXMgNQo+PiBb ICAgMTcuMTcxNjY2XSB0cG06IFRQTTJfQ0FQX1BDUlM6IG1vcmUgZGF0YSAwIC0tLT4gbW9yZSBk YXRhIGlzIHplcm8uCj4+IFsgICAxNy4xNzE2NjZdIHRwbTogVFBNMl9DQVBfUENSUzogbW9yZSBk YXRhIDAKPj4gWyAgIDE3LjE3MTY2N10gdHBtOiBjb3VudCBwY3IgYmFua3MgaXMgMiAtLS0tLS0+ IGNvdW50IG9mIGFjdGl2ZSBwY3IgYmFua3MKPj4gaW5mb3JtYXRpb24gcmV0dXJuZWQKPj4KPj4g bW9yZV9kYXRhIGlzIGFsd2F5cyB6ZXJvIGhlcmUsIHNvIGFtIG5vdCBzdXJlIGhvdyB0byBoYW5k bGUgbW9yZV9kYXRhIGluCj4+IHRoaXMgY2FzZSA/Cj4+IFNpbmNlIHByb3BlcnR5X2lkIGlzIGFs d2F5cyB6ZXJvLCBJIGFtIG5vdCBhYmxlIHRvIHJlcXVlc3QgZm9yIG9uZSBwcm9wZXJ0eQo+PiBh dCBhIHRpbWUuCj4+IGFuZCByZXNwb25zZV9idWZmZXIgcmV0dXJucyB0aGUgZGV0YWlscyBmb3Ig Ym90aCBhY3RpdmUgYmFua3MuCj4+Cj4+IFRoaXMgaXMgdGhlIGV4cGVjdGVkIGJlaGF2aW9yIGRl ZmluZWQgaW4gVENHIDIuMCBQYXJ0IDMgQ29tbWFuZHMKPj4gU3BlY2lmaWNhdGlvbiAoU2VjdGlv biAzMC4yLjEpOgo+Pgo+PiAiVFBNX0NBUF9QQ1JTIOKAkyBSZXR1cm5zIHRoZSBjdXJyZW50IGFs bG9jYXRpb24gb2YgUENSIGluIGEKPj4gVFBNTF9QQ1JfU0VMRUNUSU9OLiBUaGUgcHJvcGVydHkg cGFyYW1ldGVyIHNoYWxsIGJlIHplcm8uIFRoZSBUUE0gd2lsbAo+PiBhbHdheXMgcmVzcG9uZCB0 byB0aGlzIGNvbW1hbmQgd2l0aCB0aGUgZnVsbCBQQ1IgYWxsb2NhdGlvbiBhbmQgbW9yZURhdGEK Pj4gd2lsbCBiZSBOTy4iCj4+Cj4+IFBsZWFzZSBsZXQgbWUga25vdywgaWYgSSBhbSBtaXNzaW5n IHNvbWV0aGluZy4KPgo+IFRoYW5rcyBmb3IgcG9pbnRpbmcgdGhhdC4gSSB0aGluayB5b3UgZ290 IGl0IHJpZ2h0IGFuZCBJIGhhZCBzb21lIHdyb25nCj4gYXNzdW1wdGlvbnMgYWJvdXQgJ21vcmVE YXRhJy4KPgo+IEhlcmUncyB3aGF0IEkgcHJvcG9zZS4gRG8gYSBub24tZ2VuZXJpYyBmdW5jdGlv biBqdXN0IGZvciBnZXR0aW5nIENBUF9QQ1JTLgo+IFlvdSBjb3VsZCBjYWxsIGl0IHRwbTJfZ2V0 X3Bjcl9hbGxvY2F0aW9uKCkgYXMgeW91IGRvbid0IHdhbnQgb3IgcmF0aGVyCj4gbmVlZCB0byBo YW5kbGUgYWxsIHRoZSBiZWxscyBhbmQgd2hpc3RsZXMgaW4gdGhhdCBUUE0gY29tbWFuZC4KPgo+ IEl0IG1ha2VzIGEgbG90IG1vcmUgc2Vuc2Ugbm93IHRoYW4gaGF2aW5nIG9uZS1zaXplLWZvci1h bGwgZnVuY3Rpb24uCgpUaGFua3MgSmFya2tvLCBZZWFoLCBTdXJlLCBJIHdpbGwgd3JpdGUgaXQg YXMgZGlmZmVyZW50IG5vbi1nZW5lcmljIGNhbGwuCk90aGVyd2lzZSwgdGhlIGZ1bmN0aW9uIHdv cmtzIGdvb2QuCkFsc28sIEkgYW0gdGhpbmtpbmcgbm93IEkgY2FuIHdyaXRlICJtdWx0aS1iYW5r IHN1cHBvcnQgZm9yIGV4dGVuZCIgb24gCnRvcCBvZiBtYXN0ZXIgYnJhbmNoIGl0c2VsZi4gIEFu eSBpc3N1ZXMgd2l0aCB0aGF0ID8KClRoYW5rcyAmIFJlZ2FyZHMsCiAgICAtIE5heW5hCgo+Cj4g L0phcmtrbwo+CgoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fCnRwbWRkLWRldmVsIG1haWxpbmcgbGlzdAp0cG1kZC1k ZXZlbEBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQKaHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQv bGlzdHMvbGlzdGluZm8vdHBtZGQtZGV2ZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932297AbcKVJIu (ORCPT ); Tue, 22 Nov 2016 04:08:50 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:52856 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754050AbcKVJIn (ORCPT ); Tue, 22 Nov 2016 04:08:43 -0500 Subject: Re: [tpmdd-devel] [PATCH RFC 2/2] tpm: refactor tpm2_get_tpm_pt to tpm2_getcap_cmd To: Jarkko Sakkinen References: <1476008057-2395-1-git-send-email-jarkko.sakkinen@linux.intel.com> <1476008057-2395-3-git-send-email-jarkko.sakkinen@linux.intel.com> <58254759.80406@linux.vnet.ibm.com> <20161112000242.63hgv5ujmkr7hy6a@intel.com> <582D998C.40605@linux.vnet.ibm.com> <20161117174241.wvyd7g5lj4ibfnry@intel.com> <582EF011.1050007@linux.vnet.ibm.com> <20161118161224.7sq4dbcnyzumbvds@intel.com> Cc: Peter Huewe , "moderated list:TPM DEVICE DRIVER" , open list From: Nayna Date: Tue, 22 Nov 2016 14:38:21 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20161118161224.7sq4dbcnyzumbvds@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16112209-0044-0000-0000-000001D20D34 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00006121; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000189; SDB=6.00783810; UDB=6.00378562; IPR=6.00561430; BA=6.00004900; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00013406; XFM=3.00000011; UTC=2016-11-22 09:08:40 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16112209-0045-0000-0000-000005FF0D8C Message-Id: <58340B05.4060702@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-11-22_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1611220165 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/18/2016 09:43 PM, Jarkko Sakkinen wrote: > On Fri, Nov 18, 2016 at 05:42:01PM +0530, Nayna wrote: >> >> >> On 11/17/2016 11:12 PM, Jarkko Sakkinen wrote: >>> On Thu, Nov 17, 2016 at 05:20:36PM +0530, Nayna wrote: >>> >>>> I tested this for capability TPM2_CAP_PCRS. It seems TPM2_CAP_PCRS >>>> capability always returns full PCR allocation, and more_data as 0, So, I >>>> think the idea of looping over based on more_data may not work for this >>>> capability. >>> >>> You can always request one value at a time until there's no more. >>> >>> If you request N values, depending on the hardware, the hardware returns >>> to you anything from 1 to N values. If you implement a function that >>> requests N values in the command, you *must* handle the case where >>> moreData is 1 even if the hardware you are testing that never happens. >>> >>> That's the reason why I would start with a function that you request one >>> property of one capability and optimize it in future if it doesn't scale >>> for some workload. >>> >>> Do you have a workload where it doesn't scale? >> >> Thanks Jarkko for explaining in detail. >> >> If I understood correctly, the idea is to request for one property at a >> time, and if we need multiple properties, then to request for each of them >> in a loop. In case of TPM2_CAP_PCRS, property is always zero. This is how I >> am calling getcap_cmd for TPM2_CAP_PCRS. >> >> tpm2_getcap_cmd(chip, TPM2_CAP_PCRS, 0, &cap_data, "get active pcr banks"); >> >> Output : >> >> [ 17.081665] tpm: cap id to receive value is 2 >> [ 17.081666] tpm: TPM2_CAP_COMMANDS: more data 1 >> [ 17.081667] tpm: 2 >> [ 17.081668] tpm: tpm2_get_active_banks -------> cap is TPM2_CAP_PCRS >> [ 17.171665] tpm: cap id to receive value is 5 >> [ 17.171666] tpm: TPM2_CAP_PCRS: more data 0 ---> more data is zero. >> [ 17.171666] tpm: TPM2_CAP_PCRS: more data 0 >> [ 17.171667] tpm: count pcr banks is 2 ------> count of active pcr banks >> information returned >> >> more_data is always zero here, so am not sure how to handle more_data in >> this case ? >> Since property_id is always zero, I am not able to request for one property >> at a time. >> and response_buffer returns the details for both active banks. >> >> This is the expected behavior defined in TCG 2.0 Part 3 Commands >> Specification (Section 30.2.1): >> >> "TPM_CAP_PCRS – Returns the current allocation of PCR in a >> TPML_PCR_SELECTION. The property parameter shall be zero. The TPM will >> always respond to this command with the full PCR allocation and moreData >> will be NO." >> >> Please let me know, if I am missing something. > > Thanks for pointing that. I think you got it right and I had some wrong > assumptions about 'moreData'. > > Here's what I propose. Do a non-generic function just for getting CAP_PCRS. > You could call it tpm2_get_pcr_allocation() as you don't want or rather > need to handle all the bells and whistles in that TPM command. > > It makes a lot more sense now than having one-size-for-all function. Thanks Jarkko, Yeah, Sure, I will write it as different non-generic call. Otherwise, the function works good. Also, I am thinking now I can write "multi-bank support for extend" on top of master branch itself. Any issues with that ? Thanks & Regards, - Nayna > > /Jarkko >