In addition to what Dan said about encrypting data, you may want to integrity and replay protect your bl31 data.
Raghu
On Oct 19, 2023, at 7:16 AM, Dan Handley via TF-A tf-a@lists.trustedfirmware.org wrote:
Hi
Just reading the below thread late...
Another reason for running in SRAM rather DRAM is the additional physical security it provides. It is much harder for an attacker to physically probe SRAM than DRAM. If this is something you care about in your platform (e.g. if BL31 contains secrets) then suspend-to-DRAM should also encrypt BL31 state as part of saving to DRAM. If this and the other 2 reasons Okash mentions do not apply, then perhaps executing from DRAM is a reasonable option.
Regards
Dan.
-----Original Message----- From: Okash Khawaja via TF-A tf-a@lists.trustedfirmware.org Sent: Wednesday, October 11, 2023 12:07 PM To: Thomas Richard thomas.richard@bootlin.com Cc: tf-a@lists.trustedfirmware.org; Gregory CLEMENT gregory.clement@bootlin.com Subject: [TF-A] Re: Suspend to RAM support for K3 J7200
Hi Thomas,
On Wed, Oct 11, 2023 at 10:40 AM Thomas Richard via TF-A <tf- a@lists.trustedfirmware.org> wrote:
Hello,
I just sent a series to gerrit: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/23992. I'm writing this email to add more context to this series, as I didn't find how to to it with gerrit.
You should be able to hit Reply and add comment if you're logged into gerrit.
This series is only the TF-A part to add suspend to RAM support for the TI K3 J7200 target. Some modifications are also needed in Linux kernel, U-Boot (R5 SPL) and DM-Firmware. During the suspend sequence, TF-A save itself in DRAM, in a reserved memory region dedicated to lpm. TF-A will be restored by R5 SPL. We need to save it in DRAM (which will be in retention mode during suspend) because as it runs in SRAM, it will be lost once the SOC is powered-off by the PMIC.
General question/discussion point (although your description above provides a good context for it): TF-A BL31 canonically runs from SRAM. But in case like this where we have to copy it to DRAM any way, would it make sense to run BL31 from DRAM and therefore simplify the design? I can think of two reasons why one wouldn't want to do that. First is performance of SRAM vs DRAM. But do we have data which proves one way or the other? With caches enabled after some initial CPU init code, performance difference might be significantly mitigated. Second is a case where BL31 might need to run while DRAM is inaccessible, e.g. a component in the path from CPU to DRAM, or the memory controller itself is power gated. This is possible but seems like niche scenario which may not apply in most cases.
Best Regards,
-- Thomas Richard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com -- TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org
-- TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org
-- TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org