linux-stable.git/drivers/tee/optee, branch linux-5.15.y

tee: optee: Fix supplicant wait loop

2025-03-13T11:50:53+00:00

commit 70b0d6b0a199c5a3ee6c72f5e61681ed6f759612 upstream.

OP-TEE supplicant is a user-space daemon and it's possible for it
be hung or crashed or killed in the middle of processing an OP-TEE
RPC call. It becomes more complicated when there is incorrect shutdown
ordering of the supplicant process vs the OP-TEE client application which
can eventually lead to system hang-up waiting for the closure of the
client application.

Allow the client process waiting in kernel for supplicant response to
be killed rather than indefinitely waiting in an unkillable state. Also,
a normal uninterruptible wait should not have resulted in the hung-task
watchdog getting triggered, but the endless loop would.

This fixes issues observed during system reboot/shutdown when supplicant
got hung for some reason or gets crashed/killed which lead to client
getting hung in an unkillable state. It in turn lead to system being in
hung up state requiring hard power off/on to recover.

Fixes: 4fb0a5eb364d ("tee: add OP-TEE driver")
Suggested-by: Arnd Bergmann 
Cc: stable@vger.kernel.org
Signed-off-by: Sumit Garg 
Reviewed-by: Arnd Bergmann 
Reviewed-by: Jens Wiklander 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

tee: optee: Fix kernel panic caused by incorrect error handling

2024-04-10T14:18:46+00:00

commit 95915ba4b987cf2b222b0f251280228a1ff977ac upstream.

The error path while failing to register devices on the TEE bus has a
bug leading to kernel panic as follows:

[   15.398930] Unable to handle kernel paging request at virtual address ffff07ed00626d7c
[   15.406913] Mem abort info:
[   15.409722]   ESR = 0x0000000096000005
[   15.413490]   EC = 0x25: DABT (current EL), IL = 32 bits
[   15.418814]   SET = 0, FnV = 0
[   15.421878]   EA = 0, S1PTW = 0
[   15.425031]   FSC = 0x05: level 1 translation fault
[   15.429922] Data abort info:
[   15.432813]   ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000
[   15.438310]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[   15.443372]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[   15.448697] swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000d9e3e000
[   15.455413] [ffff07ed00626d7c] pgd=1800000bffdf9003, p4d=1800000bffdf9003, pud=0000000000000000
[   15.464146] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP

Commit 7269cba53d90 ("tee: optee: Fix supplicant based device enumeration")
lead to the introduction of this bug. So fix it appropriately.

Reported-by: Mikko Rapeli 
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218542
Fixes: 7269cba53d90 ("tee: optee: Fix supplicant based device enumeration")
Cc: stable@vger.kernel.org
Signed-off-by: Sumit Garg 
Signed-off-by: Jens Wiklander 
Signed-off-by: Greg Kroah-Hartman

tee: optee: Fix supplicant based device enumeration

2023-12-13T17:36:38+00:00

[ Upstream commit 7269cba53d906cf257c139d3b3a53ad272176bca ]

Currently supplicant dependent optee device enumeration only registers
devices whenever tee-supplicant is invoked for the first time. But it
forgets to remove devices when tee-supplicant daemon stops running and
closes its context gracefully. This leads to following error for fTPM
driver during reboot/shutdown:

[   73.466791] tpm tpm0: ftpm_tee_tpm_op_send: SUBMIT_COMMAND invoke error: 0xffff3024

Fix this by adding an attribute for supplicant dependent devices so that
the user-space service can detect and detach supplicant devices before
closing the supplicant:

$ for dev in /sys/bus/tee/devices/*; do if [[ -f "$dev/need_supplicant" && -f "$dev/driver/unbind" ]]; \
      then echo $(basename "$dev") > $dev/driver/unbind; fi done

Reported-by: Jan Kiszka 
Closes: https://github.com/OP-TEE/optee_os/issues/6094
Fixes: 5f178bb71e3a ("optee: enable support for multi-stage bus enumeration")
Signed-off-by: Sumit Garg 
Reviewed-by: Ilias Apalodimas 
Acked-by: Jerome Forissier 
[jw: fixed up Date documentation]
Signed-off-by: Jens Wiklander 
Signed-off-by: Sasha Levin

tee: optee: fix possible memory leak in optee_register_device()

2022-12-02T16:41:03+00:00

[ Upstream commit cce616e012c215d65c15e5d1afa73182dea49389 ]

If device_register() returns error in optee_register_device(),
the name allocated by dev_set_name() need be freed. As comment
of device_register() says, it should use put_device() to give
up the reference in the error path. So fix this by calling
put_device(), then the name can be freed in kobject_cleanup(),
and optee_device is freed in optee_release_device().

Fixes: c3fa24af9244 ("tee: optee: add TEE bus device enumeration support")
Signed-off-by: Yang Yingliang 
Reviewed-by: Sumit Garg 
Signed-off-by: Jens Wiklander 
Signed-off-by: Sasha Levin

optee: use driver internal tee_context for some rpc

2022-03-02T10:47:51+00:00

commit aceeafefff736057e8f93f19bbfbef26abd94604 upstream.

Adds a driver private tee_context by moving the tee_context in struct
optee_notif to struct optee. This tee_context was previously used when
doing internal calls to secure world to deliver notification.

The new driver internal tee_context is now also when allocating driver
private shared memory. This decouples the shared memory object from its
original tee_context. This is needed when the life time of such a memory
allocation outlives the client tee_context.

This patch fixes the problem described below:

The addition of a shutdown hook by commit f25889f93184 ("optee: fix tee out
of memory failure seen during kexec reboot") introduced a kernel shutdown
regression that can be triggered after running the OP-TEE xtest suites.

Once the shutdown hook is called it is not possible to communicate any more
with the supplicant process because the system is not scheduling task any
longer. Thus if the optee driver shutdown path receives a supplicant RPC
request from the OP-TEE we will deadlock the kernel's shutdown.

Fixes: f25889f93184 ("optee: fix tee out of memory failure seen during kexec reboot")
Fixes: 217e0250cccb ("tee: use reference counting for tee_context")
Reported-by: Lars Persson 
Cc: stable@vger.kernel.org
Reviewed-by: Sumit Garg 
Signed-off-by: Jens Wiklander 
[JW: backport to 5.15-stable + update commit message]
Signed-off-by: Jens Wiklander 
Signed-off-by: Greg Kroah-Hartman

tee: optee: Fix incorrect page free bug

2021-12-29T11:28:59+00:00

commit 18549bf4b21c739a9def39f27dcac53e27286ab5 upstream.

Pointer to the allocated pages (struct page *page) has already
progressed towards the end of allocation. It is incorrect to perform
__free_pages(page, order) using this pointer as we would free any
arbitrary pages. Fix this by stop modifying the page pointer.

Fixes: ec185dd3ab25 ("optee: Fix memory leak when failing to register shm pages")
Cc: stable@vger.kernel.org
Reported-by: Patrik Lantz 
Signed-off-by: Sumit Garg 
Reviewed-by: Tyler Hicks 
Signed-off-by: Jens Wiklander 
Signed-off-by: Greg Kroah-Hartman

tee: optee: Fix missing devices unregister during optee_remove

2021-10-12T11:24:39+00:00

When OP-TEE driver is built as a module, OP-TEE client devices
registered on TEE bus during probe should be unregistered during
optee_remove. So implement optee_unregister_devices() accordingly.

Fixes: c3fa24af9244 ("tee: optee: add TEE bus device enumeration support")
Reported-by: Sudeep Holla 
Signed-off-by: Sumit Garg 
Signed-off-by: Jens Wiklander

tee/optee/shm_pool: fix application of sizeof to pointer

2021-09-14T05:54:56+00:00

sizeof when applied to a pointer typed expression gives the size of
the pointer.

./drivers/tee/optee/shm_pool.c:38:28-34: ERROR application of sizeof to pointer

This issue was detected with the help of Coccinelle.

Reviewed-by: Daniel Thompson 
Reported-by: Zeal Robot 
Signed-off-by: jing yangyang 
Signed-off-by: Jens Wiklander

tee: Correct inappropriate usage of TEE_SHM_DMA_BUF flag

2021-07-21T05:55:50+00:00

Currently TEE_SHM_DMA_BUF flag has been inappropriately used to not
register shared memory allocated for private usage by underlying TEE
driver: OP-TEE in this case. So rather add a new flag as TEE_SHM_PRIV
that can be utilized by underlying TEE drivers for private allocation
and usage of shared memory.

With this corrected, allow tee_shm_alloc_kernel_buf() to allocate a
shared memory region without the backing of dma-buf.

Cc: stable@vger.kernel.org
Signed-off-by: Sumit Garg 
Co-developed-by: Tyler Hicks 
Signed-off-by: Tyler Hicks 
Reviewed-by: Jens Wiklander 
Reviewed-by: Sumit Garg 
Signed-off-by: Jens Wiklander

optee: Clear stale cache entries during initialization

2021-07-21T05:39:44+00:00

The shm cache could contain invalid addresses if
optee_disable_shm_cache() was not called from the .shutdown hook of the
previous kernel before a kexec. These addresses could be unmapped or
they could point to mapped but unintended locations in memory.

Clear the shared memory cache, while being careful to not translate the
addresses returned from OPTEE_SMC_DISABLE_SHM_CACHE, during driver
initialization. Once all pre-cache shm objects are removed, proceed with
enabling the cache so that we know that we can handle cached shm objects
with confidence later in the .shutdown hook.

Cc: stable@vger.kernel.org
Signed-off-by: Tyler Hicks 
Reviewed-by: Jens Wiklander 
Reviewed-by: Sumit Garg 
Signed-off-by: Jens Wiklander