Never mind question 2 below. Educated myself that there is no NS bit in the stage 2 tables which i had assumed. I think Andrew's suggestion should work too, however it does have the issue that the SP may see incoherent data if there is an NS attribute mismatch. With option 4 i suggested, you would get a fault when incorrect attributes are used. No strong preference though.

-Raghu

On 6/8/20 7:10 AM, Raghu Krishnamurthy via Hafnium wrote:

Hi Achin,

Thanks for the explanation. Agree that this is a problem.

1. Pasting Andrew's question for continuity: Is it possible that the

SPMC could map it in both the secure and  non-secure stage 2 page tables, so the SP can decide which security state to map it in at stage 1? Or am I misunderstanding how this works?

2. Perhaps i'm missing something, but I'm surprised by the assumption

that a given SP(which runs only in secure world) will have multiple S2 tables. How would the SPMC decide whether to point VSTTBR_EL2 to the secure or non-secure S2 tables when entering an SP? Unless the way this works architecturally is that the stage 1 walk's NS attribute is used to select VSTTBR_EL2 or VTTBR_EL2. That seems backward.

3. Have you considered option 4, where an FFA_MEM_SHARE between 2 SP's

shall always share only pages mapped as secure and between SP and a VM share only pages mapped as non-secure? Or is this not an option? This will make the SPMC design simpler and puts the onus on lower privileged SP's to know if they are communicating with secure world or NS world components. This obviously incurs overhead from the SP's point of view but if the more important goal is to keep S-EL2 simpler, this might be a good option.

Thanks Raghu

On 6/8/20 2:37 AM, Andrew Walbran wrote:

...

On Sun, 7 Jun 2020 at 16:46, Achin Gupta via Hafnium <hafnium@lists.trustedfirmware.org mailto:hafnium@lists.trustedfirmware.org> wrote:

Hi Raghu,

Howdy! CIL…

> On 4 Jun 2020, at 16:21, Raghu K via Hafnium     <hafnium@lists.trustedfirmware.org     mailto:hafnium@lists.trustedfirmware.org> wrote:      >      > Hi Achin,      >      > Would you mind elaborating more on why the SPM needs to determine     the security state and why it is important to do this without     trusting the SP? When you say SPM, it sounds like you are talking     about the SPMD running in EL3 for ex., that is not a part of the     SPMC which perhaps runs as S-EL2 and the SPMD may need to know this     to figure out how to map a particular physical page. Is that the use     case you are thinking about?

So this is in the context of PSA FF-A Memory management ABIs. Also,     I have the S-EL2 SPMC case in mind. SPMD in EL3 does not participate     in memory management in this case when it comes to managing any     architectural state i.e. translation tables, control regs etc

Say, a SP0 invokes FFA_MEM_SHARE to share a single page A with SP1.     The SPMC would need to map page A in SP’s stage 2 tables. To do     this, it would need to determine whether the IPA of page A belongs     to the Secure or Non-secure IPA space. This is under the assumption     that some memory ranges in SP0’s IPA space will be Non-secure.

IMO, this information can be determined in one of the following ways:

1. Perform PTW in SW to determine whether IPA is mapped in the     tables referenced by VSTTBR_EL2 or VTTBR_EL2. I am assuming the SPMC     maintains separate S2 translations for the Secure and NS address     spaces.

2. Through an internal data structure which tracks the attributes of     a memory region assigned to a guest.

3. SP0 specifies the security state of page A in FFA_MEM_SHARE. The     spec does not cover this currently. However, the SPMC cannot trust     that the SP0 is providing the right security state and must verify     this independently anyways.

1 seems clunky. 2 is not done in upstream Hf. 3 does not really help.

I think I had misunderstood that a AT* instruction could be used.     There do not seem to be any in the Arm ARM that only perform a IPA     to PA i.e. a S2 translation.

So I am wondering what can be done to solve this problem assuming we     agree that this is a problem in the first place.

Is it possible that the SPMC could map it in both the secure and non-secure stage 2 page tables, so the SP can decide which security state to map it in at stage 1? Or am I misunderstanding how this works?

Hth,

Cheers,     Achin

>      > Thanks      > Raghu      >      > On 6/4/20 3:07 AM, Achin Gupta via Hafnium wrote:      >> Hi All,      >>      >> I am thinking of a scenario where a SP shares Non-secure memory     with one or more SPs or VMs. The NS memory region could have been     donated to the SP by a VM earlier (far fetched but possible).      >>      >> The question is how does the SPM determine the security state of     the memory region being shared by the SP.      >>      >> It is especially important that the SPM does this without     trusting the SP.      >>      >> I don't think it should rely on the AT* instructions. The SP     could change the security state of the region in S1. AFAIK, there     are no AT* instructions that only do S2 walks with a IPA as an input.      >>      >> So is the only option to perform a walk in both the Secure and     Non-secure S2 tables to determine where is the address mapped.      >>      >> This seems a bit clunky. So wondering if I am missing anything     and there is an easier way to do this.      >>      >> What do you reckon?      >>      >> cheers,      >> Achin      >      > --      > Hafnium mailing list      > Hafnium@lists.trustedfirmware.org     mailto:Hafnium@lists.trustedfirmware.org      > https://lists.trustedfirmware.org/mailman/listinfo/hafnium

--     Hafnium mailing list     Hafnium@lists.trustedfirmware.org     mailto:Hafnium@lists.trustedfirmware.org     https://lists.trustedfirmware.org/mailman/listinfo/hafnium