Then, when it's done, TZ cleans the buffer and returns it back to NWd OS. However, if while TZ was using the buffer and before it could clean it, the system resets, then on reboot, that buffer will go to NWd OS since it belonged to NWd OS in the first place.
Before sharing such memory, can NWd not send MEM_PROTECT to that address so that a reboot clears it? The secret/sensitive data is really a NWd secret that should be locked down to that power cycle. Since the sensitive data is being exposed by TZ to the NWd when the ownership of such memory is given back to NWd, it sems like it should be the responsibility of the NWd to account for such reset attacks. Either that or any such shared memory between OS and Secure world should be secure by default and cleared on reset and ownership explicitly handed by secure world to normal world during each boot to avoid such attacks. This goes back to the rule of thumb I mentioned below.
Would that not work?
Thanks Raghu
-----Original Message----- From: Okash Khawaja okash.khawaja@gmail.com Sent: Thursday, May 6, 2021 9:26 AM To: raghu.ncstate@icloud.com Cc: tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] MEM_PROTECT for secure world?
Hi,
On Thu, May 6, 2021 at 3:43 PM raghu.ncstate@icloud.com wrote:
If I understand the cold boot attack correctly for the normal world, it is that we boot a NWd OS once, make it decrypt all its secrets into DRAM, pull the power and quickly boot to another OS and read contents of DRAM before the data decays, to extract secrets of the old OS using the new OS. While this can apply to secure world, It might be a safe assumption that we cannot boot arbitrary, unsigned TZ code and trusted OS's on an ARM system in the last few years due to use of CoT, Rollback protection etc.
Yes replacing OS is one way. Another possibility is when NWd OS passes a DRAM buffer to a different or more privileged domain, e.g. a secondary VM or TZ. Let's say it's TZ in this example. As part of the transfer the buffer is secured in such a way that NWd OS can't access it. TZ uses that buffer and possibly writes sensitive info into it. Then, when it's done, TZ cleans the buffer and returns it back to NWd OS. However, if while TZ was using the buffer and before it could clean it, the system resets, then on reboot, that buffer will go to NWd OS since it belonged to NWd OS in the first place. At that time NWd OS may read potentially secret info that it shouldn't have access to. If TZ could indicate (like MEM_PROTECT does) that it temporarily has a NWd buffer when it was transferred to it, then upon reboot, the buffer could be cleaned before NWd OS got to run.
As a general rule of thumb, early boot code should probably be scrubbing secure DRAM anyway, I think, to prevent this attack, in which case the way to do the cold boot attack would be through a run time attack on TZ code.
Thanks Raghu
-----Original Message----- From: TF-A tf-a-bounces@lists.trustedfirmware.org On Behalf Of Okash Khawaja via TF-A Sent: Wednesday, May 5, 2021 9:10 AM To: tf-a@lists.trustedfirmware.org Subject: [TF-A] MEM_PROTECT for secure world?
Hi,
As a PSCI call, MEM_PROTECT which is used to protect against cold reboot attack, can't be called from TZ-secure. In a situation where at run time, HLOS in NS-EL1 transfers some buffer that it owns, to a secure partition then secure partition can't call MEM_PROTECT because psci_smc_handler will return SMC_UNK if the caller is secure.
Should MEM_PROTECT be available to TZ-secure as well?
Thanks, Okash -- TF-A mailing list TF-A@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a