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. -----------------------------------------------------------------------------------
Hi Varun,
Thank you for your comments. Indeed, without S-EL2, the effectiveness of this mitigation is reduced, but it's not completely useless since in order to successfully tamper with the tables, EL3 gadgets are still required. The goal is to maximize the number of gadgets required by an attacker to actually see the effects of a write to the translation tables. Essentially, to tie the translation tables as much as possible to the hardware state (TLB, cache).
Just how much harder this raises the bar depends on the exception level that the write gadget operates in. Assuming the goal is to protect EL3 tables, then if an attacker has a write gadget at:
* EL3, they would also need: * A TLBI gadget in EL3 * A cache flush gadget in EL3 if hardware assisted coherency is not supported * Gadgets to disable/enable the MMU, since it would prevent them from making the change. So, the sequence would be "disable MMU -> write to tables -> propagate changes (with the above two gadgets) -> enable MMU" * S-EL1/S-EL0, they would also need: * A TLBI gadget in EL3 * A cache flush gadget in EL3 if hardware assisted coherency is not supported * So, no difference here made by changing permissions from RW to RO, but still needs EL3 gadgets to invalidate TLB entries and flush caches.
The only real world exploit that I am aware of (and the one which inspired the development of this feature) is this: https://vimeo.com/335948808. It is the EL3 scenario shown above, but the attacker also obtained control of the PC (which I guess is kind of a "game over" case anyway). I guess it would be easy for them in that case to simply jump to the disable/enable MMU routines and complete the sequence, but without the PC gadget this becomes quite tricky IMO. The May 2018 versions of Huawei kernel and trusted firmware were used in the exploit (these security holes were patched later that year).
Petre [https://www.bing.com/th?id=OVP.hPhwCT9CykNTW2AkhMyGFgEsCo&pid=Api]https://vimeo.com/335948808 EL3 Tour: Get the Ultimate Privilege of Android Phone - Guanxing Wen - INFILTRATE 2019https://vimeo.com/335948808 INFILTRATE 2020 will be held April 23/24, Miami Beach, Florida, infiltratecon.com vimeo.com
________________________________ From: Varun Wadekar vwadekar@nvidia.com Sent: 17 February 2020 20:35 To: Petre-Ionut Tudor Petre-Ionut.Tudor@arm.com Cc: tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org Subject: RE: Protecting Secure World Translation Tables
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@lists.trustedfirmware.org