Received: by 2002:ac0:8c9a:0:0:0:0:0 with SMTP id r26csp3863176ima; Mon, 4 Feb 2019 06:29:13 -0800 (PST) X-Google-Smtp-Source: ALg8bN6Iumn6/IXO0w0L4etKDrFvnFbP1QUez0PZbH6L8zUsTV2tRBDIRVMVvRy762vcfA2PRqpy X-Received: by 2002:a63:b30f:: with SMTP id i15mr46763813pgf.240.1549290552930; Mon, 04 Feb 2019 06:29:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549290552; cv=none; d=google.com; s=arc-20160816; b=zm0KmQNo57ERt3VqONgDHbXclmLq/QVR4d03YPt93NCoO/xJ5yuDJOjdkiXBYNr5HP NAXXrSlTQa3c/pyPVjSevFSnl7rR+xu5heVrh+M3Ns6HTxakLVklfu+itu1xNS3CD/rg Hn+BK6Ydp7q2CeZC7qTZuE1vDRu4Llc5tEqowIvlrt5SoxUbKjboNqUwyDaXRfZ7BRAa XWN62xvfdTU6T/RWcVlPjv3a/o0WaUNGbKG18I8JQjzmMTfDDiDhbU7ag/399JcOUYAW zhglUz810hkORZMHJV9tSqxXYMrt4kwCbrCv1eryydM0G5Gtw72dJ/c9YXnv0whZ/qpw Mesg== 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=ToBUvvYTHdJAQD4RgdWbNZZziJbM10x3H3HTVmKuulU=; b=eTp0j7w3K3h5PsLMH/4XHVUFkTOWy7UCnnuIKkftYj6WB9TkqgIuosFL8K/cx5xVzf kfZ/tNX43epn1FcoOro53LhetLON5c/lrQpLVgKvhBPF0cTOF9K5Irtq+jD7DdgrG9OP jDunBYXIUo1LpYP2F/66Cwg7NRPNnZjk3/cy3o/ErYPUC9amzvmJ6axKGIkJC2cJvgXD 8MS5xLHu0HEd5k/uAALzvX+Jdz3oui3dKDroxT2FA+U86eKp5fvm2goKEiTC5NgS1tQU Uk+MIEnhtEwc9TEVO9DvvoCR04iJK0cMzI5itvHKhaHurtQOq7PeN6NMgVKZExjQzYjp Q4zg== 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 d23si134229pgj.558.2019.02.04.06.28.56; Mon, 04 Feb 2019 06:29:12 -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 S1731292AbfBDNWL (ORCPT + 99 others); Mon, 4 Feb 2019 08:22:11 -0500 Received: from lhrrgout.huawei.com ([185.176.76.210]:32863 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727950AbfBDNWL (ORCPT ); Mon, 4 Feb 2019 08:22:11 -0500 Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id A5758746AE9CE44AB664; Mon, 4 Feb 2019 13:22:09 +0000 (GMT) Received: from [10.204.65.155] (10.204.65.155) by smtpsuk.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 4 Feb 2019 13:21:59 +0000 Subject: Re: [PATCH v9 6/6] tpm: pass an array of tpm_extend_digest structures to tpm_pcr_extend() To: Jarkko Sakkinen CC: Mimi Zohar , , , , , , , , References: <20190201100641.26936-1-roberto.sassu@huawei.com> <20190201100641.26936-7-roberto.sassu@huawei.com> <1549048506.6993.73.camel@linux.ibm.com> <9f8a64d6-d566-1497-1d2b-465440cdfa80@huawei.com> <20190204120746.GG26799@linux.intel.com> From: Roberto Sassu Message-ID: <8b519a73-eb76-c700-69bc-17f7788cca08@huawei.com> Date: Mon, 4 Feb 2019 14:21:59 +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: <20190204120746.GG26799@linux.intel.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.204.65.155] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2/4/2019 1:07 PM, Jarkko Sakkinen wrote: > On Mon, Feb 04, 2019 at 10:14:38AM +0100, Roberto Sassu wrote: >> On 2/1/2019 8:15 PM, Mimi Zohar wrote: >>> Hi Roberto, >>> >>> Sorry for the delayed review.  A few comments inline below, minor >>> suggestions. >>> >>>> diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h >>>> index cc12f3449a72..e6b2dcb0846a 100644 >>>> --- a/security/integrity/ima/ima.h >>>> +++ b/security/integrity/ima/ima.h >>>> @@ -56,6 +56,7 @@ extern int ima_policy_flag; >>>> extern int ima_hash_algo; >>>> extern int ima_appraise; >>>> extern struct tpm_chip *ima_tpm_chip; >>>> +extern struct tpm_digest *digests; >>>> /* IMA event related data */ >>>> struct ima_event_data { >>>> diff --git a/security/integrity/ima/ima_init.c b/security/integrity/ima/ima_init.c >>>> index 6bb42a9c5e47..296a965b11ef 100644 >>>> --- a/security/integrity/ima/ima_init.c >>>> +++ b/security/integrity/ima/ima_init.c >>>> @@ -27,6 +27,7 @@ >>>> /* name for boot aggregate entry */ >>>> static const char boot_aggregate_name[] = "boot_aggregate"; >>>> struct tpm_chip *ima_tpm_chip; >>>> +struct tpm_digest *digests; >>> >>> "digests" is used in the new ima_init_digests() and in >>> ima_pcr_extend().  It's nice that the initialization routines are >>> grouped together here in ima_init.c, but wouldn't it better to define >>> "digests" in ima_queued.c, where it is currently being used? >>>  "digests" could then be defined as static. >> >> 'digests' and ima_init_digests() can be moved to ima_queue.c, but I have >> to add the definition of ima_init_digests() to ima.h. Should I do it? >> >> >>>> /* Add the boot aggregate to the IMA measurement list and extend >>>> * the PCR register. >>>> @@ -104,6 +105,24 @@ void __init ima_load_x509(void) >>>> } >>>> #endif >>>> +int __init ima_init_digests(void) >>>> +{ >>>> + int i; >>>> + >>>> + if (!ima_tpm_chip) >>>> + return 0; >>>> + >>>> + digests = kcalloc(ima_tpm_chip->nr_allocated_banks, sizeof(*digests), >>>> + GFP_NOFS); >>>> + if (!digests) >>>> + return -ENOMEM; >>>> + >>>> + for (i = 0; i < ima_tpm_chip->nr_allocated_banks; i++) >>>> + digests[i].alg_id = ima_tpm_chip->allocated_banks[i].alg_id; >>>> + >>>> + return 0; >>>> +} >>>> + >>>> int __init ima_init(void) >>>> { >>>> int rc; >>>> @@ -125,6 +144,9 @@ int __init ima_init(void) >>>> ima_load_kexec_buffer(); >>>> + rc = ima_init_digests(); >>> >>> Ok. Getting the tpm chip is at the beginning of this function. >>>  Deferring allocating "digests" to here, avoids having to free memory >>> on failure. >>> >>> ima_load_kexec_buffer() restores prior measurements, but doesn't >>> extend the TPM.  For anyone reading the code, a short comment above >>> ima_load_kexec_buffer() would make sense. >> >> Ok. Should I resend the last patch again with the fixes you suggested? > > Send the full patch set. For me it is easier then to apply the series > rather than cherry-picking patches from random versions of the patch > set. I can include your fix in patch 4/6, if you prefer. Roberto > /Jarkko > -- HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Bo PENG, Jian LI, Yanli SHI