Hi Andrej, Yes, I agree this is a useful design to mitigate the code size issue. Just sharing the advice from security perspective. Basically, we need to review the shared libs carefully(one of the focus of threat modelling).
It's not a mandatory limit. From PSA FF spec v1.0 beta1 section 3.1.4 (Mandatory isolation rules) and 3.1.5 (Optional isolation rules), it's OK to have the shared RO code sections. It doesn't break the mandatory isolation rule I3 - If domain A needs protection from domain B, then Private data in domain A cannot be accessed by domain B.
But it's worth to notice/mention that this will break optional isolation rules I4 and I5. I4 - If domain A needs protection from domain B, then Code and Constant data in domain A is not readable or executable by domain B. I5 - Code in a domain is not executable by any other domain. It makes sense to give the choice to the users. (may notify the user about the potential security risk)
Why the TFM services (SST, attestation) do not call PSA Crypto API?
I think the experts of the modules might be more suitable than me to answer this question. 😊
Thanks.
Hi @Ken Liu (Arm Technology China), I got your reply in another thread, so just to gather them here.
For first point, we can take a security analysis on this part and check if there are vulnerabilities. The security requirement for these code are quite high, you can take 'memset' as example, it is read-only, caller stack based so no footprint would leave to another caller.
Yes, like I mentioned above it's one of the focus of threat modelling.
For seconds point, it is do-able -- but need big change everywhere; and it back to the per-partition library design while we move to isolation level 3.
Understand. Just thinking if we can keep the shared libs in the same protection domain. (to avoid breaking optional isolation rules)
BTW, from PSA FF spec v1.0 beta1 section 3.1.2(memory access rules) rule l1, we may need to consider the separation of RO-Code and RO-data(execution never).
Thanks.
Regards, David Wang Arm Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142)
-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Andrej Butok via TF-M Sent: Monday, March 25, 2019 7:04 PM To: TF-M@lists.trustedfirmware.org Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M
Hi David,
Using shared libraries may give the window to exploit the vulnerabilities.
Yes, you are right. BUT Code size may be a very critical parameter especially for constrained MCUs. Please do not give any mandatory limits. If any, they should be configurable. Let's give a possibility to choose for final users.
BTW:
1) Current TF-M is using library approach with mbedTLS copy per each service. OK, security => but wasting of resources. In our code, we are using one copy of mbedTLS to avoid this type of wasting, but it requires original code modification. Please, give more freedom to final TFM users!
2) Why the TFM services (SST, attestation) do not call PSA Crypto API? It will eliminates mbedTLS duplication.
Thanks, Andrej
-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of David Wang (Arm Technology China) via TF-M Sent: Monday, March 25, 2019 10:57 AM To: tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M
Hi Ken, Some comments from security review's perspective. * Using shared libraries may give the window to exploit the vulnerabilities. App RoT can analyze the shared lib to find out the useable vulnerabilities for attacking PSA RoT. * Is it a good idea to have two separate shared libs - one for all app RoT and one for all PSA RoT for isolation level2? (can still share one copy for level1.)
Regards, David Wang Arm Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142)
-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Monday, March 25, 2019 5:05 PM To: tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M
Hi,
The document is updated due to a change in MPU regions part:
In original design, some partition libraries like 'thread_exit' is going to be linked with partition statically, which means there would be multiple copies of these libraries for each partition. This provided strict protection of isolation but it looks over-protect.
If we keep one shared code region for each partition to call these libraries, we could: * Save memory * The protection is enough if we mark the code area as read-only.
In this case, the unprivileged code and RO region needs to be kept and these shared codes could be put there. The requirement of these codes are: * These codes must be thread safe and reentrant * These codes must be put in read-only region
The change mainly happen under section "Linker script sections re-arrangement". Please help to comment.
Thanks!
-Ken
-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Thursday, March 21, 2019 3:20 PM To: tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M
Hi, The document is updated, and keep open for comments ; )
The updated content is:
- Available MPU regions for peripheral has number limitation based
on platform. If a SP needs many un-continuous peripheral registers and the number exceeds available MPU number, it needs further investigation. 2. Rely on linker to clean the unused object files instead of remove them in scatter before the dependency is fully figured out.
Thanks!
-Ken
From: Ken Liu (Arm Technology China) Sent: Tuesday, February 19, 2019 6:44 PM To: tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: [RFC] Design document of isolation level 2 on TF-M
Hello, The first IPC implementation works under isolation level 1. The high isolation levels need to be there to get compatible with PSA Firmware Framework. A design document is created about implementing isolation level 2 for IPC model: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeve loper.trustedfirmware.org%2Fw%2Ftf_m%2Fdesign%2Ftrusted_firmware-& data=02%7C01%7Candrey.butok%40nxp.com%7C6a9c2cb6a5034aec48b908d6b10845 48%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636891046406628979& ;sdata=yPus0lkd4L71ng5Z5o2hu2bDEMBAzSwUxAm1fyYf564%3D&reserved=0 m_isolation_level_2/
The mainly change of isolation level 2 compare to isolation level 1 is:
- Put AppRoT Secure Partitions' components with same attribute (code,
read- only data, read-write data) into the same region, which helps MPU setting region attributes.
- Change Secure Partition privileged setting based on Secure Partition
type while scheduling.
- Change mechanism of privileged API, such as printf.
If you have any comments please share it. You can reply in mailing list if there is no place for putting comments on the page.
Thank you!
-Ken
-- TF-M mailing list TF-M@lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist s.trustedfirmware.org%2Fmailman%2Flistinfo%2Ftf-m&data=02%7C01%7Ca ndrey.butok%40nxp.com%7C6a9c2cb6a5034aec48b908d6b1084548%7C686ea1d3bc2 b4c6fa92cd99c5c301635%7C0%7C0%7C636891046406638984&sdata=7Wva1R6Lv EKMxCpaVr6gRE26Fodub%2FPTQlLOiB2YvX0%3D&reserved=0
-- TF-M mailing list TF-M@lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.trus... -- TF-M mailing list TF-M@lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.trus... -- TF-M mailing list TF-M@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m
tf-m@lists.trustedfirmware.org