Hi Soby Mathew,
Thanks for your reply.
IMHO, the isolate pagetable is much more heavy. It looks like a big idea.
And if we have a dynamic mapping function, which map the service's needed memory in the service's call can also mitigate this. But this can be more slower.
For accessing limited resource, what's your idea?
-Feng
On 2019/7/9 4:27 下午, Soby Mathew wrote:
Hi Feng, Thanks for your email. This is an interesting topic and this is an active area of work for us but in a slightly different manner. Could you please send this message to the mailing list tf-a@lists.trustedfirmware.org , so we can continue conversation on the list ?
The mailing list info can be found here : https://lists.trustedfirmware.org/mailman/listinfo/tf-a
Thanks & Regards Soby Mathew
-----Original Message----- From: feng chen puck.chen@foxmail.com Sent: 08 July 2019 16:24 To: Dan Handley Dan.Handley@arm.com; Soby Mathew Soby.Mathew@arm.com; Sandrine Bailleux Sandrine.Bailleux@arm.com; Alexei Fedorov Alexei.Fedorov@arm.com; Paul Beesley Paul.Beesley@arm.com; John Tsichritzis John.Tsichritzis@arm.com Subject: [RFC] isolate the memory into different pagetable for TF-A
Hello maintainers,
Is it possible for mapping the memory into different page-tables for TF-A?
Since the ATF is running in EL3 mode, which is the highest level of ARM SoCs.
And for security reason, once one service provided in TF has some vulnerabilities, It can access all the memory TF mapped. And it could be more acceptable.
Thinking about the userland goto kernelland, the process use isolated page tables.
So I want to implement this for TF-A, different memory-mapping for different service, and it can also use a shared mem-mapping space which all the service need to use.
I want to know how do you think about this? Does this make sense to you?
Cherrs,
Feng
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.
On 09/07/2019 16:21, feng chen wrote:
Hi Soby Mathew,
Thanks for your reply.
IMHO, the isolate pagetable is much more heavy. It looks like a big idea.
Hi Feng Chen, To reply to your earlier query, direction of travel for TF-A is to move EL3 services into Secure Partitions at lower ELs (S-EL1/S-EL0), allowing a reduction of EL3 memory mappings. This will sandbox the service in its own virtual address space. The plan is to reduce the amount of EL3 firmware and the associated memory mappings thus reducing the attack surface. The whitepaper mentioned below has further details on this :
https://community.arm.com/processors/b/blog/posts/architecting-more-secure-w...
Mapping in specific memory regions for services at EL3 seems possible, but would be restricted to peripheral/data memory for the service. Isolating the `code` for the service within EL3 would be very expensive and, being the same exception level, it has questionable security benefit. The SPM architecture discussed in the white paper is a better solution wherein the services are isolated at a lower EL with the help of virtualization support in hardware.
And if we have a dynamic mapping function, which map the service's needed memory in the service's call can also mitigate this. But this can be more slower.
For accessing limited resource, what's your idea?
If you are referring to the case when several services want to access the same device, one solution with the SPM model is to encapsulate the device in its own `secure partition` thus every service wanting to access the device will have to send the request to this secure partition. The other solution would be for the S-EL2 hypervisor to trap accesses to these devices and handle it on service' behalf.
Best Regards Soby Mathew
-Feng
On 2019/7/9 4:27 下午, Soby Mathew wrote:
Hi Feng, Thanks for your email. This is an interesting topic and this is an active area of work for us but in a slightly different manner. Could you please send this message to the mailing list tf-a@lists.trustedfirmware.org , so we can continue conversation on the list ?
The mailing list info can be found here : https://lists.trustedfirmware.org/mailman/listinfo/tf-a
Thanks & Regards Soby Mathew
-----Original Message----- From: feng chen puck.chen@foxmail.com Sent: 08 July 2019 16:24 To: Dan Handley Dan.Handley@arm.com; Soby Mathew Soby.Mathew@arm.com; Sandrine Bailleux Sandrine.Bailleux@arm.com; Alexei Fedorov Alexei.Fedorov@arm.com; Paul Beesley Paul.Beesley@arm.com; John Tsichritzis John.Tsichritzis@arm.com Subject: [RFC] isolate the memory into different pagetable for TF-A
Hello maintainers,
Is it possible for mapping the memory into different page-tables for TF-A?
Since the ATF is running in EL3 mode, which is the highest level of ARM SoCs.
And for security reason, once one service provided in TF has some vulnerabilities, It can access all the memory TF mapped. And it could be more acceptable.
Thinking about the userland goto kernelland, the process use isolated page tables.
So I want to implement this for TF-A, different memory-mapping for different service, and it can also use a shared mem-mapping space which all the service need to use.
I want to know how do you think about this? Does this make sense to you?
Cherrs,
Feng
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.
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@lists.trustedfirmware.org