From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id D77EDCD4F39 for ; Thu, 14 May 2026 12:42:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=zCss989jz0IZOa0mWrlu9uT1RRGrb397aKWD16jEzQ4=; b=vHjdZLCTB63aP93j2oF0Qy91bJ stD260iG1A+4qqtmO68Ipo+j71RKbCuMzuG60LygiKE7leM01r9pR4U5Uclcu7Op1NIxdCLheDVge u144ASLlcLelomtFjrX6J2EA9h6zwjUH6b2U8d6aVKjUAjuXm1QSADtAEgI5svgKkzUEFfoiz4PDg N40eY/51k57Jc71r8TOUZqgG/A+bmlS0YfAR38aKccE84sxYSyQevf0YGoovPiiaNb+9+kAPW+ihR ioCbc+Dw/UAyrwpRPPRJ5gIVP5Gd/4Veu99VXNuZ7ksIvBeUa1DIb0BtEhOj4jFBdPJFe0Zq3WeDs Vt7IjP9A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wNVOu-00000005UNP-2fF6; Thu, 14 May 2026 12:42:52 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wNVOs-00000005UMq-3Fxu for linux-arm-kernel@lists.infradead.org; Thu, 14 May 2026 12:42:52 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 78EB8244B; Thu, 14 May 2026 05:42:42 -0700 (PDT) Received: from e129823.arm.com (e129823.arm.com [10.1.197.6]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A1A283F7B4; Thu, 14 May 2026 05:42:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1778762567; bh=CSZGuhEMgcVv+yjLSc1VRGD3BlRDfXMIcohRaOGnXhU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=YLD8FxWG6lmZaF+56qA4ExHRj6gmec4W4Jy6zLkG6oqEGkL02iZdRMKmMRRZjCR0U xVNyfG7Hlzpevqw0I2XS7WY265pckgOkpMzxKPGXjvD5U9THwi517swXo7gmN3Lc01 lO/Kf4a3JDrJykgmj9Ar3XiURm1HGddmuTvrsPkk= Date: Thu, 14 May 2026 13:42:42 +0100 From: Yeoreum Yun To: Mimi Zohar Cc: David Safford , Jonathan McDowell , linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, linux-integrity@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, paul@paul-moore.com, jmorris@namei.org, serge@hallyn.com, roberto.sassu@huawei.com, dmitry.kasatkin@gmail.com, eric.snowberg@oracle.com, jarkko@kernel.org, jgg@ziepe.ca, sudeep.holla@kernel.org, maz@kernel.org, oupton@kernel.org, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org, noodles@meta.com, sebastianene@google.com Subject: Re: [PATCH] ima: debugging late_initcall_sync measurements Message-ID: References: <9d1af933ef218b159762884357d127e3644dfe2c.camel@linux.ibm.com> <77ad49cca1acf707f4152ed3e2066b2f24c90c16.camel@linux.ibm.com> <2b3782398cc17ce9d355490a0c42ebce9120a9ae.camel@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.9.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260514_054250_904090_DA003C4F X-CRM114-Status: GOOD ( 42.56 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Mimi, > > On Fri, 2026-05-08 at 10:06 +0100, Yeoreum Yun wrote: > > > > > > The kernel selftests caused the measurements between late_initcall and > > > > late_initcall_sync. After disabling all of the kernel selftests, there weren't > > > > any measurements. Re-enabling the FIPS selftests on PowerVM LPAR resulted in > > > > measurements. (I didn't try re-enabling any of the other selftests.) > > > > > > > > CONFIG_FIPS_SIGNATURE_SELFTEST=y > > > > CONFIG_FIPS_SIGNATURE_SELFTEST_RSA=y > > > > CONFIG_FIPS_SIGNATURE_SELFTEST_ECDSA=y > > > > > > Thanks for shraring this ;) > > > > > > I found the reason for those mesaurements. Those come from the > > > request_module() and usermode-thread generates them while handling module > > > loading request for crypto-x962(ecdsa-nist-p256). > > > Since it's not a real kernel module, > > > I confirmed file measurements between late_initcall and > > > late_initcall_sync are gone for modeprobe with below change: > > > > > > @@ -1246,9 +1250,14 @@ EXPORT_SYMBOL_GPL(ima_measure_critical_data); > > > */ > > > static int ima_kernel_module_request(char *kmod_name) > > > { > > > if (strncmp(kmod_name, "crypto-pkcs1(rsa,", 17) == 0) > > > return -EINVAL; > > > > > > + if (IS_BUILTIN(CONFIG_CRYPTO_ECDSA) && > > > + (strncmp(kmod_name, "crypto-x962(ecdsa", 17) == 0)) > > > + return -EINVAL; > > > + > > > return 0; > > > } > > > > > > Though this is the only request_module() call between > > > late_initcall and late_initcall_sync, but I also confirmed there're > > > request_modules() call before ima initalisation before "late_initcall": > > > > > > /* > > > * NOTE: kmod_name is printed on ima_kernel_module_request() > > > */ > > > > > > // This is called from module_init(stm_core_init) -> device_initcall() > > > // which is in driver/hwtracing/stm/core.c (built-in) > > > [ 1.421986] ima: kmod_name: stm_p_basic > > > ... > > > [ 1.444900] ima: kmod_name: crypto-pkcs1(rsa,sha512) > > > [ 1.444903] ima: kmod_name: crypto-pkcs1(rsa,sha512)-all > > > ... > > > [ 1.452029] ima: kmod_name: crypto-cbc(aes) > > > [ 1.465321] ima: kmod_name: crypto-cbc(aes)-all > > > ... > > > [ 1.467845] Key type encrypted registered > > > [ 1.467848] AppArmor: AppArmor sha256 policy hashing enabled > > > > > > // IMA is initailised at late_initcall level. > > > [ 1.467850] ima: [init_ima_late:1336] > > > > > > If IMA should care request_module() from kernel before IMA init, > > > I think there is no way to solve except queuing those events > > > (kernel_load_data/kernel_load_post_data and open for module binary etc.) > > > though it breaks "measure before use" principle since IMA couldn't > > > measure at that time. > > > > > > But if you don't care about those things -- some events happend before > > > IMA init, I think your suggestion -- controlling the init time of ima_init() > > > via a Kconfig option is good and ignoring some usermodehelper request > > > including request_module() before IMA initialisation upto user by that option. > > > > Thank you for the complete analysis. The early measurements before the TPM is > > initialized is a problem that needs to be addressed. As to whether the solution > > will require queueing is yet to be determined. (Roberto has some thoughts on > > addressing it.) This discussion makes it clear that simply delaying IMA > > initialization by moving it from late_initcall to late_initcall_sync could miss > > measurements. That said, exposing it as an opt-in Kconfig for those who accept > > the risk is a sensible pragmatic compromise. > > I think once we address ealry measurements before intialising TPM, > It doesn't matter when IMA is initialissed since they're considered as > ealry measurements anyway. > > BTW, I'm not sure whether we should take pragmatic compromise first to > support deferred TPM initialisation or solving it together via solution > of ealry measurements (whatever it is) in now. I wonder what's going on for discussion to resolve these problem: 1) measurement event (via file operation) before IMA initialisation. 2) deferred TPM device initailisation and IMA. Might someone could think it wouldn't be a problem since initrd is measuared in PCR9 by boot loader (e.x) grub, but it still has a problem for the case uses root= boot option where it doesn't use initrd but use specified block dev with a filesystem. I think soluation would be determined whether IMA neglects the measurement event before its initialisation or not in current state: a) Case for neglecting measurement event before IMA initailisation. In this case, As you suggeested, IMA initialisation should be determined by build config whether it initialises at late_initcall or late_initcall_sync so that make user can choice upto their platform. b) Case for considering measurement event event before IMA initialisation. I couldn't image any other solution except queuing those event and extend them after generating boot_aggregate log and if those event can be queued, it wouldn't a problem to move IMA initialisation to late_initcall_sync. But you mention there are some thoughts from Roberto, might there was some discussion with him. If you don't mind, would you let me know how the discussion is going on and your thought to fix this all? Thanks! -- Sincerely, Yeoreum Yun