From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1C87E2561AA; Sun, 8 Feb 2026 14:09:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770559753; cv=none; b=FgsWnhQk6+pYp6nPkAI91prdkIAohD9HtDeNng2MleGuf50ohEib+N8u2kD8I/qT9ee3oBIB7/TORsAdHnuqCB/eKs8G1ZoWylzT8KiNoXUXjTDqNMKb3xjn2CHC3yrUcWyVQKnkhGOrVq6SdwUeclmH/0d2ySukFejrAxJGe5Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770559753; c=relaxed/simple; bh=Y7VdEvB6KNDjDlcFT19MDaynWdFHk56AYryt43oMvP4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=AFOOGqZ0RTBvKePIC8GANPboOYhjOnw29TddfMAkFUBQ/dSpmWES91vZ0+zbQoATi9dYt618lGoG9PD4p0JqyDIdk9fNb58uHHC9N4JY84ffSBu2idxXbDM/emQrSKrrtVEg3JlVz93JyVFC7GxgRo5kQ3eSReP595sg88cIYUU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=sX4UAoqb; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="sX4UAoqb" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 68A5FC4CEF7; Sun, 8 Feb 2026 14:09:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1770559753; bh=Y7VdEvB6KNDjDlcFT19MDaynWdFHk56AYryt43oMvP4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=sX4UAoqbaSdTs2rBzopjelmDvVRg4yWCfRa118M+UZXZaFx9EJqyMsX76GzCyPSZW IWAK9aqWtzuWlRhiD9zc02liLD4tdRU7p8vH5H+NSegKHvV0cR34XPoGImqDKACpRK BHCkNVtVOQbmX1lGvBdYu4IUT/1f2Jkp/vjHhAj+DsmhHm2weOV03FLG8D3G1avbzj PdD+kQginaETJik04s/2r/xEJs/S1GDCcx4Nxjsj8elvHLXwCcXWKX7j8ygZCi0SIY PWWXxGjKK8+JYjYVUAjKPpayftZqPFIWnY+ftxtsCAWEWRUXTbj7VNDZeynt13GJu2 dDaBbbrzOzkrQ== Date: Sun, 8 Feb 2026 16:09:08 +0200 From: Jarkko Sakkinen To: linux-integrity@vger.kernel.org Cc: Jarkko Sakkinen , Ross Philipson , Stefan Berger , James Bottomley , Mimi Zohar , David Howells , Paul Moore , James Morris , "Serge E. Hallyn" , "open list:KEYS-TRUSTED" , "open list:SECURITY SUBSYSTEM" , open list Subject: Re: [PATCH v9 11/11] tpm-buf: Implement managed allocations Message-ID: References: <20260125192526.782202-1-jarkko@kernel.org> <20260125192526.782202-12-jarkko@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260125192526.782202-12-jarkko@kernel.org> On Sun, Jan 25, 2026 at 09:25:21PM +0200, Jarkko Sakkinen wrote: > From: Jarkko Sakkinen > > Decouple kzalloc from buffer creation, so that a managed allocation can be > used: > > struct tpm_buf *buf __free(kfree) buf = kzalloc(TPM_BUFSIZE, > GFP_KERNEL); > if (!buf) > return -ENOMEM; > > tpm_buf_init(buf, TPM_BUFSIZE); > > Alternatively, stack allocations are also possible: > > u8 buf_data[512]; > struct tpm_buf *buf = (struct tpm_buf *)buf_data; > tpm_buf_init(buf, sizeof(buf_data)); > > This is achieved by embedding buffer's header inside the allocated blob, > instead of having an outer wrapper. > > Cc: Ross Philipson > Signed-off-by: Jarkko Sakkinen > Reviewed-by: Stefan Berger Since rest of the series does not seem to move forward maybe I should rebase this to bottom and send it as a separate patch? This patch eliminates a category of memory bugs and is that way useful. It also starts to be pretty well stress tested. BR, Jarkko