Hi Varun,
AIU, Usually 2 keys are used to protect 2 different software contexts for enforcing the security boundary between them. This is the case for kernel and userspace. In TF-A, every BL image is allowed to choose the IA key to use, hence every
BL image can have a separate IA key. Each BL image is executing within a single security domain and hence there is less use create a boundary within the BL image by using the 2nd key registers.
The Compiler by default selects either IA or IB instruction key register to use by default. It cannot automatically make use of both key registers and it doesn’t support the use of DA or DB yet I think.
There are some function attributes which allow to use a different key at a function level, but the functions need to be marked out manually. But the requirement for creating the sub-domain within a BL image by specifying a different key
for certain functions has not yet been seen AFAIK.
Best Regards
Soby Mathew
From: TF-A <tf-a-bounces@lists.trustedfirmware.org>
On Behalf Of Varun Wadekar via TF-A
Sent: 13 July 2020 22:20
To: tf-a@lists.trustedfirmware.org
Cc: Kalyani Chidambaram Vaidyanathan <kalyanic@nvidia.com>
Subject: [TF-A] Pointer Authentication keys
Hi,
From the initial read of the Arm ARM, there are multiple keys (instruction, data) provided for authenticating pointers. But the current implementation only writes IA key [1].
I would like to understand the thought process behind programming only one key here. AFAIU, we should enable all keys – IA, IB, DA, DB.
-Varun