Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp11048233imu; Thu, 6 Dec 2018 10:39:41 -0800 (PST) X-Google-Smtp-Source: AFSGD/XblAWw8I9qC3O35n/axIzV3f1IumHTG4qptN5DwDo5dTLh9gWOqSDWSaNqvpvy+jar71UG X-Received: by 2002:a63:2d46:: with SMTP id t67mr24398545pgt.140.1544121581192; Thu, 06 Dec 2018 10:39:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544121581; cv=none; d=google.com; s=arc-20160816; b=hODFEevl+CJD66oiTvMwbtNict0h5VtBaUB/oj2zoGXGOEN3BIx8hdxbq7p9/z8wmq uLhJbLRkynGCBozOX6TsUf+rckg6xRXuDPKYcgg9N4qa7GezIBhl7S82zTdk01VxFxtH l9W4WPXuD/aguQY114ctG/90mV1JsXg1y6vedOuCLSxZfatGHVJwyVR+T+3sPBt/S5lD edSLBj53fvLHLkRQsQevAvShGZoGK/GPNsmGDpLVg/18K3MwUxTPBsWUIntOj2LYaGK0 VzHH9az1TSv2IqKKPEu2c7KbIy0oevxGFBARqF8jFSLT5pduj+nkYEehBPvY3tldS2GA 0MJA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=YaNCosAG6A6ETGY5eA5QkJm6BR8HaLCUYXhJl0XXAWI=; b=wm+Fe0JU+xvUdBeH5ZSGMj2/g43SYsx4UUTHo0InNQveBwoXjlkKoDd1Ayi4tYV1eJ NJqj2JKlwZ5DzY6T1qz5jz2qIhLKEYHJDwlrLMyhHjnTZiKyKJDg3xxayP7kD06SMQKf hE7T/2pJFWWd62xX66D1N9KLlynftLnfKvMrhSBHcTbV+pOYu9WDHgr1nWNojqRRMHKo 7LJqSD7J25+qZIPolSQ1y38X8bMONAfsCspPM6F5dF27wSkPWvCZ/CUZjnkaM6nENm9t Ap4ygIMcXsL4eVMZKRB4K8gAQdayQ7RExGI6E5nhcR8teeRYQONqyvTJ27bFZGgHXKYG eltw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b26si731318pgl.539.2018.12.06.10.39.22; Thu, 06 Dec 2018 10:39:41 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726044AbeLFSij (ORCPT + 99 others); Thu, 6 Dec 2018 13:38:39 -0500 Received: from lhrrgout.huawei.com ([185.176.76.210]:32804 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725916AbeLFSij (ORCPT ); Thu, 6 Dec 2018 13:38:39 -0500 Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 9A066FCF10B52; Thu, 6 Dec 2018 18:38:35 +0000 (GMT) Received: from [10.204.65.144] (10.204.65.144) by smtpsuk.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 6 Dec 2018 18:38:30 +0000 Subject: Re: [PATCH v6 7/7] tpm: pass an array of tpm_bank_list structures to tpm_pcr_extend() To: Jarkko Sakkinen CC: , , , , , , References: <20181204082138.24600-1-roberto.sassu@huawei.com> <20181204082138.24600-8-roberto.sassu@huawei.com> <20181205001417.GF1233@linux.intel.com> From: Roberto Sassu Message-ID: <9d6e47d9-3b88-86f6-1b60-6652dfe8dc00@huawei.com> Date: Thu, 6 Dec 2018 19:38:30 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: <20181205001417.GF1233@linux.intel.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.204.65.144] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/5/2018 1:14 AM, Jarkko Sakkinen wrote: > On Tue, Dec 04, 2018 at 09:21:38AM +0100, Roberto Sassu wrote: >> The new tpm_bank_list structure has been preferred to the tpm_digest >> structure, to let the caller specify the size of the digest (which may be >> unknown to the TPM driver). > > Why is that? Didn't previous commit query these? Since the TPM driver pads/truncates the first digest passed by the caller to extend PCRs for which no digest was provided, it must know which amount of data it can use. It is possible that the algorithm of the first digest is unknown for the TPM driver, if the caller of tpm_pcr_extend() didn't check chip->allocated_banks. By requiring that the caller passes also the digest size, this problem does not arise. It seems reasonable to me to pass this information, as the caller calculated the digest and it should know the digest size. Roberto >> +struct tpm_bank_list { >> + u16 alg_id; >> + u16 extend_size; >> + const u8 *extend_array; >> +}; > > Naming is not good here. If this only for extending shouldn't that > be in the structs name? > > /Jarkko > -- HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Bo PENG, Jian LI, Yanli SHI