Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.ibm.com>
To: Yeoreum Yun <yeoreum.yun@arm.com>
Cc: David Safford <david.safford@gmail.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,
	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
Date: Thu, 14 May 2026 10:53:43 -0400	[thread overview]
Message-ID: <484268465668bbe64bebb651ec1a5ba1cb3a8078.camel@linux.ibm.com> (raw)
In-Reply-To: <agXDQhREKIpN7mKX@e129823.arm.com>

On Thu, 2026-05-14 at 13:42 +0100, Yeoreum Yun wrote:
> 
> 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?

Adding support for "missing early IMA measurements" would be considered a new
feature.  Queueing early measurements before IMA is enabled, as previously
mentioned, breaks the "measure before use" principle and could therefore be
exploited to bypass it.

One alternative being considered is denying access to anything that would be
measured/appraised based on a builtin IMA policy, though it remains unclear
whether this approach would break boot on existing systems.

Mimi


      reply	other threads:[~2026-05-14 14:54 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-24 13:23 [RFC PATCH v3 0/4] Fix IMA + TPM initialisation ordering issue Jonathan McDowell
2026-04-24 13:24 ` [RFC PATCH v3 1/4] lsm: Allow LSMs to register for late_initcall_sync init Jonathan McDowell
2026-04-24 13:24 ` [RFC PATCH v3 2/4] security: ima: call ima_init() again at late_initcall_sync for defered TPM Jonathan McDowell
2026-04-24 16:55   ` Yeoreum Yun
2026-04-24 20:25   ` Mimi Zohar
2026-04-25  9:10     ` Jonathan McDowell
2026-04-24 13:24 ` [RFC PATCH v3 3/4] Revert "tpm: tpm_crb_ffa: try to probe tpm_crb_ffa when it's built-in" Jonathan McDowell
2026-04-24 16:10   ` Sudeep Holla
2026-04-24 13:24 ` [RFC PATCH v3 4/4] Revert "firmware: arm_ffa: Change initcall level of ffa_init() to rootfs_initcall" Jonathan McDowell
2026-04-24 16:09   ` Sudeep Holla
2026-04-25 14:19   ` Jarkko Sakkinen
2026-05-08 18:03   ` Sudeep Holla
2026-04-29 20:01 ` [PATCH] ima: debugging late_initcall_sync measurements Mimi Zohar
2026-04-30  9:48   ` Yeoreum Yun
2026-04-30 21:39     ` Mimi Zohar
2026-04-30 22:35       ` Paul Moore
2026-05-01  1:51         ` Mimi Zohar
2026-05-03 16:46           ` Paul Moore
2026-05-04 12:02             ` Mimi Zohar
2026-05-04 20:51               ` Paul Moore
2026-05-05 21:02                 ` Mimi Zohar
2026-05-05 22:55                   ` Paul Moore
2026-05-06  1:51                     ` Mimi Zohar
2026-05-06  2:11                       ` Paul Moore
2026-05-07  2:25                         ` Mimi Zohar
2026-05-07  8:10                           ` Roberto Sassu
2026-05-07 14:00                             ` Mimi Zohar
2026-05-01 16:52       ` David Safford
2026-05-03 11:36         ` Mimi Zohar
2026-05-03 12:42           ` Mimi Zohar
2026-05-06  5:54             ` Yeoreum Yun
2026-05-06  7:23               ` Yeoreum Yun
2026-05-06 11:47               ` Mimi Zohar
2026-05-06 13:57                 ` Yeoreum Yun
2026-05-07  2:32                   ` Mimi Zohar
2026-05-07  5:50                     ` Yeoreum Yun
2026-05-07 11:28                       ` Mimi Zohar
2026-05-07 12:41                         ` Yeoreum Yun
2026-05-07 20:03                           ` Yeoreum Yun
2026-05-07 21:36                             ` Mimi Zohar
2026-05-08  9:06                               ` Yeoreum Yun
2026-05-08 12:55                                 ` Mimi Zohar
2026-05-08 13:41                                   ` Yeoreum Yun
2026-05-14 12:42                                     ` Yeoreum Yun
2026-05-14 14:53                                       ` Mimi Zohar [this message]

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=484268465668bbe64bebb651ec1a5ba1cb3a8078.camel@linux.ibm.com \
    --to=zohar@linux.ibm.com \
    --cc=catalin.marinas@arm.com \
    --cc=david.safford@gmail.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=yeoreum.yun@arm.com \
    --cc=yuzenghui@huawei.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