linux-kernel - Re: [regression] significant delays when secureboot is enabled since 6.10

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: <D46RE2BWMGJ4.25VA7IVYTJ8MO@kernel.org>
Date: Sun, 15 Sep 2024 12:43:35 +0300
From: "Jarkko Sakkinen" <jarkko@...nel.org>
To: "Roberto Sassu" <roberto.sassu@...weicloud.com>, "James Bottomley"
 <James.Bottomley@...senPartnership.com>, "Linux regressions mailing list"
 <regressions@...ts.linux.dev>
Cc: <keyrings@...r.kernel.org>, "linux-integrity@...r.kernel.org"
 <linux-integrity@...r.kernel.org>, "LKML" <linux-kernel@...r.kernel.org>,
 "Pengyu Ma" <mapengyu@...il.com>
Subject: Re: [regression] significant delays when secureboot is enabled
 since 6.10

On Thu Sep 12, 2024 at 11:13 AM EEST, Roberto Sassu wrote:
> @[
>     tpm_transmit_cmd+50
>     tpm2_load_context+161
>     tpm2_start_auth_session+98
>     tpm2_pcr_extend+39
>     tpm_pcr_extend+221
>     ima_add_template_entry+437
>     ima_store_template+114
>     ima_store_measurement+209
>     process_measurement+2473
>     ima_file_check+82
>     security_file_post_open+92
>     path_openat+550
>     do_filp_open+171
>     do_sys_openat2+186
>     do_sys_open+76
>     __x64_sys_openat+35
>     x64_sys_call+9589
>     do_syscall_64+96
>     entry_SYSCALL_64_after_hwframe+118
> , 
>     0x7f03ea0ade55
>     0x55f929b7dac2
>     0x7f03e9fd4b8a
>     0x7f03e9fd4c4b
>     0x55f929b7e9b5
> , cat]: 35928108
> @[
>     tpm_transmit_cmd+50
>     tpm2_start_auth_session+650
>     tpm2_pcr_extend+39
>     tpm_pcr_extend+221
>     ima_add_template_entry+437
>     ima_store_template+114
>     ima_store_measurement+209
>     process_measurement+2473
>     ima_file_check+82
>     security_file_post_open+92
>     path_openat+550
>     do_filp_open+171
>     do_sys_openat2+186
>     do_sys_open+76
>     __x64_sys_openat+35
>     x64_sys_call+9589
>     do_syscall_64+96
>     entry_SYSCALL_64_after_hwframe+118
> , 
>     0x7f03ea0ade55
>     0x55f929b7dac2
>     0x7f03e9fd4b8a
>     0x7f03e9fd4c4b
>     0x55f929b7e9b5
> , cat]: 84616611

These commands and TPM2_CreatePrimary are the ones that give overhead
to the AMD boot-up:

1. TPM2_LoadContext (35 ms)
2. TPM2_StartAuthSession (85 ms)

We can conclude that the implementation is too slow and making it faster
requires a whole set of small improvements. From this basis the only
right fix is to make it opt-in kernel command-line option.

That will give space to make small performance improvements over time,
and not rush. How the session is orchestrated is not production quality,
and the bug gives direct evidence of that.

High-level improvements that could be done over time:

- Do not call start_auth_session() in extend and get_random().
  Orchestrate outside.
- Find places to not close and open session sequentially, e.g.
  with the help of use SA_CONTINUE_SESSION.

When it comes to boot we should aim for one single start_auth_session
during boot, i.e. different phases would leave that session open so
that we don't have to load the context every single time.  I think it
should be doable.

Making all this happen is not a "performance regression fix". It is
set of gradual improvements to the code that is not there yet

On plus side, the kernel command-line option allows the enable the
feature by default during compilation time for all architectures.

I've made my decision on this and will submit a fix for it.

BR, Jarkko