Hi Varun,
Thank you for the suggestions. My comments are inline.
Petre
________________________________ From: TF-A tf-a-bounces@lists.trustedfirmware.org on behalf of Varun Wadekar via TF-A tf-a@lists.trustedfirmware.org Sent: 18 February 2020 05:44 To: Raghu Krishnamurthy raghu.ncstate@icloud.com Cc: tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] Protecting Secure World Translation Tables
Thanks Raghu.
I agree that this patch reduces the attack surface and would be a good addition, if we consider use cases where EL3 code runs in a silo. Since S-EL1 can contain any third party code, there is an opportunity to change memory contents without EL3 ever noticing the change. A hash for the RO page tables would improve this change immensely IMO.
Petre: Thank you for the suggestion. Sounds like an interesting improvement to make (maybe in a follow-up to this change?, since my rotation in the TF-A team is nearing its end).
This change is not effective for platforms that use dynamic page tables e.g. Tegra platforms, so we won't be enabling it. But if other maintainers think this is a good addition to their platforms, I don’t have any objection.
Petre: Do you think it would be worth making this feature play more nicely with the dynamic translation library? I'm thinking providing a counter-API to make tables writable again. So that, every time a dynamic API is needed, since the translation context will be aware of the tables being RO, it first calls a make_tables_writable API before doing whatever it needs to and after it completes (whether successfully or not) calls make_tables_readonly. Essentially, it would act like a wrapper around the dynamic library functions.
What do you think of this? Is the disable MMU + cache flush penalty too severe (incurred twice for each dynamic xlat API call)?
-----Original Message----- From: TF-A tf-a-bounces@lists.trustedfirmware.org On Behalf Of Raghu Krishnamurthy via TF-A Sent: Monday, February 17, 2020 4:16 PM To: tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] Protecting Secure World Translation Tables
External email: Use caution opening links or attachments
I think it is worth implementing this to raise the bar for successful attacks. To Varun's point, in today's systems without S-EL2(<v8.4), it would be less effective as pointed out, since EL3 memory can be completely accessed by SEL1 and SEL1 code tends to have a larger code base on mobile devices(OPTEE, tlk etc). However, on systems with very thin SEL1 shims(typically servers), this would definitely raise the bar for attacks, since you effectively only have SEL0 and EL3. SEL1 cannot be exploited practically.
For new SoCs with SEL2, this mitigation can still be very effective if we can ensure future SEL2 implementations have much smaller code bases and implements this mitigation itself. Effectively, i view SEL2 and EL3 as being equally privileged(it is no different than SEL1 because SEL2 can barf all over EL3 memory and TZ resources if exploited). SEL2 extensions, however, gives EL3 protection from SEL1 and can prevent SEL1 from accessing ALL TZ resources. If you view SEL2 and EL3 as equally privileged and view both together as a single entity, v8.4 systems effectively have EL3, SEL1, SEL0 AND the ability for EL3 to protect itself and other TZ resources from SEL1. In such a system, EL3(and SEL2) having this mitigation will definitely raise the bar for successful attacks.
Also, the cost to implement this mitigation is relatively low for a fairly significant raise in the bar for successful attacks.
PS - I say significantly raise the bar since an attacker will potentially require gadgets to modify TTBRx, invalidate TLB's, and enough gadgets in the code base to have a successful attack. If code in TF-A EL3 is fairly small, and code that writes to TTBR_EL3 can be in some section of the image that can be reclaimed/erased after initial setup, the attacker would have no gadget to modify TTBR_EL3, so there would be virtually no way to change TTBR_EL3. On a default build of FVP, there is a grand total of 1 instruction that writes to TTBR0_EL3 in enable_mmu_direct_el3. This might be a nice follow up change to this mitigation, if others think it is worth it. The same could be extended to other system registers that don't ever need to be changed(VBAR_EL3? SCTLR_EL3?).
Thanks Raghu
On 2/17/20 12:35 PM, Varun Wadekar via TF-A wrote:
Hello Petre,
Thanks for the patch. Before I review the actual code, would like to understand how effective this patch will be and if you have seen a real world attack that this patch mitigates.
AFAIU, the ARM architecture provides the TZ bit as the only protection to create "partitions" on a CPU core. So, potentially S-EL1 can access almost all TZ resources that EL3 can access. Thus, creating a silo inside EL3 exception mode is not an effective mitigation against any other TZ component writing to the physical memory where the page tables are stored. For the scope of this attack vector, are we assuming that the system cannot be compromised by attacking other TZ software components in the system?
I feel until we have a way to distinguish between CPU realms (EL3 v S-EL2 v S-EL1) at the hardware bus level (ARM v9?), these mitigations are not that effective.
Thoughts?
-Varun
-----Original Message----- From: TF-A tf-a-bounces@lists.trustedfirmware.org On Behalf Of Petre-Ionut Tudor via TF-A Sent: Monday, February 17, 2020 9:40 AM To: tf-a@lists.trustedfirmware.org Subject: [TF-A] Protecting Secure World Translation Tables
External email: Use caution opening links or attachments
Hello Everyone,
For quite some time I have been working on a security hardening feature that offers extra protection against tampering with the Secure world translation tables. An example would be using a gadget that can perform writes to arbitrary Secure memory locations to change memory attributes and/or the memory map.
A real world exploit that uses read/write gadgets to tamper with translation tables can be found here: https://vimeo.com/335948808. If you only want the slide deck, it's available here: https://speakerdeck.com/hhj4ck/el3-tour-get-the-ultimate-privilege-of-androi....
A patch implementing this feature has been recently pushed upstream here: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3349. It extends v2 of the translation tables library with an API that can be called by a BL image any time after the initialization of the xlat tables to make them read-only.
It would be great to hear your opinions about this, particularly whether or not it is a desirable feature to have in TF-A and what extra work needs to be done for it to meet the use cases that you consider most relevant.
Best wishes Petre IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-A mailing list TF-A@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a
------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
-- TF-A mailing list TF-A@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- TF-A mailing list TF-A@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a
Hi Petre,
We can consider adding a hash for the page tables in another patch.
Petre: Do you think it would be worth making this feature play more nicely with the dynamic translation library? I'm thinking providing a counter-API to make tables writable again. So that, every time a dynamic API is needed, since the translation context will be aware of the tables being RO, it first calls a make_tables_writable API before doing whatever it needs to and after it completes (whether successfully or not) calls make_tables_readonly. Essentially, it would act like a wrapper around the dynamic library functions.
What do you think of this? Is the disable MMU + cache flush penalty too severe (incurred twice for each dynamic xlat API call)?
[VW] I think it would be great if the dynamic mappings work with the patch. I understand that one draw back would be additional latency (disable MMU + cache flush). I do not have exact numbers to see how much of an impact that would be. Do you have any reference numbers?
-Varun
From: Petre-Ionut Tudor Petre-Ionut.Tudor@arm.com Sent: Tuesday, February 18, 2020 7:02 AM To: Raghu Krishnamurthy raghu.ncstate@icloud.com; Varun Wadekar vwadekar@nvidia.com Cc: nd nd@arm.com; Varun Wadekar via TF-A tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] Protecting Secure World Translation Tables
External email: Use caution opening links or attachments
Hi Varun,
Thank you for the suggestions. My comments are inline.
Petre
________________________________ From: TF-A <tf-a-bounces@lists.trustedfirmware.orgmailto:tf-a-bounces@lists.trustedfirmware.org> on behalf of Varun Wadekar via TF-A <tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org> Sent: 18 February 2020 05:44 To: Raghu Krishnamurthy <raghu.ncstate@icloud.commailto:raghu.ncstate@icloud.com> Cc: tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org> Subject: Re: [TF-A] Protecting Secure World Translation Tables
Thanks Raghu.
I agree that this patch reduces the attack surface and would be a good addition, if we consider use cases where EL3 code runs in a silo. Since S-EL1 can contain any third party code, there is an opportunity to change memory contents without EL3 ever noticing the change. A hash for the RO page tables would improve this change immensely IMO.
Petre: Thank you for the suggestion. Sounds like an interesting improvement to make (maybe in a follow-up to this change?, since my rotation in the TF-A team is nearing its end).
This change is not effective for platforms that use dynamic page tables e.g. Tegra platforms, so we won't be enabling it. But if other maintainers think this is a good addition to their platforms, I don't have any objection.
Petre: Do you think it would be worth making this feature play more nicely with the dynamic translation library? I'm thinking providing a counter-API to make tables writable again. So that, every time a dynamic API is needed, since the translation context will be aware of the tables being RO, it first calls a make_tables_writable API before doing whatever it needs to and after it completes (whether successfully or not) calls make_tables_readonly. Essentially, it would act like a wrapper around the dynamic library functions.
What do you think of this? Is the disable MMU + cache flush penalty too severe (incurred twice for each dynamic xlat API call)?
-----Original Message----- From: TF-A <tf-a-bounces@lists.trustedfirmware.orgmailto:tf-a-bounces@lists.trustedfirmware.org> On Behalf Of Raghu Krishnamurthy via TF-A Sent: Monday, February 17, 2020 4:16 PM To: tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] Protecting Secure World Translation Tables
External email: Use caution opening links or attachments
I think it is worth implementing this to raise the bar for successful attacks. To Varun's point, in today's systems without S-EL2(<v8.4), it would be less effective as pointed out, since EL3 memory can be completely accessed by SEL1 and SEL1 code tends to have a larger code base on mobile devices(OPTEE, tlk etc). However, on systems with very thin SEL1 shims(typically servers), this would definitely raise the bar for attacks, since you effectively only have SEL0 and EL3. SEL1 cannot be exploited practically.
For new SoCs with SEL2, this mitigation can still be very effective if we can ensure future SEL2 implementations have much smaller code bases and implements this mitigation itself. Effectively, i view SEL2 and EL3 as being equally privileged(it is no different than SEL1 because SEL2 can barf all over EL3 memory and TZ resources if exploited). SEL2 extensions, however, gives EL3 protection from SEL1 and can prevent SEL1 from accessing ALL TZ resources. If you view SEL2 and EL3 as equally privileged and view both together as a single entity, v8.4 systems effectively have EL3, SEL1, SEL0 AND the ability for EL3 to protect itself and other TZ resources from SEL1. In such a system, EL3(and SEL2) having this mitigation will definitely raise the bar for successful attacks.
Also, the cost to implement this mitigation is relatively low for a fairly significant raise in the bar for successful attacks.
PS - I say significantly raise the bar since an attacker will potentially require gadgets to modify TTBRx, invalidate TLB's, and enough gadgets in the code base to have a successful attack. If code in TF-A EL3 is fairly small, and code that writes to TTBR_EL3 can be in some section of the image that can be reclaimed/erased after initial setup, the attacker would have no gadget to modify TTBR_EL3, so there would be virtually no way to change TTBR_EL3. On a default build of FVP, there is a grand total of 1 instruction that writes to TTBR0_EL3 in enable_mmu_direct_el3. This might be a nice follow up change to this mitigation, if others think it is worth it. The same could be extended to other system registers that don't ever need to be changed(VBAR_EL3? SCTLR_EL3?).
Thanks Raghu
On 2/17/20 12:35 PM, Varun Wadekar via TF-A wrote:
Hello Petre,
Thanks for the patch. Before I review the actual code, would like to understand how effective this patch will be and if you have seen a real world attack that this patch mitigates.
AFAIU, the ARM architecture provides the TZ bit as the only protection to create "partitions" on a CPU core. So, potentially S-EL1 can access almost all TZ resources that EL3 can access. Thus, creating a silo inside EL3 exception mode is not an effective mitigation against any other TZ component writing to the physical memory where the page tables are stored. For the scope of this attack vector, are we assuming that the system cannot be compromised by attacking other TZ software components in the system?
I feel until we have a way to distinguish between CPU realms (EL3 v S-EL2 v S-EL1) at the hardware bus level (ARM v9?), these mitigations are not that effective.
Thoughts?
-Varun
-----Original Message----- From: TF-A <tf-a-bounces@lists.trustedfirmware.orgmailto:tf-a-bounces@lists.trustedfirmware.org> On Behalf Of Petre-Ionut Tudor via TF-A Sent: Monday, February 17, 2020 9:40 AM To: tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org Subject: [TF-A] Protecting Secure World Translation Tables
External email: Use caution opening links or attachments
Hello Everyone,
For quite some time I have been working on a security hardening feature that offers extra protection against tampering with the Secure world translation tables. An example would be using a gadget that can perform writes to arbitrary Secure memory locations to change memory attributes and/or the memory map.
A real world exploit that uses read/write gadgets to tamper with translation tables can be found here: https://vimeo.com/335948808. If you only want the slide deck, it's available here: https://speakerdeck.com/hhj4ck/el3-tour-get-the-ultimate-privilege-of-androi....
A patch implementing this feature has been recently pushed upstream here: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3349. It extends v2 of the translation tables library with an API that can be called by a BL image any time after the initialization of the xlat tables to make them read-only.
It would be great to hear your opinions about this, particularly whether or not it is a desirable feature to have in TF-A and what extra work needs to be done for it to meet the use cases that you consider most relevant.
Best wishes Petre IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-A mailing list TF-A@lists.trustedfirmware.orgmailto:TF-A@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a
------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
-- TF-A mailing list TF-A@lists.trustedfirmware.orgmailto:TF-A@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- TF-A mailing list TF-A@lists.trustedfirmware.orgmailto:TF-A@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a
Hi Varun,
[VW] I think it would be great if the dynamic mappings work with the patch.
Thank you for this feedback. This is something for the future, though, since one implication would be that, from the perspective of the dynamic translation APIs, the xlat tables would essentially be read-write, but at the same time so would all of Secure physical memory locations (since the MMU would be off). Therefore, extra care would need to be taken not to give/expose new gadgets that can do nasty things.
Sadly, my time in the TF-A team is nearing its end, so the priority now is for the basic feature to make its way into the code base.
I understand that one draw back would be additional latency (disable MMU + cache flush). I do not have exact numbers to see how much of an impact that would be. Do you have any reference numbers?
Unfortunately I haven't done any profiling here, since this API was designed to only be called once, during boot time. Therefore, we did not concentrate so much on the performance penalty incurred. I imagine it might get pretty severe if lots of calls are made, since we lose the cache...
Thanks Petre ________________________________ From: Varun Wadekar vwadekar@nvidia.com Sent: 18 February 2020 18:47 To: Petre-Ionut Tudor Petre-Ionut.Tudor@arm.com; Raghu Krishnamurthy raghu.ncstate@icloud.com Cc: nd nd@arm.com; Varun Wadekar via TF-A tf-a@lists.trustedfirmware.org; tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org Subject: RE: [TF-A] Protecting Secure World Translation Tables
Hi Petre,
We can consider adding a hash for the page tables in another patch.
Petre: Do you think it would be worth making this feature play more nicely with the dynamic translation library? I'm thinking providing a counter-API to make tables writable again. So that, every time a dynamic API is needed, since the translation context will be aware of the tables being RO, it first calls a make_tables_writable API before doing whatever it needs to and after it completes (whether successfully or not) calls make_tables_readonly. Essentially, it would act like a wrapper around the dynamic library functions.
What do you think of this? Is the disable MMU + cache flush penalty too severe (incurred twice for each dynamic xlat API call)?
[VW] I think it would be great if the dynamic mappings work with the patch. I understand that one draw back would be additional latency (disable MMU + cache flush). I do not have exact numbers to see how much of an impact that would be. Do you have any reference numbers?
-Varun
From: Petre-Ionut Tudor Petre-Ionut.Tudor@arm.com Sent: Tuesday, February 18, 2020 7:02 AM To: Raghu Krishnamurthy raghu.ncstate@icloud.com; Varun Wadekar vwadekar@nvidia.com Cc: nd nd@arm.com; Varun Wadekar via TF-A tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] Protecting Secure World Translation Tables
External email: Use caution opening links or attachments
Hi Varun,
Thank you for the suggestions. My comments are inline.
Petre
________________________________
From: TF-A <tf-a-bounces@lists.trustedfirmware.orgmailto:tf-a-bounces@lists.trustedfirmware.org> on behalf of Varun Wadekar via TF-A <tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org> Sent: 18 February 2020 05:44 To: Raghu Krishnamurthy <raghu.ncstate@icloud.commailto:raghu.ncstate@icloud.com> Cc: tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org> Subject: Re: [TF-A] Protecting Secure World Translation Tables
Thanks Raghu.
I agree that this patch reduces the attack surface and would be a good addition, if we consider use cases where EL3 code runs in a silo. Since S-EL1 can contain any third party code, there is an opportunity to change memory contents without EL3 ever noticing the change. A hash for the RO page tables would improve this change immensely IMO.
Petre: Thank you for the suggestion. Sounds like an interesting improvement to make (maybe in a follow-up to this change?, since my rotation in the TF-A team is nearing its end).
This change is not effective for platforms that use dynamic page tables e.g. Tegra platforms, so we won't be enabling it. But if other maintainers think this is a good addition to their platforms, I don’t have any objection.
Petre: Do you think it would be worth making this feature play more nicely with the dynamic translation library? I'm thinking providing a counter-API to make tables writable again. So that, every time a dynamic API is needed, since the translation context will be aware of the tables being RO, it first calls a make_tables_writable API before doing whatever it needs to and after it completes (whether successfully or not) calls make_tables_readonly. Essentially, it would act like a wrapper around the dynamic library functions.
What do you think of this? Is the disable MMU + cache flush penalty too severe (incurred twice for each dynamic xlat API call)?
-----Original Message----- From: TF-A <tf-a-bounces@lists.trustedfirmware.orgmailto:tf-a-bounces@lists.trustedfirmware.org> On Behalf Of Raghu Krishnamurthy via TF-A Sent: Monday, February 17, 2020 4:16 PM To: tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] Protecting Secure World Translation Tables
External email: Use caution opening links or attachments
I think it is worth implementing this to raise the bar for successful attacks. To Varun's point, in today's systems without S-EL2(<v8.4), it would be less effective as pointed out, since EL3 memory can be completely accessed by SEL1 and SEL1 code tends to have a larger code base on mobile devices(OPTEE, tlk etc). However, on systems with very thin SEL1 shims(typically servers), this would definitely raise the bar for attacks, since you effectively only have SEL0 and EL3. SEL1 cannot be exploited practically.
For new SoCs with SEL2, this mitigation can still be very effective if we can ensure future SEL2 implementations have much smaller code bases and implements this mitigation itself. Effectively, i view SEL2 and EL3 as being equally privileged(it is no different than SEL1 because SEL2 can barf all over EL3 memory and TZ resources if exploited). SEL2 extensions, however, gives EL3 protection from SEL1 and can prevent SEL1 from accessing ALL TZ resources. If you view SEL2 and EL3 as equally privileged and view both together as a single entity, v8.4 systems effectively have EL3, SEL1, SEL0 AND the ability for EL3 to protect itself and other TZ resources from SEL1. In such a system, EL3(and SEL2) having this mitigation will definitely raise the bar for successful attacks.
Also, the cost to implement this mitigation is relatively low for a fairly significant raise in the bar for successful attacks.
PS - I say significantly raise the bar since an attacker will potentially require gadgets to modify TTBRx, invalidate TLB's, and enough gadgets in the code base to have a successful attack. If code in TF-A EL3 is fairly small, and code that writes to TTBR_EL3 can be in some section of the image that can be reclaimed/erased after initial setup, the attacker would have no gadget to modify TTBR_EL3, so there would be virtually no way to change TTBR_EL3. On a default build of FVP, there is a grand total of 1 instruction that writes to TTBR0_EL3 in enable_mmu_direct_el3. This might be a nice follow up change to this mitigation, if others think it is worth it. The same could be extended to other system registers that don't ever need to be changed(VBAR_EL3? SCTLR_EL3?).
Thanks Raghu
On 2/17/20 12:35 PM, Varun Wadekar via TF-A wrote:
Hello Petre,
Thanks for the patch. Before I review the actual code, would like to understand how effective this patch will be and if you have seen a real world attack that this patch mitigates.
AFAIU, the ARM architecture provides the TZ bit as the only protection to create "partitions" on a CPU core. So, potentially S-EL1 can access almost all TZ resources that EL3 can access. Thus, creating a silo inside EL3 exception mode is not an effective mitigation against any other TZ component writing to the physical memory where the page tables are stored. For the scope of this attack vector, are we assuming that the system cannot be compromised by attacking other TZ software components in the system?
I feel until we have a way to distinguish between CPU realms (EL3 v S-EL2 v S-EL1) at the hardware bus level (ARM v9?), these mitigations are not that effective.
Thoughts?
-Varun
-----Original Message----- From: TF-A <tf-a-bounces@lists.trustedfirmware.orgmailto:tf-a-bounces@lists.trustedfirmware.org> On Behalf Of Petre-Ionut Tudor via TF-A Sent: Monday, February 17, 2020 9:40 AM To: tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org Subject: [TF-A] Protecting Secure World Translation Tables
External email: Use caution opening links or attachments
Hello Everyone,
For quite some time I have been working on a security hardening feature that offers extra protection against tampering with the Secure world translation tables. An example would be using a gadget that can perform writes to arbitrary Secure memory locations to change memory attributes and/or the memory map.
A real world exploit that uses read/write gadgets to tamper with translation tables can be found here: https://vimeo.com/335948808. If you only want the slide deck, it's available here: https://speakerdeck.com/hhj4ck/el3-tour-get-the-ultimate-privilege-of-androi....
A patch implementing this feature has been recently pushed upstream here: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3349. It extends v2 of the translation tables library with an API that can be called by a BL image any time after the initialization of the xlat tables to make them read-only.
It would be great to hear your opinions about this, particularly whether or not it is a desirable feature to have in TF-A and what extra work needs to be done for it to meet the use cases that you consider most relevant.
Best wishes Petre IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-A mailing list TF-A@lists.trustedfirmware.orgmailto:TF-A@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a
------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
-- TF-A mailing list TF-A@lists.trustedfirmware.orgmailto:TF-A@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- TF-A mailing list TF-A@lists.trustedfirmware.orgmailto:TF-A@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a
tf-a@lists.trustedfirmware.org
-
Petre-Ionut Tudor -
Varun Wadekar