Hi Jens,
" TAs use their own pauth keys, I think SPs should do the same. Or we're exposing keys that shouldn't be exposed to SPs." Yes I am implementing the same behavior as in case of TA-s. The SP-s have own keys which are used when they are running.
Now everything is clear, thank you for the help!
Br, Gábor
-----Original Message----- From: Jens Wiklander jens.wiklander@linaro.org Sent: Wednesday, June 26, 2024 3:03 PM To: Gabor Toth Gabor.Toth2@arm.com Cc: op-tee@lists.trustedfirmware.org Subject: Re: Enable pointer authentication for the SP initialization
Hi Gabor,
On Wed, Jun 26, 2024 at 12:29 PM Gabor Toth Gabor.Toth2@arm.com wrote:
Hi Jens,
As I see after the SP-s return to SEL1 the context is restored and the pauth keys are set to the keys of the atomic context (kernels[n].keys). So the only problem is that at initialization the keys of the thread-line context (thread_core_local[n].keys) are used instead of the atomic ones.
Since " which context is used is more by chance than by design", do you see anything against initializing the pauth keys to the keys of the atomic context instead of the kernel-like ones here: https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/kernel/entry_a6... ?
No, at the point where this macro is used we're definitely in an atomic context. I meant before that we're emulating a threaded context to the extent it's needed at some places, for instance, to keep mutex_lock() happy.
With this change and moving the SP initialization right after enabling SCTLR_ENIA the feature seems to be working properly and the protection is already enabled when the sp boot starts.
TAs use their own pauth keys, I think SPs should do the same. Or we're exposing keys that shouldn't be exposed to SPs.
Cheers, Jens
Br, Gábor
-----Original Message----- From: Jens Wiklander jens.wiklander@linaro.org Sent: Tuesday, June 25, 2024 3:21 PM To: Gabor Toth Gabor.Toth2@arm.com Cc: op-tee@lists.trustedfirmware.org Subject: Re: Enable pointer authentication for the SP initialization
Hi Gabor,
On Tue, Jun 25, 2024 at 1:16 PM Gabor Toth Gabor.Toth2@arm.com wrote:
Hi Guys,
Currently pointer authentication is disabled at the beginning of the SP-s and is enabled after boot_init_primary_late here: https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/kernel/ en try_a64.S#L385
We would like to have it already enabled when the SP starts running to protect all the code and to also avoid problems like having the feature enabled between a paciasp-autiasp pair. I tried moving the feature enablement right before the initialization of the SP-s, here: https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/kernel/ bo ot.c#L1064
When __thread_enter_user_mode is called thread_core_local[0] keys are used by the feature, but before switching to user mode the related registers are set to threads[0].keys and not returned to the original values resulting in exception.
I see three possible ways to solve this:
- Enable PAC before SP initialization is started and restore the original keys in functions that change them if the feature is enabled.
- Enable PAC before SP initialization is started and disable the protection (by attribute) for functions that change keys to avoid such issues.
- Keep enablement like this and disable the protection for the related functions in trusted-services. We would like to avoid this solution due to compatibility issues with other SPMC implementations.
My problem is that I do not understand the purpose of thread_core_local[n].keys and threads[n].keys, why are there two different key pairs?
Each execution context has its own pair of PAC keys to make it harder for one execution context to write something useful into the stack of another execution context.
Is it a bug that the original keys are not restored or is intentional like this?
During boot, until the first exit into the normal world, OP-TEE doesn't have a clear difference between preemptible thread and atomic contexts. Until now we have used a thread-like context when needed by certain functions and then switched back to an atomic context. SPs are initialized during this phase so which context is used is more by chance than by design.
Do you have an idea what would be the best solution for implementing this change?
SPs should be initialized at a later step when SCTLR_ENIA has been enabled. Each SP should use its own pair of PAC keys, they should not try to reuse anything from the thread context or atomic per CPU context.
Cheers, Jens