[PATCH v3 0/8] Suspend to RAM support for K3 J7200

[Thomas Richard]

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