From: Yeoreum Yun <yeoreum.yun@arm.com>
To: Paul Moore <paul@paul-moore.com>
Cc: Mimi Zohar <zohar@linux.ibm.com>,
roberto.sassu@huawei.com, Jonathan McDowell <noodles@earth.li>,
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
Date: Tue, 28 Apr 2026 14:21:20 +0100 [thread overview]
Message-ID: <afC0UPfGhNTsXnyi@e129823.arm.com> (raw)
In-Reply-To: <CAHC9VhS_WgwhW_NDO91LoTeSzdieGqbwqnwPq8KpavH1_Lwi7g@mail.gmail.com>
Hi Paul,
> On Fri, Apr 24, 2026 at 6:49 PM Mimi Zohar <zohar@linux.ibm.com> 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
next prev parent reply other threads:[~2026-04-28 13:21 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-22 16:24 [RFC PATCH v2 0/4] fix FF-A call failed with pKVM when ff-a driver is built-in Yeoreum Yun
2026-04-22 16:24 ` [RFC PATCH v2 1/4] security: ima: call ima_init() again at late_initcall_sync for defered TPM Yeoreum Yun
2026-04-22 17:20 ` Mimi Zohar
2026-04-22 18:46 ` Yeoreum Yun
2026-04-22 19:41 ` Yeoreum Yun
2026-04-22 21:20 ` Mimi Zohar
2026-04-23 5:55 ` Yeoreum Yun
2026-04-23 11:01 ` Mimi Zohar
2026-04-23 11:20 ` Yeoreum Yun
2026-04-23 12:34 ` Yeoreum Yun
2026-04-23 12:53 ` Jonathan McDowell
2026-04-23 13:07 ` Yeoreum Yun
2026-04-23 13:43 ` Mimi Zohar
2026-04-23 13:55 ` Yeoreum Yun
2026-04-23 14:03 ` Jonathan McDowell
2026-04-23 14:33 ` Yeoreum Yun
2026-04-23 18:01 ` Mimi Zohar
2026-04-23 18:13 ` Yeoreum Yun
2026-04-24 1:27 ` Paul Moore
2026-04-24 5:57 ` Yeoreum Yun
2026-04-24 20:15 ` Paul Moore
2026-04-24 20:57 ` Mimi Zohar
2026-04-24 21:08 ` Paul Moore
2026-04-24 22:00 ` Mimi Zohar
2026-04-24 22:10 ` Paul Moore
2026-04-24 22:49 ` Mimi Zohar
2026-04-28 1:31 ` Paul Moore
2026-04-28 13:21 ` Yeoreum Yun [this message]
2026-04-30 0:36 ` Paul Moore
2026-04-29 13:33 ` Roberto Sassu
2026-04-30 0:43 ` Paul Moore
2026-04-25 4:53 ` Yeoreum Yun
2026-04-28 1:31 ` Paul Moore
2026-04-23 14:48 ` Mimi Zohar
2026-04-23 17:02 ` Jonathan McDowell
2026-04-23 17:13 ` Mimi Zohar
2026-04-22 16:24 ` [RFC PATCH v2 2/4] tpm: tpm_crb_ffa: revert defered_probed when tpm_crb_ffa is built-in Yeoreum Yun
2026-04-23 10:17 ` Jarkko Sakkinen
2026-04-22 16:24 ` [RFC PATCH v2 3/4] firmware: arm_ffa: revert ffa_init() initcall level to device_initcall Yeoreum Yun
2026-04-23 9:13 ` Sudeep Holla
2026-04-22 16:24 ` [RFC PATCH v2 4/4] firmware: arm_ffa: check pkvm initailised when initailise ffa driver Yeoreum Yun
2026-04-23 8:34 ` Marc Zyngier
2026-04-23 10:29 ` Yeoreum Yun
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=afC0UPfGhNTsXnyi@e129823.arm.com \
--to=yeoreum.yun@arm.com \
--cc=catalin.marinas@arm.com \
--cc=dmitry.kasatkin@gmail.com \
--cc=eric.snowberg@oracle.com \
--cc=jarkko@kernel.org \
--cc=jgg@ziepe.ca \
--cc=jmorris@namei.org \
--cc=joey.gouly@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=maz@kernel.org \
--cc=noodles@earth.li \
--cc=noodles@meta.com \
--cc=oupton@kernel.org \
--cc=paul@paul-moore.com \
--cc=roberto.sassu@huawei.com \
--cc=sebastianene@google.com \
--cc=serge@hallyn.com \
--cc=sudeep.holla@kernel.org \
--cc=suzuki.poulose@arm.com \
--cc=will@kernel.org \
--cc=yuzenghui@huawei.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.