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 EA72117C6C; Mon, 16 Sep 2024 05:16:08 +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=1726463769; cv=none; b=fouohTAxIhZFEsI2cpTYHlY5ssokwF4ZNdERg/L2nZtEkvuOK96R6+mC0lb4lKA+CRbmpV2ZOYecIYGcd0kk2U7VaybHPKw5voyoh2tMIHvrFESe/l3c38Zph9TvnJUfedzlVuyuN3FYTCi93Gy5fsHQLBQK29gANEP8ZZ1sdvc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1726463769; c=relaxed/simple; bh=vvZ8k9hQDToFD2OaOTfacHZqXgJx9ZtN2s+yDabkp6o=; h=Mime-Version:Content-Type:Date:Message-Id:To:Cc:Subject:From: References:In-Reply-To; b=qgAraAX0P84ZVPFiiQA21ModIz0N3jZl0cCzC4u8jf/V1q3D+1Hx/ZOAZ7ouoBQEa+Ek2/r4/nidcYO0Pfce5SIkPG5EYXJTUrv/XC9nHXpD55VkBU5LJv1OMp88uQhorw21v1eIchRndpI61fTy5vz+2gD49jGRqv+2eTEttX8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=DgF5l6tt; 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="DgF5l6tt" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EFA98C4CEC4; Mon, 16 Sep 2024 05:16:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1726463768; bh=vvZ8k9hQDToFD2OaOTfacHZqXgJx9ZtN2s+yDabkp6o=; h=Date:To:Cc:Subject:From:References:In-Reply-To:From; b=DgF5l6tt4B0ppnxeTZncFtw91SDoNMFoxngETAhM8VAdkUt7UObQMbredWJjpZce5 yIen9OXRrEc6KS/nqOohNv5bY2EtOq568H65kkFUDfbmhhv9wfO1reuKzoKq+pvd/n Km8wyP0UwZ5E/MIAcPDnoxwFD+HdrQhU0VbKz2NawGj9FOlUVpMuCAAwdWf+0DVD0C 9Rcx9DWEJdBFypUp9N7AWWheafP+P5GMYcSYlx4xSTzwwCgzLIWy4jCfkSjqu89EXQ Lr6DbjslUM3qLLeHz+rN7X19GWJZdcJND41O1IrThgI3B9zn5QxGem3/EO+/K6iEFT zCBRtbRJmNgnQ== Precedence: bulk X-Mailing-List: linux-integrity@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Mon, 16 Sep 2024 08:16:04 +0300 Message-Id: To: "Pengyu Ma" Cc: , , , "Peter Huewe" , "Jason Gunthorpe" , "open list" Subject: Re: [PATCH 0/4] tpm: lazy flush for the session null key From: "Jarkko Sakkinen" X-Mailer: aerc 0.18.2 References: <20240915180448.2030115-1-jarkko@kernel.org> In-Reply-To: On Mon Sep 16, 2024 at 5:33 AM EEST, Pengyu Ma wrote: > After applied your patches, the boot time is ~15 seconds. > Less than 20 sec, but still much more than 7 sec when disabling HMAC. Great, and thank you for testing this. I did expect it to fully address the issue but it is on the direct path. It took me few days to get my testing environment right before moving forward [1], mainly to get bpftrace included, thus the delay. Do you mind if I add tested-by for the for this one? Before the patch set the in-kernel TPM sequences were along the lines of: 1. Load the null key. 2. Load the auth session. 3. Do stuff with overhead from encryption. 4. Save the session. 5. Save the null key. With the changes: 1. Load the session. 2. Do stuff with overhead from encryption. 3. Save the session. Each swapped session gets an increasing count. If the count grows over treshold measured by the difference of the count in the latest loaded session and the session currently being saved, then TPM throws out=20 a context gap error. It has a limited resolution for this. As long as /dev/tpm0 is not opened by any process, there is only one session open (or at least fixed pre-determined number moving forward). This means that context gap error cannot occur, as the only session saved is the auth session. I'll implement a patch on top of this, which does exactly this: track the number of open /dev/tpm{rm0}. Only when the device is open, the auth session is flushed. With this change the sequence reduces to: 1. Do stuff with overhead from encryption. Since the results are promising (thanks to you), I create a new version of this patch set with this additional fix. There's no chance to reach the same exact boot-up time as without encryption but I think we might be able to reach a reasonable cost. [1] https://codeberg.org/jarkko/linux-tpmdd-test BR, Jarkko