Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759244AbbFBOgS (ORCPT ); Tue, 2 Jun 2015 10:36:18 -0400 Received: from mga03.intel.com ([134.134.136.65]:10731 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758792AbbFBOgL (ORCPT ); Tue, 2 Jun 2015 10:36:11 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,540,1427785200"; d="scan'208";a="703968943" Date: Tue, 2 Jun 2015 17:36:05 +0300 From: Jarkko Sakkinen To: Peter Huewe Cc: jgunthorpe@obsidianresearch.com, safford@us.ibm.com, Marcel Selhorst , "moderated list:TPM DEVICE DRIVER" , open list Subject: Re: [PATCH] tpm: introduce struct tpm_buf Message-ID: <20150602143605.GA6493@jsakkine-mobl1> References: <1433250262-17200-1-git-send-email-jarkko.sakkinen@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2748 Lines: 83 On Tue, Jun 02, 2015 at 03:18:54PM +0200, Peter Huewe wrote: > Hi, > > Betreff: [PATCH] tpm: introduce struct tpm_buf > > This patch introduces struct tpm_buf that provides a string buffer for > > constructing TPM commands. This allows to construct variable sized TPM > > commands. This feature is needed for TPM 2.0 commands in order to allow > > policy authentication and algorithmic agility. > > > > The commands in the tpm2-cmd.c have been updated to use struct tpm_buf. > > Lots of awkward length calculations could be dropped because the buffer > > knows its length. > > > > The code is is along the lines of the string buffer code in > > security/trusted/trusted.h. > > > > > --- a/drivers/char/tpm/tpm.h > > +++ b/drivers/char/tpm/tpm.h > > @@ -382,6 +382,93 @@ struct tpm_cmd_t { > > tpm_cmd_params params; > > } __packed; > > > > +/* A string buffer type for constructing TPM commands. This is based on the > > + * code in security/keys/trusted.h. > > + */ > > + > > +#define TPM_BUF_SIZE 512 > Where does 512 come from? What about longer commands? Isn't TPM_BUF_SIZE defined elsewhere as 4096? No matter which algorithm we use for trusted keys, 512 bytes is enough for command and response and trusted keys is the most demanding use case for TPM at the moment. I chose this buffer size because I can still get away without using heap, which is nice for some use cases that should be resistant to failure (suspend/resume mainly). This was the buffer size also used in security/keys/trusted.c that contains TPM 1.x based trusted keys (that I hope will migrate to TPM driver soon). However, if there is rationale to use a larger buffer size and heap, I'm welcome for counter opinions. > > > > + > > +struct tpm_buf { > > + u8 data[TPM_BUF_SIZE]; > > +}; > > + > > > +static inline void tpm_buf_append(struct tpm_buf *buf, > > + const unsigned char *data, > > + unsigned int len) > > +{ > > + struct tpm_input_header *head = (struct tpm_input_header *) buf->data; > > + > > + BUG_ON((len + tpm_buf_length(buf)) > TPM_BUF_SIZE); > > + > > + memcpy(&buf->data[tpm_buf_length(buf)], data, len); > > + head->length = cpu_to_be32(tpm_buf_length(buf) + len); > > +} > > + > > +static inline void tpm_buf_store(struct tpm_buf *buf, > > + unsigned int pos, > > + const unsigned char *data, > > + unsigned int len) > > +{ > > + BUG_ON((pos + len) > TPM_BUF_SIZE); > > + > > + memcpy(&buf->data[pos], data, len); > Isn't the updating of the length missing? > > +} > > Thanks, > Peter /Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/