>> We can't trust NWd for TZ domain. In this case we assume that NWd OS is malicious.
[RK] Of course 😊
>> The reason this is not practical is because the memory that NWd OS gives to TZ can come from any >>location in DRAM.
[RK] I understand the problem from your description below and understand that need for PSCI_MEM_PROTECT in the secure world. While this does work to fix the problem, I think the model where NWd lending memory to secure world that is owned by NWd by default is somewhat broken, precisely since it introduces such issues. I usually prefer the model where we use secure defaults for memory pages, in this case, any page that can ever be used by secure world is by default owned by secure world and transferred to NWd on every boot, so that it can be cleared. This likely means there is a limited set of pages that can be shared/transferred for example. I do however understand that this model is not practical in all environments and PSCI_MEM_PROTECT in TZ works and is probably required to address the issue you bring forth.
Yes that's the point. E.g. buffers for DMA-BUF can from a DRAM range which is usually too large for it to be practical to zero out on every boot before giving it to kernel. Boot budgets, such as time to load the first non-secure binary such as an OS loader (which is relevant here), are usually very tight and zeroing out DRAM before that will have a significant impact on that budget. On an "unclean" boot which would happen in an out of ordinary scenario (i.e. when MEM_PROTECT indicates so) the extra time during boot can be justified. That is part of the reason MEM_PROTECT exists, i.e. not having to wipe memory on every boot.
As a side note, FF-A memory sharing between normal and secure world(or in fact even between any two security domains such as 2 FFA VM's) needs to be wary of this issue and the spec should probably warn about such problems and use the same solution(PSCI_MEM_PROTECT) to address it.
I think it should be made possible to allow MEM_PROTECT to be called from secure domains also. As it is, MEM_PROTECT only provides protection within non-secure domain, e.g. between two VMs. I think, at this stage, it's fair to say that protecting secure world from non-secure world is far more important than protection within non-secure world. At present critical use cases like DRM, trusted UI, face authentication, fingerprint authentication mostly rely on TZ. MEM_PROTECT offers no protection for TZ.
Â
Thanks
Raghu
Thanks
Raghu
-----Original Message-----
From: Okash Khawaja <okash.khawaja@gmail.com>
Sent: Friday, May 7, 2021 7:23 AM
To: raghu.ncstate@icloud.com
Cc: tf-a@lists.trustedfirmware.org
Subject: Re: [TF-A] MEM_PROTECT for secure world?
On Thu, May 6, 2021 at 5:36 PM <raghu.ncstate@icloud.com> wrote:
>
> >>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?
We can't trust NWd for TZ domain. In this case we assume that NWd OS is malicious.
> 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.
Sorry if I wasn't clear. The secret info is for use by TZ only. When TZ returns the buffer back to NWd, TZ will clear the buffer first.
> 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?
I see what you mean. The reason this is not practical is because the memory that NWd OS gives to TZ can come from any location in DRAM.
E.g. ION or it's successor DMA-BUF + CMA [1] can, in practice, allocate buffers from different locations in DRAM and hand those buffers to TZ for some implementation of DRM such as Widevine L1.
Overhead of keeping track of all such locations in DRAM (since the buffer could come from anywhere) for every boot cycle will be expensive in both time and memory needed to track those buffers. It's the same reason we have PSCI MEM_PROTECT for NWd which allows us to detect at boot that we need to clean some DRAM buffers, and thus not have to bear the cost of this overhead on every boot. PSCI MEM_PROTECT only works for buffers within NWd domain but not for TZ which is of higher privilege :)
>
> Thanks
> Raghu
>
Thanks,
Okash
[1] https://lwn.net/Articles/792733/
> -----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
> >
>