linux-kernel - Re: [PATCH 0/4] tpm: lazy flush for the session null key

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <D47GBS5ZGNPC.3IRSGEBQGJURI@kernel.org>
Date: Mon, 16 Sep 2024 08:16:04 +0300
From: "Jarkko Sakkinen" <jarkko@...nel.org>
To: "Pengyu Ma" <mapengyu@...il.com>
Cc: <linux-integrity@...r.kernel.org>,
 <James.Bottomley@...senpartnership.com>, <roberto.sassu@...wei.com>, "Peter
 Huewe" <peterhuewe@....de>, "Jason Gunthorpe" <jgg@...pe.ca>, "open list"
 <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/4] tpm: lazy flush for the session null key

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 
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