Hi Okash,
My understanding is that the NS world must call PSCI_MEM_PROTECT_CHECK_RANGE and PSCI_MEM_PROTECT before passing the buffer to the S world. So, I believe the check in the code is correct.
The spec guarantees that the memory range passed with this SMC will be cleared before executing a system reset.
This statement from the spec is confusing - " When MEM_PROTECT is called, the implementation must ensure that all volatile memory that is accessible by the caller is overwritten on the following boot". How can the implementation know the memory accessible by the caller in the first place? I feel this creates an unwanted dependency - EL3 needs to understand memory requirements for all NS clients.
I would like to believe that the implementation is only aware of a memory range registered by a caller via the MEM_PROTECT SMC call and so clears only this range before a system reset.
-Varun
-----Original Message----- From: TF-A tf-a-bounces@lists.trustedfirmware.org On Behalf Of Okash Khawaja via TF-A Sent: Wednesday, May 5, 2021 5:10 PM To: tf-a@lists.trustedfirmware.org Subject: [TF-A] MEM_PROTECT for secure world?
External email: Use caution opening links or attachments
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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.trus...