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 D58C2FF885A for ; Tue, 28 Apr 2026 13:21:39 +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-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=UB3CDI+mylgRjieE5aEKSHoXj3T/nTJ0KbppMNT5pLo=; b=uJVN2KOkxS7h22QTeT/hE6/qZ9 xyp6Uxir45d07TLRGcvb9kPJTOsGgBLCJe8h79YgvRA4JIJ/TRK+05ryHcBjOC6Dh7KfjQLlxT2aO 7YrxRxeOMKADIi6c7RiPcZ39Oad6MFAAVPP1wcu6pt0zCyaBWJ3UIw3ynFcbUZPqNQPoIql30wNRB BQA1tFdfazO9k3GxK92jFZMicbqrtY4letlhaf7KLhTARr3W/jhu3seSbqVisIMUhgSGDUfuBSrrn lj+f3ATlfz6UN17qcungzcfkUdVtfA90Hqk4yDj2epRQQuKZQgR4KvVvKIatTfZAGF5zCMwtESm3X USSWBHrg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1wHiNa-00000001X16-04Kq; Tue, 28 Apr 2026 13:21:34 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1wHiNW-00000001X0J-1xp8 for linux-arm-kernel@lists.infradead.org; Tue, 28 Apr 2026 13:21:32 +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 830982BCB; Tue, 28 Apr 2026 06:21:21 -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 DADBE3F62B; Tue, 28 Apr 2026 06:21:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1777382487; bh=bsvWlDxYnAplPFAgfU//71QRl4oKYiApqcT8JyjzfgE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=pdhUfWsdmeN3C7bkilDKrPemnn+Oq83RRdC0jvgk7oqYcB095DXFCXxYuWkk0UNEX fIpcey6sslxOGabc6XfGzmecVE2summH/DK2QVGNggJHiRT0Sc7B2RNU7tnq4Eh50E BfHAUUmAgFezutGPVgqHQ6FZ1hjcTqgpvtFQwlmg= Date: Tue, 28 Apr 2026 14:21:20 +0100 From: Yeoreum Yun To: Paul Moore Cc: Mimi Zohar , roberto.sassu@huawei.com, 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, jmorris@namei.org, serge@hallyn.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: [RFC PATCH v2 1/4] security: ima: call ima_init() again at late_initcall_sync for defered TPM Message-ID: References: <014cf39aa8d6a0bcfa1a95c069675977ac67b843.camel@linux.ibm.com> <1f78fc75b2e95239973612a4b6c4cc782960b7ac.camel@linux.ibm.com> <1e51c2fd090e5ceb07b1d09e50650c70fd3ccdb1.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: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260428_062130_625528_87CC96AB X-CRM114-Status: GOOD ( 22.29 ) 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 Paul, > On Fri, Apr 24, 2026 at 6:49 PM Mimi Zohar wrote: > > On Fri, 2026-04-24 at 18:10 -0400, Paul Moore wrote: > > > (I'm assuming you meant initcall and not syscall above, but if you're > > > talking about something else, please let me know.) > > > > > > Saying that you aren't comfortable moving IMA initialization to > > > late-sync is inconsistent with allowing IMA initialization to be > > > deferred to late-sync. Either it is okay to initialize IMA in > > > late-sync or it isn't. You must pick one. > > > > Yes, we're discussing late_initcall and late_initcall_sync. > > > > I prefer to look at it as being pragmatic. I'd rather err on the side of caution > > and not move the syscall to late_initcall_sync, than move it. > > If you were truly erring on the side of caution you wouldn't allow > late-sync initialization without knowing if it was safe or not. > Determine whether IMA initialization is safe at late-sync. If it is > safe, move the init to late-sync; if not, keep it at late and figure > out another mechanism to sync with the TPM availability. If needed, > you could probably use the LSM notifier to enable the TPM driver to > signal when it is up and running. I don't think LSM notifier wouldn't be good since it a one time notification for initailisation and it wouldn't tell properly whehter TPM isn't present in system or present unless functions ima_init() are rewritten to discern the "TPM deferred" and "TPM doesn't exist" in the system (e.x) boot-aggregate log creation. One question, though. In the end, for systems where the TPM has already been probed by late_initcall(), init_ima() continues to be called at late_initcall(), while the above approach is introduced for systems where the TPM is not properly initialized by that point. If init_ima(), which used to be called at late_initcall(), were instead called at late_initcall_sync(), could this break system integration? In my view, both late_initcall and late_initcall_sync run during the do_basic_setup() phase, so it doesn’t seem like this would cause tampering or affect things like the creation of the boot-aggregate log. Is there any particular reason why init_ima() must be called specifically at late_initcall()? Thanks. -- Sincerely, Yeoreum Yun