Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp8710909imu; Thu, 15 Nov 2018 16:27:29 -0800 (PST) X-Google-Smtp-Source: AJdET5fVvqzLGIPISLNsqH4S0me42WNALZGNmaX0YnB+TCLDgnl4LdyiB1b8qe3wsomBJ3jvOHJO X-Received: by 2002:a63:3e05:: with SMTP id l5mr7347115pga.96.1542328049396; Thu, 15 Nov 2018 16:27:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542328049; cv=none; d=google.com; s=arc-20160816; b=pnJwHU37yFYLZwfvapUYnu1QcN/0Xq+Oy1j3YbRcj0x8XoXLFy93WimJIU3GHEi9Fl b3mlx9hbj9d2fn4PpGB+DhIRH7acgridmy4HbRYq01/AblrU25lVShFCZays4bMd8EO2 d76DmQi9+ZgPGpYbzvoIdv+6lvQFLE4qKMSr1/AgsE4o1nDOLbtnoX12JNgqlX4XWnYt 5rooQA/4OEy1nrhk1nh08mzdVdaw/EVluaA5hOduvlVRAlTsIVbG/69s30ts/3Vxlnin WneJ2xPRm0jLXNXYc6OYIekziPN6OOkSr8LI0pwZLEZM55rqs/M78hrBAidxyibgB1mk P9lQ== 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:autocrypt:openpgp:from:references:cc:to:subject; bh=ZBM0WtLrjdevm4jICEuijuNs3mYgyjhrfKS7rmrlWeg=; b=zeGLoGt34TBycB0Tyw6QdvoZiMVJkvO8MpM4ufDUoCbX5EKFTyk8/avxi0dkYI+0wx JmgzQv8Iqa0fu9+1X42KqmO6gKb8HovK7udu4cRIcu+wzNUz1GDBRyE/vUgtAAt2Z9jJ LOUKfvKam0RnRpFturLZb58jCF9TnXYNRR8SEjt8iED/L5KC9Ot2LTrcttcwTXKsqYWn f/vjuKKgVO11rcE8jp6sjVcOwoXJB+DLCNnDjvpWHFTBGAdC20Qp/rRR6VTwSM+B7nDU apD6XAVnzViFJG+v8OzwbksxWYf+LEk2IMLcO6/vdpjHJCXNMwLCyAe6wCpwEi6nuRWM pdhw== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m16-v6si34504625pfd.160.2018.11.15.16.27.14; Thu, 15 Nov 2018 16:27:29 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389114AbeKPKgn (ORCPT + 99 others); Fri, 16 Nov 2018 05:36:43 -0500 Received: from mga04.intel.com ([192.55.52.120]:17668 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726687AbeKPKgm (ORCPT ); Fri, 16 Nov 2018 05:36:42 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Nov 2018 16:26:34 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,238,1539673200"; d="scan'208";a="250111739" Received: from tstruk-mobl1.jf.intel.com ([10.7.196.53]) by orsmga004.jf.intel.com with ESMTP; 15 Nov 2018 16:26:33 -0800 Subject: Re: [PATCH v3] tpm: add support for partial reads To: Jarkko Sakkinen Cc: jgg@ziepe.ca, linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org References: <154231454280.17567.455994477207265338.stgit@tstruk-mobl1.jf.intel.com> <20181115233158.GA30018@linux.intel.com> From: Tadeusz Struk Openpgp: preference=signencrypt Autocrypt: addr=tadeusz.struk@intel.com; prefer-encrypt=mutual; keydata= xsDiBEiLICMRBADteQacQxypsuFvAw6IwYzbD8pgQi+kLYBcqfGgVAUN/cO+sLl6u1lVdaDB fhAArdbV9lpoqcWnmhQFTb4A+W569EpydBr6nuatWkEB+fmmx8YoUtuZfXt7v+1l1rc09kaW LY+TkwQkvFCeuvdasgmBLnmRWymEGWi1E12hUgTw/wCgtK24geC7XkiuANMv0gpr+raOgQMD /2yJZ0SeXQApWyTRaeIYN8GgYHZTWuBp/ofN+viEkhrDxahcaGPP5B/Nv6VS1+M0e5m8OzHj qPUbgfyOeJcslC5aoZdqqqzVWVLaA/+Jy+O+6T3k3R/IryVVATldBlwnGFDhET0mKQsd15zt cIdQBBbfSFR5VlugZuWV5q442IpPA/4g7nen9FFPxh45Te8D54hAsOCywjm6xUE0UJGYHeJ/ MXCPtuXfVCbYcOxZVH7kUS2Vtk5d3bF40IE2WnVq1ZScNANF4ZjikxYhYGfNWX3HXak1gSoj UrY87rMSjPIAry4L0BoIx2qgL/k4iV/3QcXL4t5wosU0iw++suf1zGGcKM0gVGFkZXVzeiBT dHJ1ayA8dHN0cnVrQGdtYWlsLmNvbT7CYwQTEQIAIwIbAwYLCQgHAwIEFQIIAwQWAgMBAh4B AheABQJQTjJTAhkBAAoJEDFswfskq9xyqvcAoI2nsaUCX8ZGbu+Jhq+++qlBFJ2rAJ983RoO R2ofHhn3g3Qi4K34tw0l087BTQRauzUlARAAqkWRL/InEPnoGMg/gw/CRaDBaIBgMsvIcghI 7xevIzpleXt6jKHghSBooH+zaT7qi4u2gkgPn4odsER3Rm94XgrZJgoqls6EpKMWpJNGP4HT eYgykhfsZOLX8ijUbjTM/Sm/dZVo6aYoBL2+ciJwyl+Zt3Mp6un3/GWu6cA9005V50pRqO7j PTlVCHi2bedcEEf5DDsYJv/3Oz8/4LpSf6BL6BltjeZVa2y03dTMmD031JTH+OuyJm1yh72Z HWxhlYNXOv6uFJJVr+paQjrAsBVIYKhK24bD+uGJxLm8AN9i7/Si+2YeSsXvKUhk9mIoFBnU VFo63cziRTcpRu/kXgDAbujwN88qytEcvhEZHS6B9vdws+lhTpolEjkLCkz0Y59z4Fs9srKy QkRN+wtdiLgrwyDW3ryAKxcDmOumGWebDxpaOI/pBhrlS93HmDlvj7JmgTUU4a/NhwI3dXh5 pn8FZzZyVXe3Kc3bu5T3UAC7uztinsAvCJQS6jGZWrXmXkqYkaLXQOw61eInWjr01zE/zDbE mdJPM0+va/gtZx9TtGxr4PpjbqswqCiubLDZXZHh5uqArPv/i+E8aXIsNSTN6Rrqs1j9YgDN ALksibv6+tXH3sOlCUgjuZgJH3+s/mnaAtiV2rZ/WlH15d6nd0uiDSZrKhlR+g4NHMh1ztEA EQEAAcJPBBgRAgAPBQJauzUlAhsMBQkJZgGAAAoJEDFswfskq9xyfv8AoI8aPrJCoM0h5WOP kKxMmPEPHzUNAJ9jBBYXhX1CWg+IhI7i/fLlI0vwCA== Message-ID: <825f4c01-efb1-5034-ea90-9ea5ea8f5b45@intel.com> Date: Thu, 15 Nov 2018 16:26:33 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: <20181115233158.GA30018@linux.intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/15/18 3:31 PM, Jarkko Sakkinen wrote: > You could drop these memset() calls and also one from > tpm_timeout_work(). The call could be done once in the beginning of > tpm_common_write() instead of having three different call sites. > Don't we want to clean the buffer as the response is read? When we will only memset it in write and if one would send just one command there will only be one response. The data will sit in the buffer until the next command. There will be a quite bit time window when the data can leak. > > Naming becomes a mess and the comment for data_pending variable is > incorrect as it is also used for synchronous operation. > > Maybe add a prepending commit to rename it as > > /* Holds the resul of the tpm_transmit() last call. */ > ssize_t transmit_result; Agree, will do that. > > That is at least clear and obvious on what it contains. > > The comment for partial_data is incorrect as the variable does not > contain any data. Yes, I will change it. > > We could use declare: > > /* Holds the count how much of the response is still unread. */ > size_t response_pending; > > Observe another remark from your commit: there is no reaso to ssize_t as > the type as the value should never be a negative number. Yes, in fact now the priv->data_pending can also be only positive. I'll change it and send a new version soon. Thanks, -- Tadeusz