Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp5758796imd; Wed, 31 Oct 2018 01:19:05 -0700 (PDT) X-Google-Smtp-Source: AJdET5fT7EqkS8UoVNNds3hWZUu6NC6KwaS8KW9MdnuqtgL6q8DhWQ8efQX/SgJJHo+M1KyHEb1/ X-Received: by 2002:a63:7cf:: with SMTP id 198mr2215217pgh.129.1540973945486; Wed, 31 Oct 2018 01:19:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540973945; cv=none; d=google.com; s=arc-20160816; b=soH1K0v/Upzt9ULkJFb1PzLDy5KYE0QD6tATLF1YYCk+OrmcbjS9yoFISSdqmBQQKc bIVl8sY0ruN+jXqCmdC4TozUQNopcmUUSUOkllpvLjisbUbMKFDod+Dd8YdluhjZhFA9 dNpyeP0g/hIbLwYMIsqfCq6EGcAQXytSLpw1j4cOvRVKcpKI9vBqIj9Zsze23t/ute1K e56hPKfKedK2q6eJr1YX53Z57V+E//imnJrnE//NSPPzD4hC557SBaB3FyfEVYxMAHDk fJKC2tODEluR49+kbyh6yL07A6/Y9rz6yo5gAigIZ3wjL+k8gcmiNvtiqkA5ZNwnLZ35 P+Pw== 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=1rgyhrq5ygB5Jv0rovEAAM4xCJn418CSEhB/luZSIc4=; b=lKqX2fovUQjRvgi49ZoDJGslPOJcTvbfv35EZw2zHF+LxMRgn/x8tt/TFMr0FJ3fpa 38pxLUOM7bcqH4+7vO6GfjMoK2TvD9GLseZG3kebcYbPP0sEQVhVfliwEjAbCtRbD3oL RXJbvuTIFft1U3d6mTbhaISYQwx3gUQKuq1gxBF5YO1g9FvoOqo8INaq9fg2ME3D86Cq INHIa5TTfSvgg0wWSl3G+RnVG1o7ACAXhyC7fdbf/x0euC6qXyD3WKb+Ftc2TJQvSYlQ IcmHEZAK33gmVqS3NprIN11zxuTAgMEUZYLWn6/gBMTl61bIYk5OLTTbA5GhF74bvB/P 5ubA== 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 x21-v6si25379653pll.221.2018.10.31.01.18.50; Wed, 31 Oct 2018 01:19:05 -0700 (PDT) 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 S1727573AbeJaRON (ORCPT + 99 others); Wed, 31 Oct 2018 13:14:13 -0400 Received: from lhrrgout.huawei.com ([185.176.76.210]:32709 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727020AbeJaRON (ORCPT ); Wed, 31 Oct 2018 13:14:13 -0400 Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 1D5F2325EA7D7; Wed, 31 Oct 2018 08:17:05 +0000 (GMT) Received: from [10.204.65.163] (10.204.65.163) by smtpsuk.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 31 Oct 2018 08:16:57 +0000 Subject: Re: [PATCH v3 5/5] tpm: ensure that output of PCR read contains the correct digest size To: Jarkko Sakkinen CC: , , , , References: <20181030154711.2782-1-roberto.sassu@huawei.com> <20181030154711.2782-6-roberto.sassu@huawei.com> From: Roberto Sassu Message-ID: <7adca046-ae80-7453-9fee-a802b46ceb86@huawei.com> Date: Wed, 31 Oct 2018 09:16:53 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.204.65.163] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/30/2018 8:52 PM, Jarkko Sakkinen wrote: > On Tue, 30 Oct 2018, Roberto Sassu wrote: >> This patch ensures that the digest size returned by the TPM during a PCR >> read matches the size of the algorithm passed as argument to >> tpm2_pcr_read(). The check is performed after information about the PCR >> banks has been retrieved. >> >> Signed-off-by: Roberto Sassu > > What is the scenarion when this can happen (should be explained in > the commit message)? Without an HMAC session, the request/response payload can be modified. This patch ensures that the digest size in the payload is equal to the size of the algorithm specified by the caller. Patch 3/5 only ensures that there is no buffer overflow when data is copied to the tpm_digest structure passed by the caller. Patch 5/5 uses the PCR bank information introduced in patch 4/5 to ensure that the exact amount of data is copied from the response payload. However, the patch may not help because an attacker can modify the algorithm in the request payload so that the TPM returns a shorter digest. For me it is ok to remove this patch from the set. It was requested by Mimi. Roberto -- HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Bo PENG, Jian LI, Yanli SHI