On 1/9/24 18:32, Andrew Davis wrote:
On 1/8/24 10:56 AM, Thomas Richard wrote:
This series is the U-Boot part of the work to add the suspend to RAM support for the K3 J7200 EVM board.
During the boot R5 SPL makes a copy of DM-Firmware and TF-A in memory. Resume detection is done by reading a magic value in a pmic register (set by DM-Firmware).
If a resume is detected, R5 SPL run the exit retention sequence of the DDR. Then it load TF-A and DM-Firmware using the copies done during the boot (fit image processing is skipped). Before to start TF-A, R5 SPL writes a magic value in scratchpad ram. This will be used by TF-A to detect that the board is resuming.
The copy of TF-A/DM-Firmware, the SPL stack and malloc are located in a reserved memory region (for the kernel point of view) to avoid any memory corruption.
This version is mostly to test the firewall protection with the suspend to ram.
Seems to show the opposite, if you are able to access and load TF-A back to its spot after resume from un-trusted SPL then the firewall did not survive suspend to RAM. That is a huge security gap if TIFS is forgetting to put back the firewalls on resume.. What is the point of firewalls on these systems if I can just knock them all out by doing a simple suspend/resume cycle?
Hello Andrew,
Why are you talking about un-trusted SPL, how R5 SPL can be un-trusted ? Our resume sequence starts like a power-on: ROM code is started, it loads TIFS and R5 SPL. As defined in the chain of trust [1], ROM authenticates TIFS and R5 SPL. So I don't understand how R5 SPL can be un-trusted.
Then R5 SPL detects that the board is resuming (and does some specific operations on the DDR). But even if the board is resuming, TF-A is authenticated (using ti_secure_image_post_process) like during the boot.
So once TF-A is loaded, firewall is active. TF-A restores its context, then jump to its warm entrypoint.
I guess a weak point could be TF-A context (stored in DDR).
[1] https://docs.u-boot.org/en/latest/board/ti/k3.html#chain-of-trust
Some comments (for the v2) were not fixed in this version.
Why not?
This series has been tested with the series [1] to enable the firewall. At the end of the resume sequence, TF-A is well protected by the firewall, but OP-TEE remains unprotected.
Then why post this? If it is just to get some eyes on it, then label it as an "RFC" so our silence isn't considered acceptance, otherwise we have to manually NAK these each time.
Yes sorry, I totally forgot to label it as RFC.
Regards,
Thomas