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