public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
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


  reply	other threads:[~2026-04-28 13:21 UTC|newest]

Thread overview: 40+ 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-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox