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
[1] https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/+...
Hi Soby,
Thanks for the explanation. I agree with the justification for using one key per BL. But it also makes sense to use DA in tandem to cover data pointers.
I guess, since this is a new feature we will have to wait until the toolchain catches up and supports multiple keys or more use cases show up.
-Varun
From: Soby Mathew Soby.Mathew@arm.com Sent: Thursday, July 16, 2020 7:34 AM To: Varun Wadekar vwadekar@nvidia.com Cc: Kalyani Chidambaram Vaidyanathan kalyanic@nvidia.com; tf-a@lists.trustedfirmware.org Subject: RE: Pointer Authentication keys
External email: Use caution opening links or attachments
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.orgmailto: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.orgmailto:tf-a@lists.trustedfirmware.org Cc: Kalyani Chidambaram Vaidyanathan <kalyanic@nvidia.commailto: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
[1] https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/+...
tf-a@lists.trustedfirmware.org
-
Soby Mathew -
Varun Wadekar