Hi Okash, Thanks for raising this. There have been many discussions on these within the team. There are security tradeoffs when moving data structures from SRAM to DRAM as they are now susceptible to DDR attacks like row hammer. So, any moving of data from SRAM need to be done analyzing the security tradeoffs. This decision would need to be platform specific based on Threat model of the deployment. Also, it would be good if TF-A can have a framework to easily allocate memory in DDR rather than via linker scripts as done today. One possible mitigation for DDR allocations is to have a mechanism to store the SHA in SRAM so that BL31 can verify the integrity (although PoC-PoU threat remains which needs to be mitigated separately).
From my PoV, these are some of the improvements that need to be made :
1. Any new Architectural features should not affect platforms which do not use the feature. Today, even though the code is compiled out with suitable ENABLE_FEAT_yyy flag, the data footprint cost is not removed. EL2 sysreg is a single data structure and any feature register increases the memory footprint : https://github.com/ARM-software/arm-trusted-firmware/blob/master/include/lib...
2. Make it easier for platforms to reclaim boot code and use as R/W data like stack. We did some work with the introduction `__init` attribute. There are probably more functions which can have `__init` attribute as TF-A has evolved from the initial work. I am not sure if any platform other than FVP is using this reclaim feature.
3. Add capability to reclaim boot time data at runtime. This could be marked by `__initdata` attribute. The init data that comes to mind are the rw data used for FCONF and perhaps XLAT_TABLE_LIB.
4. Remove the EL1 context when SPM is present in S-EL2. This needs Hafnium to be able to save incoming NS EL1 context which it doesn't have today. This will also help CCA systems as RMM also follows the same model and is potentially a huge saving as in a CCA system this can save 528 bytes of SRAM per CPU. So on a 64 CPU system this is ~30 Kb on a 64 CPU system. This will help any S-EL2/CCA systems to reduce the SRAM footprint.
Best Regards Soby Mathew
-----Original Message----- From: Okash Khawaja via TF-A tf-a@lists.trustedfirmware.org Sent: Monday, July 17, 2023 12:54 PM To: tf-a@lists.trustedfirmware.org Subject: [TF-A] The increasing size of BL31
Hi,
Typically, BL31 runs in SRAM which tends to be limited. As we add support for newer architectural features e.g. CCA, general features and standards, the size of BL31 image will grow and become harder to fit in most SRAMs.
This email is to share ideas on how to address this problem.
A simple approach will be to identify parts of NOBITS ELF sections of BL31 which can be moved out to DRAM. Since NOBITS sections aren't part of the file image, loading and authentication code doesn't have to change. The challenge will be to come up with some criteria to help decide what kind of buffers can be kept in DRAM vs SRAM.
Other ideas are also welcome. Please share your thoughts.
Thanks, Okash -- TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org