PSA-FF does not require isolation of code. Section 3.1 describes the isolation architecture (pages 21-25) and has three mandatory rules:
1. Only "code" is executable 2. Only "private data" is writable 3. "private data" is protected from untrusted "protection domains". (E.g. secure side "private data" cannot be accessed by non-secure)
[quoted items are defined terms in that section of the document]
Protecting "code" and "constant data" from other "protection domains" is provided in optional isolation rules 4, 5 and 6 with increasing levels of isolation (and system cost). The security rationale for isolating code is (a) confidentiality of the code and associated read-only data and (b) reduction of the number of ROP/JOP gadgets available to an attacker.
The level of isolation and implementation of the optional rules is intended to be a framework and/or product decision in order to match the product security requirements.
Regards, Andrew
From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Ken Liu via TF-M Sent: 09 January 2020 09:01 To: tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: Re: [TF-M] Code Protection between secure services
Hi,
I assume the main purpose of isolation would be protect the code been seen by the AppRoT. Let's check with the FF author for detailed answers.
The building instructions now is just create separate libraries and finally combine them together - since vendors can create Secure Partitions, these modularized building can't be avoided.
/Ken
From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Reinhard Keil via TF-M Sent: Thursday, January 9, 2020 4:00 PM To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Subject: [TF-M] Code Protection between secure services
I suggest we review the requirement of code isolation on the secure side.
R/W data and R/O data should definitely be isolated, but code isolation has implications:
* Code cannot be share between services (i.e. no linker optimization to reduce memory footprint) * Sharing library code * Overall the build instructions of the system are more complicated * Adding device specific driver code (i.e. to crypto) can become tricky
Reinhard 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.