public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: Mimi Zohar <zohar@linux.ibm.com>
Cc: Paul Menzel <pmenzel@molgen.mpg.de>,
	Dmitry Kasatkin <dmitry.kasatkin@gmail.com>,
	Jarkko Sakkinen <jarkko@kernel.org>,
	linux-integrity@vger.kernel.org,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: init_ima() adds 8 % to boot time
Date: Tue, 22 Feb 2022 07:25:30 +0100	[thread overview]
Message-ID: <YhSB2vwzjZ555lco@pevik> (raw)
In-Reply-To: <7d84425f36e3b04ab1adabed23f98b478b53b770.camel@linux.ibm.com>

Hi Mimi,

> [Cc'ing Jarkko, Petr Vorel]
Thanks!

> Hi Paul,

> On Sat, 2022-02-19 at 10:44 +0100, Paul Menzel wrote:
> > 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@lists.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_agg:0regate() {
> >          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).


> > [1]: 
> > https://salsa.debian.org/kernel-team/linux/-/commit/6e679322d7d98d30b4a8a3d1b659c899a6e9d4df

> Thank you including the initial and other TPM delays.  The main reason
> for the "boot_aggregate" is to tie the pre-OS measurements to the post
> OS measurement list.  Without the TPM based 'boot_aggregate', any IMA
> measurement list could be used to verify a TPM quote.  The
> 'boot_aggregate' is calculated, originally, based on PCRs 0 - 7 and
> more recently may include PCRs 8 & 9 as well.  The 'boot_aggregate' is
> the first record in the IMA measurement list and the first record after
> a soft reboot (kexec).  It is the one and only IMA measurement record
> not dependent on policy.

> There are TPM 1.2 & 2.0 standards' requirements, but there are also
> buggy TPMs which don't adhere to them to such an extent that IMA goes
> into 'TPM-bypass' mode. Perhaps for those not interested in extending
> the concepts of trusted boot to the running OS, defining a new boot
> command line option to force IMA into this 'TPM-bypass' mode would be
> an acceptable alternative to the delay.  The IMA measurement list would
> still include a 'boot_aggregate' record, but one containing 0's.
This sounds reasonable.

Kind regards,
Petr

> thanks,

> Mimi


      parent reply	other threads:[~2022-02-22  6:25 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-19  9:44 init_ima() adds 8 % to boot time Paul Menzel
2022-02-20 15:19 ` Mimi Zohar
2022-02-20 22:57   ` Jarkko Sakkinen
2022-02-20 23:19     ` Mimi Zohar
2022-02-21 20:06       ` Jarkko Sakkinen
2022-02-22  6:25   ` Petr Vorel [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YhSB2vwzjZ555lco@pevik \
    --to=pvorel@suse.cz \
    --cc=dmitry.kasatkin@gmail.com \
    --cc=jarkko@kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pmenzel@molgen.mpg.de \
    --cc=zohar@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox