Hello,
I think this is a good idea to keep multiple moving parts in sync. OTOH, does this also mean that all changes *must* be part of a topic branch? That would be an overkill IMO.
-Varun
-----Original Message-----
From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> On Behalf Of Olivier Deprez via Hafnium
Sent: Thursday, July 9, 2020 6:16 AM
To: Benjamin Copeland <ben.copeland(a)linaro.org>; Joanna Farley <Joanna.Farley(a)arm.com>; bill.fletcher(a)linaro.org
Cc: hafnium(a)lists.trustedfirmware.org
Subject: Re: [Hafnium] change.submitWholeTopic option for Gerrit
External email: Use caution opening links or attachments
Ben,
Kindly please hold on, I guess I should forward this comm. to other MLs for which the corresponding tforg projects will inherit the newly enabled feature.
Thanks & Regards,
Olivier.
________________________________________
From: Benjamin Copeland <ben.copeland(a)linaro.org>
Sent: 09 July 2020 15:12
To: Joanna Farley; bill.fletcher(a)linaro.org
Cc: Olivier Deprez; Andrew Walbran; hafnium(a)lists.trustedfirmware.org
Subject: Re: [Hafnium] change.submitWholeTopic option for Gerrit
If we are all in agreement I will get it enabled.
Regards
Ben
On Thu, 9 Jul 2020 at 13:51, Joanna Farley <Joanna.Farley(a)arm.com<mailto:Joanna.Farley@arm.com>> wrote:
Agree __
On 09/07/2020, 13:48, "Hafnium on behalf of Olivier Deprez via Hafnium" <hafnium-bounces(a)lists.trustedfirmware.org<mailto:hafnium-bounces@lists.trustedfirmware.org> on behalf of hafnium(a)lists.trustedfirmware.org<mailto:hafnium@lists.trustedfirmware.org>> wrote:
Hi Andrew,
We seem to reach a consensus within ARM that it is something we can enable.
As a slight usage detail, we'd expect developers to use their initials for gerrit topics such a xy/topic-name.
That's already recommended for TF-A, although not always enforced.
This would avoid unintended/accidental merges in different repos because of gerrit topic name clashes.
Does it make sense?
Other folks in the ML, please shout if you disagree (you can also express that you agree 🙂).
Regards,
Olivier.
________________________________
From: Andrew Walbran
Sent: Wednesday, July 01, 2020 11:28
To: hafnium(a)lists.trustedfirmware.org<mailto:hafnium@lists.trustedfirmware.org>; Benjamin Copeland; Olivier Deprez
Subject: Re: change.submitWholeTopic option for Gerrit
Any thoughts on this?
On Fri, 26 Jun 2020 at 21:21, Andrew Walbran <qwandor(a)google.com<mailto:qwandor@google.com><mailto:qwandor@google.com<mailto:qwandor@google.com>>> wrote:
Hello,
How would people feel about enabling the change.submitWholeTopic option (https://gerrit-review.googlesource.com/Documentation/config-gerrit.html#cha…) for Gerrit?
So far, we have relied on this to ensure that submodule changes get submitted along with the corresponding change to the main repository. Our usual workflow has been that whenever a change is made to one of the submodule repositories, both that change and the corresponding change to the main repository are tagged with the same topic. That way it is only possible to submit either once they have all been reviewed +2 and the main change has passed presubmit. This avoids submodules getting out of sync or changes to them being missed or not properly tested.
However, it looks like this is a per-host configuration option rather than per-repository, so it would also affect the other Trusted Firmware projects using the same Gerrit host. Are there any other uses of topics there which would conflict with this config change?
(If there are other people who might have an opinion on this please add them to the thread.)
--
Hafnium mailing list
Hafnium(a)lists.trustedfirmware.org<mailto:Hafnium@lists.trustedfirmware.org>
https://lists.trustedfirmware.org/mailman/listinfo/hafnium
--
Hafnium mailing list
Hafnium(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/hafnium
Agree __
On 09/07/2020, 13:48, "Hafnium on behalf of Olivier Deprez via Hafnium" <hafnium-bounces(a)lists.trustedfirmware.org on behalf of hafnium(a)lists.trustedfirmware.org> wrote:
Hi Andrew,
We seem to reach a consensus within ARM that it is something we can enable.
As a slight usage detail, we'd expect developers to use their initials for gerrit topics such a xy/topic-name.
That's already recommended for TF-A, although not always enforced.
This would avoid unintended/accidental merges in different repos because of gerrit topic name clashes.
Does it make sense?
Other folks in the ML, please shout if you disagree (you can also express that you agree 🙂).
Regards,
Olivier.
________________________________
From: Andrew Walbran
Sent: Wednesday, July 01, 2020 11:28
To: hafnium(a)lists.trustedfirmware.org; Benjamin Copeland; Olivier Deprez
Subject: Re: change.submitWholeTopic option for Gerrit
Any thoughts on this?
On Fri, 26 Jun 2020 at 21:21, Andrew Walbran <qwandor(a)google.com<mailto:qwandor@google.com>> wrote:
Hello,
How would people feel about enabling the change.submitWholeTopic option (https://gerrit-review.googlesource.com/Documentation/config-gerrit.html#cha…) for Gerrit?
So far, we have relied on this to ensure that submodule changes get submitted along with the corresponding change to the main repository. Our usual workflow has been that whenever a change is made to one of the submodule repositories, both that change and the corresponding change to the main repository are tagged with the same topic. That way it is only possible to submit either once they have all been reviewed +2 and the main change has passed presubmit. This avoids submodules getting out of sync or changes to them being missed or not properly tested.
However, it looks like this is a per-host configuration option rather than per-repository, so it would also affect the other Trusted Firmware projects using the same Gerrit host. Are there any other uses of topics there which would conflict with this config change?
(If there are other people who might have an opinion on this please add them to the thread.)
--
Hafnium mailing list
Hafnium(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/hafnium
Hi Andrew,
We seem to reach a consensus within ARM that it is something we can enable.
As a slight usage detail, we'd expect developers to use their initials for gerrit topics such a xy/topic-name.
That's already recommended for TF-A, although not always enforced.
This would avoid unintended/accidental merges in different repos because of gerrit topic name clashes.
Does it make sense?
Other folks in the ML, please shout if you disagree (you can also express that you agree 🙂).
Regards,
Olivier.
________________________________
From: Andrew Walbran
Sent: Wednesday, July 01, 2020 11:28
To: hafnium(a)lists.trustedfirmware.org; Benjamin Copeland; Olivier Deprez
Subject: Re: change.submitWholeTopic option for Gerrit
Any thoughts on this?
On Fri, 26 Jun 2020 at 21:21, Andrew Walbran <qwandor(a)google.com<mailto:qwandor@google.com>> wrote:
Hello,
How would people feel about enabling the change.submitWholeTopic option (https://gerrit-review.googlesource.com/Documentation/config-gerrit.html#cha…) for Gerrit?
So far, we have relied on this to ensure that submodule changes get submitted along with the corresponding change to the main repository. Our usual workflow has been that whenever a change is made to one of the submodule repositories, both that change and the corresponding change to the main repository are tagged with the same topic. That way it is only possible to submit either once they have all been reviewed +2 and the main change has passed presubmit. This avoids submodules getting out of sync or changes to them being missed or not properly tested.
However, it looks like this is a per-host configuration option rather than per-repository, so it would also affect the other Trusted Firmware projects using the same Gerrit host. Are there any other uses of topics there which would conflict with this config change?
(If there are other people who might have an opinion on this please add them to the thread.)
Hi,
The issue happens because driver/linux/Makefile defines CHECKPATCH with a default script path only if CHECKPATCH is not already set (uses ?= operator)
It works by unsetting the existing environment CHECKPATCH from kokoro/build.sh when invoking the linux driver checkpatch as done here:
https://review.trustedfirmware.org/c/hafnium/hafnium/+/4879
I think that's fine with build dependencies, nothing to change here.
Regards,
Olivier.
________________________________
From: Andrew Walbran
Sent: Monday, May 18, 2020 17:21
To: Olivier Deprez
Cc: hafnium(a)lists.trustedfirmware.org
Subject: Re: [Hafnium] kokoro/build and CHECKPATCH
If there are dependencies missing from https://hafnium.googlesource.com/hafnium/+/refs/heads/master/docs/GettingSt… then please send me a change to add them. I'm curious about pathlib, as it's not listed in https://hafnium.googlesource.com/hafnium/+/refs/heads/master/build/docker/D… either.
We should probably fix the build to ignore any locally set value of CHECKPATCH, as it should always be using the version checked into the repository.
On Mon, 18 May 2020 at 16:01, Olivier Deprez <Olivier.Deprez(a)arm.com<mailto:Olivier.Deprez@arm.com>> wrote:
Hi Andrew,
Notice I do git clean -fdx prior to trying CHECKPATCH set/not set, because it looks there's some dependency to local ninja build files.
When CHECKPATCH is set I'm still seeing the issue mentioned earlier.
When CHECKPATCH is not set, I got failures related to missing python dependencies on my ubuntu host (ply pathlib python-git). I don't recall seeing those dependencies listed in Hafnium pages, but that's fair enough. Now the checkpatch step passes by installing those python libs.
Obviously I'm not facing this issue when running through docker hermetic build.
So I guess it's low priority glitch, not sure if it really requires a fix or a notice in documentation?
Regards,
Olivier.
________________________________________
From: Andrew Walbran
Sent: Monday, May 18, 2020 13:32
To: Olivier Deprez
Cc: hafnium(a)lists.trustedfirmware.org<mailto:hafnium@lists.trustedfirmware.org>
Subject: Re: [Hafnium] kokoro/build and CHECKPATCH
That's weird, I haven't seen that before. Running either kokoro/build.sh or 'make checkpatch' locally works for me, whether or not CHECKPATCH is set.
The Makefile in the root directory is setting CHECKPATCH unconditionally, but it looks like the one under drive/linux uses the existing value if there is one. Maybe we should change that?
What error do you get when CHECKPATCH is not set?
On Fri, 15 May 2020 at 18:18, Olivier Deprez via Hafnium <hafnium(a)lists.trustedfirmware.org<mailto:hafnium@lists.trustedfirmware.org>> wrote:
Hi,
Is there a known problem around checkpatch when running kokoro/build.sh locally?
I noticed if CHECKPATCH env variable is already set then kokoro/build.sh fails with:
+ export CROSS_COMPILE=aarch64-linux-gnu-
+ CROSS_COMPILE=aarch64-linux-gnu-
+ cd driver/linux
+ make HAFNIUM_PATH=/home/olidep01/WORK/hafnium-upstream checkpatch
<my-own-checkpatch-dir>/checkpatch.pl<http://checkpatch.pl> -f main.c
Must be run from the top-level dir. of a kernel tree
Makefile:43: recipe for target 'checkpatch' failed
make: *** [checkpatch] Error 2
If I unset CHECKPATCH before running build.sh then it fails at the driver/linux check.
Is this something known and/or needing fix?
Regards,
Olivier.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose,
or store or copy the information in any medium. Thank you.
--
Hafnium mailing list
Hafnium(a)lists.trustedfirmware.org<mailto:Hafnium@lists.trustedfirmware.org>
https://lists.trustedfirmware.org/mailman/listinfo/hafnium
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hello,
How would people feel about enabling the change.submitWholeTopic option (
https://gerrit-review.googlesource.com/Documentation/config-gerrit.html#cha…)
for Gerrit?
So far, we have relied on this to ensure that submodule changes get
submitted along with the corresponding change to the main repository. Our
usual workflow has been that whenever a change is made to one of the
submodule repositories, both that change and the corresponding change to
the main repository are tagged with the same topic. That way it is only
possible to submit either once they have all been reviewed +2 and the main
change has passed presubmit. This avoids submodules getting out of sync or
changes to them being missed or not properly tested.
However, it looks like this is a per-host configuration option rather than
per-repository, so it would also affect the other Trusted Firmware projects
using the same Gerrit host. Are there any other uses of topics there
which would conflict with this config change?
(If there are other people who might have an opinion on this please add
them to the thread.)
Hi all
The new TrustedFirmware.org security incident process is now live. This process is described here:
https://developer.trustedfirmware.org/w/collaboration/security_center/repor…
Initially the process will be used for the following projects: TF-A, TF-M, OP-TEE and Mbed TLS. The security documentation for each project will be updated soon to reflect this change.
If you are part of an organization that believes it should receive security vulnerability information before it is made public then please ask your relevant colleagues to register as Trusted Stakeholders as described here:
https://developer.trustedfirmware.org/w/collaboration/security_center/trust…
Note we prefer individuals in each organization to coordinate their registration requests with each other and to provide us with an email alias managed by your organization instead of us managing a long list of individual addresses.
Best regards
Dan.
(on behalf of the TrustedFirmware.org security team)
Hi Raghu,
Here are a few more technical details.
An SPM design doc is in progress here:
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4637
The following WIP patches enable an early testing (spm-wip topic branch):
https://review.trustedfirmware.org/q/topic:%22spm-wip%22+(status:open%20OR%…
As Matteo said, those patches are not yet marked under review waiting for re-licensing to complete.
See the build script below if you wish to reproduce.
Currently only FVP is supported by enabling Armv8.4-SecEL2 model toggle.
This is running the TF-A-tests framework, although a reasonable target is to also have secure world test cases within Hafnium CI/test scripts.
Test payloads at S-EL1 are TF-A-tests Cactus bare metal partitions (https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/spm/cactus/cactus_…)
The test scenario is:
TF-A boots and BL2 loads: Hafnium as BL32 in secure world, an SPMC manifest, two Cactus Secure Partition payloads.
Hafnium is booted at S-EL2 in the secure world and returns to EL3.
Normal world hands over to TFTF at NS-EL2.
TFTF boots and initiates basic PSA FF-A direct messaging communication with one and the other Cactus SP.
I can share more from the test logs if necessary.
There is more to come related to booting a real TEE in place of Cactus.
Regards,
Olivier.
#== Sample build script ==========================================
<put bash shebang here>
mkdir SPM; cd SPM
# Build Hafnium
git clone https://review.trustedfirmware.org/hafnium/hafnium && cd hafnium
git submodule update --init
git fetch "https://review.trustedfirmware.org/hafnium/hafnium" refs/changes/20/4720/1 && git checkout FETCH_HEAD
git checkout -b spm
cd project/reference
git checkout -b spm
git fetch "https://review.trustedfirmware.org/hafnium/project/reference" refs/changes/21/4721/1 && git cherry-pick FETCH_HEAD
cd ../..
make PROJECT=reference
cd ..
# Build TF-A-tests
git clone https://review.trustedfirmware.org/TF-A/tf-a-tests && cd tf-a-tests
make CROSS_COMPILE=aarch64-none-elf- PLAT=fvp DEBUG=1 TESTS=spm
cd ..
# Build TF-A
git clone https://review.trustedfirmware.org/TF-A/trusted-firmware-a && cd trusted-firmware-a
make \
CROSS_COMPILE=aarch64-none-elf- \
SPD=spmd \
CTX_INCLUDE_EL2_REGS=1 \
ARM_ARCH_MINOR=4 \
PLAT=fvp \
DEBUG=1 \
BL33=../tf-a-tests/build/fvp/debug/tftf.bin \
BL32=../hafnium/out/reference/secure_aem_v8a_fvp_clang/hafnium.bin \
SP_LAYOUT_FILE=../tf-a-tests/build/fvp/debug/sp_layout.json \
all fip
#=====================================================
________________________________________
From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of Matteo Carlini via Hafnium <hafnium(a)lists.trustedfirmware.org>
Sent: 19 June 2020 10:47
To: raghu.ncstate(a)icloud.com
Cc: hafnium(a)lists.trustedfirmware.org
Subject: Re: [Hafnium] Running hafnium in Secure-world
Hi Raghu,
Hafnium is going to be precisely the reference Secure EL2 SPM, collaboratively developed and hosted here by Trusted Firmware.org.
The project is finalising its migration as we speak (look at the relicensing commit here https://review.trustedfirmware.org/c/hafnium/hafnium/+/4616) and we'll soon create a blogpost to celebrate the final migration and its new life under Trusted Firmware.
The development teams are already working internally to achieve the above S-EL2 goal and they'll be posting the initial enablement patches and proto-branches as soon as the relicensing is complete, so to continue the development completely in the open and welcome partners' comments and help. They can certainly chime in here and provide their current status from a technical perspective.
The Normal world instance of Hafnium remains for now just as test payload for the PSA FF-A (SPCI) interface to help developing the Secure-EL2 SPM side of it, nothing more than that.
You can always refer to my Linaro presentation back in March that described the overall goal and direction for this enablement: https://connect.linaro.org/resources/ltd20/ltd20-200k/
Please note there will also be a TF-A Tech Forum session entirely focused on the Secure EL2 / Hafnium development topic quite soon (2nd July tentative), watch this space:
https://www.trustedfirmware.org/meetings/tf-a-technical-forum/
So I'd strongly encourage to participate to it, to discuss live all the latest news.
Thanks
Matteo
> From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of
> Raghu K via Hafnium <hafnium(a)lists.trustedfirmware.org>
> Sent: 18 June 2020 22:59
> To: hafnium(a)lists.trustedfirmware.org
> Subject: [Hafnium] Running hafnium in Secure-world
>
> All,
>
> Is it possible to run hafnium in SEL2? From looking at the code, it seems like
> hafnium currently only supports running in NS world. Is my understanding
> correct? I was wondering if/when there is a plan for secure world support in
> hafnium and if anybody is working on it.
>
> Thanks
> Raghu
--
Hafnium mailing list
Hafnium(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/hafnium
Hi Raghu,
Hafnium is going to be precisely the reference Secure EL2 SPM, collaboratively developed and hosted here by Trusted Firmware.org.
The project is finalising its migration as we speak (look at the relicensing commit here https://review.trustedfirmware.org/c/hafnium/hafnium/+/4616) and we'll soon create a blogpost to celebrate the final migration and its new life under Trusted Firmware.
The development teams are already working internally to achieve the above S-EL2 goal and they'll be posting the initial enablement patches and proto-branches as soon as the relicensing is complete, so to continue the development completely in the open and welcome partners' comments and help. They can certainly chime in here and provide their current status from a technical perspective.
The Normal world instance of Hafnium remains for now just as test payload for the PSA FF-A (SPCI) interface to help developing the Secure-EL2 SPM side of it, nothing more than that.
You can always refer to my Linaro presentation back in March that described the overall goal and direction for this enablement: https://connect.linaro.org/resources/ltd20/ltd20-200k/
Please note there will also be a TF-A Tech Forum session entirely focused on the Secure EL2 / Hafnium development topic quite soon (2nd July tentative), watch this space:
https://www.trustedfirmware.org/meetings/tf-a-technical-forum/
So I'd strongly encourage to participate to it, to discuss live all the latest news.
Thanks
Matteo
> From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of
> Raghu K via Hafnium <hafnium(a)lists.trustedfirmware.org>
> Sent: 18 June 2020 22:59
> To: hafnium(a)lists.trustedfirmware.org
> Subject: [Hafnium] Running hafnium in Secure-world
>
> All,
>
> Is it possible to run hafnium in SEL2? From looking at the code, it seems like
> hafnium currently only supports running in NS world. Is my understanding
> correct? I was wondering if/when there is a plan for secure world support in
> hafnium and if anybody is working on it.
>
> Thanks
> Raghu
All,
Is it possible to run hafnium in SEL2? From looking at the code, it
seems like hafnium currently only supports running in NS world. Is my
understanding correct? I was wondering if/when there is a plan for
secure world support in hafnium and if anybody is working on it.
Thanks
Raghu
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(a)lists.trustedfirmware.org> on behalf of Olivier Deprez via Hafnium <hafnium(a)lists.trustedfirmware.org>
Sent: 09 June 2020 14:55
To: Raghu Krishnamurthy; Andrew Walbran; Achin Gupta
Cc: hafnium(a)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(a)lists.trustedfirmware.org> on behalf of Raghu Krishnamurthy via Hafnium <hafnium(a)lists.trustedfirmware.org>
Sent: 08 June 2020 17:11
To: hafnium(a)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.
>
> 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(a)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(a)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(a)lists.trustedfirmware.org
>> <mailto:Hafnium@lists.trustedfirmware.org>
>> > https://lists.trustedfirmware.org/mailman/listinfo/hafnium
>>
>> -- Hafnium mailing list
>> Hafnium(a)lists.trustedfirmware.org
>> <mailto:Hafnium@lists.trustedfirmware.org>
>> https://lists.trustedfirmware.org/mailman/listinfo/hafnium
>>
--
Hafnium mailing list
Hafnium(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/hafnium
--
Hafnium mailing list
Hafnium(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/hafnium
