| Message ID | 20240915180448.2030115-1-jarkko@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | tpm: lazy flush for the session null key | expand |
On Sun Sep 15, 2024 at 9:04 PM EEST, Jarkko Sakkinen wrote: > There is no load and flush the null key for every transaction. It only > needs to be flushed when user space accesses TPM. This postpones the > flush up to that point. > > The goal is to take the first step addressing [1]. Other performance > improvements are needed too but this is the most obvious one and > easiest to address. > > [1] https://bugzilla.kernel.org/show_bug.cgi?id=219229 > > Jarkko Sakkinen (4): > tpm: remove file header documentation from tpm2-sessions.c > tpm: address tpm2_create_null_primary() return value > tpm: address tpm2_create_primary() failure > tpm: flush the session null key only when required > > drivers/char/tpm/tpm-chip.c | 13 ++++ > drivers/char/tpm/tpm-dev-common.c | 7 ++ > drivers/char/tpm/tpm-interface.c | 9 ++- > drivers/char/tpm/tpm2-cmd.c | 3 + > drivers/char/tpm/tpm2-sessions.c | 115 ++++++++++-------------------- > include/linux/tpm.h | 2 + > 6 files changed, 68 insertions(+), 81 deletions(-) I did not take any benchmarks yet but I did run this through run-tests.sh in [1] to make sure that it does not break anything. Looking at pseude-code of ContextSave from [2] fixing this is orthogonal from any possible context gap issues as null key is just plain transient object. I would fix the obvious first and then look what can be done to sessions (e.g. global LRU tracking of sessions or similar approach). I don't expect over the top performance improvement with this patch set. [1] https://codeberg.org/jarkko/linux-tpmdd-test [2] https://trustedcomputinggroup.org/wp-content/uploads/TPM-2.0-1.83-Part-3-Commands-Code.pdf BR, Jarkko
After applied your patches, the boot time is ~15 seconds. Less than 20 sec, but still much more than 7 sec when disabling HMAC. Send again in text mode. On Mon, Sep 16, 2024 at 10:25 AM Pengyu Ma <mapengyu@gmail.com> wrote: > > Hi Jarkko, > > After applied your patches, the boot time is ~15 seconds. > Less than 20 sec, but still much more than 7 sec when disabling HMAC. > > Thanks, > Aaron > > > On Mon, Sep 16, 2024 at 2:04 AM Jarkko Sakkinen <jarkko@kernel.org> wrote: >> >> There is no load and flush the null key for every transaction. It only >> needs to be flushed when user space accesses TPM. This postpones the >> flush up to that point. >> >> The goal is to take the first step addressing [1]. Other performance >> improvements are needed too but this is the most obvious one and >> easiest to address. >> >> [1] https://bugzilla.kernel.org/show_bug.cgi?id=219229 >> >> Jarkko Sakkinen (4): >> tpm: remove file header documentation from tpm2-sessions.c >> tpm: address tpm2_create_null_primary() return value >> tpm: address tpm2_create_primary() failure >> tpm: flush the session null key only when required >> >> drivers/char/tpm/tpm-chip.c | 13 ++++ >> drivers/char/tpm/tpm-dev-common.c | 7 ++ >> drivers/char/tpm/tpm-interface.c | 9 ++- >> drivers/char/tpm/tpm2-cmd.c | 3 + >> drivers/char/tpm/tpm2-sessions.c | 115 ++++++++++-------------------- >> include/linux/tpm.h | 2 + >> 6 files changed, 68 insertions(+), 81 deletions(-) >> >> -- >> 2.46.0 >>
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
On Mon, Sep 16, 2024 at 1:16 PM Jarkko Sakkinen <jarkko@kernel.org> wrote: > > 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? > Yes, please feel free to add it. And thanks for the effort and details. BR, Pengyu. > 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