Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932869AbbFIMF6 (ORCPT ); Tue, 9 Jun 2015 08:05:58 -0400 Received: from mga03.intel.com ([134.134.136.65]:45373 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752586AbbFIMFk (ORCPT ); Tue, 9 Jun 2015 08:05:40 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,579,1427785200"; d="scan'208";a="743581451" Date: Tue, 9 Jun 2015 15:05:33 +0300 From: Jarkko Sakkinen To: Peter Huewe Cc: "moderated list:TPM DEVICE DRIVER" , safford@us.ibm.com, open list Subject: Re: [tpmdd-devel] [PATCH v2] tpm: introduce struct tpm_buf Message-ID: <20150609120533.GA3694@jsakkine-mobl1> References: <1433349555-30868-1-git-send-email-jarkko.sakkinen@linux.intel.com> <201506082239.33639.PeterHuewe@gmx.de> <20150609091932.GC4968@jsakkine-mobl1> <1C403FBE-76FF-425C-8627-5956838CD560@gmx.de> <20150609113913.GA1079@jsakkine-mobl1> <41179E5D-88E5-46B0-BEB8-6D759F917BDD@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41179E5D-88E5-46B0-BEB8-6D759F917BDD@gmx.de> 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: 1818 Lines: 54 On Tue, Jun 09, 2015 at 01:58:59PM +0200, Peter Huewe wrote: > > > Am 9. Juni 2015 13:39:13 MESZ, schrieb Jarkko Sakkinen : > >On Tue, Jun 09, 2015 at 12:32:57PM +0200, Peter Huewe wrote: > >> > >> > >> Hi > >> > >> >> > +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); > >> >> > +} > >> >> > >> >> Don't you have to update the ->length here? > >> > > >> >No. Store is for placing value in position, not appending to the > >end. > >> > > >> Then either add a length check (whether ->length is big enough) > >and/or > >> call the function "update" > > > >There is a length check in the beginning (first line of the function > >body). > > > Nope. > The check in the first line checks whether the write is <= the max > buffer size, but not <= head->length. > > Since head->length is not updated (as per design) it is possible to > write data without effect using this function. This is not what I > expect from an API. > > > Example I create a buffer using tpm_buf_append with 12 bytes, so > head->length == 12 Then I use tpm_buf_store at pos 10 and len 4 --> in > the buffer are 14 bytes, but tpm_buf_length will only report 12 bytes. > > Which is not what I would expect and your current check dies not prevent this. Aah. Right. A valid point. I'll add this check to the invariant. /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/