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...
Hi Varun,
On Fri, May 14, 2021 at 2:16 PM Varun Wadekar vwadekar@nvidia.com wrote:
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.
I think we shouldn't trust NS world to be making this SMC when transferring a buffer to S world because S world is more privileged. That is the reason why I think MEM_PROTECT in its current form only works for partitions within NS world.
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.
Yes this is confusing. In practice the memory that needs to be zeroed out is quite large. If we take example of pKVM, the memory allocated to secondary VMs originally comes from primary OS (e.g. Android). That memory can be 4K fragmented and spread across DRAM. It won't be practical to track which 4K fragments belonged to which VM, so that we can wipe that memory on boot. Therefore in this example, all memory belonging to primary OS will need to be cleared on an "unclean" boot.
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.
I think the spec expects memory to be cleaned after system reset, on a boot and not before. In any case, from pKVM example above and also from DMA-BUF heap I mentioned in the other email, it is unlikely that the memory range will be limited.
-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...
Hi,
I think we shouldn't trust NS world to be making this SMC when transferring a buffer to S world because S world is more privileged.
I agree. But the intention of the current implementation is to ask S world to clear NS world memory. IIUC, the NS world trusts the S world to save itself from other NS world components.
In practice the memory that needs to be zeroed out is quite large
I agree. But the spec does not influence the implementation in any way. E.g. you can use DMAs available to clear memory.
It won't be practical to track which 4K fragments belonged to which VM, so that we can wipe that memory on boot.
Do you think we should extend the spec to allow registering multiple DRAM ranges?
I think the spec expects memory to be cleaned after system reset, on a boot and not before.
Isnt that a security hole? An attacker can intercept boot even before TF-A gets a chance to run and extract DRAM contents with this approach. So, I believe it makes sense to clear memory *before* issuing a system reset.
-----Original Message----- From: Okash Khawaja okash.khawaja@gmail.com Sent: Friday, May 14, 2021 3:02 PM To: Varun Wadekar vwadekar@nvidia.com Cc: tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] MEM_PROTECT for secure world?
External email: Use caution opening links or attachments
Hi Varun,
On Fri, May 14, 2021 at 2:16 PM Varun Wadekar vwadekar@nvidia.com wrote:
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.
I think we shouldn't trust NS world to be making this SMC when transferring a buffer to S world because S world is more privileged. That is the reason why I think MEM_PROTECT in its current form only works for partitions within NS world.
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.
Yes this is confusing. In practice the memory that needs to be zeroed out is quite large. If we take example of pKVM, the memory allocated to secondary VMs originally comes from primary OS (e.g. Android). That memory can be 4K fragmented and spread across DRAM. It won't be practical to track which 4K fragments belonged to which VM, so that we can wipe that memory on boot. Therefore in this example, all memory belonging to primary OS will need to be cleared on an "unclean" boot.
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.
I think the spec expects memory to be cleaned after system reset, on a boot and not before. In any case, from pKVM example above and also from DMA-BUF heap I mentioned in the other email, it is unlikely that the memory range will be limited.
-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%2Flist s.trustedfirmware.org%2Fmailman%2Flistinfo%2Ftf-a&data=04%7C01%7Cv wadekar%40nvidia.com%7C4d55667fd28149a403a508d916e0d2e0%7C43083d157273 40c1b7db39efd9ccc17a%7C0%7C0%7C637565977129031486%7CUnknown%7CTWFpbGZs b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D %7C1000&sdata=28vh1br892VNqb4zw%2FXVKMvuDJ5t3UBDTp2L2dLTGu4%3D& ;reserved=0
Hi Varun,
On Fri, May 14, 2021 at 3:23 PM Varun Wadekar vwadekar@nvidia.com wrote:
Hi,
I think we shouldn't trust NS world to be making this SMC when transferring a buffer to S world because S world is more privileged.
I agree. But the intention of the current implementation is to ask S world to clear NS world memory. IIUC, the NS world trusts the S world to save itself from other NS world components.
My reading of MEM_PROTECT is slightly different. This is an example of cold reboot attack I am thinking of. During DRM, NS world HLOS passes some buffers to TZ. While TZ is using those buffers, NS world can't read them. But before TZ had a chance to clear those buffers, the system resets. On the boot after that reset, that memory is marked as non-secure and therefore accessible from HLOS. This is the attack I think MEM_PROTECT should protect against. Is your understanding different?
In practice the memory that needs to be zeroed out is quite large
I agree. But the spec does not influence the implementation in any way. E.g. you can use DMAs available to clear memory.
It won't be practical to track which 4K fragments belonged to which VM, so that we can wipe that memory on boot.
Do you think we should extend the spec to allow registering multiple DRAM ranges?
Mmm... I'm not sure if that will help because there will be so many such ranges. It might be simpler and faster to clear all of non-secure memory when the MEM_PROTECT flag is set, instead of iterating through these ranges. We can ask others for opinion too.
I think the spec expects memory to be cleaned after system reset, on a boot and not before.
Isnt that a security hole? An attacker can intercept boot even before TF-A gets a chance to run and extract DRAM contents with this approach. So, I believe it makes sense to clear memory *before* issuing a system reset.
Doing it before system reset might be better. I was talking about what the spec seems to say: "When this function is called, the implementation overwrites all the volatile memory, that is accessible by the caller, when booting the system following a system reset." Also, in some cases it might not be possible to always have a chance to do the cleanup before shutdown. E.g. if someone disconnects power and quickly reconnects power.
-----Original Message----- From: Okash Khawaja okash.khawaja@gmail.com Sent: Friday, May 14, 2021 3:02 PM To: Varun Wadekar vwadekar@nvidia.com Cc: tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] MEM_PROTECT for secure world?
External email: Use caution opening links or attachments
Hi Varun,
On Fri, May 14, 2021 at 2:16 PM Varun Wadekar vwadekar@nvidia.com wrote:
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.
I think we shouldn't trust NS world to be making this SMC when transferring a buffer to S world because S world is more privileged. That is the reason why I think MEM_PROTECT in its current form only works for partitions within NS world.
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.
Yes this is confusing. In practice the memory that needs to be zeroed out is quite large. If we take example of pKVM, the memory allocated to secondary VMs originally comes from primary OS (e.g. Android). That memory can be 4K fragmented and spread across DRAM. It won't be practical to track which 4K fragments belonged to which VM, so that we can wipe that memory on boot. Therefore in this example, all memory belonging to primary OS will need to be cleared on an "unclean" boot.
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.
I think the spec expects memory to be cleaned after system reset, on a boot and not before. In any case, from pKVM example above and also from DMA-BUF heap I mentioned in the other email, it is unlikely that the memory range will be limited.
-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%2Flist s.trustedfirmware.org%2Fmailman%2Flistinfo%2Ftf-a&data=04%7C01%7Cv wadekar%40nvidia.com%7C4d55667fd28149a403a508d916e0d2e0%7C43083d157273 40c1b7db39efd9ccc17a%7C0%7C0%7C637565977129031486%7CUnknown%7CTWFpbGZs b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D %7C1000&sdata=28vh1br892VNqb4zw%2FXVKMvuDJ5t3UBDTp2L2dLTGu4%3D& ;reserved=0
tf-a@lists.trustedfirmware.org
-
Okash Khawaja -
Varun Wadekar