linux-kernel - init_ima() adds 8 % to boot time

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-next>] [day] [month] [year] [list]

Message-ID: <32f90c33-eeb9-64a0-b2e2-9258ba2e1820@molgen.mpg.de>
Date:   Sat, 19 Feb 2022 10:44:42 +0100
From:   Paul Menzel <pmenzel@...gen.mpg.de>
To:     Mimi Zohar <zohar@...ux.ibm.com>,
        Dmitry Kasatkin <dmitry.kasatkin@...il.com>
Cc:     linux-integrity@...r.kernel.org,
        LKML <linux-kernel@...r.kernel.org>
Subject: init_ima() adds 8 % to boot time

Dear Linux folks,


Debian builds its Linux kernel image with `CONFIG_IMA=y` since version 
5.13.9 [1]. Unfortunately, on the Dell Latitude E7250 `init_ima` takes 
around 33 ms, adding 8 % to the boot time up to loading the initrd.

     [    0.000000] Linux version 5.17.0-rc4-amd64 
(debian-kernel@...ts.debian.org) (gcc-11 (Debian 11.2.0-16) 11.2.0, GNU 
ld (GNU Binutils for Debian) 2.38) #1 SMP PREEMPT Debian 5.17~rc4-1~exp1 
(2022-02-18)
     […]
     [    0.238520] calling  init_tis+0x0/0xde @ 1
     [    0.254749] tpm_tis 00:08: 1.2 TPM (device-id 0x3205, rev-id 80)
     [    0.285665] initcall init_tis+0x0/0xde returned 0 after 46038 usecs
     […]
     [    0.301327] calling  init_ima+0x0/0xb5 @ 1
     [    0.301332] ima: Allocated hash algorithm: sha256
     [    0.335502] ima: No architecture policies found
     [    0.335520] initcall init_ima+0x0/0xb5 returned 0 after 33389 usecs
     […]
     [    0.447312] Run /init as init process

Tracing `init_ima` with a depth of 5 shows 
`ima_calc_boot_aggregate_tfm()` takes 24 ms, and 
`ima_add_template_entry()` takes 10 ms.

         1.282630 |   1)   swapper-1    |               | 
ima_add_boot_aggregate() {
         1.282631 |   1)   swapper-1    |               | 
ima_calc_boot_aggregate() {
         1.282631 |   1)   swapper-1    |   0.153 us    | 
ima_alloc_tfm();
         1.282631 |   1)   swapper-1    | * 24404.59 us | 
ima_calc_boot_aggregate_tfm();
         1.307037 |   1)   swapper-1    |   0.482 us    | 
ima_free_tfm.part.0();
         1.307038 |   1)   swapper-1    | * 24407.06 us |        } /* 
ima_calc_boot_aggregate */
         1.307038 |   1)   swapper-1    |               | 
ima_alloc_init_template() {
         1.307038 |   1)   swapper-1    |   0.173 us    | 
ima_template_desc_current();
         1.307039 |   1)   swapper-1    |   0.836 us    | 
__kmalloc();
         1.307040 |   1)   swapper-1    |   0.580 us    | 
__kmalloc();
         1.307041 |   1)   swapper-1    |   1.555 us    | 
ima_eventdigest_ng_init();
         1.307043 |   1)   swapper-1    |   1.275 us    | 
ima_eventname_ng_init();
         1.307044 |   1)   swapper-1    |   0.256 us    | 
ima_eventsig_init();
         1.307045 |   1)   swapper-1    |   6.618 us    |        } /* 
ima_alloc_init_template */
         1.307045 |   1)   swapper-1    |               | 
ima_store_template() {
         1.307045 |   1)   swapper-1    |   5.049 us    | 
ima_calc_field_array_hash();
         1.307051 |   1)   swapper-1    | # 9316.953 us | 
ima_add_template_entry();
         1.316369 |   1)   swapper-1    | # 9323.728 us |        } /* 
ima_store_template */
         1.316369 |   1)   swapper-1    | * 33738.54 us |      } /* 
ima_add_boot_aggregate */

Tracing `ima_calc_boot_aggregate_tfm()` (attached) shows that the first 
`tpm1_pcr_read()` takes 16 ms in `tpm_transmit()`. Is communicating with 
the TPM supposed to be that slow?

In the last years, Linux decreased it’s boot time a lot, so do you see a 
way to move things out of the hot path and get `init_ima` well below 10 
ms? (As systems get faster and faster, having systems with standard 
distributions to be up below two seconds after pressing the power button 
should be a reasonable goal (500 ms firmware (like coreboot) + 500 ms 
Linux kernel + 1 s user space).


Kind regards,

Paul


[1]: 
https://salsa.debian.org/kernel-team/linux/-/commit/6e679322d7d98d30b4a8a3d1b659c899a6e9d4df
View attachment "linux-5.17-rc4-ima_calc_boot_aggregate_tfm.trace.txt" of type "text/plain" (21571 bytes)