From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 23D8BC25B67 for ; Thu, 26 Oct 2023 17:56:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231245AbjJZR4F (ORCPT ); Thu, 26 Oct 2023 13:56:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60978 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229649AbjJZR4C (ORCPT ); Thu, 26 Oct 2023 13:56:02 -0400 Received: from bedivere.hansenpartnership.com (bedivere.hansenpartnership.com [96.44.175.130]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 34BB11A2 for ; Thu, 26 Oct 2023 10:55:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hansenpartnership.com; s=20151216; t=1698342959; bh=AoxGJ+wBYwrKrdP9vB2wZ9O/z3R0MKu7k+bX0EK20fE=; h=Message-ID:Subject:From:To:Date:In-Reply-To:References:From; b=XJoRIE5+yAGK/Q0gi9XmPd3BMMF0qnoW0dXzrr8Al9EPjhL22fFTei3Vt8lI+AnHC iyPxjppUrDbRPhVDPQbbPR0f3t131ZcTfycp64GEz9PmG3hTHVYqBUDlQUwHi7k+OG QvUR7S4Vz/0HNOljG0VAf+JfzpzIwp1TGGKbNP5U= Received: from localhost (localhost [127.0.0.1]) by bedivere.hansenpartnership.com (Postfix) with ESMTP id 9A4251286BB1; Thu, 26 Oct 2023 13:55:59 -0400 (EDT) Received: from bedivere.hansenpartnership.com ([127.0.0.1]) by localhost (bedivere.hansenpartnership.com [127.0.0.1]) (amavis, port 10024) with ESMTP id WV6ZavWvzbtC; Thu, 26 Oct 2023 13:55:59 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hansenpartnership.com; s=20151216; t=1698342959; bh=AoxGJ+wBYwrKrdP9vB2wZ9O/z3R0MKu7k+bX0EK20fE=; h=Message-ID:Subject:From:To:Date:In-Reply-To:References:From; b=XJoRIE5+yAGK/Q0gi9XmPd3BMMF0qnoW0dXzrr8Al9EPjhL22fFTei3Vt8lI+AnHC iyPxjppUrDbRPhVDPQbbPR0f3t131ZcTfycp64GEz9PmG3hTHVYqBUDlQUwHi7k+OG QvUR7S4Vz/0HNOljG0VAf+JfzpzIwp1TGGKbNP5U= Received: from lingrow.int.hansenpartnership.com (unknown [IPv6:2601:5c4:4302:c21::c14]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by bedivere.hansenpartnership.com (Postfix) with ESMTPSA id 1181A1286B29; Thu, 26 Oct 2023 13:55:57 -0400 (EDT) Message-ID: Subject: Re: [PATCH v3 1/6] tpm: Move buffer handling from static inlines to real functions From: James Bottomley To: Jerry Snitselaar , Jarkko Sakkinen Cc: linux-integrity@vger.kernel.org, keyrings@vger.kernel.org, William Roberts , Stefan Berger , David Howells , Jason Gunthorpe , Mimi Zohar , Peter Huewe , Mario Limonciello , Julien Gomes , open list Date: Thu, 26 Oct 2023 13:55:55 -0400 In-Reply-To: References: <20231024011531.442587-1-jarkko@kernel.org> <20231024011531.442587-2-jarkko@kernel.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.4 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2023-10-26 at 10:10 -0700, Jerry Snitselaar wrote: > On Wed, Oct 25, 2023 at 08:35:55PM +0300, Jarkko Sakkinen wrote: > > On Wed Oct 25, 2023 at 12:03 PM EEST, Jerry Snitselaar wrote: > > > Reviewed-by: Jerry Snitselaar > > > > On Wed, 2023-10-25 at 02:03 -0700, Jerry Snitselaar wrote: > > > Reviewed-by: Jerry Snitselaar > > > > > > > Thanks I'll add it to the next round. > > > > For the tpm_buf_read(), I was thinking along the lines of: > > > > /** > >  * tpm_buf_read() - Read from a TPM buffer > >  * @buf:        &tpm_buf instance > >  * @pos:        position within the buffer > >  * @count:      the number of bytes to read > >  * @output:     the output buffer > >  * > >  * Read bytes from a TPM buffer, and update the position. Returns > > false when the > >  * amount of bytes requested would overflow the buffer, which is > > expected to > >  * only happen in the case of hardware failure. > >  */ > > static bool tpm_buf_read(const struct tpm_buf *buf, off_t *pos, > > size_t count, void *output) > > { > >         off_t next = *pos + count; > > > >         if (next >= buf->length) { > >                 pr_warn("%s: %lu >= %lu\n", __func__, next, > > *offset); > >                 return false; > >         } > > > >         memcpy(output, &buf->data[*pos], count); > >         *offset = next; > >         return true; > > } > > > > BR, Jarkko > > > > Then the callers will check, and return -EIO? Really, no, why would we do that? The initial buffer is a page and no TPM currently can have a command that big, so if the buffer overflows, it's likely a programming error (failure to terminate loop or something) rather than a runtime one (a user actually induced a command that big and wanted it to be sent to the TPM). The only reason you might need to check is the no-alloc case and you passed in a much smaller buffer, but even there, I would guess it will come down to a coding fault not a possible runtime error. James