Received: by 2002:a05:6a10:7420:0:0:0:0 with SMTP id hk32csp4416366pxb; Mon, 21 Feb 2022 20:56:16 -0800 (PST) X-Google-Smtp-Source: ABdhPJxtMh+GiqWirSFRtlV5slvZbJgkVKXDehGJmzc/L6yfKE5IHjDhuaNPeeiJPIL8MHTt2X4h X-Received: by 2002:a63:36c5:0:b0:34b:5d0c:90da with SMTP id d188-20020a6336c5000000b0034b5d0c90damr18501178pga.72.1645505776119; Mon, 21 Feb 2022 20:56:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1645505776; cv=none; d=google.com; s=arc-20160816; b=C0HXLS5PMsEw5hPcLae4eaMRIRCyQ5i7F8uhAt6YPDcRgaqG2OEBT2zaK2LcyXegYZ qrfWShsiF9T1khBjl5b9nPLT2WamJ51J7js8fYi6psYVlb7ImTjqdgVUrc1oHkyWXjvA sxplq+W8hJU/OCQfvqiu78cLnkjWMkMXS3SU6SIYb68DRG9TxdbIyioH0IzLoDk4rP9X GTgPjwt3c05iEf21XIVnViicdSOa0W451QveSZ0VQU/cq91WrYAw+G4s1llbsDXUOmlw guOloRZuSrNE4vwoWPkv2M2ejLQ3xOyPz0vhMbXOQ+fvBButug9iUPeMAONQ5Wvt4JpC ts1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=rERaczPl04oya2eIwktMHiFIhPg0epo7dpLqkQP1IwM=; b=U618ACiiLCAEMDDcjdZXSlUkCkrb+GjA9AVLIyX3ibi3tJKUmFUnmibBd8FzFJrg3B GkHNRzeFOJr8KwIvg0+K0yu5b3r8728bkZ6FAR3p9pc3PyMrgdc4RsVyR33krm6lSW/d TtXqizFm1PW0sRfRL3CrMiCyqC7e0oxgdfy67BM3rETUXHrwJSH+r2BcVP6O94Vit47k rlNN/jYGibVO44RLBQ/ZMSGF5sXQkmwvisFdoEyW8FzhYsOYsqhDviMv1e6vXy8JX6eG kxYWJYBxtsm8jB371FNowF62Bi+yGhjKDkzHUiRKpS5oXPhY0HoTqgOkcLYIJxZqh+nC miWQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=MFOSqqRk; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id e9-20020a17090a4a0900b001b98932d482si1038614pjh.178.2022.02.21.20.56.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Feb 2022 20:56:16 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=MFOSqqRk; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id D661B1D0D7; Mon, 21 Feb 2022 20:33:32 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233406AbiBUUGQ (ORCPT + 99 others); Mon, 21 Feb 2022 15:06:16 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:40754 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232083AbiBUUGP (ORCPT ); Mon, 21 Feb 2022 15:06:15 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 03D51237C6; Mon, 21 Feb 2022 12:05:50 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 78BC2B815A6; Mon, 21 Feb 2022 20:05:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C01A4C340E9; Mon, 21 Feb 2022 20:05:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1645473948; bh=altu+U1/3ri4Dn3ihYdl52MdZAnh/l+MxbnJTLMjq1A=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=MFOSqqRk87MCF/kneZ21dXHmCOTaFwabWjhBn+xJ/sXhWcU5DuwP7kOh82YEG6EsE /utrkYpdRlhnnNY0gSJ+3Vu5gzaWtvrVwMxvJNQJI166w7krK+mTmK+dgQRFZK9LD9 BT5SbxJXakiUDfHwSwijnj6dWeVUQa1QqYyJaIkt+2NXDi2YX+2/LixEbxO1lFG6M8 u0rquwvxcXwhSsiUEWUcIS/tWdge2LCYmSxxvLY94DNkhgojF56dHsoo13Zdej/tRp j3UxZvb7x9SfybVQbQUNpApXi7yWcdU9kwlq8q/+YckkIaP2QCe4xZwS7TIxdUB/6O PUmU5atskShfQ== Date: Mon, 21 Feb 2022 21:06:23 +0100 From: Jarkko Sakkinen To: Mimi Zohar Cc: Paul Menzel , Dmitry Kasatkin , linux-integrity@vger.kernel.org, LKML , Petr Vorel Subject: Re: init_ima() adds 8 % to boot time Message-ID: References: <32f90c33-eeb9-64a0-b2e2-9258ba2e1820@molgen.mpg.de> <7d84425f36e3b04ab1adabed23f98b478b53b770.camel@linux.ibm.com> <07a65960197c4b50f996abdf2b062e836ce1226d.camel@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <07a65960197c4b50f996abdf2b062e836ce1226d.camel@linux.ibm.com> X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Feb 20, 2022 at 06:19:59PM -0500, Mimi Zohar wrote: > On Sun, 2022-02-20 at 23:57 +0100, Jarkko Sakkinen wrote: > > On Sun, Feb 20, 2022 at 10:19:37AM -0500, Mimi Zohar wrote: > > > [Cc'ing Jarkko, Petr Vorel] > > > > > > 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. > > > > I support the opt-in boot option. > > > > If the full hardware specifications are known for a device, you might want > > to use this. > > The default would be to extend the TPM with the 'boot_aggregate', with > an option to opt-out of extending the TPM. Ah, right, thanks for correction. By "opt-in" I meant "opt-out" :-) BR, Jarkko