Hi Raghu/Olivier/Andrew,
Please find an attempt to respond to your thoughts below.
Olivier. Can the SPM use an AT* instruction even if not trusting the SP is not an issue? "AT S1E1R" takes a VA as an input. How will the SPM figure this out? I don't think there is an AT instruction that only does the S2 walk on an IPA. Am I missing something from the Arm ARM?
I agree with Raghu's concern about Andrew's approach to map the memory region in both Secure and NS physical address spaces. I don't think the SPM should willingly map a Secure memory region in the NS PA space. This also sounds like a backdoor from a security perspective.
Raghu. I have considered Option 4 but not sure yet if it is enforceable in the spec. In a content protection use case, the system could lack HW to flip the security state of a memory region at runtime. The SPM could trust the Hypervisor to remove access to a Normal memory region from a VM before it is donated to a SP through FFA_MEM_DONATE. The SP could share this memory region with other SPs. It would still be a Normal memory region.
Hafnium can still keep its implementation simple as you suggest I guess! Otherwise, it will just have to use another impdef. mechanism to track the security state of memory regions.
Agree on programming the VSTCR_EL2 and VTCR_EL2 such that:
- NS IPAs access the NS PA space - Secure IPAs access the Secure PA space - S2 PTWs for the Secure IPA space are to the Secure PA space
Raghu. You mentioned S2 PTWs for the NS IPA space should access the Secure PA space. Is this cause SPM will by default use Secure memory for the S2 tables?
I will double check what we are doing in our internal prototype Hf which uses the VSTCR_EL2.
Please shout if I have missed anything. Wondering if we can have a Hf tech forum for such discussions to avoid long email threads. Maybe reuse the TF-A tech forum for starters?
cheers, Achin
On Tue, Jun 09, 2020 at 07:53:23AM -0700, Raghu K wrote:
Though this might have to be complemented with a security state
field in memory region tracking logic?
This is one way of doing it. I think Achin pointed out in one of his earlier emails that upstream hf does not do this(which is why i suggested option 4).
w.r.t VTCR_EL2, based on the assumption that we have two S2 tables, one for secure IPA and another for NS-IPA address space, i imagine the NSW bit being set to 0(table walks for NS IPA lands in secure PA space) and NSA bit being set to 1 so that the output addresses land in non-secure PA space. VSTCR_EL2.SA/SW should be set to 0. I think.
On 6/9/20 6:19 AM, Olivier Deprez wrote:
Thinking a bit further, this does not prevents a compromised SP to later change the region security state. So I guess if using AT instruction, this check has to be done at least in any FFA memory sharing operation transiting through the SPM. Though this might have to be complemented with a security state field in memory region tracking logic?
Also related to VTCR_EL2 NSA/NSW this is related to Stage-2 IPA to PA translation. So I suspect this might have to be set always, whichever using one or two sets of page tables because an NS IPA from Stage-1 shall be routed as an NS PA to TZ controller (?)
From: Hafnium hafnium-bounces@lists.trustedfirmware.org on behalf of Olivier Deprez via Hafnium hafnium@lists.trustedfirmware.org Sent: 09 June 2020 14:55 To: Raghu Krishnamurthy; Andrew Walbran; Achin Gupta Cc: hafnium@lists.trustedfirmware.org Subject: Re: [Hafnium] Determine security state of a memory region
Hi,
I think the subtlety resides in PAR_EL1.NS (bit 9). When a secure hypervisor performs AT S1E1R, then the resulting translation output is the SEL1 IPA (including the NS bit state).
I did the following trials with SPM executing AT S1E1R for a known region mapped by an SP: -the SP does not map the region =>PAR_EL1.F=1 -the SP maps the regions secure =>PAR_EL1.NS=0 -the SP maps the region non-secure =>PAR_EL1.NS=1
This permits checking the SP region security state without trusting the SP.
On a related topic I also noticed VTCR_EL2.NSA and VTCR_EL2.NSW (and VSTCR_EL2.SA/SW=0). With default values of 0, this means Stage-1 translations always result to Secure IPA space (also in the case S-EL1 MMU is disabled). Hence I think PTWs always go through VSTTBR.
I guess the two VTCR_EL2 bits shall be set if we adopt a model where: -any NS shared mapping resolves to VTTBR -remaining SP mappings resolve to VSTTBR
Regards, Olivier.
From: Hafnium hafnium-bounces@lists.trustedfirmware.org on behalf of Raghu Krishnamurthy via Hafnium hafnium@lists.trustedfirmware.org Sent: 08 June 2020 17:11 To: hafnium@lists.trustedfirmware.org Subject: Re: [Hafnium] Determine security state of a memory region
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.
- 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?
- 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.
- 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-- Hafnium mailing list Hafnium@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/hafnium -- Hafnium mailing list Hafnium@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/hafnium