Dear Linux folks,
Trying to optimize the boot time of Linux on the Dell XPS 13 9360,
probing of MSFT0101:00 takes 52 ms, making `init_tis()` taking almost 10
% alone until starting the initrd:
[ 0.000000] Linux version 6.8.0-rc4
([email protected]) (gcc (Debian 13.2.0-13) 13.2.0,
GNU ld (GNU Binutils for Debian) 2.42) #20 SMP PREEMPT_DYNAMIC Mon Feb
12 09:40:49 CET 2024
[…]
[ 0.000000] DMI: Dell Inc. XPS 13 9360/0596KF, BIOS 2.21.0
06/02/2022
[…]
[ 0.320057] calling init_tis+0x0/0x100 @ 1
[ 0.332190] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 4)
[ 0.372164] probe of MSFT0101:00 returned 0 after 52101 usecs
[ 0.372186] initcall init_tis+0x0/0x100 returned 0 after 52127 usecs
[…]
[ 0.588643] Freeing unused decrypted memory: 2036K
[ 0.589068] Freeing unused kernel image (initmem) memory: 3976K
[ 0.606115] Write protecting the kernel read-only data: 22528k
[ 0.606527] Freeing unused kernel image (rodata/data gap)
memory: 276K
[ 0.652327] x86/mm: Checked W+X mappings: passed, no W+X pages
found.
[ 0.652329] x86/mm: Checking user space page tables
[ 0.695968] x86/mm: Checked W+X mappings: passed, no W+X pages
found.
[ 0.696104] Run /init as init process
[…]
For users, where boot time is most important, can this be moved out of
the hot path somehow?
Kind regards,
Paul
On Wed Feb 14, 2024 at 3:10 PM UTC, Paul Menzel wrote:
> Dear Linux folks,
>
>
> Trying to optimize the boot time of Linux on the Dell XPS 13 9360,
> probing of MSFT0101:00 takes 52 ms, making `init_tis()` taking almost 10
> % alone until starting the initrd:
>
> [ 0.000000] Linux version 6.8.0-rc4
> ([email protected]) (gcc (Debian 13.2.0-13) 13.2.0,
> GNU ld (GNU Binutils for Debian) 2.42) #20 SMP PREEMPT_DYNAMIC Mon Feb
> 12 09:40:49 CET 2024
> […]
> [ 0.000000] DMI: Dell Inc. XPS 13 9360/0596KF, BIOS 2.21.0
> 06/02/2022
> […]
> [ 0.320057] calling init_tis+0x0/0x100 @ 1
> [ 0.332190] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 4)
> [ 0.372164] probe of MSFT0101:00 returned 0 after 52101 usecs
> [ 0.372186] initcall init_tis+0x0/0x100 returned 0 after 52127 usecs
> […]
> [ 0.588643] Freeing unused decrypted memory: 2036K
> [ 0.589068] Freeing unused kernel image (initmem) memory: 3976K
> [ 0.606115] Write protecting the kernel read-only data: 22528k
> [ 0.606527] Freeing unused kernel image (rodata/data gap)
> memory: 276K
> [ 0.652327] x86/mm: Checked W+X mappings: passed, no W+X pages
> found.
> [ 0.652329] x86/mm: Checking user space page tables
> [ 0.695968] x86/mm: Checked W+X mappings: passed, no W+X pages
> found.
> [ 0.696104] Run /init as init process
> […]
>
> For users, where boot time is most important, can this be moved out of
> the hot path somehow?
It can't be IRQ probing as IRQ's are *disabled* by default. So we can
disclose that.
I think the delay is caused by tpm2_probe(), which is called by
tpm_tis_core_init(). It sends an idempotent TPM2 command to the TPM
chip to know whether it is TPM 1.x or TPM2 chip.
That detection is definitely required.
Even some other subsystems in the kernel require to know the correct
TPM version, like hwrng and IMA.
> Kind regards,
>
> Paul
BR, Jarkko
Dear Jarkko,
Thank you for your reply.
Am 16.02.24 um 23:07 schrieb Jarkko Sakkinen:
> On Wed Feb 14, 2024 at 3:10 PM UTC, Paul Menzel wrote:
>> Trying to optimize the boot time of Linux on the Dell XPS 13 9360,
>> probing of MSFT0101:00 takes 52 ms, making `init_tis()` taking almost 10
>> % alone until starting the initrd:
>>
>> [ 0.000000] Linux version 6.8.0-rc4 ([email protected]) (gcc (Debian 13.2.0-13) 13.2.0,
>> GNU ld (GNU Binutils for Debian) 2.42) #20 SMP PREEMPT_DYNAMIC Mon Feb 12 09:40:49 CET 2024
>> […]
>> [ 0.000000] DMI: Dell Inc. XPS 13 9360/0596KF, BIOS 2.21.0 06/02/2022
>> […]
>> [ 0.320057] calling init_tis+0x0/0x100 @ 1
>> [ 0.332190] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 4)
>> [ 0.372164] probe of MSFT0101:00 returned 0 after 52101 usecs
>> [ 0.372186] initcall init_tis+0x0/0x100 returned 0 after 52127 usecs
>> […]
>> [ 0.588643] Freeing unused decrypted memory: 2036K
>> [ 0.589068] Freeing unused kernel image (initmem) memory: 3976K
>> [ 0.606115] Write protecting the kernel read-only data: 22528k
>> [ 0.606527] Freeing unused kernel image (rodata/data gap) memory: 276K
>> [ 0.652327] x86/mm: Checked W+X mappings: passed, no W+X pages found.
>> [ 0.652329] x86/mm: Checking user space page tables
>> [ 0.695968] x86/mm: Checked W+X mappings: passed, no W+X pages found.
>> [ 0.696104] Run /init as init process
>> […]
>>
>> For users, where boot time is most important, can this be moved out of
>> the hot path somehow?
>
> It can't be IRQ probing as IRQ's are *disabled* by default. So we can
> disclose that.
>
> I think the delay is caused by tpm2_probe(), which is called by
> tpm_tis_core_init(). It sends an idempotent TPM2 command to the TPM
> chip to know whether it is TPM 1.x or TPM2 chip.
>
> That detection is definitely required.
>
> Even some other subsystems in the kernel require to know the correct
> TPM version, like hwrng and IMA.
Understood. The TPM in my laptop does not change, so could this be
cached, or does a Linux CLI paramater exist, that I can specify the version?
Kind regards,
Paul
On Fri Feb 16, 2024 at 10:20 PM UTC, Paul Menzel wrote:
> Dear Jarkko,
>
>
> Thank you for your reply.
>
> Am 16.02.24 um 23:07 schrieb Jarkko Sakkinen:
> > On Wed Feb 14, 2024 at 3:10 PM UTC, Paul Menzel wrote:
>
> >> Trying to optimize the boot time of Linux on the Dell XPS 13 9360,
> >> probing of MSFT0101:00 takes 52 ms, making `init_tis()` taking almost 10
> >> % alone until starting the initrd:
> >>
> >> [ 0.000000] Linux version 6.8.0-rc4 ([email protected]) (gcc (Debian 13.2.0-13) 13.2.0,
> >> GNU ld (GNU Binutils for Debian) 2.42) #20 SMP PREEMPT_DYNAMIC Mon Feb 12 09:40:49 CET 2024
> >> […]
> >> [ 0.000000] DMI: Dell Inc. XPS 13 9360/0596KF, BIOS 2.21.0 06/02/2022
> >> […]
> >> [ 0.320057] calling init_tis+0x0/0x100 @ 1
> >> [ 0.332190] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 4)
> >> [ 0.372164] probe of MSFT0101:00 returned 0 after 52101 usecs
> >> [ 0.372186] initcall init_tis+0x0/0x100 returned 0 after 52127 usecs
> >> […]
> >> [ 0.588643] Freeing unused decrypted memory: 2036K
> >> [ 0.589068] Freeing unused kernel image (initmem) memory: 3976K
> >> [ 0.606115] Write protecting the kernel read-only data: 22528k
> >> [ 0.606527] Freeing unused kernel image (rodata/data gap) memory: 276K
> >> [ 0.652327] x86/mm: Checked W+X mappings: passed, no W+X pages found.
> >> [ 0.652329] x86/mm: Checking user space page tables
> >> [ 0.695968] x86/mm: Checked W+X mappings: passed, no W+X pages found.
> >> [ 0.696104] Run /init as init process
> >> […]
> >>
> >> For users, where boot time is most important, can this be moved out of
> >> the hot path somehow?
> >
> > It can't be IRQ probing as IRQ's are *disabled* by default. So we can
> > disclose that.
> >
> > I think the delay is caused by tpm2_probe(), which is called by
> > tpm_tis_core_init(). It sends an idempotent TPM2 command to the TPM
> > chip to know whether it is TPM 1.x or TPM2 chip.
> >
> > That detection is definitely required.
> >
> > Even some other subsystems in the kernel require to know the correct
> > TPM version, like hwrng and IMA.
> Understood. The TPM in my laptop does not change, so could this be
> cached, or does a Linux CLI paramater exist, that I can specify the version?
Oops, I totally ignored tpm_chip_register() which runs more TPM commands:
1. PCR alloction: tpm2_get_pcr_allocation()
2. self-test: tpm2_do_selftest()
(in some cases also tpm2_startup())
Just probe (a single trivial TPM command doing zero calcuation) causing
that long delay would not make sense, so sorry for misleading with this!
So the problem here is in-kernel clients of TPM that initialize during
the boot such as IMA and hwrng.
The call for tpm_chip_register() is in the tail of each chip driver,
i.e. it is in the "overall" framework and thus theoretically could be
relocated to a workqueue. This requires tho changes to all clients and
error code for the case where tpm_transmit() flushes this workqueue but
initialization fails.
So *I think* (was not fully scientifical feasibility study) it is
possible but it is not as small change as you would first think.
> Kind regards,
>
> Paul
BR, Jarkko