Linux kernel -stable discussions
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko@kernel.org>
To: Siddharth Chintamaneni <sidchintamaneni@gmail.com>
Cc: Peter Huewe <peterhuewe@gmx.de>, Jason Gunthorpe <jgg@ziepe.ca>,
	Sudeep Holla <sudeep.holla@kernel.org>,
	Yeoreum Yun <yeoreum.yun@arm.com>,
	Stuart Yoder <stuart.yoder@arm.com>,
	apais@microsoft.com, rlmenge@gmail.com,
	hargar@linux.microsoft.com, linux-integrity@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH v1 1/1] tpm: tpm_crb_ffa: Only register driver when ACPI TPM2 uses FF-A
Date: Fri, 13 Nov 2026 22:20:45 +0200	[thread overview]
Message-ID: <avdxHSKkqubIrAZ5@kernel.org> (raw)
In-Reply-To: <CAE5sdEgEFjGz6W0e5g4uxRVC2Otyvr4Pak-aAZogObWaFtNsTA@mail.gmail.com>

On Fri, Nov 13, 2026 at 11:31:31AM -0800, Siddharth Chintamaneni wrote:
> On Fri, 13 Nov 2026 at 10:31, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> >
> > On Thu, Nov 12, 2026 at 11:38:07PM +0000, Siddharth Chintamaneni wrote:
> > > Prior to commit 677042afb97a ("tpm: tpm_crb_ffa: revert defered_probed
> > > when tpm_crb_ffa is built-in"), built-in tpm_crb_ffa only registered
> > > tpm_crb_ffa_driver from tpm_crb_ffa_init() after crb_acpi_probe()
> > > confirmed start_method == ACPI_TPM2_CRB_WITH_ARM_FFA. After that
> > > commit, tpm_crb_ffa unconditionally registers on the FF-A bus at
> > > device_initcall time (and when loaded as a module) without checking
> > > the platform's ACPI TPM2 table.
> > >
> > > A platform's firmware may expose a TPM CRB over FF-A Secure Partition
> > > for UEFI boot services while advertising a non-FF-A start method to
> > > the OS in the ACPI TPM2 table. When the ACPI TPM2 table designates a
> > > non-FF-A start method, Linux has no consumer for tpm_crb_ffa and
> > > should not probe the FF-A TPM service.
> > >
> > > On Microsoft Cobalt 200 systems, the ACPI TPM2 table does not use
> > > ACPI_TPM2_CRB_WITH_ARM_FFA, yet ffa_init() discovers the FF-A TPM
> > > partition and tpm_crb_ffa_probe() unconditionally sends
> > > CRB_FFA_GET_INTERFACE_VERSION via FFA_MSG_SEND_DIRECT_REQ2/REQ SMC.
> > > That request wedges the calling CPU in Secure World (with Non-Secure
> > > interrupts and GICv3 pseudo-NMIs masked), hanging boot with an RCU CPU
> > > stall:
> > >
> > >   [    5.507519] ARM FF-A: Driver version 1.2
> > >   [    5.507519] ARM FF-A: Firmware version 1.2 found
> > >   [    5.507551] ARM FF-A: Notification setup failed -61, not enabled
> > >   [    7.150580] Freeing initrd memory: 293640K
> > >   [   65.515248] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
> > >   [   65.521346] rcu:     10-...0: (3 GPs behind) idle=dd9c/1/0x4000000000000000 softirq=37/37 fqs=5262
> > >   [   65.530031] rcu:              hardirqs   softirqs   csw/system
> > >   [   65.535589] rcu:      number:        0          0            0
> > >   [   65.541146] rcu:     cputime:        0          0            0   ==> 30028(ms)
> > >   [   65.548102] rcu:     (detected by 66, t=15010 jiffies, g=-951, q=1384 ncpus=132)
> > >   [   65.555228] Sending NMI from CPU 66 to CPUs 10:
> > >   [   75.560686] After 10 seconds, these CPUS still haven't responded to the NMI: 10
> > >
> > > Check the ACPI TPM2 table in tpm_crb_ffa_driver_init() and return
> > > -ENODEV before calling ffa_register() unless the table is present and
> > > specifies ACPI_TPM2_CRB_WITH_ARM_FFA, matching the check_acpi_tpm2()
> > > pattern in tpm_tis.c. This ensures Linux only issues FF-A TPM requests
> > >
> > > when ACPI advertises the FF-A start method (for both built-in and
> > > modular builds), while preserving normal FF-A bus probing on platforms
> > > that use CRB over FF-A.
> > >
> > > Fixes: 677042afb97a ("tpm: tpm_crb_ffa: revert defered_probed when tpm_crb_ffa is built-in")
> > > Fixes: eb93f0734ef1 ("tpm_crb: ffa_tpm: Implement driver compliant to CRB over FF-A")
> >
> > Pick the older.
> >
> > I attached a prepending patch that caches the start method, which can be
> > later used in tpm_tis and tpm_crb.
> >
> > So that totals four patches:
> >
> > 1. My patch.
> > 2. Your fix using the cached value.
> > 3. tpm_tis update to use the cached value.
> > 4. tpm_crb update to use the cached value.
> >
> 
> Sounds good! I can put together that 4 patch v2 series.
> 
> Two quick notes before I spin v2
> 
> - Module loading with CONFIG_TCG_CRB=m and CONFIG_TCG_ARM_CRB_FFA=m:
>   As Sashiko flagged on v1 [1], because tpm_crb.ko directly references
>   tpm_crb_ffa_init() and tpm_crb_ffa_start(), returning -ENODEV from
>   tpm_crb_ffa's module_init would prevent modprobe from loading
>   tpm_crb.ko on non-FF-A systems. In v2, I will move the start_method
>   check into tpm_crb_ffa_probe() (matching check_acpi_tpm2() in tpm_tis)
>   so both modules load cleanly while still skipping the FF-A probe on
>   non-FF-A platforms
> 
> - regarding the location of caching approach -
>   tpm_crb_ffa never allocates a struct tpm_chip, and both tpm_tis
>   (check_acpi_tpm2()) and tpm_crb (crb_acpi_probe()) check start_method
>   before calling tpmm_chip_alloc().  Would it work for you if patch 1
>   caches start_method once in tpm_init() (subsys_initcall in
>   tpm-interface.c) and exports a small helper (e.g.
>   tpm_acpi_start_method()) so tpm_crb_ffa_probe(), tpm_tis, and tpm_crb
>   can all query it before chip allocation? (Also noticed a small '||' ->
>   '&&' typo on the header.length check in the attached patch.)

Move it to tpm_init() and store the result to a global variable, let's
say tpm2_acpi_start_method. There's only one of these so it's all fine.

You can then mark the resulting commit as:

Signed-off-by: Siddharth Chintamaneni <sidchintamaneni@gmail.com>
Co-developed-by: Siddharth Chintamaneni <sidchintamaneni@gmail.com>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>

I just put those tag because it is easy to mix up with Co-by tag,
when using it.

Br, Jarkko

      reply	other threads:[~2026-11-13 20:20 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-12 23:38 [PATCH v1 1/1] tpm: tpm_crb_ffa: Only register driver when ACPI TPM2 uses FF-A Siddharth Chintamaneni
2026-11-13 18:31 ` Jarkko Sakkinen
2026-11-13 19:31   ` Siddharth Chintamaneni
2026-11-13 20:20     ` Jarkko Sakkinen [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=avdxHSKkqubIrAZ5@kernel.org \
    --to=jarkko@kernel.org \
    --cc=apais@microsoft.com \
    --cc=hargar@linux.microsoft.com \
    --cc=jgg@ziepe.ca \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterhuewe@gmx.de \
    --cc=rlmenge@gmail.com \
    --cc=sidchintamaneni@gmail.com \
    --cc=stable@vger.kernel.org \
    --cc=stuart.yoder@arm.com \
    --cc=sudeep.holla@kernel.org \
    --cc=yeoreum.yun@arm.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