- Hafnium - lists.trustedfirmware.org

Re: [Hafnium] Debugging page table creation in Hafnium

by Andrew Walbran

Yep, mm_vm_dump sounds like what you're looking for. You can add a call where you like and it will go to the log UART. On Thu, 16 Jul 2020 at 19:14, Raghu K via Hafnium < hafnium(a)lists.trustedfirmware.org> wrote: > Quick search indicates mm_vm_dump() and the functions it calls in > src/mm.c should do what you want. i've not tried it or don't know the > format, but this may be what you are looking for. > > -Raghu > > On 7/16/20 11:03 AM, Madhukar Pappireddy via Hafnium wrote: > > Hi, > > > > I was wondering if there is support in Hafnium to dump page tables to a > log file. I am new to the Hafnium project and would appreciate any help. > Below is an example from TF-A which provides such provision. > > > > ......<snip> > > VERBOSE: Translation tables state: > > VERBOSE: Xlat regime: EL3 > > VERBOSE: Max allowed PA: 0xfffffffff > > VERBOSE: Max allowed VA: 0xfffffffff > > VERBOSE: Max mapped PA: 0x2f1fffff > > VERBOSE: Max mapped VA: 0x2f1fffff > > VERBOSE: Initial lookup level: 1 > > VERBOSE: Entries @initial lookup level: 64 > > VERBOSE: Used 3 sub-tables out of 5 (spare: 2) > > [LV1] VA:0x0 size:0x40000000 > > [LV2] VA:0x0 size:0x200000 > > [LV3] VA:0x0 PA:0x0 size:0x1000 MEM-RO-EXEC-S > > [LV3] VA:0x1000 PA:0x1000 size:0x1000 MEM-RO-EXEC-S > > [LV3] VA:0x2000 PA:0x2000 size:0x1000 MEM-RO-EXEC-S > > [LV3] VA:0x3000 PA:0x3000 size:0x1000 MEM-RO-EXEC-S > > [LV3] VA:0x4000 PA:0x4000 size:0x1000 MEM-RO-EXEC-S > > [LV3] VA:0x5000 PA:0x5000 size:0x1000 MEM-RO-EXEC-S > > [LV3] VA:0x6000 PA:0x6000 size:0x1000 MEM-RO-EXEC-S > > [LV3] VA:0x7000 PA:0x7000 size:0x1000 MEM-RO-EXEC-S > > [LV3] VA:0x8000 PA:0x8000 size:0x1000 MEM-RO-XN-S > > [LV3] VA:0x9000 PA:0x9000 size:0x1000 MEM-RO-XN-S > > [LV3] VA:0xa000 PA:0xa000 size:0x1000 MEM-RO-XN-S > > [LV3] VA:0xb000 size:0x1000 > > [LV3] (500 invalid descriptors omitted) > > [LV2] VA:0x200000 size:0x200000 > > [LV2] (30 invalid descriptors omitted) > > [LV2] VA:0x4000000 size:0x200000 > > ..... <snip> > > > > Thanks, > > Madhukar > > > > -- > Hafnium mailing list > Hafnium(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/hafnium >

6 years, 1 month

1
0
0 0

Re: [Hafnium] Debugging page table creation in Hafnium

by Raghu K

Quick search indicates mm_vm_dump() and the functions it calls in src/mm.c should do what you want. i've not tried it or don't know the format, but this may be what you are looking for. -Raghu On 7/16/20 11:03 AM, Madhukar Pappireddy via Hafnium wrote: > Hi, > > I was wondering if there is support in Hafnium to dump page tables to a log file. I am new to the Hafnium project and would appreciate any help. Below is an example from TF-A which provides such provision. > > ......<snip> > VERBOSE: Translation tables state: > VERBOSE: Xlat regime: EL3 > VERBOSE: Max allowed PA: 0xfffffffff > VERBOSE: Max allowed VA: 0xfffffffff > VERBOSE: Max mapped PA: 0x2f1fffff > VERBOSE: Max mapped VA: 0x2f1fffff > VERBOSE: Initial lookup level: 1 > VERBOSE: Entries @initial lookup level: 64 > VERBOSE: Used 3 sub-tables out of 5 (spare: 2) > [LV1] VA:0x0 size:0x40000000 > [LV2] VA:0x0 size:0x200000 > [LV3] VA:0x0 PA:0x0 size:0x1000 MEM-RO-EXEC-S > [LV3] VA:0x1000 PA:0x1000 size:0x1000 MEM-RO-EXEC-S > [LV3] VA:0x2000 PA:0x2000 size:0x1000 MEM-RO-EXEC-S > [LV3] VA:0x3000 PA:0x3000 size:0x1000 MEM-RO-EXEC-S > [LV3] VA:0x4000 PA:0x4000 size:0x1000 MEM-RO-EXEC-S > [LV3] VA:0x5000 PA:0x5000 size:0x1000 MEM-RO-EXEC-S > [LV3] VA:0x6000 PA:0x6000 size:0x1000 MEM-RO-EXEC-S > [LV3] VA:0x7000 PA:0x7000 size:0x1000 MEM-RO-EXEC-S > [LV3] VA:0x8000 PA:0x8000 size:0x1000 MEM-RO-XN-S > [LV3] VA:0x9000 PA:0x9000 size:0x1000 MEM-RO-XN-S > [LV3] VA:0xa000 PA:0xa000 size:0x1000 MEM-RO-XN-S > [LV3] VA:0xb000 size:0x1000 > [LV3] (500 invalid descriptors omitted) > [LV2] VA:0x200000 size:0x200000 > [LV2] (30 invalid descriptors omitted) > [LV2] VA:0x4000000 size:0x200000 > ..... <snip> > > Thanks, > Madhukar >

6 years, 1 month

1
0
0 0

Debugging page table creation in Hafnium

by Madhukar Pappireddy

Hi, I was wondering if there is support in Hafnium to dump page tables to a log file. I am new to the Hafnium project and would appreciate any help. Below is an example from TF-A which provides such provision. ......<snip> VERBOSE: Translation tables state: VERBOSE: Xlat regime: EL3 VERBOSE: Max allowed PA: 0xfffffffff VERBOSE: Max allowed VA: 0xfffffffff VERBOSE: Max mapped PA: 0x2f1fffff VERBOSE: Max mapped VA: 0x2f1fffff VERBOSE: Initial lookup level: 1 VERBOSE: Entries @initial lookup level: 64 VERBOSE: Used 3 sub-tables out of 5 (spare: 2) [LV1] VA:0x0 size:0x40000000 [LV2] VA:0x0 size:0x200000 [LV3] VA:0x0 PA:0x0 size:0x1000 MEM-RO-EXEC-S [LV3] VA:0x1000 PA:0x1000 size:0x1000 MEM-RO-EXEC-S [LV3] VA:0x2000 PA:0x2000 size:0x1000 MEM-RO-EXEC-S [LV3] VA:0x3000 PA:0x3000 size:0x1000 MEM-RO-EXEC-S [LV3] VA:0x4000 PA:0x4000 size:0x1000 MEM-RO-EXEC-S [LV3] VA:0x5000 PA:0x5000 size:0x1000 MEM-RO-EXEC-S [LV3] VA:0x6000 PA:0x6000 size:0x1000 MEM-RO-EXEC-S [LV3] VA:0x7000 PA:0x7000 size:0x1000 MEM-RO-EXEC-S [LV3] VA:0x8000 PA:0x8000 size:0x1000 MEM-RO-XN-S [LV3] VA:0x9000 PA:0x9000 size:0x1000 MEM-RO-XN-S [LV3] VA:0xa000 PA:0xa000 size:0x1000 MEM-RO-XN-S [LV3] VA:0xb000 size:0x1000 [LV3] (500 invalid descriptors omitted) [LV2] VA:0x200000 size:0x200000 [LV2] (30 invalid descriptors omitted) [LV2] VA:0x4000000 size:0x200000 ..... <snip> Thanks, Madhukar

6 years, 1 month

1
0
0 0

TF-A Tech Forum Agenda @ Thr 16th July 2020 16:00-1700 BST

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 16th July 2020 16:00 – 17:00 (BST). A reoccurring meeting invite has been sent out to the subscribers of this TF-A mailing list. If you don’t have this please let me know. Agenda: * Secure EL2 SPM (Secure Partition Manager) Hafnium-based * In this TF-A Tech Forum session we present the status and open roadmap for the Secure Partition Manager firmware development. The TF-A SPM is the reference open source implementation for the PSA FF-A (Platform Security Architecture Firmware Framework for A-class) specification in the Secure world. It leverages the Armv8.4-Secure EL2 extension bringing virtualization technology in the Secure world (S-EL2 exception level). The development derives originally from the Google Hafnium project, which has been recently transitioned to https://www.trustedfirmware.org/ under the BSD 3-Clause license. * Optional TF-A Mailing List Topic Discussions If TF-A contributors have anything they wish to present at any future TF-A tech forum please contact me to have that scheduled. Previous sessions, both recording and presentation material can be found on the trustedfirmware.org TF-A Technical meeting webpage: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ A scheduling tracking page is also available to help track sessions suggested and being prepared: https://developer.trustedfirmware.org/w/tf_a/tf-a-tech-forum-scheduling/ Final decisions on what will be presented will be shared a few days before the next meeting and shared on the TF-A mailing list. Thanks Joanna

6 years, 1 month

1
0
0 0

Re: [Hafnium] change.submitWholeTopic option for Gerrit

by Andrew Walbran

No, it's only necessary if you're changing a submodule, or have changes that are in some other way dependent on each other. Most changes don't need a topic. On Thu, 9 Jul 2020 at 17:50, Varun Wadekar via Hafnium < hafnium(a)lists.trustedfirmware.org> wrote: > 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(a)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(a)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(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><mailto:qwandor@google.com<mailto: > qwandor(a)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(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 > -- > Hafnium mailing list > Hafnium(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/hafnium >

6 years, 1 month

1
0
0 0

Re: [Hafnium] change.submitWholeTopic option for Gerrit

by Varun Wadekar

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

6 years, 1 month

1
0
0 0

Re: [Hafnium] change.submitWholeTopic option for Gerrit

by Joanna Farley

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

6 years, 1 month

3
2
0 0

Re: [Hafnium] change.submitWholeTopic option for Gerrit

by Olivier Deprez

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.)

6 years, 1 month

2
2
0 0

Re: [Hafnium] kokoro/build and CHECKPATCH

by Olivier Deprez

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.

6 years, 1 month

1
0
0 0

change.submitWholeTopic option for Gerrit

by Andrew Walbran

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.)

6 years, 1 month

1
1
0 0

New TrustedFirmware.org security incident process is now live

by Dan Handley

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)

6 years, 1 month

1
0
0 0

Re: [Hafnium] Running hafnium in Secure-world

by Olivier Deprez

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

6 years, 1 month

2
1
0 0

Re: [Hafnium] Running hafnium in Secure-world

by Matteo Carlini

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

6 years, 2 months

1
0
0 0

Running hafnium in Secure-world

by Raghu K

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

6 years, 2 months

1
0
0 0

Re: [Hafnium] Determine security state of a memory region

by Olivier Deprez

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

6 years, 2 months

4
6
0 0

Re: [Hafnium] CPTR_EL2 configuration

by Serban Constantinescu

+Andrew Scull <ascull(a)google.com> who kindly answered this offline. On Fri, May 22, 2020 at 9:38 AM Olivier Deprez via Hafnium < hafnium(a)lists.trustedfirmware.org> wrote: > Hi, > > Hafnium sets CPTR_EL2.TTA (bit 28), which traps accesses to trace system > registers to EL2. > > https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/arch/aarch64/s… > > However CPTR_EL2 register has a different bit field definition depending > on HCR_EL2.E2H state. > When HCR_EL2.E2H=0 (Hafnium case) CPTR_EL2.TTA bit position is 20. > > Is this a slight issue needing fix? > It sounds like this was copied badly from the spec and should be fixed. We don't enable VHE and we should do as the spec says. HTH, Serban > > 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 > https://lists.trustedfirmware.org/mailman/listinfo/hafnium >

6 years, 2 months

2
1
0 0

Re: [Hafnium] Determine security state of a memory region

by Olivier Deprez

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

6 years, 2 months

1
0
0 0

Re: [Hafnium] Mismatched memory attributes in Hf?

by Andrew Walbran

I don't understand the cache specification well enough to comment, but perhaps Andrew or Wedson can help or give some background? On Mon, 8 Jun 2020 at 11:11, Achin Gupta via Hafnium < hafnium(a)lists.trustedfirmware.org> wrote: > Hi All, > > In Arm, we are experimenting with running OP-TEE under Hafnium as the SPMC > in S-EL2. We have been debugging this Stage 2 fault that OP-TEE runs into a > during a test to share memory (xtest 1003). It seems this is due to a bug > in Hafnium but want to be sure before posting a fix. Some thoughts below to > this end. Apologies for the verbosity but I hope you will appreciate it is > required. > > The fault occurs when OP-TEE tries to access a memory region that was > shared with it by the OP-TEE driver in Linux i.e. the driver has called > FFA_MEM_SHARE to share the memory, OP-TEE has called FFA_MEM_RETRIEVE_REQ > to map it in its S2 and Hf has called FFA_MEM_RETRIVE_RESP to describe the > IPA range to OP-TEE. So, the S2 tables are created correctly before OP-TEE > tries to use them. > > The S2 fault is a L3 Translation fault. The L3 descriptor in S2 tables is > NULL when the fault occurs. So this makes sense. This also implies that the > translation is not cached in the TLBs. > > The key thing is that the fault only occurs when cache state modelling is > turned on in the FVP_Base_RevC-2xAEMv8A model we are using for development. > The fault occurs both when the S2 tables are created and accessed on the > same PE as well as different PEs. It does not matter whether the PEs are in > the same or different clusters. The fault occurs both with and without a > Hypervisor (Hf) in the Normal world. So presence of Hf in EL2 is not a > factor. > > We noticed that Hf marks its internal memory as outer-shareable. See [1] > and [2]. It uses inner-shareable for S2 PTWs though. See [3]. This is a > mismatch of memory attributes as per Page 2563 in ARM DDI 0487F.b. The > start of the text is quoted below. > > "The rules about mismatched attributes given in Mismatched memory > attributes…” > > And indeed, the fault is not seen if we mark Hf’s internal memory as inner > shareable to match the PTWs. The DSBs after creating the S2 tables in [4] > are for inner-shareable access types. It seems that the inner-shareable PTW > is unable to observe the outer shareable page table write. Using the inner > shareable attributes for the internal memory makes the write observable. > > Alternatively, if we change shareability of PTWs in VTCR_EL2 to outer > shareable then the fault is no longer observed. It is not clear how the > PTWs and page table writes are synchronised in this case without a DSB OSH. > This is not a violation of the architecture afaiu. > > It seems that it would be worth aligning these attributes. > > The next bit is why Hf uses the outer shareable attribute for internal > memory in the first place. The recommendation seems to be to use > inner-shareable. See [5] and [6]. > > So we are wondering if this should be fixed too. Please let me know if we > have misunderstood anything so far. Happy to post a patch if not or provide > more information. > > Cheers, > Achin > > [1] > https://hafnium.googlesource.com/hafnium/+/refs/heads/master/src/arch/aarch… > [2] > https://hafnium.googlesource.com/hafnium/+/refs/heads/master/src/mm.c#1043 > [3] > https://hafnium.googlesource.com/hafnium/+/refs/heads/master/src/arch/aarch… > [4] > https://hafnium.googlesource.com/hafnium/+/refs/heads/master/src/arch/aarch… > [5] "Shareable Normal memory” in Pg. 154 in ARM DDI 0487F.b > [6] > https://linux-arm-kernel.infradead.narkive.com/RZHvk1cT/question-how-can-we… > > > -- > Hafnium mailing list > Hafnium(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/hafnium >

6 years, 2 months

3
2
0 0

Re: [Hafnium] Determine security state of a memory region

by Raghu Krishnamurthy

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 >>

6 years, 2 months

1
0
0 0

Re: [Hafnium] Determine security state of a memory region

by Andrew Walbran

On Sun, 7 Jun 2020 at 16:46, Achin Gupta via Hafnium < hafnium(a)lists.trustedfirmware.org> wrote: > Hi Raghu, > > Howdy! CIL… > > > On 4 Jun 2020, at 16:21, Raghu K via Hafnium < > hafnium(a)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 > > https://lists.trustedfirmware.org/mailman/listinfo/hafnium > > -- > Hafnium mailing list > Hafnium(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/hafnium >

6 years, 2 months

2
1
0 0

Re: [Hafnium] Bring up hafnium on Pi4 board

by Andrew Walbran

I'm not sure about the exact issue you're seeing, but one thing that could be helpful for debugging is to increase the log verbosity level, by changing the log_level in build/BUILDCONFIG.gn to LOG_LEVEL_VERBOSE and rebuilding. Can you also share the command you are using to make the ramdisk? Changing the order of files in it (e.g. putting the manifest file first) might work around the issue if it is caused by alignment. On Mon, 8 Jun 2020 at 04:26, 王华 via Hafnium < hafnium(a)lists.trustedfirmware.org> wrote: > > > > Hi, David : > Thanks very much for your help. > I check the firmware version as following command , It seems that it > is the newest stable FW. But still failed. > pi@raspberrypi:~$ vcgencmd bootloader_version > Apr 16 2020 18:11:26 > version > a5e1b95f320810c69441557c5f5f0a7f2460dfb8 (release) > > timestamp 1587057086 > > > I share my config.txt in attchment and hafnium.elf in > https://drive.google.com/file/d/12M-qqTQTF7BampvLOZLhMDZDNuQpoiEB/view?usp=… > > > > > > > > 在 2020-06-07 22:05:15，"David Brazdil" <dbrazdil(a)google.com> 写道： > > Hi Wanghua, > > > Happy to help, the RPi4 port should still be working. Though we do not > continuously test it, so there is a possibility that the code has rotted a > bit. > > I can share my notes on how I got it working, but you seem to have figured > out pretty much all of it. > > > You're seeing the hypervisor abort when accessing address 0x19536ee (FAR) > - that's inside the radisk as reported above the error. The value of ESR > suggests that this is an alignment error (the address is indeed unaligned). > So Hafnium probably crashed trying to parse something in the ramdisk. > > > Before we try anything else, could you try to update your RPi4 firmware? I > remember that I had issues with the 'initramfs' option in config.txt - it > would load random data from the SD card. The error that you're seeing could > be a result of that. > Instructions on how to update your firmware: > https://www.raspberrypi.org/documentation/hardware/raspberrypi/booteeprom.md > > > If that doesn't help, could you please attach your > out/reference/rpi4_clang/hafnium.elf? It would be good to know which > function is at the crashing PC 0x8b0dc. > > > David > > > > > On Sun, Jun 7, 2020 at 2:08 PM 王华 via Hafnium < > hafnium(a)lists.trustedfirmware.org> wrote: > > Hi all : > > Has anyone brought up Hafnium on Raspberry Pi 4 board ? I tried but > failed by the following steps: > > 1.Make the Hafnium RAM disk with aarch64 build Pi4 kernel , RAM disk for > Linux , manifest.dtb. > > The manifest.dtb buildt by : > > /dts-v1/; > > > / { > > │ hypervisor { > > │ │ compatible = "hafnium,hafnium"; > > │ │ vm1 { > > │ │ │ debug_name = "Linux VM"; > > │ │ │ kernel_filename = "vmlinuz"; > > │ │ │ ramdisk_filename = "initrd.img"; > > │ │ }; > > │ }; > > }; > > 2.Copy bl31.bin hafnium.bin initrd.img to fat32 boot direction and > configure config.txt . Power up my unit and got the uart error log : > > NOTICE: BL31: v2.3(debug):v2.3-109-g771c676b1 > > NOTICE: BL31: Built : 15:49:37, Jun 1 2020 > > INFO: Changed device tree to advertise PSCI. > > INFO: ARM GICv2 driver initialized > > INFO: BL31: Initializing runtime services > > INFO: BL31: cortex_a72: CPU workaround for 859971 was applied > > INFO: BL31: cortex_a72: CPU workaround for cve_2017_5715 was applied > > INFO: BL31: cortex_a72: CPU workaround for cve_2018_3639 was applied > > INFO: BL31: Preparing for EL3 exit to normal world > > INFO: Entry point address = 0x80000 > > INFO: SPSR = 0x3c9 > > NOTICE: Initialising hafnium > > INFO: text: 0x80000 - 0x97000 > > INFO: rodata: 0x97000 - 0x9a000 > > INFO: data: 0x9a000 - 0x117000 > > INFO: Supported bits in physical address: 44 > > INFO: Stage 2 has 4 page table levels with 1 pages at the root. > > INFO: Found PSCI version: 0x10001 > > INFO: Memory range: 0x0 - 0x3b3fffff > > INFO: Memory range: 0x40000000 - 0xfbffffff > > INFO: Ramdisk range: 0x1800000 - 0x353dbff > > ERROR: Data abort: pc=0x8b0dc, esr=0x96000021, ec=0x25, far=0x19536ee > > Panic: EL2 exception > > Is there anyone can help me with this issue or share me the way to bring > up Hafnium on pi4 ? Thanks very much ! > > > ------ > > By Wanghua > > > > > Best Regards！ > > -- > 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 >

6 years, 2 months

3
3
0 0

Mismatched memory attributes in Hf?

by Achin Gupta

Hi All, In Arm, we are experimenting with running OP-TEE under Hafnium as the SPMC in S-EL2. We have been debugging this Stage 2 fault that OP-TEE runs into a during a test to share memory (xtest 1003). It seems this is due to a bug in Hafnium but want to be sure before posting a fix. Some thoughts below to this end. Apologies for the verbosity but I hope you will appreciate it is required. The fault occurs when OP-TEE tries to access a memory region that was shared with it by the OP-TEE driver in Linux i.e. the driver has called FFA_MEM_SHARE to share the memory, OP-TEE has called FFA_MEM_RETRIEVE_REQ to map it in its S2 and Hf has called FFA_MEM_RETRIVE_RESP to describe the IPA range to OP-TEE. So, the S2 tables are created correctly before OP-TEE tries to use them. The S2 fault is a L3 Translation fault. The L3 descriptor in S2 tables is NULL when the fault occurs. So this makes sense. This also implies that the translation is not cached in the TLBs. The key thing is that the fault only occurs when cache state modelling is turned on in the FVP_Base_RevC-2xAEMv8A model we are using for development. The fault occurs both when the S2 tables are created and accessed on the same PE as well as different PEs. It does not matter whether the PEs are in the same or different clusters. The fault occurs both with and without a Hypervisor (Hf) in the Normal world. So presence of Hf in EL2 is not a factor. We noticed that Hf marks its internal memory as outer-shareable. See [1] and [2]. It uses inner-shareable for S2 PTWs though. See [3]. This is a mismatch of memory attributes as per Page 2563 in ARM DDI 0487F.b. The start of the text is quoted below. "The rules about mismatched attributes given in Mismatched memory attributes…” And indeed, the fault is not seen if we mark Hf’s internal memory as inner shareable to match the PTWs. The DSBs after creating the S2 tables in [4] are for inner-shareable access types. It seems that the inner-shareable PTW is unable to observe the outer shareable page table write. Using the inner shareable attributes for the internal memory makes the write observable. Alternatively, if we change shareability of PTWs in VTCR_EL2 to outer shareable then the fault is no longer observed. It is not clear how the PTWs and page table writes are synchronised in this case without a DSB OSH. This is not a violation of the architecture afaiu. It seems that it would be worth aligning these attributes. The next bit is why Hf uses the outer shareable attribute for internal memory in the first place. The recommendation seems to be to use inner-shareable. See [5] and [6]. So we are wondering if this should be fixed too. Please let me know if we have misunderstood anything so far. Happy to post a patch if not or provide more information. Cheers, Achin [1] https://hafnium.googlesource.com/hafnium/+/refs/heads/master/src/arch/aarch… [2] https://hafnium.googlesource.com/hafnium/+/refs/heads/master/src/mm.c#1043 [3] https://hafnium.googlesource.com/hafnium/+/refs/heads/master/src/arch/aarch… [4] https://hafnium.googlesource.com/hafnium/+/refs/heads/master/src/arch/aarch… [5] "Shareable Normal memory” in Pg. 154 in ARM DDI 0487F.b [6] https://linux-arm-kernel.infradead.narkive.com/RZHvk1cT/question-how-can-we…

6 years, 2 months

1
0
0 0

Re: [Hafnium] Bring up hafnium on Pi4 board

by David Brazdil

Hi Wanghua, Happy to help, the RPi4 port should still be working. Though we do not continuously test it, so there is a possibility that the code has rotted a bit. I can share my notes on how I got it working, but you seem to have figured out pretty much all of it. You're seeing the hypervisor abort when accessing address 0x19536ee (FAR) - that's inside the radisk as reported above the error. The value of ESR suggests that this is an alignment error (the address is indeed unaligned). So Hafnium probably crashed trying to parse something in the ramdisk. Before we try anything else, could you try to update your RPi4 firmware? I remember that I had issues with the 'initramfs' option in config.txt - it would load random data from the SD card. The error that you're seeing could be a result of that. Instructions on how to update your firmware: https://www.raspberrypi.org/documentation/hardware/raspberrypi/booteeprom.md If that doesn't help, could you please attach your out/reference/rpi4_clang/hafnium.elf? It would be good to know which function is at the crashing PC 0x8b0dc. David On Sun, Jun 7, 2020 at 2:08 PM 王华 via Hafnium < hafnium(a)lists.trustedfirmware.org> wrote: > Hi all : > > Has anyone brought up Hafnium on Raspberry Pi 4 board ? I tried but > failed by the following steps: > > 1.Make the Hafnium RAM disk with aarch64 build Pi4 kernel , RAM disk for > Linux , manifest.dtb. > > The manifest.dtb buildt by : > > /dts-v1/; > > > / { > > │ hypervisor { > > │ │ compatible = "hafnium,hafnium"; > > │ │ vm1 { > > │ │ │ debug_name = "Linux VM"; > > │ │ │ kernel_filename = "vmlinuz"; > > │ │ │ ramdisk_filename = "initrd.img"; > > │ │ }; > > │ }; > > }; > > 2.Copy bl31.bin hafnium.bin initrd.img to fat32 boot direction and > configure config.txt . Power up my unit and got the uart error log : > > NOTICE: BL31: v2.3(debug):v2.3-109-g771c676b1 > > NOTICE: BL31: Built : 15:49:37, Jun 1 2020 > > INFO: Changed device tree to advertise PSCI. > > INFO: ARM GICv2 driver initialized > > INFO: BL31: Initializing runtime services > > INFO: BL31: cortex_a72: CPU workaround for 859971 was applied > > INFO: BL31: cortex_a72: CPU workaround for cve_2017_5715 was applied > > INFO: BL31: cortex_a72: CPU workaround for cve_2018_3639 was applied > > INFO: BL31: Preparing for EL3 exit to normal world > > INFO: Entry point address = 0x80000 > > INFO: SPSR = 0x3c9 > > NOTICE: Initialising hafnium > > INFO: text: 0x80000 - 0x97000 > > INFO: rodata: 0x97000 - 0x9a000 > > INFO: data: 0x9a000 - 0x117000 > > INFO: Supported bits in physical address: 44 > > INFO: Stage 2 has 4 page table levels with 1 pages at the root. > > INFO: Found PSCI version: 0x10001 > > INFO: Memory range: 0x0 - 0x3b3fffff > > INFO: Memory range: 0x40000000 - 0xfbffffff > > INFO: Ramdisk range: 0x1800000 - 0x353dbff > > ERROR: Data abort: pc=0x8b0dc, esr=0x96000021, ec=0x25, far=0x19536ee > > Panic: EL2 exception > > Is there anyone can help me with this issue or share me the way to bring > up Hafnium on pi4 ? Thanks very much ! > > > ------ > > By Wanghua > > > > > Best Regards！ > > -- > Hafnium mailing list > Hafnium(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/hafnium >

6 years, 2 months

2
1
0 0

Re: [Hafnium] Determine security state of a memory region

by Achin Gupta

Hi Raghu, Howdy! CIL… > On 4 Jun 2020, at 16:21, Raghu K via Hafnium <hafnium(a)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. 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 > https://lists.trustedfirmware.org/mailman/listinfo/hafnium

6 years, 2 months

1
0
0 0

Bring up hafnium on Pi4 board

by 王华

Hi all : Has anyone brought up Hafnium on Raspberry Pi 4 board ? I tried but failed by the following steps: 1.Make the Hafnium RAM disk with aarch64 build Pi4 kernel , RAM disk for Linux , manifest.dtb. The manifest.dtb buildt by : /dts-v1/; / { │ hypervisor { │ │ compatible = "hafnium,hafnium"; │ │ vm1 { │ │ │ debug_name = "Linux VM"; │ │ │ kernel_filename = "vmlinuz"; │ │ │ ramdisk_filename = "initrd.img"; │ │ }; │ }; }; 2.Copy bl31.bin hafnium.bin initrd.img to fat32 boot direction and configure config.txt . Power up my unit and got the uart error log : NOTICE: BL31: v2.3(debug):v2.3-109-g771c676b1 NOTICE: BL31: Built : 15:49:37, Jun 1 2020 INFO: Changed device tree to advertise PSCI. INFO: ARM GICv2 driver initialized INFO: BL31: Initializing runtime services INFO: BL31: cortex_a72: CPU workaround for 859971 was applied INFO: BL31: cortex_a72: CPU workaround for cve_2017_5715 was applied INFO: BL31: cortex_a72: CPU workaround for cve_2018_3639 was applied INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x80000 INFO: SPSR = 0x3c9 NOTICE: Initialising hafnium INFO: text: 0x80000 - 0x97000 INFO: rodata: 0x97000 - 0x9a000 INFO: data: 0x9a000 - 0x117000 INFO: Supported bits in physical address: 44 INFO: Stage 2 has 4 page table levels with 1 pages at the root. INFO: Found PSCI version: 0x10001 INFO: Memory range: 0x0 - 0x3b3fffff INFO: Memory range: 0x40000000 - 0xfbffffff INFO: Ramdisk range: 0x1800000 - 0x353dbff ERROR: Data abort: pc=0x8b0dc, esr=0x96000021, ec=0x25, far=0x19536ee Panic: EL2 exception Is there anyone can help me with this issue or share me the way to bring up Hafnium on pi4 ? Thanks very much ! ------ By Wanghua Best Regards！

6 years, 2 months

1
0
0 0

Re: [Hafnium] Determine security state of a memory region

by Raghu K

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? 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

6 years, 2 months

1
0
0 0

Determine security state of a memory region

by Achin Gupta

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

6 years, 2 months

1
0
0 0

CPTR_EL2 configuration

by Olivier Deprez

Hi, Hafnium sets CPTR_EL2.TTA (bit 28), which traps accesses to trace system registers to EL2. https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/arch/aarch64/s… However CPTR_EL2 register has a different bit field definition depending on HCR_EL2.E2H state. When HCR_EL2.E2H=0 (Hafnium case) CPTR_EL2.TTA bit position is 20. Is this a slight issue 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.

6 years, 3 months

1
0
0 0

Hafnium chat channel

by Andrew Walbran

Hi all, It would be useful to have a chat group of some sort for quick questions that don't warrant an email thread. What is the preferred solution for this for Arm and Trusted Firmware? I saw that there is already an Arm Developer Ecosystem Discord server, would a channel there be appropriate? What does TF-A use?

6 years, 3 months

1
0
0 0

Clarifications and minor issue with FF-A 1.0 memory sharing fragmentation

by Andrew Walbran

Hello, I've run into a few issues while implementing fragmentation for memory sharing based on the FF-A 1.0 spec, which I think need clarifying or fixing. 1. From section 13.2.2.3 points 2-6, it sounds like the 'sender' in the case of a FFA_MEM_RETRIEVE_RESP_32 from the SPM to the non-secure hypervisor is the SPM. Am I correct in understanding that this means that the sender id for FFA_MEM_FRAG_TX and FFA_MEM_FRAG_RX should thus always be the ID of the SPM, when the hypervisor is retrieving a memory region from the SPM for the purposes of a reclaim operation from a normal world VM? 2. When a normal world VM tries to share memory with a secure partition via FFA_MEM_SHARE, it may be that the buffer between the hypervisor and the SPM is busy because another VM is also sharing memory or doing something else that uses the buffer, on a different physical CPU. This could happen either for the initial fragment sent via FFA_MEM_SHARE or for a subsequent fragment sent with FFA_MEM_FRAG_TX. The spec currently says in section 12.3.1.2, point 13.2 that the hypervisor must return ABORTED in the FFA_MEM_SHARE case, and doesn't allow any relevant error codes in the description of FFA_MEM_FRAG_TX in section 13.2.2.5, though it does mention ABORTED in section 13.2.2.3 point 8. However, the buffer being busy need not mean that the whole transaction is aborted; it should be possible for the sender to try again after a short time, when hopefully the buffer is available again. So it would make more sense for the hypervisor to return an FFA_BUSY error in this case, as it does in other cases where a buffer is currently unavailable but the caller can try again.

6 years, 3 months

3
3
0 0

Re: [Hafnium] kokoro/build and CHECKPATCH

by Olivier Deprez

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 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> 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 -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 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.

6 years, 3 months

2
1
0 0

Re: [Hafnium] kokoro/build and CHECKPATCH

by Andrew Walbran

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> 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 -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 > https://lists.trustedfirmware.org/mailman/listinfo/hafnium >

6 years, 3 months

1
0
0 0

kokoro/build and CHECKPATCH

by Olivier Deprez

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 -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.

6 years, 3 months

1
0
0 0

Re: [Hafnium] Hafnium repo management.

by Andrew Walbran

On Tue, 21 Apr 2020 at 21:18, Raghu K via Hafnium < hafnium(a)lists.trustedfirmware.org> wrote: > All, > > I was looking at the hafnium repositories on trusted firmware and was > wondering how we envision managing the project on trustedfirmware.org vs > googlesource. Is the plan to set up this project to be like > googlesource, i.e using repo to manage the multiple repositories ? There > appears to be dependencies on third party tools/prebuilts in the > BUILD.gn files so using something like repo even on trustedfirmware.org > sounds useful. > The plan is to continue using git submodules for this. The main Hafnium repository has submodules for: prebuilts driver/linux project/reference third_party/dtc third_party/googletest third_party/linux The .gitmodules file currently still points to the old URLs but this will be updated once the migration is complete. (We are currently blocked on getting CI running on the new infrastructure.) The advantage of submodules over repo for this is that it ties specific versions together, which is important for bisection or otherwise checking out old versions to work properly. Often we make changes in one repository which need to happen at the same time as a change in another repository for the build to work. Repo doesn't provide a way to link versions together like this. We were using repo for some internal Google tools which don't support submodules, but this shouldn't be necessary anymore.

6 years, 4 months

2
1
0 0

Re: [Hafnium] Hafnium repo management.

by Joanna Farley

Hi Raghu, The transition of repo, CI and tools is still taking place, we can expect in the shorter term the project management to be very similar although on TF.org servers to what it was previously but longer term tighter integration with TF-A will occur but details are still being worked out. We expect a TF-A Tech Forum meeting in the near term future to cover more details of Hafnium integration and other subjects. Thanks Joanna On 21/04/2020, 21:19, "Hafnium on behalf of Raghu K via Hafnium" <hafnium-bounces(a)lists.trustedfirmware.org on behalf of hafnium(a)lists.trustedfirmware.org> wrote: All, I was looking at the hafnium repositories on trusted firmware and was wondering how we envision managing the project on trustedfirmware.org vs googlesource. Is the plan to set up this project to be like googlesource, i.e using repo to manage the multiple repositories ? There appears to be dependencies on third party tools/prebuilts in the BUILD.gn files so using something like repo even on trustedfirmware.org sounds useful. Thanks Raghu -- Hafnium mailing list Hafnium(a)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.

6 years, 4 months

1
0
0 0

Hafnium repo management.

by Raghu K

All, I was looking at the hafnium repositories on trusted firmware and was wondering how we envision managing the project on trustedfirmware.org vs googlesource. Is the plan to set up this project to be like googlesource, i.e using repo to manage the multiple repositories ? There appears to be dependencies on third party tools/prebuilts in the BUILD.gn files so using something like repo even on trustedfirmware.org sounds useful. Thanks Raghu

6 years, 4 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

Hafnium