linux-toradex.git/drivers/firmware/arm_ffa, branch v6.19 Linux kernel for Apalis and Colibri modules firmware: arm_ffa: Add support for IMPDEF value in the memory access descriptor 2025-10-13T09:34:46+00:00 Sudeep Holla sudeep.holla@arm.com 2025-09-23T15:09:27+00:00 11fb1a82aefa6f7fea6ac82334edb5639b9927df FF-A v1.2 introduced 16 byte IMPLEMENTATION DEFINED value in the endpoint memory access descriptor to allow any sender could to specify an its any custom value for each receiver. Also this value must be specified by the receiver when retrieving the memory region. The sender must ensure it informs the receiver of this value via an IMPLEMENTATION DEFINED mechanism such as a partition message. So the FF-A driver can use the message interfaces to communicate the value and set the same in the ffa_mem_region_attributes structures when using the memory interfaces. The driver ensure that the size of the endpoint memory access descriptors is set correctly based on the FF-A version. Fixes: 9fac08d9d985 ("firmware: arm_ffa: Upgrade FF-A version to v1.2 in the driver") Reported-by: Lixiang Mao <liximao@qti.qualcomm.com> Tested-by: Lixiang Mao <liximao@qti.qualcomm.com> Message-Id: <20250923150927.1218364-1-sudeep.holla@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> 
FF-A v1.2 introduced 16 byte IMPLEMENTATION DEFINED value in the endpoint
memory access descriptor to allow any sender could to specify an its any
custom value for each receiver. Also this value must be specified by the
receiver when retrieving the memory region. The sender must ensure it
informs the receiver of this value via an IMPLEMENTATION DEFINED mechanism
such as a partition message.

So the FF-A driver can use the message interfaces to communicate the value
and set the same in the ffa_mem_region_attributes structures when using
the memory interfaces.

The driver ensure that the size of the endpoint memory access descriptors
is set correctly based on the FF-A version.

Fixes: 9fac08d9d985 ("firmware: arm_ffa: Upgrade FF-A version to v1.2 in the driver")
Reported-by: Lixiang Mao <liximao@qti.qualcomm.com>
Tested-by: Lixiang Mao <liximao@qti.qualcomm.com>
Message-Id: <20250923150927.1218364-1-sudeep.holla@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
firmware: arm_ffa: Change initcall level of ffa_init() to rootfs_initcall 2025-07-22T23:23:18+00:00 Yeoreum Yun yeoreum.yun@arm.com 2025-07-19T10:27:02+00:00 0e0546eabcd6c19765a8dbf5b5db3723e7b0ea75 The Linux IMA (Integrity Measurement Architecture) subsystem used for secure boot, file integrity, or remote attestation cannot be a loadable module for few reasons listed below: o Boot-Time Integrity: IMA’s main role is to measure and appraise files before they are used. This includes measuring critical system files during early boot (e.g., init, init scripts, login binaries). If IMA were a module, it would be loaded too late to cover those. o TPM Dependency: IMA integrates tightly with the TPM to record measurements into PCRs. The TPM must be initialized early (ideally before init_ima()), which aligns with IMA being built-in. o Security Model: IMA is part of a Trusted Computing Base (TCB). Making it a module would weaken the security model, as a potentially compromised system could delay or tamper with its initialization. IMA must be built-in to ensure it starts measuring from the earliest possible point in boot which inturn implies TPM must be initialised and ready to use before IMA. To enable integration of tpm_event_log with the IMA subsystem, the TPM drivers (tpm_crb and tpm_crb_ffa) also needs to be built-in. However with FF-A driver also being initialised at device initcall level, it can lead to an initialization order issue where: - crb_acpi_driver_init() may run before tpm_crb_ffa_driver()_init and ffa_init() - As a result, probing the TPM device via CRB over FFA is deferred - ima_init() (called as a late initcall) runs before deferred probe completes, IMA fails to find the TPM and logs the below error: | ima: No TPM chip found, activating TPM-bypass! Eventually it fails to generate boot_aggregate with PCR values. Because of the above stated dependency, the ffa driver needs to initialised before tpm_crb_ffa module to ensure IMA finds the TPM successfully when present. [ jarkko: reformatted some of the paragraphs because they were going past the 75 character boundary. ] Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org> 
The Linux IMA (Integrity Measurement Architecture) subsystem used for
secure boot, file integrity, or remote attestation cannot be a loadable
module for few reasons listed below:

 o Boot-Time Integrity: IMA’s main role is to measure and appraise files
 before they are used. This includes measuring critical system files during
 early boot (e.g., init, init scripts, login binaries). If IMA were a
 module, it would be loaded too late to cover those.

 o TPM Dependency: IMA integrates tightly with the TPM to record
 measurements into PCRs. The TPM must be initialized early (ideally before
 init_ima()), which aligns with IMA being built-in.

 o Security Model: IMA is part of a Trusted Computing Base (TCB). Making it
 a module would weaken the security model, as a potentially compromised
 system could delay or tamper with its initialization.

IMA must be built-in to ensure it starts measuring from the earliest
possible point in boot which inturn implies TPM must be initialised and
ready to use before IMA.

To enable integration of tpm_event_log with the IMA subsystem, the TPM
drivers (tpm_crb and tpm_crb_ffa) also needs to be built-in. However with
FF-A driver also being initialised at device initcall level, it can lead to
an initialization order issue where:
 - crb_acpi_driver_init() may run before tpm_crb_ffa_driver()_init and
   ffa_init()
 - As a result, probing the TPM device via CRB over FFA is deferred
 - ima_init() (called as a late initcall) runs before deferred probe
   completes, IMA fails to find the TPM and logs the below error:

   |  ima: No TPM chip found, activating TPM-bypass!

Eventually it fails to generate boot_aggregate with PCR values.

Because of the above stated dependency, the ffa driver needs to initialised
before tpm_crb_ffa module to ensure IMA finds the TPM successfully when
present.

[ jarkko: reformatted some of the paragraphs because they were going past
  the 75 character boundary. ]

Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
firmware: arm_ffa: Replace mutex with rwlock to avoid sleep in atomic context 2025-06-09T10:24:43+00:00 Sudeep Holla sudeep.holla@arm.com 2025-05-28T08:49:43+00:00 9ca7a421229bbdfbe2e1e628cff5cfa782720a10 The current use of a mutex to protect the notifier hashtable accesses can lead to issues in the atomic context. It results in the below kernel warnings: | BUG: sleeping function called from invalid context at kernel/locking/mutex.c:258 | in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 9, name: kworker/0:0 | preempt_count: 1, expected: 0 | RCU nest depth: 0, expected: 0 | CPU: 0 UID: 0 PID: 9 Comm: kworker/0:0 Not tainted 6.14.0 #4 | Workqueue: ffa_pcpu_irq_notification notif_pcpu_irq_work_fn | Call trace: | show_stack+0x18/0x24 (C) | dump_stack_lvl+0x78/0x90 | dump_stack+0x18/0x24 | __might_resched+0x114/0x170 | __might_sleep+0x48/0x98 | mutex_lock+0x24/0x80 | handle_notif_callbacks+0x54/0xe0 | notif_get_and_handle+0x40/0x88 | generic_exec_single+0x80/0xc0 | smp_call_function_single+0xfc/0x1a0 | notif_pcpu_irq_work_fn+0x2c/0x38 | process_one_work+0x14c/0x2b4 | worker_thread+0x2e4/0x3e0 | kthread+0x13c/0x210 | ret_from_fork+0x10/0x20 To address this, replace the mutex with an rwlock to protect the notifier hashtable accesses. This ensures that read-side locking does not sleep and multiple readers can acquire the lock concurrently, avoiding unnecessary contention and potential deadlocks. Writer access remains exclusive, preserving correctness. This change resolves warnings from lockdep about potential sleep in atomic context. Cc: Jens Wiklander <jens.wiklander@linaro.org> Reported-by: Jérôme Forissier <jerome.forissier@linaro.org> Closes: https://github.com/OP-TEE/optee_os/issues/7394 Fixes: e0573444edbf ("firmware: arm_ffa: Add interfaces to request notification callbacks") Message-Id: <20250528-ffa_notif_fix-v1-3-5ed7bc7f8437@arm.com> Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org> Tested-by: Jens Wiklander <jens.wiklander@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> 
The current use of a mutex to protect the notifier hashtable accesses
can lead to issues in the atomic context. It results in the below
kernel warnings:

  |  BUG: sleeping function called from invalid context at kernel/locking/mutex.c:258
  |  in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 9, name: kworker/0:0
  |  preempt_count: 1, expected: 0
  |  RCU nest depth: 0, expected: 0
  |  CPU: 0 UID: 0 PID: 9 Comm: kworker/0:0 Not tainted 6.14.0 #4
  |  Workqueue: ffa_pcpu_irq_notification notif_pcpu_irq_work_fn
  |  Call trace:
  |   show_stack+0x18/0x24 (C)
  |   dump_stack_lvl+0x78/0x90
  |   dump_stack+0x18/0x24
  |   __might_resched+0x114/0x170
  |   __might_sleep+0x48/0x98
  |   mutex_lock+0x24/0x80
  |   handle_notif_callbacks+0x54/0xe0
  |   notif_get_and_handle+0x40/0x88
  |   generic_exec_single+0x80/0xc0
  |   smp_call_function_single+0xfc/0x1a0
  |   notif_pcpu_irq_work_fn+0x2c/0x38
  |   process_one_work+0x14c/0x2b4
  |   worker_thread+0x2e4/0x3e0
  |   kthread+0x13c/0x210
  |   ret_from_fork+0x10/0x20

To address this, replace the mutex with an rwlock to protect the notifier
hashtable accesses. This ensures that read-side locking does not sleep and
multiple readers can acquire the lock concurrently, avoiding unnecessary
contention and potential deadlocks. Writer access remains exclusive,
preserving correctness.

This change resolves warnings from lockdep about potential sleep in
atomic context.

Cc: Jens Wiklander <jens.wiklander@linaro.org>
Reported-by: Jérôme Forissier <jerome.forissier@linaro.org>
Closes: https://github.com/OP-TEE/optee_os/issues/7394
Fixes: e0573444edbf ("firmware: arm_ffa: Add interfaces to request notification callbacks")
Message-Id: <20250528-ffa_notif_fix-v1-3-5ed7bc7f8437@arm.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Tested-by: Jens Wiklander <jens.wiklander@linaro.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
firmware: arm_ffa: Move memory allocation outside the mutex locking 2025-06-09T10:24:43+00:00 Sudeep Holla sudeep.holla@arm.com 2025-05-28T08:49:42+00:00 27e850c88df0e25474a8caeb2903e2e90b62c1dc The notifier callback node allocation is currently done while holding the notify_lock mutex. While this is safe even if memory allocation may sleep, we need to move the allocation outside the locked region in preparation to move from using muxtes to rwlocks. Move the memory allocation to avoid potential sleeping in atomic context once the locks are moved from mutex to rwlocks. Fixes: e0573444edbf ("firmware: arm_ffa: Add interfaces to request notification callbacks") Message-Id: <20250528-ffa_notif_fix-v1-2-5ed7bc7f8437@arm.com> Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> 
The notifier callback node allocation is currently done while holding
the notify_lock mutex. While this is safe even if memory allocation may
sleep, we need to move the allocation outside the locked region in
preparation to move from using muxtes to rwlocks.

Move the memory allocation to avoid potential sleeping in atomic context
once the locks are moved from mutex to rwlocks.

Fixes: e0573444edbf ("firmware: arm_ffa: Add interfaces to request notification callbacks")
Message-Id: <20250528-ffa_notif_fix-v1-2-5ed7bc7f8437@arm.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
firmware: arm_ffa: Fix memory leak by freeing notifier callback node 2025-06-09T10:24:43+00:00 Sudeep Holla sudeep.holla@arm.com 2025-05-28T08:49:41+00:00 a833d31ad867103ba72a0b73f3606f4ab8601719 Commit e0573444edbf ("firmware: arm_ffa: Add interfaces to request notification callbacks") adds support for notifier callbacks by allocating and inserting a callback node into a hashtable during registration of notifiers. However, during unregistration, the code only removes the node from the hashtable without freeing the associated memory, resulting in a memory leak. Resolve the memory leak issue by ensuring the allocated notifier callback node is properly freed after it is removed from the hashtable entry. Fixes: e0573444edbf ("firmware: arm_ffa: Add interfaces to request notification callbacks") Message-Id: <20250528-ffa_notif_fix-v1-1-5ed7bc7f8437@arm.com> Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> 
Commit e0573444edbf ("firmware: arm_ffa: Add interfaces to request
notification callbacks") adds support for notifier callbacks by allocating
and inserting a callback node into a hashtable during registration of
notifiers. However, during unregistration, the code only removes the
node from the hashtable without freeing the associated memory, resulting
in a memory leak.

Resolve the memory leak issue by ensuring the allocated notifier callback
node is properly freed after it is removed from the hashtable entry.

Fixes: e0573444edbf ("firmware: arm_ffa: Add interfaces to request notification callbacks")
Message-Id: <20250528-ffa_notif_fix-v1-1-5ed7bc7f8437@arm.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
firmware: arm_ffa: Skip Rx buffer ownership release if not acquired 2025-04-08T09:32:15+00:00 Sudeep Holla sudeep.holla@arm.com 2025-03-21T11:57:00+00:00 4567bdaaaaa1744da3d7da07d9aca2f941f5b4e5 Completion of the FFA_PARTITION_INFO_GET ABI transfers the ownership of the caller’s Rx buffer from the producer(typically partition mnager) to the consumer(this driver/OS). FFA_RX_RELEASE transfers the ownership from the consumer back to the producer. However, when we set the flag to just return the count of partitions deployed in the system corresponding to the specified UUID while invoking FFA_PARTITION_INFO_GET, the Rx buffer ownership shouldn't be transferred to this driver. We must be able to skip transferring back the ownership to the partition manager when we request just to get the count of the partitions as the buffers are not acquired in this case. Firmware may return FFA_RET_DENIED or other error for the ffa_rx_release() in such cases. Fixes: bb1be7498500 ("firmware: arm_ffa: Add v1.1 get_partition_info support") Message-Id: <20250321115700.3525197-1-sudeep.holla@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> 
Completion of the FFA_PARTITION_INFO_GET ABI transfers the ownership of
the caller’s Rx buffer from the producer(typically partition mnager) to
the consumer(this driver/OS). FFA_RX_RELEASE transfers the ownership
from the consumer back to the producer.

However, when we set the flag to just return the count of partitions
deployed in the system corresponding to the specified UUID while
invoking FFA_PARTITION_INFO_GET, the Rx buffer ownership shouldn't be
transferred to this driver. We must be able to skip transferring back
the ownership to the partition manager when we request just to get the
count of the partitions as the buffers are not acquired in this case.

Firmware may return FFA_RET_DENIED or other error for the ffa_rx_release()
in such cases.

Fixes: bb1be7498500 ("firmware: arm_ffa: Add v1.1 get_partition_info support")
Message-Id: <20250321115700.3525197-1-sudeep.holla@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
firmware: arm_ffa: Set dma_mask for ffa devices 2025-02-28T11:20:06+00:00 Viresh Kumar viresh.kumar@linaro.org 2025-01-17T10:05:52+00:00 cc0aac7ca17e0ea3ca84b552fc79f3e86fd07f53 Set dma_mask for FFA devices, otherwise DMA allocation using the device pointer lead to following warning: WARNING: CPU: 1 PID: 1 at kernel/dma/mapping.c:597 dma_alloc_attrs+0xe0/0x124 Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Message-Id: <e3dd8042ac680bd74b6580c25df855d092079c18.1737107520.git.viresh.kumar@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> 
Set dma_mask for FFA devices, otherwise DMA allocation using the device pointer
lead to following warning:

WARNING: CPU: 1 PID: 1 at kernel/dma/mapping.c:597 dma_alloc_attrs+0xe0/0x124

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Message-Id: <e3dd8042ac680bd74b6580c25df855d092079c18.1737107520.git.viresh.kumar@linaro.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
firmware: arm_ffa: Skip the first/partition ID when parsing vCPU list 2025-02-23T21:41:14+00:00 Sudeep Holla sudeep.holla@arm.com 2025-02-23T21:39:09+00:00 c67c2332f8c80b03990914dfb66950c8d2fb87d8 The FF-A notification id list received in response to the call FFA_NOTIFICATION_INFO_GET is encoded as: partition ID followed by 0 or more vCPU ID. The count includes all of them. Fix the issue by skipping the first/partition ID so that only the list of vCPU IDs are processed correctly for a given partition ID. The first/ partition ID is read before the start of the loop. Fixes: 3522be48d82b ("firmware: arm_ffa: Implement the NOTIFICATION_INFO_GET interface") Reported-by: Andrei Homescu <ahomescu@google.com> Message-Id: <20250223213909.1197786-1-sudeep.holla@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> 
The FF-A notification id list received in response to the call
FFA_NOTIFICATION_INFO_GET is encoded as: partition ID followed by 0 or
more vCPU ID. The count includes all of them.

Fix the issue by skipping the first/partition ID so that only the list
of vCPU IDs are processed correctly for a given partition ID. The first/
partition ID is read before the start of the loop.

Fixes: 3522be48d82b ("firmware: arm_ffa: Implement the NOTIFICATION_INFO_GET interface")
Reported-by: Andrei Homescu <ahomescu@google.com>
Message-Id: <20250223213909.1197786-1-sudeep.holla@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
firmware: arm_ffa: Explicitly cast return value from NOTIFICATION_INFO_GET 2025-02-21T11:40:24+00:00 Sudeep Holla sudeep.holla@arm.com 2025-02-21T09:56:32+00:00 3e282f41585c4dd49b688bd6395fd6f21a57c9f7 The return value ret.a2 is of type unsigned long and FFA_RET_NO_DATA is a negative value. Since the return value from the firmware can be just 32-bit even on 64-bit systems as FFA specification mentions it as int32 error code in w0 register, explicitly casting to s32 ensures correct sign interpretation when comparing against a signed error code FFA_RET_NO_DATA. Without casting, comparison between unsigned long and a negative constant could lead to unintended results due to type promotions. Fixes: 3522be48d82b ("firmware: arm_ffa: Implement the NOTIFICATION_INFO_GET interface") Reported-by: Andrei Homescu <ahomescu@google.com> Message-Id: <20250221095633.506678-2-sudeep.holla@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> 
The return value ret.a2 is of type unsigned long and FFA_RET_NO_DATA is
a negative value.

Since the return value from the firmware can be just 32-bit even on
64-bit systems as FFA specification mentions it as int32 error code in
w0 register, explicitly casting to s32 ensures correct sign interpretation
when comparing against a signed error code FFA_RET_NO_DATA.

Without casting, comparison between unsigned long and a negative
constant could lead to unintended results due to type promotions.

Fixes: 3522be48d82b ("firmware: arm_ffa: Implement the NOTIFICATION_INFO_GET interface")
Reported-by: Andrei Homescu <ahomescu@google.com>
Message-Id: <20250221095633.506678-2-sudeep.holla@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
firmware: arm_ffa: Explicitly cast return value from FFA_VERSION before comparison 2025-02-21T11:40:24+00:00 Sudeep Holla sudeep.holla@arm.com 2025-02-21T09:56:31+00:00 cecf6a504137aa238d768ae440a1f6488cb2f436 The return value ver.a0 is unsigned long type and FFA_RET_NOT_SUPPORTED is a negative value. Since the return value from the firmware can be just 32-bit even on 64-bit systems as FFA specification mentions it as int32 error code in w0 register, explicitly casting to s32 ensures correct sign interpretation when comparing against a signed error code FFA_RET_NOT_SUPPORTED. Without casting, comparison between unsigned long and a negative constant could lead to unintended results due to type promotions. Fixes: 3bbfe9871005 ("firmware: arm_ffa: Add initial Arm FFA driver support") Reported-by: Andrei Homescu <ahomescu@google.com> Message-Id: <20250221095633.506678-1-sudeep.holla@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> 
The return value ver.a0 is unsigned long type and FFA_RET_NOT_SUPPORTED
is a negative value.

Since the return value from the firmware can be just 32-bit even on
64-bit systems as FFA specification mentions it as int32 error code in
w0 register, explicitly casting to s32 ensures correct sign interpretation
when comparing against a signed error code FFA_RET_NOT_SUPPORTED.

Without casting, comparison between unsigned long and a negative
constant could lead to unintended results due to type promotions.

Fixes: 3bbfe9871005 ("firmware: arm_ffa: Add initial Arm FFA driver support")
Reported-by: Andrei Homescu <ahomescu@google.com>
Message-Id: <20250221095633.506678-1-sudeep.holla@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>