- Hafnium - lists.trustedfirmware.org

Firmware-A v2.13 release code freeze notification

by Olivier Deprez

Hi All, The next release of the Firmware-A bundle of projects tagged v2.13 has an expected code freeze date of May, 2nd 2025. In order to accommodate the Linaro connect event occurring during the week of May 12th we may extend the release completion date up until the week of May 26th. v2.13 release preparation tasks start from now. We want to ensure that planned feature patches for the release are submitted in good time for the review process to conclude. As a kind recommendation and a matter of sharing CI resources, please launch CI jobs with care e.g.: -For simple platform, docs changes, or one liners, use Allow-CI+1 label (no need for a full Allow-CI+2 run). -For large patch stacks use Allow-CI+2 at top of the patch stack (and if required few individual Allow+CI+1 labels in the middle of the patch stack). -Carefully analyze results and fix the change if required, before launching new jobs on the same change. -If after issuing a Allow-CI+1 or Allow-CI+2 label a Build start notice is not added as a gerrit comment on the patch right away please be patient as under heavy load CI jobs can be queued and in extreme conditions it can be over an hour before the Build start notice is issued. Issuing another Allow-CI+1 or Allow-CI+2 label will just result in an additional job being queued. Regards, Olivier.

1 day, 9 hours

1
1
0 0

Notification setup failed log in the latest Linux

by Sungbae Yoo

Hi, I have a couple of questions related to notification. Recently, we are working on kernel upgrade and I found this log while booting. | genirq: Flags mismatch irq 6. 00004401 (ARM-FFA-NPI) vs. 00004400 (IPI) | ARM FF-A: Error registering percpu NPI nIRQ 6 : -16 | ARM FF-A: Notification setup failed -16, not enabled This does not affect the other functionalities when I tested using xtest of OP-TEE. And, I found a commit [1] related this log in linux kernel and it said | If the firmware returns incorrect SRI/NRI number, we fail to set it up | in the kernel which is absolutely fine. So I checked hafnium and I found that hafnium returns "5" as HF_NOTIFICATION_PENDING_INTID [2] and it conflicts with IPI numbers (IPI_TIMER) [3]. So the question is : 1. HF_NOTIFICATION_PENDING_INTID seems to be conflicted. Do you have any plan to change its number greater than MAX_IPI? 2. Or, Is there the other way to avoid IRQ number conflicts? I mean, Did I miss something to configure? 3. Actually, I haven't find any use-case of notification yet. so notification is still working in progress? [1] https://lore.kernel.org/linux-arm-kernel/171396205191.700527.18157351542957… [2] https://github.com/TF-Hafnium/hafnium/blob/main/inc/vmapi/hf/types.h#L62 [3] https://elixir.bootlin.com/linux/v6.14.1/source/arch/arm64/kernel/smp.c#L72

3 days, 17 hours

3
5
0 0

trustedfirmware git and gerrit slowness

by Olivier Deprez

Hi, You must have noticed slowness or breakages with review.trustedfirmware.org or git.trustedfirmware.org during the week. There are high and lows of network bandwidth usage affecting server availability. The issue is being investigated but not yet 100% root caused. Apologies for the frustration and inconvenience that this is causing. Rest assured the team is on board to resolve this unfortunate situation. Regards, Olivier.

2 weeks, 6 days

1
0
0 0

Firmware-A v2.12 release follow up - shrinkwrap

by Olivier Deprez

Hi, As a follow up to the Firmware-A v2.12 release [1], we are pleased to share the shrinkwrap tool [2] configurations have been updated to consume latest firmware/upstream ingredients using following tags: TF-A: v2.12.0 TF-a-tests: v2.12.0 Hafnium: v2.12.0 TF-RMM: tf-rmm-v0.6.0 CCA EDK2: 3223_arm_cca_rmm_v1.0_rel0_v3 linux: cca-full/v5+v7 kvmtool: cca/v3 An additional merge request is in queue for kvm-unit-tests update to cca/rmm-v1.0-rel0 tag. Shrinkwrap is a convenient tool for building a fully integrated Arm CCA SW stack running on the Base AEM FVP platform. In particular this is the tool of choice for RMM development to reproduce a 3 or 4 worlds RME based environment. Regards, Olivier. [1] https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.… [2] https://shrinkwrap.docs.arm.com/en/latest/

5 months

1
0
0 0

Trusted Firmware v2.12 release announcement

by Olivier Deprez

Hi All, We are pleased to announce the formal release of Trusted Firmware-A version 2.12 bundle of project deliverables. This includes Trusted Firmware-A, Trusted Firmware-A Tests, Hafnium, RMM, Trusted Services, and TF-A OpenCI scripts/jobs components. These went live on Nov, 21st 2024. Please find references to tags and change logs at the end of this email. Many thanks to the trustedfirmware.org community for the active engagement in delivering this release! Notable features of the release version 2.12 are as follows: TF-A/EL3 * New CPUs support: Cortex-A320 (Arcadia), Cortex-A720AE. * Arch extensions: : FEAT_THE, FEAT_LS64_ACCDATA, FEAT_Debugv8p9, FEAT_SCTLR2, FEAT_FGT2 ; Arm 9.4 : FEAT_D128 support. * Context management: Asymmetric CPU features, EL3 execution context, SVE S/R support. * RME: GPT contiguous descriptor (or GPT large mappings support). * Arm CCA: added attestation generic library, el3 attestation token signing support. Boot flow * Tools: * Introduced the Transfer List Compiler (TLC) Host Tool supporting the FW hand-off specification. * Introduced CoT Device Tree to C File (DT2C) tool. * mbedTLS Improvements: * Resolved random authentication failures with ECDSA. * Enhanced mbedTLS configuration selection. * Maximize usage of mbedTLS library APIs in TF-A. * Upgraded to mbedTLS v3.6.1. * Feature addition/support: * Support for the ECDSA P-384 curve with the PSA Crypto implementation. * Documentation: * Added the DPE Design and Threat Model document to TF-A readthedocs. Errata (CPU/GIC) * Cortex-A720, Cortex-A520, Cortex-X4 errata. TF-A platforms support * New platforms added: TC4, RD-1 AE, RK3566/RK3568. * Platform fixes: FPGA, FVP, Neoverse-RD, TC, Corstone-1000, Allwinner, AST2700, Poplar, Agilex, A3K, MT8188, iMX8M, S32G274A, qemu, Rpi3, Rockchip, STM32MP1, STM32MP2, Versal, ZynqMP. Hafnium/SPM (S-EL2) * FF-A features additions * FF-A v1.2 FFA_MSG_WAIT RX buffer ownership flag. * FF-A v1.2 FFA_VERSION endpoint restriction. * FF-A v1.1 VM availability messages. * Architectural support * vCPU IPI signaling. * Arch timer virtualization. * RME: GPF support and memcpy hardening. * Secure Interrupt Handling for UP S-EL1 partitions. TF-RMM (R-EL2) * REL0 RMM 1.0 support. * Support for alternative attestation token signing via EL3. * Various improvements and bugfixes as listed in the change log. TF-A Tests * Arm arch. extensions: AMU, FEAT_FGT2, LS64_ACCDATA, FEAT_Debugv8p9, LS64 64-byte load/store. * Asymmetric feature testing (FEAT_SPE, FEAT_TRBE, FEAT_TCR2). * EL1 and EL2 context switch tests. * FF-A: v1.2 support, S-EL2 arch timer virtualization, S-EL2+RME hardening, EL3 SPMC TFTF test suite, EL3 SVE test coverage. * RME: RMM v1.0 testing support, PCIe DOE support, RMI support for FEAT_LPA2, SIMD, PAuth. * Platforms: AMD Versal Gen 2 added, Neoverse-RD refactoring, FVP PCIe support. Release tags across repositories: https://git.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/+/r… https://git.trustedfirmware.org/plugins/gitiles/TF-A/tf-a-tests/+/refs/tags… https://git.trustedfirmware.org/plugins/gitiles/ci/tf-a-ci-scripts/+/refs/t… https://git.trustedfirmware.org/plugins/gitiles/ci/tf-a-job-configs/+/refs/… https://git.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/refs/tags… https://git.trustedfirmware.org/plugins/gitiles/ci/hafnium-ci-scripts/+/ref… https://git.trustedfirmware.org/plugins/gitiles/ci/hafnium-job-configs/+/re… https://git.trustedfirmware.org/plugins/gitiles/TF-RMM/tf-rmm/+/refs/tags/t… https://git.trustedfirmware.org/plugins/gitiles/TS/trusted-services/+/refs/… Change logs: https://trustedfirmware-a.readthedocs.io/en/v2.12.0/change-log.html#id1 https://trustedfirmware-a-tests.readthedocs.io/en/latest/change-log.html#ve… https://hafnium.readthedocs.io/en/v2.12.0/change-log.html#v2-12 https://tf-rmm.readthedocs.io/en/latest/about/change-log.html#v0-6-0 Regards, Olivier.

5 months, 2 weeks

1
0
0 0

Firmware-A v2.12 release code freeze notification

by Govindraj Raja

Hi All, The next release of the Firmware-A bundle of projects tagged v2.12 has an expected code freeze date of Nov, 8th 2024. Refer to the release cadence section from TF-A documentation (https://trustedfirmware-a.readthedocs.io/en/latest/about/release-informatio…). Closing out the release takes around 6-10 working days after the code freeze. v2.12 release preparation tasks start from now. We want to ensure that planned feature patches for the release are submitted in good time for the review process to conclude. As a kind recommendation and a matter of sharing CI resources, please launch CI jobs with care e.g.: -For simple platform, docs changes, or one liners, use Allow-CI+1 label (no need for a full Allow-CI+2 run). -For large patch stacks use Allow-CI+2 at top of the patch stack (and if required few individual Allow+CI+1 labels in the middle of the patch stack). -Carefully analyze results and fix the change if required, before launching new jobs on the same change. -If after issuing a Allow-CI+1 or Allow-CI+2 label a Build start notice is not added as a gerrit comment on the patch right away please be patient as under heavy load CI jobs can be queued and in extreme conditions it can be over an hour before the Build start notice is issued. Issuing another Allow-CI+1 or Allow-CI+2 label will just result in an additional job being queued. -- Thanks, Govindraj R

5 months, 3 weeks

1
1
0 0

Re: TF-A Tech Forum regular call

by Olivier Deprez

+ other MLs ________________________________ From: Olivier Deprez Sent: 30 October 2024 11:41 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: TF-A Tech Forum regular call Dear TF-A ML members, As mentioned in https://www.trustedfirmware.org/meetings/tf-a-technical-forum/, trustedfirmware.org hosts regular technical calls on Thursdays. It mentions TF-A although in practise a number of Cortex-A projects beyond TF-A were discussed (refer to prior recordings on this page). Unfortunately this slot hasn't been very active recently. By this email I'm kindly emphasizing this forum is open to the community (and beyond trustedfirmware.org members) and you are welcome to propose topics. Presentations/slides are not strictly necessary, and we can also host informal discussions or session of questions. If you think of a topic, please reach to me and I'll be happy to accommodate. Thanks for your contributions in advance! Regards, Olivier.

6 months, 1 week

1
0
0 0

Hafnium in Industry

by Friedrich

Hi, Can someone explain to me where and why Hafnium is used in the industry? I've only ever seen it being used in academic research. Thanks, Friedrich

7 months, 3 weeks

2
1
1 0

Current status of NWd driver for secondary VM SMP support

by Sungbae Yoo

Hi, I have a couple of question about SMP support of linux driver. We'd like to run multiple SP that uses secondary cores. The first SP can initialize all secondary vCPUs when linux invokes cpu on for all secondary cores. But the other SP doesn't initialize its secondary vCPUs. If My understanding is correct, they will be initialized when FFA_RUN calls to each vCPUs are called [1] and FFA_RUN calls are called by Normal world driver in linux [2]. But I can't find any implementations regarding this in the latest upstream linux (v6.10). Actually, I found ffa_cpu_ops in linux code [3], but couldn't the place where it is used. I think that ffa_run has to be called in driver to initialize secodary vCPUs of secondary VMs. Am I missing something in the code? Or Is there no implementation yet in upstream? I'd like to know about the current status of secondary VM SMP support in linux. If linux driver doesn't support it yet, Do you have any plan to make an implementation and merge it? Thanks, Sungbae Yoo. [1] https://hafnium.readthedocs.io/en/latest/secure-partition-manager/secure-pa… [2] https://lists.trustedfirmware.org/archives/list/hafnium@lists.trustedfirmwa… [3] https://elixir.bootlin.com/linux/v6.11-rc5/source/drivers/firmware/arm_ffa/…

8 months, 1 week

2
1
0 0

Could you add a new gicd_set_ctlr() API to set GICD_CTLR to wait until RWP becomes zero?

by magicse7en＠outlook.com

Hi , Could you add below patch to gicv3_helpers.h? --- a/src/arch/aarch64/plat/interrupts/gicv3_helpers.h +++ b/src/arch/aarch64/plat/interrupts/gicv3_helpers.h @@ -203,6 +203,16 @@ static inline void gicd_wait_for_pending_write(uintptr_t gicd_base) } } +static inline void gicd_set_ctlr(uintptr_t base, + unsigned int bitmap, + unsigned int rwp) +{ + gicd_write_ctlr(base, gicd_read_ctlr(base) | bitmap); + if (rwp != 0U) { + gicd_wait_for_pending_write(base); + } +} + static inline uint32_t gicd_read_pidr2(uintptr_t base) { return io_read32(IO32_C(base + GICD_PIDR2_GICV3)); The existed gicd_write_ctlr() just write the GICD_CTLR, but from GIC spec, if write GICD_CTLR, it needs to wait the RWP bit becomes zero. Therefore, I think the gicd_set_ctlr() function of tf-a is a good choice. I tried to push this patch to https://review.trustedfirmware.org/, but I encountered below error. error: RPC failed; HTTP 403 curl 22 The requested URL returned error: 403

10 months, 2 weeks

2
1
1 0

Trusted Firmware v2.10 Release Announcement

by Olivier Deprez

Hi All, We are pleased to announce the formal release of Trusted Firmware-A version 2.10 bundle of project deliverables. This includes Trusted Firmware-A, Trusted Firmware-A Tests, Hafnium, RMM and TF-A OpenCI Scripts/Jobs 2.10 releases involving the tagging of multiple repositories. These went live on 22nd November 2023. Please find references to tags and change logs at the end of this email. Many thanks to the community for the active engagement in delivering this release! Notable Features of the Version 2.10 Release are as follows: TF-A/EL3 Root World * New Features: * Firmware handoff library support * Improvements to BL31 runtime exception handling * Context management refactoring for RME/4 worlds * Gelas, Nevis & Travis CPUs support * V8.9 features enabled (FEAT_ HAFT, RPRFM, LRCPC3, MTE_PERM) TF-A Boot BL1/BL2 * New Features * Trusted Boot support for ECDSA (Elliptic Curve Digital Signature Algorithm) * Migrated to PSA crypto API’s * Improved the GUID Partition Table (GPT) parser. * Various security Improvements and threat Model updates for ARM CCA * Signer id extraction Implementation Hafnium/SEL2 SPM * New Features: * FF-A v1.2: FFA_YIELD with time-out; EL3 SPMDs LSPs communication; memory sharing updates. * Memory region relative base address field support in SP manifests. * Interrupt re-configuration hypervisor calls. * Memory management: S2 PT NS/S IPA split * SMCCCv1.2+ compliance fixes. * Feature parity test improvements, EL3 SPMC and Hafnium (S-EL2 SPMC) TF-RMM/REL2 * New Feature/Support * Fenimore v1.0 EAC5 aligned implementation. * TFTF Enhancements for RME testing * Initial CBMC support * NS SME support in RMM * BTI support for RMM Errata * Errata implemented (1xCortex-X2/ Matterhorn-ELP, 1xCortex-A710/Matterhorn, 1xNeoverse N2/Perseus, 2xNeoverse V2/Demeter, Makalu ELP/Cortex X3, Klein/Cortex-A510) * Fix some minor defects with version in a few errata that applies for some follow up revisions of the CPUs. (Neoverse V1, Cortex-X2, Cortex-A710) TF-A Tests * Core * Added errata management firmware interface tests. * Added firmware handoff tests. * Introduced RAS KFH support test. * SPM/FF-A * Support SMCCCv1.2 extended GP registers set. * Test SMCCC compliance at the non-secure physical instance. * Test secure eSPI interrupt handling. * Test FF-A v1.2 FFA_PARTITION_INFO_GET_REGS interface. * RMM * Added FPU/SVE/SME tests * Added multiple REC single CPU tests. * Added PAuth support in Realms tests. * Added PMU tests. Platform Support * New platforms added: * Aspeed AST2700, NXP IMX93, Intel Agilex5, Nuvoton NPCM845x, QTI MDM9607, MSM8909, MSM8939, ST STM32MP2 Release tags across repositories: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tag/?h=v2.10 https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tag/?h=v2.10 https://git.trustedfirmware.org/ci/tf-a-ci-scripts.git/tag/?h=v2.10 https://git.trustedfirmware.org/ci/tf-a-job-configs.git/tag/?h=v2.10 https://git.trustedfirmware.org/hafnium/hafnium.git/tag/?h=v2.10 https://git.trustedfirmware.org/ci/hafnium-ci-scripts.git/tag/?h=v2.10 https://git.trustedfirmware.org/ci/hafnium-job-configs.git/tag/?h=v2.10 https://git.trustedfirmware.org/TF-RMM/tf-rmm.git/tag/?h=tf-rmm-v0.4.0 Change logs: https://trustedfirmware-a.readthedocs.io/en/v2.10/change-log.html#id1 https://trustedfirmware-a-tests.readthedocs.io/en/v2.10/change-log.html#ver… https://hafnium.readthedocs.io/en/latest/change-log.html#v2-10 https://tf-rmm.readthedocs.io/en/tf-rmm-v0.4.0/about/change-log.html#v0-4-0 Regards, Olivier.

11 months, 2 weeks

1
1
0 0

Firmware-A v2.10 release code freeze notification

by Olivier Deprez

Hi All, The next release of the Firmware-A bundle of projects tagged v2.10 has an expected code freeze date of Nov, 7th 2023. Refer to the Release Cadence section from TF-A documentation (https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/docs/about…). Closing out the release takes around 6-10 working days after the code freeze. Preparations tasks for v2.10 release should start in coming month. We want to ensure that planned feature patches for the release are submitted in good time for the review process to conclude. As a kind recommendation and a matter of sharing CI resources, please launch CI jobs with care e.g.: -For simple platform, docs changes, or one liners, use Allow-CI+1 label (no need for a full Allow-CI+2 run). -For large patch stacks use Allow-CI+2 at top of the patch stack (and if required few individual Allow+CI+1 in the middle of the patch stack). -Carefully analyze results and fix the change if required, before launching new jobs on the same change. -If after issuing a Allow-CI+1 or Allow-CI+2 label a Build start notice is not added as a gerrit comment on the patch right away please be patient as under heavy load CI jobs can be queued and in extreme conditions it can be over an hour before the Build start notice is issued. Issuing another Allow-CI+1 or Allow-CI+2 label will just result in an additional job being queued. Thanks & Regards, Olivier.

11 months, 4 weeks

1
3
0 0

Hafnium - number of PEs vs number of VCPU

by Pawandeep Oza (QUIC)

Hi, I have a question about hafnium executing PSCI_CPU_ON. So what I observe is, if I define single SP with 2 Physical CPUs & 2 VCPUS defined in SPMC manifest for hypervisor and secure partition, respectively. And when I do have > 2 cpus running in non-secure world, precisely at the moment when Linux brings up 3rd CPU with PSCI_CPU_ON, EL3 PSCI calls will be forwarded to hafnium running in secure EL2. And this is where it hits. And since hafnium doesn't find 3rd CPU defined in manifest it will hit "Dead stop here if no more CPU. */ .global cpu_entry cpu_entry: #if SECURE_WORLD == 1 /* Get number of cpus gathered from DT. */ adrp x3, cpu_count add x3, x3, :lo12:cpu_count ldr w3, [x3] /* Prevent number of CPUs to be higher than supported by platform. */ cmp w3, #MAX_CPUS bhi . /* x0 points to first cpu in cpus array. */ adrp x0, cpus add x0, x0, :lo12:cpus /* Get current core affinity. */ get_core_affinity x1, x2 /* Dead stop here if no more cpu. */ 0: cbz w3, 0b sub w3, w3, #1 /* Get cpu id pointed to by x0 in cpu array. */ ldr x2, [x0, CPU_ID] If I have defined this 3rd physical CPU in hafnium manifest then hafniu proceed further from above code. But then will hit plat_psci_cpu_resume and eventually it will abort with following check CHECK(vcpu_index < vm->vcpu_count); cpu_init: /* Call into C code, x0 holds the CPU pointer. */ bl cpu_main /* Run the vCPU returned by cpu_main. */ bl vcpu_restore_all_and_run it looks like hafnium expects >= the number of physical Pes running at non-secure side to be defined in SPMC manifest file. Also it expects the same number of VCPUs to be defined in manifest file. but my understanding is, there could be number of PEs running at non-secure side could be greater than number of Pes/VCPUs at secure side. But from the code flow of hafnium, I don't think it supports that. Regards, Oza.

1 year

2
1
0 0

Reminder: TrustedFirmware Discord Channel

by don.harbin＠linaro.org

The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.

1 year

1
0
0 0

FFA_CONSOLE_LOG control characters filtering

by Olivier Deprez

Hi, I noticed Hafnium's FFA_CONSOLE_LOG implementation permits writing any ascii character to the UART. In particular the StMM/EDKII print library explicitly adds <CR> characters on any output string, however those are not interpreted by the implementation and directly sent to the UART driver (as opposed to <LF> https://review.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/refs/h… ) . Is it fair adding filtering to omit control characters https://review.trustedfirmware.org/c/hafnium/hafnium/+/27265/2/src/api.c#44… ? Regards, Olivier.

1 year, 1 month

1
0
0 0

Secure interrupt while sending direct response

by Jens Wiklander

Hi all, I'm testing FF-A notifications with OP-TEE and Hafnium. I'm using interrupts from the secure uart as a trigger to set a notification for the normal world. Sometimes when testing I run into: VERBOSE: Secure virtual interrupt not yet serviced by SP 8001. FFA_MSG_SEND_DIRECT_RESP interrupted Hafnium then returns an FFA_ERROR (code -5) as a response to the FFA_MSG_SEND_DIRECT_RESP OP-TEE was just exiting with. After some digging in the code I find a comment at the top of plat_ffa_is_direct_response_interrupted() https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/arch/aarch64/p… /* * A secure interrupt might trigger while the target SP is currently * running to send a direct response. SPMC would then inject virtual * interrupt to vCPU of target SP and resume it. * However, it is possible that the S-EL1 SP could have its interrupts * masked and hence might not handle the virtual interrupt before * sending direct response message. In such a scenario, SPMC must * return an error with code FFA_INTERRUPTED to inform the S-EL1 SP of * a pending interrupt and allow it to be handled before sending the * direct response. */ The specification doesn't mention this as a valid error code for FFA_MSG_SEND_DIRECT_RESP. Is this something we can expect to be added to the specification or at least something OP-TEE has to be prepared to handle regardless? As far as I can tell there's no way of guaranteeing that Hafnium will not return this error for FFA_MSG_SEND_DIRECT_RESP. Even if we were able to execute the smc instruction with secure interrupts unmasked, what if the interrupt is raised just after the smc instruction has been trapped in Hafnium? It is a bit inconvenient as it means saving the registers passed to the smc instruction to be able to restart the smc instruction with the same arguments. It seems we may need to redesign the exit procedure. It would be nice with an example of how an S-EL1 SP is supposed to exit with FFA_MSG_SEND_DIRECT_RESP. Thoughts? Thanks, Jens

1 year, 4 months

3
7
0 0

scaling platform's spmc build

by Olivier Deprez

Hi, As of today, the way to build Hafnium is a single make command to build Hafnium binaries (e.g. SPMC) and tests for all platforms at once. This is an overhead for deployments or integrations downstream that are only interested in building a single platform SPMC image, and are not interested in running Hafnium tests. We have a proposal to help scaling to those deployments where only an SPMC binary for a given platform is required. On the benefits side, this greatly decreases the build time for said deployments and limits build dependencies (e.g. ones within the test framework). There are certainly more complex solutions that we thought about (like segregating individual project git trees beyond 'reference') . However, the proposed change remains simple and keeps the build system backwards compatible with existing deployments. Essentially this introduces a PLATFORM command line build option for the sake of building the SPMC for one given platform (omitting tests). If required it can be combined with the existing PROJECT variable. Example usages: * make [PROJECT=reference] : builds all platforms from 'reference' project including tests (same as today) * make PLATFORM=secure_aem_v8a_fvp_vhe : builds the SPMC targeting FVP from the 'reference' project (omitting tests) * Similarly for Arm solutions, make PLATFORM=secure_tc, make PLATFORM=secure_rd_fremont * make PROJECT=project1 : make all platforms from alternate project 'project1' * make PROJECT=project2 PLATFORM=platform1 : make a single 'platform1' hafnium binary from project 'project2' See the changes: https://review.trustedfirmware.org/c/hafnium/hafnium/+/24822 https://review.trustedfirmware.org/c/hafnium/project/reference/+/24821/ Let us know if the approach sounds reasonable. Regards, Olivier.

1 year, 5 months

2
2
0 0

Manifest bindings

by Jens Wiklander

Hi, https://hafnium.readthedocs.io/en/latest/design/ffa-manifest-binding.html has a nice description of the manifest bindings. The intention is obviously to match the fields in the FF-A specification. However, the "pages-count" field in the bindings is called "page count" in the specification. Any chance of fixing this so the two fields have the same name? Thanks, Jens

1 year, 7 months

2
2
0 0

Compile errors when building Hafnium on Arm devices

by Chenxu Wang

Hi All, I try to build Hafnium v2.8 on Armv8-A device, but I got some compile errors. Here are my building scripts: ``` cd hafnium PATH=$PWD/prebuilts/linux-x64/clang/bin:$PWD/prebuilts/linux-x64/dtc:$PATH make PROJECT=reference ``` Here are some compile errors (The remainings are similar.) ``` [66/3042] CC aem_v8a_fvp_clang/obj/test/arch/arch_test.elf.dlog_test.o FAILED: aem_v8a_fvp_clang/obj/test/arch/arch_test.elf.dlog_test.o clang -MMD -MF aem_v8a_fvp_clang/obj/test/arch/arch_test.elf.dlog_test.o.d -DVM_TOOLCHAIN=0 -DGIC_VERSION=3 -DGICD_BASE=0x2f000000 -DGICR_BASE=0x2f100000 -DGICR_FRAMES=8 -DHEAP_PAGES=180 -DMAX_CPUS=8 -DMAX_VMS=16 -DLOG_LEVEL=LOG_LEVEL_INFO -DENABLE_ASSERTIONS=1 -DPARTITION_MAX_MEMORY_REGIONS=8 -DPARTITION_MAX_DEVICE_REGIONS=8 -DPARTITION_MAX_INTERRUPTS_PER_DEVICE=4 -DPARTITION_MAX_STREAMS_PER_DEVICE=4 -DHF_NUM_INTIDS=64 -DSECURE_WORLD=0 -DENABLE_VHE=0 -I../../inc -I../../inc/vmapi -I../../src/arch/aarch64/inc -Iaem_v8a_fvp_clang/gen/offset_size_header -I../../test/inc -ffunction-sections -fdata-sections -flto -fno-builtin -ffreestanding -fpic -mcpu=cortex-a57+nofp -mstrict-align -mgeneral-regs-only -target aarch64-none-eabi -fcolor-diagnostics -nostdinc -isystem /include -isystem hafnium/inc/system -g -Wall -O2 -Wpedantic -Werror -fstack-protector-all -std=c11 -c ../../test/arch/dlog_test.c -o aem_v8a_fvp_clang/obj/test/arch/arch_test.elf.dlog_test.o In file included from ../../test/arch/dlog_test.c:9: ../../inc/hf/dlog.h:11:10: fatal error: 'stdarg.h' file not found #include <stdarg.h> ^~~~~~~~~~ 1 error generated. [67/3042] CC aem_v8a_fvp_clang/obj/src/vm.vm.o FAILED: aem_v8a_fvp_clang/obj/src/vm.vm.o clang -MMD -MF aem_v8a_fvp_clang/obj/src/vm.vm.o.d -DVM_TOOLCHAIN=0 -DGIC_VERSION=3 -DGICD_BASE=0x2f000000 -DGICR_BASE=0x2f100000 -DGICR_FRAMES=8 -DHEAP_PAGES=180 -DMAX_CPUS=8 -DMAX_VMS=16 -DLOG_LEVEL=LOG_LEVEL_INFO -DENABLE_ASSERTIONS=1 -DPARTITION_MAX_MEMORY_REGIONS=8 -DPARTITION_MAX_DEVICE_REGIONS=8 -DPARTITION_MAX_INTERRUPTS_PER_DEVICE=4 -DPARTITION_MAX_STREAMS_PER_DEVICE=4 -DHF_NUM_INTIDS=64 -DSECURE_WORLD=0 -DENABLE_VHE=0 -I../../inc -I../../inc/vmapi -I../../src/arch/aarch64/inc -Iaem_v8a_fvp_clang/gen/offset_size_header -ffunction-sections -fdata-sections -flto -fno-builtin -ffreestanding -fpic -mcpu=cortex-a57+nofp -mstrict-align -mgeneral-regs-only -target aarch64-none-eabi -fcolor-diagnostics -nostdinc -isystem /include -isystem hafnium/inc/system -g -Wall -O2 -Wpedantic -Werror -fstack-protector-all -std=c11 -c ../../src/vm.c -o aem_v8a_fvp_clang/obj/src/vm.vm.o In file included from ../../src/vm.c:9: ../../inc/hf/vm.h:11:10: fatal error: 'stdatomic.h' file not found #include <stdatomic.h> ^~~~~~~~~~~~~ 1 error generated. ``` Can someone help me? Sincerely, WANG Chenxu

1 year, 7 months

2
2
0 0

New TrustedFirmware Discord Server

by Don Harbin

Hi All, Note you may have received another instance of this note but when I attempted to send to all TF ML's simultaneously it seemed to fail, so sending to each one at a time. Sorry about that. :/ We've created a Discord Server for real time chats/sharing. This solution comes at no cost to the project, is set up with channels for each project, includes a #general channel, and supports direct 1-1 chats between members, all with the goal of improving collaboration between trustedfirmware.org developers. We encourage all to join! :) Instructions for joining can be found on the TF.org FAQ page <https://www.trustedfirmware.org/faq/>. See you all there and please don't hesitate to reach out if you have any questions! Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

1 year, 8 months

1
0
0 0

Fwd: New TrustedFirmware Discord Server

by Don Harbin

Hi All, To all TF maillists in case all aren't yet aware. We've created a Discord Server for real time chats/sharing. This solution comes at no cost to the project, is set up with channels for each project, includes a #general channel, and supports direct 1-1 chats between members, all with the goal of improving collaboration between trustedfirmware.org developers. I've attached a recent screenshot from the #general channel as a sample of the interface and usages. We encourage all to join! :) Instructions for joining can be found on the TF.org FAQ page <https://www.trustedfirmware.org/faq/>. See you all there and please don't hesitate to reach out if you have any questions! Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

1 year, 8 months

1
0
0 0

Hafnium documentation moved to readthedocs

by Olivier Deprez

Hi, This is to inform that the Hafnium documentation is being migrated to its own ReadTheDocs project (from TF-A RTD project): https://hafnium.readthedocs.io This primarily concerns the SPM design doc and threat model. Hafnium documentation changes should target hafnium tree moving forward: https://git.trustedfirmware.org/hafnium/hafnium.git/tree/docs The remaining work over the coming days is: -creating a docs watcher automatically triggering RTD builds. -polishing few leftovers originating from TF-A in migrated documents. -cleanly removing the now duplicated docs from TF-A tree. If any question feel free to reach to the team. Regards, Olivier.

1 year, 9 months

1
0
0 0

multiple SP secondary boot

by 梅建强(禹夜)

Hi, Madhu, Olivier, I am glad that I have the same understanding as both of you about description in FF-A 1.1 18.3.2.1.1. Other points to discuss: >For SPs beyond the first SP, it is up to the normal world driver to invoke FFA_RUN for each secondary vCPU. OK, I basically understand what you said. But I did not use this interface. I need to make it clear for my current implementation for booting secondary vCPUs on SPs beyond the first SP. I connect all vCPUs with the same index on all SP. If there is no vCPU for the current index, just skip to next vCPU with the same index on next SP. So for each index, we can build a vCPU boot list. Later when the nwd boots, upon invocation of PSCI_CPU_ON, each secondary vCPU for the first SP get initialized. Then Hafnium starts the next secondary vCPU on SP beyond the first SP according to the boot list. At present, we have implemented it and tested it without problems. Is this a violation of the FF-A spe, or is there any other problem? >Note I don't believe the current optee linux driver supports the above. >In which case the scenario you describe (multiple optee instances) might not work out of the box. Agree. >Also note there must be other issues like how to handle the secure storage when multiple optee instances exists. Could you describe it in more detail? Thanks for your supports. Regards, Yuye. ------------------------------------------------------------------ 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> 发送时间：2023年7月17日(星期一) 22:29 收件人：Madhukar Pappireddy <Madhukar.Pappireddy(a)arm.com>; 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：hafnium <hafnium(a)lists.trustedfirmware.org>; 高海源(码源) <haiyuan.ghy(a)alibaba-inc.com>; 王一蒙(北见) <wym389994(a)alibaba-inc.com>; 黄明(连一) <hm281385(a)alibaba-inc.com> 主　题：Re: [Hafnium] multiple SP secondary boot Hi, I'm adding to Madhu's reply: At TF-A /secure boot time, before nwd is initialized, the first vCPU for each SP is resumed in sequence by the SPMC. It gives the opportunity for each SP to define a secondary boot address for later resuming of secondary vCPUs. Later when the nwd boots, upon invocation of PSCI_CPU_ON, each secondary vCPU for the first SP get initialized. For SPs beyond the first SP, it is up to the normal world driver to invoke FFA_RUN for each secondary vCPU. Note I don't believe the current optee linux driver supports the above. In which case the scenario you describe (multiple optee instances) might not work out of the box. Also note there must be other issues like how to handle the secure storage when multiple optee instances exists. This might work though if you decide to strip down optee instances to a very minimal set of features, that do not use the same resources. We might help further if you provide a bit more details about the intended setup/scenario. Regards, Olivier. From: Madhukar Pappireddy <Madhukar.Pappireddy(a)arm.com> Sent: 17 July 2023 16:19 To: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com>; Olivier Deprez <Olivier.Deprez(a)arm.com> Cc: hafnium <hafnium(a)lists.trustedfirmware.org>; 高海源(码源) <haiyuan.ghy(a)alibaba-inc.com>; 王一蒙(北见) <wym389994(a)alibaba-inc.com>; 黄明(连一) <hm281385(a)alibaba-inc.com> Subject: RE: [Hafnium] multiple SP secondary boot Hi Yuye, I think the following sentence in the spec is slightly confusing. " For each SP and the SPMC, the Framework assumes that the same entry point address is used for initializing any execution context during a secondary cold boot." I believe what it meant is that the entry point address for any secondary execution context of a particular SP is the same. Note that the entry point of secondary execution contexts belonging to another SP is different than the one previously registered. I can confirm that Hafnium adheres to the above statement. Please note that the cold boot flow is different for secondary cores compared to primary core. On the primary core, SPMC initializes the execution contexts of all SPs( refer to [1]). However, execution contexts of non-primary SP on secondary cores need CPU cycles to be allocated by the NWd scheduler through the FFA_RUN interface(refer to [2]). Hopefully, I was able to answer your questions. [1] https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/arch/aarch64/p… <https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/arch/aarch64/p… > [2] https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/api.c#n1047 <https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/api.c#n1047 > Thanks, Madhu -----Original Message----- From: 梅建强(禹夜) via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: Saturday, July 15, 2023 4:54 AM To: Olivier Deprez <Olivier.Deprez(a)arm.com> Cc: hafnium <hafnium(a)lists.trustedfirmware.org>; 高海源(码源) <haiyuan.ghy(a)alibaba-inc.com>; 王一蒙(北见) <wym389994(a)alibaba-inc.com>; 黄明(连一) <hm281385(a)alibaba-inc.com> Subject: [Hafnium] multiple SP secondary boot Hi, Olivier, There's a problem I'd like to discuss with you. In the FF-A 1.1 18.3.2.1.1 section, it is described as follows: For each SP and the SPMC, the Framework assumes that the same entry point address is used for initializing any execution context during a secondary cold boot. This does not seem to make sense for entry point addresses of multiple SP. In addition, I do not see support for the secondary boot of the multiple SP in the current implementation of Hafnium. If I have multiple optee instances of MP type, how should I design the cold secondary boot flow for multiple SP? My idea is to build a vCPU list with the same index between VMs, just like primary boot flow, as shown in the code below: void vcpu_update_boot(struct vcpu *vcpu) { struct vcpu *current = NULL; struct vcpu *previous = NULL; if (boot_vcpu == NULL) { boot_vcpu = vcpu; return; } current = boot_vcpu; while (current != NULL && current->vm->boot_order <= vcpu->vm->boot_order) { previous = current; current = current->next_boot; } if (previous != NULL) { previous->next_boot = vcpu; } else { boot_vcpu = vcpu; } vcpu->next_boot = current; } Anyone else have some good suggestions? Thanks for the support. Regards, Yuye. -- Hafnium mailing list -- hafnium(a)lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave(a)lists.trustedfirmware.org

1 year, 9 months

2
1
0 0

Question about SMMU S-2 translation

by Chenxu Wang

Hi all, I'd like to ask some questions about how the SMMU S-2 translation works. My questions are as follows: 1. When SMMU performs Stage-2 translation (I mean, fetches the translation table and walks it), is it constrained by GPC on CPU MMU, or GPC on SMMU, or both? For example, assume I configure the PAS of the non-secure SMMU S-2 translation table as "secure/realm/root PAS" in CPU MMU GPC, but "non-secure PAS" in SMMU (e.g., the SMMU for TestEngine on FVP) GPC, will the SMMU successfully perform S-2 translation? Or in another example, assume I configure the PAS of the non-secure SMMU S-2 translation table as "non-secure PAS" in CPU MMU GPC, but "secure/realm/root PAS" in SMMU (e.g., the SMMU for TestEngine on FVP) GPC, will the SMMU successfully perform S-2 translation? 2. Currently I use Hafnium to configure the SMMU. Due to memory limitation, I want to place the SMMU Stage-2 table in DRAM2 (starting from 0x8_8000_0000, but this region is not mapped in Hafnium). Since I think the SMMU S-2 translation is influenced by EL2 S-1 translation (really?), can I turn off the EL2 S-1 translation in Hafnium to avoid this problem? If yes, how to do it? Sincerely, WANG Chenxu

1 year, 9 months

2
1
0 0

multiple SP secondary boot

by 梅建强(禹夜)

Hi, Olivier, There's a problem I'd like to discuss with you. In the FF-A 1.1 18.3.2.1.1 section, it is described as follows: For each SP and the SPMC, the Framework assumes that the same entry point address is used for initializing any execution context during a secondary cold boot. This does not seem to make sense for entry point addresses of multiple SP. In addition, I do not see support for the secondary boot of the multiple SP in the current implementation of Hafnium. If I have multiple optee instances of MP type, how should I design the cold secondary boot flow for multiple SP? My idea is to build a vCPU list with the same index between VMs, just like primary boot flow, as shown in the code below: void vcpu_update_boot(struct vcpu *vcpu) { struct vcpu *current = NULL; struct vcpu *previous = NULL; if (boot_vcpu == NULL) { boot_vcpu = vcpu; return; } current = boot_vcpu; while (current != NULL && current->vm->boot_order <= vcpu->vm->boot_order) { previous = current; current = current->next_boot; } if (previous != NULL) { previous->next_boot = vcpu; } else { boot_vcpu = vcpu; } vcpu->next_boot = current; } Anyone else have some good suggestions? Thanks for the support. Regards, Yuye.

1 year, 9 months

3
2
0 0

Re: optee_benchmark found optee_os function vm_set_ctx() spent much time

by jens.wiklander＠linaro.org

The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.

1 year, 10 months

1
0
0 0

optee_benchmark found optee_os function vm_set_ctx() spent much time

by 高海源(码源)

Hi, Jens, Olivier: I'm a colleague of Yuye, and we are doing optee benchmark and performance optimization. We are using optee_os/optee_client/optee_examples/optee_benchmark version 3.20.0 We think the host API TEEC_InvokeCommand() is sensitive of delay, namely TEE framework like OpenEnclave called ECALL. So we remove all prints in hello_world_ta.c 's TA_InvokeCommandEntryPoint(), host test TEEC_InvokeCommand() 10k times to calculate average time cost. We tested on an ArmV9 data-center server, and we got average time is about 20 us. After using optee_benchmark tool, we found optee_os function user_ta_enter() took most of time. Specially, user_ta_enter() calls ts_push_current_session() and ts_pop_current_session(), then calls vm_set_ctx() twice, which spend 7 us and 2 us respectively, mostly of 20 us delay. I added logs to print some pointers, following is the log in update_current_ctx() I found that many InvokeCommand repeat following pattern E/TC:??? 000 user_ta_enter:155 ====== session 0x8940b5d80 func 2 cmd 4, call ts_push_current_session E/TC:??? 000 update_current_ctx:29 session 0x8940b5d80 tsd 0x89008dd38 tsd->ctx 0x0 ctx 0x8940b5d28 E/TC:??? 000 user_ta_enter:199 ====== session 0x8940b5d80 func 2 cmd 4, call ts_pop_current_session E/TC:??? 000 update_current_ctx:29 session 0x0 tsd 0x89008dd38 tsd->ctx 0x8940b5d28 ctx 0x0 I noticed many InvokeCommand use the same ctx pointer like 0x8940b5d28 My question is: Can many InvokeCommand avoid setting tsd->ctx to Non-NULL ctx, then NULL ctx, to remove the vm_set_ctx() cost of time? Is there any optimization method, likely many InvokeCommand in the same session reuse the same Non-NULL ctx, to reduce average delay of ECALLs? Thanks. Best wishes. ------------------------------------------------------------------ 发件人：Olivier Deprez<Olivier.Deprez(a)arm.com> 日　期：2023年05月30日 21:07:20 收件人：Jens Wiklander<jens.wiklander(a)linaro.org>; 梅建强(禹夜)<meijianqiang.mjq(a)alibaba-inc.com> 抄　送：op-tee<op-tee(a)lists.trustedfirmware.org>; hafnium<hafnium(a)lists.trustedfirmware.org>; 黄明<hm281385(a)alibaba-inc.com> 主　题：Re: optee_benchmark pmccfiltr_el0 Hi Yuye, In general the consensus is that PMU cycle and event counting in EL3 & secure world has to be disabled. I gather this is to avoid probing crypto algorithms timings, or leverage cache-based timing side channels (e.g. spectre). See Arm ARM D11.5.3 Prohibiting event and cycle counting Cycle and event counting is disabled by: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/include/ar… <https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/include/ar… > See also https://trustedfirmware-a.readthedocs.io/en/latest/process/security-hardeni… <https://trustedfirmware-a.readthedocs.io/en/latest/process/security-hardeni… > Note there are various knobs depending on implemented architecture extensions FEAT_PMUv3 / FEAT_PMUv3pX / FEAT_Debugv8p2 You could try to permit cycle counting in the secure world for the sake of a one shot experiment, but note that this has never been tried, and this should probably not be productized as things stand. Regards, Olivier. From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> Sent: 30 May 2023 10:38 To: Jens Wiklander <jens.wiklander(a)linaro.org>; Olivier Deprez <Olivier.Deprez(a)arm.com> Cc: op-tee <op-tee(a)lists.trustedfirmware.org>; hafnium <hafnium(a)lists.trustedfirmware.org>; 黄明(连一) <hm281385(a)alibaba-inc.com> Subject: optee_benchmark pmccfiltr_el0 Hi, It is confirmed that the problem is related to the pmu register configuration and that pmccntr_el0 can be read at any exception level. Regards, Yuye. ------------------------------------------------------------------ 发件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 发送时间：2023年5月26日(星期五) 16:59 收件人：Jens Wiklander <jens.wiklander(a)linaro.org>; Olivier Deprez <olivier.deprez(a)arm.com> 抄　送：op-tee <op-tee(a)lists.trustedfirmware.org>; hafnium <hafnium(a)lists.trustedfirmware.org>; 黄明(连一) <hm281385(a)alibaba-inc.com> 主　题：optee_benchmark pmccfiltr_el0 Hi, Jens, Olivier, In case of that optee runs at sel1 and hafnium runs at sel2, we want to test benchmark by executing the following command at optee_benchmark path: ./out/benchmark ../optee_examples/out/ca/optee_example_hello_world After entering into the benchmark pta, the bm_timestamp function attempts to read the pmccfiltr_el0 register. In cold boot, the following code will be executed during hafnium initialization: vm->arch.trapped_features |= HF_FEATURE_PERFMON; This will prevent the secondary vm from accessing the performance counter registers. We remove the code, the bm_timestamp function can read pmccfiltr_el0 without trapping into hafnium. But the value of pmccfiltr_el0 remains unchanged and cannot be counted. We tried to read the register in hafnium and found that there was no change either. In contrast, in the normal world, pmccfiltr_el0 counts normally. Is it related to the pmu register configuration or does sel1 not support the pmccfiltr_el0 count at present? Thanks for the support. Regards, Yuye.

1 year, 10 months

1
0
0 0

Hafnium with QEMU and OP-TEE

by Jens Wiklander

Hi, I'm testing with Hafnium as SPMC at S-EL2 and OP-TEE as an SP at S-EL1 on QEMU v7.0.0. I've run into a few problems and fixed most of them. I believe the setup is similar to what Shiju is using in this mail thread https://lists.trustedfirmware.org/archives/list/hafnium@lists.trustedfirmwa… My setup can be duplicated with: repo init -u https://github.com/jenswi-linaro/manifest.git -m qemu_v8.xml \ -b qemu_sel2 repo sync -j8 (cd hafnium && git submodule init && git submodule update) cd build make -j8 toolchains make -j8 all make run-only With this xtest -x 1034 passes, xtest 1034 often causes ERROR: Data abort: pc=0xe1198b8, esr=0x96000006, ec=0x25, far=0x9c Panic: EL2 exception Xtest runs dreadfully slow, I haven't investigated why yet, but at least it works. This is based on patches provided by Olivier at: [1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/16412/2 [2] https://review.trustedfirmware.org/c/hafnium/hafnium/+/16323/7 I've also encountered the problem cache maintenance problem Shiju described in the mail thread above: NOTICE: Trapped access to system register write: op0=1, op1=0, crn=7, crm=14, op2=2, rt=11. It can be worked around by compiling OP-TEE with CFG_CORE_WORKAROUND_NSITR_CACHE_PRIME=n. I'm pretty sure we do dcache clean+inv elsewhere so I'm surprised it fails here. Is Hafnium expected to block dcache clean+inv? For Hafnium I've added two patches on top of [2], available at https://github.com/jenswi-linaro/hafnium/tree/qemu_sel2: - 79b4d2cbe06e SPMC: add missing ME initialization for secondary cores - 659c79d5eacf feat(mm): fix FEAT_LPA workaround For TF-A I've added a few patches on top of [1], available at https://github.com/jenswi-linaro/arm-trusted-firmware/tree/qemu_sel2: - a040396cae9e feat(qemu): add tos-fw-config for sel2 spmc - 4f7d91723485 fix(qemu): change TOS_FW_CONFIG_NAME value - fbfc9a222c7f spmd_smc_handler() add s/ns state to SMC traces - ca65081b9cdc feat(sptool): add dependency to SP image - b1e1b46a0680 fix(qemu): restore code to added needed psci nodes For OP-TEE I've also added a few patches, available at https://github.com/jenswi-linaro/optee_os/tree/qemu_sel2: - 1057def23777 plat-vexpress: sel2 spmc: update for hafnium - f18a54ed3524 core: ffa: use hvc instead of smc with S-EL2 - d18bbc92f7c1 core: mobj_ffa_add_pages_at() trust addresses from SPMC There's also one patch for QEMU on top of v7.0.0, available at: https://github.com/jenswi-linaro/qemu/tree/qemu_sel2 - 0c1e39672dcb Read PS bits from VTCR_EL2 The QEMU problem is fixed in v.7.1.0, but I can't get that version of QEMU to work with TF-A. I guess it's because of yet another new CPU feature since I'm running with "-cpu max". I'll try to upstream the Hafnium and TF-A patches that make sense on their own. What's the plan with the interrupt controller? How will OP-TEE be able to handle secure interrupts? The hafnium git pulls in a few git submodules and even the source code for a Linux kernel. I guess this is useful in your internal CI setup, but when used isolated as in my setup it makes no sense at all. It would also be nice to be able to build with an external toolchain. I hope this is a temporary situation, I don't see why Hafnium should be pickier about toolchain than for instance TF-A. Speaking of building, I haven't been able to figure out how to build only for the QEMU variant I need so right now I'm building for everything and that takes a bit longer than necessary. I'm going to maintain the setup above as long as it's relevant to me. I may add more patches on the branches or even rebase as needed. So if anyone is using this, keep in mind that my branches may change without warning. Thanks, Jens

1 year, 10 months

4
22
0 0

optee_benchmark pmccfiltr_el0

by 梅建强(禹夜)

Hi, Olivier, That makes it clearer to me. Thanks a lot. Regards, Yuye. ------------------------------------------------------------------ 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> 发送时间：2023年5月30日(星期二) 21:07 收件人：Jens Wiklander <jens.wiklander(a)linaro.org>; 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：op-tee <op-tee(a)lists.trustedfirmware.org>; hafnium <hafnium(a)lists.trustedfirmware.org>; 黄明(连一) <hm281385(a)alibaba-inc.com> 主　题：Re: optee_benchmark pmccfiltr_el0 Hi Yuye, In general the consensus is that PMU cycle and event counting in EL3 & secure world has to be disabled. I gather this is to avoid probing crypto algorithms timings, or leverage cache-based timing side channels (e.g. spectre). See Arm ARM D11.5.3 Prohibiting event and cycle counting Cycle and event counting is disabled by: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/include/ar… <https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/include/ar… > See also https://trustedfirmware-a.readthedocs.io/en/latest/process/security-hardeni… <https://trustedfirmware-a.readthedocs.io/en/latest/process/security-hardeni… > Note there are various knobs depending on implemented architecture extensions FEAT_PMUv3 / FEAT_PMUv3pX / FEAT_Debugv8p2 You could try to permit cycle counting in the secure world for the sake of a one shot experiment, but note that this has never been tried, and this should probably not be productized as things stand. Regards, Olivier. From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> Sent: 30 May 2023 10:38 To: Jens Wiklander <jens.wiklander(a)linaro.org>; Olivier Deprez <Olivier.Deprez(a)arm.com> Cc: op-tee <op-tee(a)lists.trustedfirmware.org>; hafnium <hafnium(a)lists.trustedfirmware.org>; 黄明(连一) <hm281385(a)alibaba-inc.com> Subject: optee_benchmark pmccfiltr_el0 Hi, It is confirmed that the problem is related to the pmu register configuration and that pmccntr_el0 can be read at any exception level. Regards, Yuye. ------------------------------------------------------------------ 发件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 发送时间：2023年5月26日(星期五) 16:59 收件人：Jens Wiklander <jens.wiklander(a)linaro.org>; Olivier Deprez <olivier.deprez(a)arm.com> 抄　送：op-tee <op-tee(a)lists.trustedfirmware.org>; hafnium <hafnium(a)lists.trustedfirmware.org>; 黄明(连一) <hm281385(a)alibaba-inc.com> 主　题：optee_benchmark pmccfiltr_el0 Hi, Jens, Olivier, In case of that optee runs at sel1 and hafnium runs at sel2, we want to test benchmark by executing the following command at optee_benchmark path: ./out/benchmark ../optee_examples/out/ca/optee_example_hello_world After entering into the benchmark pta, the bm_timestamp function attempts to read the pmccfiltr_el0 register. In cold boot, the following code will be executed during hafnium initialization: vm->arch.trapped_features |= HF_FEATURE_PERFMON; This will prevent the secondary vm from accessing the performance counter registers. We remove the code, the bm_timestamp function can read pmccfiltr_el0 without trapping into hafnium. But the value of pmccfiltr_el0 remains unchanged and cannot be counted. We tried to read the register in hafnium and found that there was no change either. In contrast, in the normal world, pmccfiltr_el0 counts normally. Is it related to the pmu register configuration or does sel1 not support the pmccfiltr_el0 count at present? Thanks for the support. Regards, Yuye.

1 year, 11 months

1
0
0 0

optee_benchmark pmccfiltr_el0

by 梅建强(禹夜)

Hi, It is confirmed that the problem is related to the pmu register configuration and that pmccntr_el0 can be read at any exception level. Regards, Yuye. ------------------------------------------------------------------ 发件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 发送时间：2023年5月26日(星期五) 16:59 收件人：Jens Wiklander <jens.wiklander(a)linaro.org>; Olivier Deprez <olivier.deprez(a)arm.com> 抄　送：op-tee <op-tee(a)lists.trustedfirmware.org>; hafnium <hafnium(a)lists.trustedfirmware.org>; 黄明(连一) <hm281385(a)alibaba-inc.com> 主　题：optee_benchmark pmccfiltr_el0 Hi, Jens, Olivier, In case of that optee runs at sel1 and hafnium runs at sel2, we want to test benchmark by executing the following command at optee_benchmark path: ./out/benchmark ../optee_examples/out/ca/optee_example_hello_world After entering into the benchmark pta, the bm_timestamp function attempts to read the pmccfiltr_el0 register. In cold boot, the following code will be executed during hafnium initialization: vm->arch.trapped_features |= HF_FEATURE_PERFMON; This will prevent the secondary vm from accessing the performance counter registers. We remove the code, the bm_timestamp function can read pmccfiltr_el0 without trapping into hafnium. But the value of pmccfiltr_el0 remains unchanged and cannot be counted. We tried to read the register in hafnium and found that there was no change either. In contrast, in the normal world, pmccfiltr_el0 counts normally. Is it related to the pmu register configuration or does sel1 not support the pmccfiltr_el0 count at present? Thanks for the support. Regards, Yuye.

1 year, 11 months

2
1
0 0

optee_benchmark pmccfiltr_el0

by 梅建强(禹夜)

Hi, Jens, Olivier, In case of that optee runs at sel1 and hafnium runs at sel2, we want to test benchmark by executing the following command at optee_benchmark path: ./out/benchmark ../optee_examples/out/ca/optee_example_hello_world After entering into the benchmark pta, the bm_timestamp function attempts to read the pmccfiltr_el0 register. In cold boot, the following code will be executed during hafnium initialization: vm->arch.trapped_features |= HF_FEATURE_PERFMON; This will prevent the secondary vm from accessing the performance counter registers. We remove the code, the bm_timestamp function can read pmccfiltr_el0 without trapping into hafnium. But the value of pmccfiltr_el0 remains unchanged and cannot be counted. We tried to read the register in hafnium and found that there was no change either. In contrast, in the normal world, pmccfiltr_el0 counts normally. Is it related to the pmu register configuration or does sel1 not support the pmccfiltr_el0 count at present? Thanks for the support. Regards, Yuye.

1 year, 11 months

1
0
0 0

splitting NS/S IPA spaces

by Olivier Deprez

Hi Jens, I have a couple of Hafnium changes implementing the use of VSTTBR_EL2/VTTBR_EL2 to split an SP IPA into secure and non-secure IPA spaces. They're very much in experimental stage so difficult to share just now (I will do some time later in February). However I'd like to report some possible issue observed with qemu. Essentially, when normal world driver inits, it performs a first share operation for a single NS page: INFO: 1> 1 0 FFA_MEM_SHARE_32(84000073) 50 50 0 0 0 0 0 [...] VERBOSE: Marked sending complete. Current share states: SHARE 0x0 (from VM 0x0, attributes 0x6f (NS), flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 0 retrieved, sender's original mode: 0x87 INFO: 1< 1 0 FFA_SUCCESS_32(84000061) 0 0 0 0 0 0 0 INFO: 1> 1 0 FFA_MSG_SEND_DIRECT_REQ_32(8400006f) 8001 0 80000000 0 0 0 0 E/TC:1 0 mobj_ffa_get_by_cookie:387 Populating mobj from rx buffer, cookie 0 Retrieve operation happens: E/TC:1 0 spmc_retrieve_req:1415 spmc_retrieve_req enter. INFO: 1> 1 8001 FFA_MEM_RETRIEVE_REQ_32(84000074) 30 30 0 0 0 0 0 Current share states: SHARE 0x0 (from VM 0x0, attributes 0x6f (NS), flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 0 retrieved, sender's original mode: 0x87 Current share states: SHARE 0x0 (from VM 0x0, attributes 0x6f (NS), flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x87 INFO: 1< 1 8001 Unknown(84000075) 50 50 0 0 0 0 0 Hafnium maps the NS page into OP-TEE's S2 page tables rooted to by VTTBR_EL2 0: e178003 S 1: e179003 S f: e17a003 S 186: 240000041f867ff NS (similar dump from VSTTBR_EL2 show OP-TEE secure pages properly mapped) OP-TEE then maps the page in its S1 PTs as NS: E/TC:1 0 spmc_retrieve_req:1428 spmc_retrieve_req exit. E/TC:1 0 thread_spmc_populate_mobj_from_rx:1506 thread_spmc_populate_mobj_from_rx exit. E/TC:1 0 set_pages:1461 set_pages 0 addr 41f86000 count 1 E/TC:1 0 mobj_ffa_add_pages_at:220 mobj_ffa_add_pages_at is_ns 0 INFO: 1> 1 8001 FFA_RX_RELEASE_32(84000065) 0 0 0 0 0 0 0 INFO: 1< 1 8001 FFA_SUCCESS_32(84000061) 0 0 0 0 0 0 0 E/TC:1 0 ffa_inc_map:566 ffa_inc_map addr fa00000 pages 0x90000000e3eadd0 sz 4096 D/TC:1 0 core_mmu_xlat_table_alloc:526 xlat tables used 4 / 5 A page fault is hit when OP-TEE accesses the page from its VA: WARNING: Stage-2 page fault: pc=0xe30b764, vmid=0x8001, vcpu=1, vaddr=0xfa0001c, ipaddr=0x41f8601c, mode=0x1 0x40000000000007c This issue is not observed with the TC2 FVP and similar Hafnium+OP-TEE SW stack, at the same point of initialization. So it seems qemu is not doing the translation properly from VTTBR_EL2 for a page mapped NS by OP-TEE (hence NS IPA space). Who should I report this problem to? Regards, Olivier.

1 year, 11 months

3
5
0 0

TF-A V2.9 Bundle Release

by Joanna Farley

Hi All, We are pleased to announce the formal release of Trusted Firmware-A version 2.9 bundle of project deliverables. This includes Trusted Firmware-A, Trusted Firmware-A Tests, Hafnium and TF-A OpenCI Scripts/Jobs 2.9 releases involving the tagging of multiple repositories. Aligned but not yet part of the release is Trusted Firmware-A Realm Management Monitor v0.3.0. These went live on 23rd May 2023. I would like to thank all of the contributors for their excellent work and achievements since the last release. Thanks Joanna Notable Features of the Version 2.9 Release are as follows: TF-A/EL3 Root World * New Features: * Support for PSCI OS initiated mode * Architecture feature support for FEAT_TCR2, FEAT_GCS, FEAT_HCX, FEAT_SME2, FEAT_PIE/POR, FEAT_MPAM. * System registers access trap handler * Introduction to dynamic detection of features * Refactoring: * Context management * RAS extension exception handling and crash reporting. * Distinguish between BL2 as TF-A entry point or BL2 running at EL3 exception level. * General Support * CPU Support for Chaberton and Blackhawk for TC2023 * Eighteen (18) Errata Mitigations for Cortex X2/X3/A710/A510/A78/A78C and Neoverse N2/V1 family CPU’S * Errata Management Firmware Interface implementation supported for version 1.0 of the public specification TF-A Boot BL1/BL2 * New Feature/Support * Support for Trusted Boot rooted into RSS RoT on TC2022 platform. * Support for PSA attestation scheme with Measured Boot rooted into RSS on TC2022 platform * Migration to mbedTLS 3.x as the default cryptography library retaining backwards compatibility with mbedTLS 2.x * Improvements and hardening of Arm CCA boot and attestation support. * Hardening efforts in the X.509 certificate parser, including a security fix (TFV-10 CVE-2022-47630) Hafnium/SEL2 SPM * FF-A v1.2 ALP0 Specification Early Adoption Support * Implemented ppartition info get ABI using GP registers. * Group0 secure interrupt handling delegation. * Improved console log ABI. * FF-A v1.1 REL0 Specification Support * Interrupt handling (S-EL0 partition signalling, added action to Other-S-Int, allow a physical interrupt to be routed to a specified PE). * Memory sharing (structures updates supporting FF-A backwards compatibility, share/lend/donate memory to multiple borrowers, normal/secure fragmented memory sharing). * Power management (events relayed to the SPMC and removed limitations). * Indirect messaging (buffer synchronization and ownership transfer rules). * General Support * SPMC manifest to declare non-secure and secure system memory address ranges. * Hardened SP manifest memory regions boot time validation. * CI migration to LLVM/clang 15.0.6 * Removal of non-VHE build and test configurations. * Added EL3 SPMC test configurations using the Hafnium's CI infrastructure. TF-A Tests * New Test Support * Errata Management Firmware Interface testing * FF-A v1.1 feature testing * Realm Management Extension feature testing * New Architecture Specific feature testing related to v8.8 * 1 new platform port (RD-N2-Cfg3) TF-RMM/REL2 * New Feature/Support * Added support to create Realms which can make use of SVE, if present in hardware. * Refactor and improved the Stage 1 translation table library lib/xlat API to better fit RMM usage. * Add PMU support for Realms as described by RMM v1.0 Beta0 specification. * Support getting DRAM info from the Boot manifest dynamically at runtime. * RMM can now support the 2nd DDR bank on FVP * Define a unit test framework using CppUTest for RMM. * Added unit tests for granule, slot-buffer and Stage 1 translation table lib xlat. * Improvements to fake-host and unit tests framework. * Build improvements in RMM Platform Support * 1 new platform added, the Allwinner T507 SoC * 26 platforms updated from 14 providers * 17 different driver updates OpenCI * First release done solely relying on Trustedfirmware.org OpenCI Patch Statistics Across all Repositories * 1403 Patches merged since v2.8 November 2022 release Please refer to the TF-A [1], Hafnium [2] and TF-A Tests [3] changelogs for the complete summary of changes from the previous release. TF-A [4], TF-A Test [5], Hafnium [6], TF-A OpenCI Scripts [7] and TF-A OpenCI Jobs [8] repositories are available along with the compatible TF-RMM repository [9] and changelog [10]. [1] https://trustedfirmware-a.readthedocs.io/en/v2.9/change-log.html#id1 [2] https://review.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/HEAD/d… [3] https://trustedfirmware-a-tests.readthedocs.io/en/v2.9/change-log.html#vers… [4] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tag/?h=v2.9 [5] https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tag/?h=v2.9 [6] https://git.trustedfirmware.org/hafnium/hafnium.git/tag/?h=v2.9 [7] https://git.trustedfirmware.org/ci/tf-a-ci-scripts.git/tag/?h=v2.9 [8] https://git.trustedfirmware.org/ci/tf-a-job-configs.git/tag/?h=v2.9 [9] https://git.trustedfirmware.org/TF-RMM/tf-rmm.git/tag/?h=tf-rmm-v0.3.0 [10] https://tf-rmm.readthedocs.io/en/tf-rmm-v0.3.0/about/change-log.html#v0-3-0

1 year, 11 months

1
0
0 0

optee hot update

by 梅建强(禹夜)

Hi, Olivier, I have a few questions for your reply. > [OD] Unfortunately Hafnium is not designed for this. I can see few places where things can go wrong, but firstly as you highlighted in another thread, the init should take place on the same core that was used for initializing (aka the primary core). As I understand, the optee load smc can happen on any core as it's launched from a nwd/linux thread running on any core. This is not only a hafnium limitation, I guess OP-TEE would have the same problem further on, as it also must go through the primary core init on physical boot/primary core. Then it would require the normal world to coordinate the secondary core init. for all cores, the same way as it happens in the cold boot phase by duplicating TF-A's PSCI boot flows. I have done a restrained test for optee hot update. By setting grub.cfg, only one physical core is enabled, in which case hafnium and optee could be initialized normally. But after spmd returning to the driver, the optee driver hang in optee_ffa_probe and cannot exit normally. Maybe hafnium changes the state of some registers during initialization. And these registers may be shared with the el2 host os kernel. What issues do you think I may have overlooked? 1. Primary core and secondary core should be concepts during boot phase. At runtime, primary core and secondary core should not be distinguished. Does this mean that I can initialize the core of nwd/linux running thread with hafnium as the primary core? This may require hafnium or Atf to do some initialization for the core. 2. Can a hafnium implement an optee hot update without fully initializing itself but with a few initializing actions for optee, such as manifest_init? 3. For all cores, the same way as it happens in the cold boot phase by duplicating TF-A's PSCI boot flows. Agree with you. > [OD] No this isn't supported and not in our roadmap. As things stand with upstream components, it would be preferable going with a regular FW update flow (but requires a machine reboot). 1. When you say upstream_components, do you mean bl2u_image, ns_bl2u_image things like that or something else in other spec? Although this is an alternative update solution, machine reboot does not have the significance and advantages that belong to the hot update. Thanks for your support. Regards, Yuye. ------------------------------------------------------------------ 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> 发送时间：2023年5月9日(星期二) 23:54 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：hafnium <hafnium(a)lists.trustedfirmware.org> 主　题：Re: optee hot update Hi Yuye, See few comments inline [OD]. Regards, Olivier. From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> Sent: 06 May 2023 09:34 To: Olivier Deprez <Olivier.Deprez(a)arm.com> Cc: hafnium <hafnium(a)lists.trustedfirmware.org> Subject: optee hot update Hi, Olivier, As I can see in the Hafnium code, Hafnium performs a number of one-time functions at boot phase, like one_time_init_mm and one_time_init. I want to initialize Hafnium again from image_entry and then initialize optee after optee is updated. I wonder if there are any problems with this flow for hafnium at runtime phase. [OD] Unfortunately Hafnium is not designed for this. I can see few places where things can go wrong, but firstly as you highlighted in another thread, the init should take place on the same core that was used for initializing (aka the primary core). As I understand, the optee load smc can happen on any core as it's launched from a nwd/linux thread running on any core. This is not only a hafnium limitation, I guess OP-TEE would have the same problem further on, as it also must go through the primary core init on physical boot/primary core. Then it would require the normal world to coordinate the secondary core init. for all cores, the same way as it happens in the cold boot phase by duplicating TF-A's PSCI boot flows. Does Hafnium provide any interface to boot optee directly at runtime phase, and if not, how do you think it makes sense to modify the above flow? [OD] No this isn't supported and not in our roadmap. As things stand with upstream components, it would be preferable going with a regular FW update flow (but requires a machine reboot). Does anyone else know how to fix it? Thanks for your support. Regards, Yuye.

1 year, 12 months

1
0
0 0

optee hot update

by 梅建强(禹夜)

Hi, Olivier, As I can see in the Hafnium code, Hafnium performs a number of one-time functions at boot phase, like one_time_init_mm and one_time_init. I want to initialize Hafnium again from image_entry and then initialize optee after optee is updated. I wonder if there are any problems with this flow for hafnium at runtime phase. Does Hafnium provide any interface to boot optee directly at runtime phase, and if not, how do you think it makes sense to modify the above flow? Does anyone else know how to fix it? Thanks for your support. Regards, Yuye.

1 year, 12 months

2
1
0 0

TF-A v2.9 Release Schedule

by Joanna Farley

TF-A Community, This is to notify that we are planning to target the Trusted Firmware-A 2.9 release during the middle of May 2023 as part of the regular 6 month cadence. The aim is to consolidate all TF-A work since the 2.8 release. As part of this, a release candidate tag is targeted to be created and release activities commence from 10th May 2023 across all TF-A repositories. Essentially we will not merge any major enhancements from this date until the release is made. Please ensure any patches desired to make the 2.9 release are submitted in good time to be complete by 9th May 2023. Any major enhancement patches still open after that date will not be merged until after the release. This will involve the various repositories making up the broader TF-A project including the TF-A mainline, TF-A Tests, Hafnium, TF-A CI Scripts and TF-A CI Job. In addition a TF-RMM repository release will be made that is compatible with v2.9. We will endeavour minimise the disruption on patch merging and complete release activities ASAP after we start normally completing within 7-10 working days. Regards Joanna Farley

2 years

1
0
0 0

hyp_loaded

by 梅建强(禹夜)

Hi, Jens, In our scenario, we need to update the entire optee image, so booting the updated image must be done by hafnium (sel2 spmc). Regards, Yuye. ------------------------------------------------------------------ 发件人：Jens Wiklander <jens.wiklander(a)linaro.org> 发送时间：2023年4月24日(星期一) 19:52 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org> 主　题：Re: [Hafnium] hyp_loaded Hi Yuye, On Mon, Apr 24, 2023 at 1:32 PM 梅建强(禹夜) via Hafnium <hafnium(a)lists.trustedfirmware.org> wrote: > > Hi, Olivier, > The question in the last email may be a little confusing. > I want to change the question, do you know how implement that hafnium boot optee at runtime? > I think there should be less initialization than the first boot. If this is just to be able to load OP-TEE late during boot it might be more useful to implement this in OP-TEE itself, that way it can be used in more or less any environment supported by OP-TEE. Cheers, Jens > Thanks a lot for the support. > Regards, > Yuye. > ------------------------------------------------------------------ > 发件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > 发送时间：2023年4月23日(星期日) 16:36 > 收件人：Olivier Deprez <Olivier.Deprez(a)arm.com> > 抄送：hafnium <hafnium(a)lists.trustedfirmware.org> > 主题：hyp_loaded > Hi, Olivier, > I would like to ask you about the solution to the optee hot update. > In the current scenario, we have updated the optee core image after REE OS is booted. > And we want to re-initialize hafnium and optee in the boot flow. > So we re-execute the function spmd_init() in the ATF and enter into hafnium succesfully. > However, we find that function plat_psci_cpu_resume() has some problems with hafnium entering into optee. > We add some debug near the following code. > dlog("[Hafnium] cpu_index:%x, cpu->id:%x\n",cpu_index(c), c->id); > vcpu = vm_get_vcpu(vm, (vm->vcpu_count == 1) ? 0 : cpu_index(c)); > vcpu_locked = vcpu_lock(vcpu); > Because the tee_driver that initiate a optee update request is running on a random cpu after REE OS is booted, > cpu_id here is a random id, but cpu_index is still 0, like the print: > [Hafnium] cpu_index:0, cpu->id:2d0000 > which seems to affect optee booting and the system will hang before hafnium enter into optee. > I am not familiar with the vcpu switching. > Do you know how to solve this problem? > Or should we directly select the secondary core boot way instead of the primary on the current physical cpu? > Regards, > Yuye. > ------------------------------------------------------------------ > 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> > 发送时间：2023年2月3日(星期五) 18:10 > 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > 抄送：hafnium <hafnium(a)lists.trustedfirmware.org>; raghu.ncstate <raghu.ncstate(a)icloud.com>; Achin Gupta <Achin.Gupta(a)arm.com>; Gyorgy Szing <Gyorgy.Szing(a)arm.com> > 主题：Re: hyp_loaded > Hi Yuve, > I believe we missed to reply to: > > In addition, the OPTEE community seems to be discussing the issue of Post-boot loading OPTEE. > Does anyone know whether these two issues can be regarded as the same kind of issue? > From my perspective, this is a fundamentally different approach to how OP-TEE is loaded and booted. > And actually a quite orthogonal model of trust compared to usual TF-A deployments. > This requires an enforcement of the bootloader and kernel to verify the filesystem contents hence this has additional assumptions about the system integration. > So I believe this a different 'problem' addressed, if compared to the generic firmware update topic. > Regards, > Olivier. > From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > Sent: 19 January 2023 18:30 > To: Gyorgy Szing <Gyorgy.Szing(a)arm.com>; Achin Gupta <Achin.Gupta(a)arm.com>; raghu.ncstate <raghu.ncstate(a)icloud.com>; Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org> > Cc: nd <nd(a)arm.com> > Subject: 回复：[Hafnium] 回复：回复：回复：回复：hyp_loaded > Hi, George > Since I have to go home for the Spring Festival, I have delayed two days for the reply to this issue.Sorry about that. > > would it be possible for you to instead of extending HF with SP loading capability, implement a loader SP instead? > Yes, we have recognized that method of extanding HF is not only complex but also against the HF design principle. > We have reanalysed the SP loading. Now we think that BL31 may be a good choice to replace the HF for loading the OPTEE at runtime phase. > And it seems that we can benefit from some implementation of image loading in BL2 in TF-A. > In addition, the OPTEE community seems to be discussing the issue of Post-boot loading OPTEE. > Does anyone know whether these two issues can be regarded as the same kind of issue? > Regards, > Yuye > ------------------------------------------------------------------ > 发件人：Gyorgy Szing <Gyorgy.Szing(a)arm.com> > 发送时间：2023年1月17日(星期二) 18:27 > 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com>; Achin Gupta <Achin.Gupta(a)arm.com>; raghu.ncstate <raghu.ncstate(a)icloud.com>; Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org> > 抄送：nd <nd(a)arm.com> > 主题：RE: [Hafnium] 回复：回复：回复：回复：hyp_loaded > Hi Yuye, > would it be possible for you to instead of extending HF with SP loading capability, implement a loader SP instead? This SP would be loaded by BL2 instead of OP-TEE, and would be able to "replace itself" with the real payload of the SP later (in this case OP-TEE). For that it could either host a storage driver, if boot-time loading is needed, or if storage is only accessible from the SWd, or allow the NWd to send the payload if run-time loading is more beneficial. > The main benefit of this approach would be to keep extra complexity out of HF, and to run the loader compartmentalized (least privilege principle). > This might need some changes in HF, and will need a new treat model and threat mitigations. But I think the same is true if the loader is implemented in HF. > Experts any thoughts? Would this be feasible? Would this be a good approach? > /George > -----Original Message----- > From: 梅建强(禹夜) via Hafnium <hafnium(a)lists.trustedfirmware.org> > Sent: 17 January 2023 02:42 > To: Achin Gupta <Achin.Gupta(a)arm.com>; raghu.ncstate <raghu.ncstate(a)icloud.com>; Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org> > Subject: [Hafnium] 回复：回复：回复：回复：hyp_loaded > Hi, > > If you are looking at changing the OP-TEE image at runtime then this is effectively a firmware update right? > Yes. > > Are you planning to add this support to Hafnium too or will this be done on a separate controller? > Yes, we intend to use Hafnium to support it now. > regards, > yuye > ------------------------------------------------------------------ > 发件人：Achin Gupta <Achin.Gupta(a)arm.com> > 发送时间：2023年1月17日(星期二) 05:18 > 收件人：raghu.ncstate <raghu.ncstate(a)icloud.com>; Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org>; 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > 主题：Re: [Hafnium] 回复：回复：回复：hyp_loaded > Hi Yuye, > If you are looking at changing the OP-TEE image at runtime then this is effectively a firmware update right? Apart from storage drivers you would need some support for verifying or measuring the image as well. Are you planning to add this support to Hafnium too or will this be done on a separate controller? > cheers, > Achin > From: 梅建强(禹夜) via Hafnium <hafnium(a)lists.trustedfirmware.org> > Sent: 16 January 2023 17:50 > To: raghu.ncstate <raghu.ncstate(a)icloud.com>; Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org> > Subject: [Hafnium] 回复：回复：回复：hyp_loaded > Hi, > In our current boot flow, we have implemented TF-A BL2 to load OPTEE. > However, at runtime, this static loading method is not convenient for updating OPTEE, considering that we may make some changes to OPTEE on demand. > So we wanted to load OPTEE with a dynamic loading solution, and Hafnium would be a good runtime component, since TF-A BL2 is not a runtime component. > Before I do that, I want to implement Hafnium's static loading of OPTEE. > If you have any questions about the above ideas or other solutions to this query, glad to discuss with you. > Thanks for support. > regards, > yuye > ------------------------------------------------------------------ > 发件人：raghu.ncstate <raghu.ncstate(a)icloud.com> > 发送时间：2023年1月17日(星期二) 01:15 > 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com>; Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org> > 抄送：赵哲(为哲) <weizhe.zz(a)alibaba-inc.com> > 主题：RE: [Hafnium] 回复：回复：hyp_loaded > It would be good if consider using TF-A BL2 or equivalent to load OPTEE, that runs before hafnium, which is really the secure loader. I would recommend against hafnium including a loader, to keep it simple (and replicate the same functionality of another component), although that might be the right approach for your platform. > -----Original Message----- > From: 梅建强(禹夜) via Hafnium <hafnium(a)lists.trustedfirmware.org> > Sent: Monday, January 16, 2023 8:37 AM > To: Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org> > Cc: 赵哲(为哲) <weizhe.zz(a)alibaba-inc.com> > Subject: [Hafnium] 回复：回复：hyp_loaded > Hi, expert > It seems that if I want to implement the query, I need to implement storage drivers in hafnium by myself. > Thanks for the confirmation. > regards, > yuye > ------------------------------------------------------------------ > 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> > 发送时间：2023年1月17日(星期二) 00:30 > 收件人：hafnium <hafnium(a)lists.trustedfirmware.org>; 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > 抄送：赵哲(为哲) <weizhe.zz(a)alibaba-inc.com> > 主题：Re: 回复：[Hafnium] hyp_loaded > Hi, > In the reference implementation, OP-TEE is loaded (from flash to DRAM) as a partition by a bootloader running before Hafnium is launched. > The bootloader can be TF-A's BL2 or another solution. > Hafnium cannot "load an image/partition to DRAM" as it doesn't implement storage drivers. > Regards, > Olivier. > From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > Sent: 16 January 2023 17:25 > To: Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org> > Cc: 赵哲(为哲) <weizhe.zz(a)alibaba-inc.com> > Subject: 回复：[Hafnium] hyp_loaded > Hi, expert > For my configuration, Hafnium is used as a SPMC running on S-EL2. > Is there any problems if I use Hafnium to load an OP-TEE image in the boot flow? > regards, > yuye > ------------------------------------------------------------------ > 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> > 发送时间：2023年1月17日(星期二) 00:15 > 收件人：hafnium <hafnium(a)lists.trustedfirmware.org>; 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > 抄送：赵哲(为哲) <weizhe.zz(a)alibaba-inc.com> > 主题：Re: [Hafnium] hyp_loaded > Hi, > As I recall hyp_loaded option was introduced in context of Hafnium used as a NS EL2 hypervisor. Is this a configuration you use? > This option is only related to normal world VMs. > I don't believe it was designed for SPs or the SPMC image itself. > One reason is that SEL2/SPMC starts before the NS EL2 hypervisor in the boot flow. > For the record, the change that introduced this option: > https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > > <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > > > < < >https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > > <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > > > > < < >https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > > <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > > > < < >https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > > <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > > > > > Regards, Olivier. > From: 梅建强(禹夜) via Hafnium <hafnium(a)lists.trustedfirmware.org> > Sent: 16 January 2023 13:54 > To: Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org> > Cc: 赵哲(为哲) <weizhe.zz(a)alibaba-inc.com> > Subject: [Hafnium] hyp_loaded > Hi, expert > I want to confirm a problem about using hafnium to load spmc payload. > That is, Dose hafnium supports hyp_loaded for spmc payload or ffa_partion (such as optee_os) in the boot phase? > If the community confirms that it does not support it, I wonder, what might be the problem with doing so? > I see the following code in hanfnium： > if (manifest->vm[i].is_ffa_partition && > !manifest->vm[i].is_hyp_loaded) { > TRY(parse_ffa_partition_package(stage1_locked, &vm_node, &manifest->vm[i], vm_id, ppool)); } else { TRY(parse_vm(&vm_node, &manifest->vm[i], vm_id)); } It seems that hafnium has no handling for both is_ffa_partition and is_hyp_loaded. > regards, > yuye > -- > Hafnium mailing list -- hafnium(a)lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave(a)lists.trustedfirmware.org > -- > Hafnium mailing list -- hafnium(a)lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave(a)lists.trustedfirmware.org > -- > Hafnium mailing list -- hafnium(a)lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave(a)lists.trustedfirmware.org > -- > Hafnium mailing list -- hafnium(a)lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave(a)lists.trustedfirmware.org > -- > Hafnium mailing list -- hafnium(a)lists.trustedfirmware.org > To unsubscribe send an email to hafnium-leave(a)lists.trustedfirmware.org

2 years

1
0
0 0

hyp_loaded

by 梅建强(禹夜)

Hi, Olivier, The question in the last email may be a little confusing. I want to change the question, do you know how implement that hafnium boot optee at runtime? I think there should be less initialization than the first boot. Thanks a lot for the support. Regards, Yuye. ------------------------------------------------------------------ 发件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 发送时间：2023年4月23日(星期日) 16:36 收件人：Olivier Deprez <Olivier.Deprez(a)arm.com> 抄　送：hafnium <hafnium(a)lists.trustedfirmware.org> 主　题：hyp_loaded Hi, Olivier, I would like to ask you about the solution to the optee hot update. In the current scenario, we have updated the optee core image after REE OS is booted. And we want to re-initialize hafnium and optee in the boot flow. So we re-execute the function spmd_init() in the ATF and enter into hafnium succesfully. However, we find that function plat_psci_cpu_resume() has some problems with hafnium entering into optee. We add some debug near the following code. dlog("[Hafnium] cpu_index:%x, cpu->id:%x\n",cpu_index(c), c->id); vcpu = vm_get_vcpu(vm, (vm->vcpu_count == 1) ? 0 : cpu_index(c)); vcpu_locked = vcpu_lock(vcpu); Because the tee_driver that initiate a optee update request is running on a random cpu after REE OS is booted, cpu_id here is a random id, but cpu_index is still 0, like the print: [Hafnium] cpu_index:0, cpu->id:2d0000 which seems to affect optee booting and the system will hang before hafnium enter into optee. I am not familiar with the vcpu switching. Do you know how to solve this problem? Or should we directly select the secondary core boot way instead of the primary on the current physical cpu? Regards, Yuye. ------------------------------------------------------------------ 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> 发送时间：2023年2月3日(星期五) 18:10 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：hafnium <hafnium(a)lists.trustedfirmware.org>; raghu.ncstate <raghu.ncstate(a)icloud.com>; Achin Gupta <Achin.Gupta(a)arm.com>; Gyorgy Szing <Gyorgy.Szing(a)arm.com> 主　题：Re: hyp_loaded Hi Yuve, I believe we missed to reply to: > In addition, the OPTEE community seems to be discussing the issue of Post-boot loading OPTEE. Does anyone know whether these two issues can be regarded as the same kind of issue? From my perspective, this is a fundamentally different approach to how OP-TEE is loaded and booted. And actually a quite orthogonal model of trust compared to usual TF-A deployments. This requires an enforcement of the bootloader and kernel to verify the filesystem contents hence this has additional assumptions about the system integration. So I believe this a different 'problem' addressed, if compared to the generic firmware update topic. Regards, Olivier. From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> Sent: 19 January 2023 18:30 To: Gyorgy Szing <Gyorgy.Szing(a)arm.com>; Achin Gupta <Achin.Gupta(a)arm.com>; raghu.ncstate <raghu.ncstate(a)icloud.com>; Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: 回复：[Hafnium] 回复：回复：回复：回复：hyp_loaded Hi, George Since I have to go home for the Spring Festival, I have delayed two days for the reply to this issue.Sorry about that. > would it be possible for you to instead of extending HF with SP loading capability, implement a loader SP instead? Yes, we have recognized that method of extanding HF is not only complex but also against the HF design principle. We have reanalysed the SP loading. Now we think that BL31 may be a good choice to replace the HF for loading the OPTEE at runtime phase. And it seems that we can benefit from some implementation of image loading in BL2 in TF-A. In addition, the OPTEE community seems to be discussing the issue of Post-boot loading OPTEE. Does anyone know whether these two issues can be regarded as the same kind of issue? Regards, Yuye ------------------------------------------------------------------ 发件人：Gyorgy Szing <Gyorgy.Szing(a)arm.com> 发送时间：2023年1月17日(星期二) 18:27 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com>; Achin Gupta <Achin.Gupta(a)arm.com>; raghu.ncstate <raghu.ncstate(a)icloud.com>; Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org> 抄　送：nd <nd(a)arm.com> 主　题：RE: [Hafnium] 回复：回复：回复：回复：hyp_loaded Hi Yuye, would it be possible for you to instead of extending HF with SP loading capability, implement a loader SP instead? This SP would be loaded by BL2 instead of OP-TEE, and would be able to "replace itself" with the real payload of the SP later (in this case OP-TEE). For that it could either host a storage driver, if boot-time loading is needed, or if storage is only accessible from the SWd, or allow the NWd to send the payload if run-time loading is more beneficial. The main benefit of this approach would be to keep extra complexity out of HF, and to run the loader compartmentalized (least privilege principle). This might need some changes in HF, and will need a new treat model and threat mitigations. But I think the same is true if the loader is implemented in HF. Experts any thoughts? Would this be feasible? Would this be a good approach? /George -----Original Message----- From: 梅建强(禹夜) via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: 17 January 2023 02:42 To: Achin Gupta <Achin.Gupta(a)arm.com>; raghu.ncstate <raghu.ncstate(a)icloud.com>; Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org> Subject: [Hafnium] 回复：回复：回复：回复：hyp_loaded Hi, > If you are looking at changing the OP-TEE image at runtime then this is effectively a firmware update right? Yes. > Are you planning to add this support to Hafnium too or will this be done on a separate controller? Yes, we intend to use Hafnium to support it now. regards, yuye ------------------------------------------------------------------ 发件人：Achin Gupta <Achin.Gupta(a)arm.com> 发送时间：2023年1月17日(星期二) 05:18 收件人：raghu.ncstate <raghu.ncstate(a)icloud.com>; Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org>; 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 主题：Re: [Hafnium] 回复：回复：回复：hyp_loaded Hi Yuye, If you are looking at changing the OP-TEE image at runtime then this is effectively a firmware update right? Apart from storage drivers you would need some support for verifying or measuring the image as well. Are you planning to add this support to Hafnium too or will this be done on a separate controller? cheers, Achin From: 梅建强(禹夜) via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: 16 January 2023 17:50 To: raghu.ncstate <raghu.ncstate(a)icloud.com>; Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org> Subject: [Hafnium] 回复：回复：回复：hyp_loaded Hi, In our current boot flow, we have implemented TF-A BL2 to load OPTEE. However, at runtime, this static loading method is not convenient for updating OPTEE, considering that we may make some changes to OPTEE on demand. So we wanted to load OPTEE with a dynamic loading solution, and Hafnium would be a good runtime component, since TF-A BL2 is not a runtime component. Before I do that, I want to implement Hafnium's static loading of OPTEE. If you have any questions about the above ideas or other solutions to this query, glad to discuss with you. Thanks for support. regards, yuye ------------------------------------------------------------------ 发件人：raghu.ncstate <raghu.ncstate(a)icloud.com> 发送时间：2023年1月17日(星期二) 01:15 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com>; Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org> 抄送：赵哲(为哲) <weizhe.zz(a)alibaba-inc.com> 主题：RE: [Hafnium] 回复：回复：hyp_loaded It would be good if consider using TF-A BL2 or equivalent to load OPTEE, that runs before hafnium, which is really the secure loader. I would recommend against hafnium including a loader, to keep it simple (and replicate the same functionality of another component), although that might be the right approach for your platform. -----Original Message----- From: 梅建强(禹夜) via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: Monday, January 16, 2023 8:37 AM To: Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org> Cc: 赵哲(为哲) <weizhe.zz(a)alibaba-inc.com> Subject: [Hafnium] 回复：回复：hyp_loaded Hi, expert It seems that if I want to implement the query, I need to implement storage drivers in hafnium by myself. Thanks for the confirmation. regards, yuye ------------------------------------------------------------------ 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> 发送时间：2023年1月17日(星期二) 00:30 收件人：hafnium <hafnium(a)lists.trustedfirmware.org>; 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄送：赵哲(为哲) <weizhe.zz(a)alibaba-inc.com> 主题：Re: 回复：[Hafnium] hyp_loaded Hi, In the reference implementation, OP-TEE is loaded (from flash to DRAM) as a partition by a bootloader running before Hafnium is launched. The bootloader can be TF-A's BL2 or another solution. Hafnium cannot "load an image/partition to DRAM" as it doesn't implement storage drivers. Regards, Olivier. From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> Sent: 16 January 2023 17:25 To: Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org> Cc: 赵哲(为哲) <weizhe.zz(a)alibaba-inc.com> Subject: 回复：[Hafnium] hyp_loaded Hi, expert For my configuration, Hafnium is used as a SPMC running on S-EL2. Is there any problems if I use Hafnium to load an OP-TEE image in the boot flow? regards, yuye ------------------------------------------------------------------ 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> 发送时间：2023年1月17日(星期二) 00:15 收件人：hafnium <hafnium(a)lists.trustedfirmware.org>; 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄送：赵哲(为哲) <weizhe.zz(a)alibaba-inc.com> 主题：Re: [Hafnium] hyp_loaded Hi, As I recall hyp_loaded option was introduced in context of Hafnium used as a NS EL2 hypervisor. Is this a configuration you use? This option is only related to normal world VMs. I don't believe it was designed for SPs or the SPMC image itself. One reason is that SEL2/SPMC starts before the NS EL2 hypervisor in the boot flow. For the record, the change that introduced this option: https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > > < < >https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > > > < < >https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > > < < >https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > > > > Regards, Olivier. From: 梅建强(禹夜) via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: 16 January 2023 13:54 To: Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org> Cc: 赵哲(为哲) <weizhe.zz(a)alibaba-inc.com> Subject: [Hafnium] hyp_loaded Hi, expert I want to confirm a problem about using hafnium to load spmc payload. That is, Dose hafnium supports hyp_loaded for spmc payload or ffa_partion (such as optee_os) in the boot phase? If the community confirms that it does not support it, I wonder, what might be the problem with doing so? I see the following code in hanfnium： if (manifest->vm[i].is_ffa_partition && !manifest->vm[i].is_hyp_loaded) { TRY(parse_ffa_partition_package(stage1_locked, &vm_node, &manifest->vm[i], vm_id, ppool)); } else { TRY(parse_vm(&vm_node, &manifest->vm[i], vm_id)); } It seems that hafnium has no handling for both is_ffa_partition and is_hyp_loaded. regards, yuye -- Hafnium mailing list -- hafnium(a)lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave(a)lists.trustedfirmware.org -- Hafnium mailing list -- hafnium(a)lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave(a)lists.trustedfirmware.org -- Hafnium mailing list -- hafnium(a)lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave(a)lists.trustedfirmware.org -- Hafnium mailing list -- hafnium(a)lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave(a)lists.trustedfirmware.org

2 years

2
1
0 0

hyp_loaded

by 梅建强(禹夜)

Hi, Olivier, I would like to ask you about the solution to the optee hot update. In the current scenario, we have updated the optee core image after REE OS is booted. And we want to re-initialize hafnium and optee in the boot flow. So we re-execute the function spmd_init() in the ATF and enter into hafnium succesfully. However, we find that function plat_psci_cpu_resume() has some problems with hafnium entering into optee. We add some debug near the following code. dlog("[Hafnium] cpu_index:%x, cpu->id:%x\n",cpu_index(c), c->id); vcpu = vm_get_vcpu(vm, (vm->vcpu_count == 1) ? 0 : cpu_index(c)); vcpu_locked = vcpu_lock(vcpu); Because the tee_driver that initiate a optee update request is running on a random cpu after REE OS is booted, cpu_id here is a random id, but cpu_index is still 0, like the print: [Hafnium] cpu_index:0, cpu->id:2d0000 which seems to affect optee booting and the system will hang before hafnium enter into optee. I am not familiar with the vcpu switching. Do you know how to solve this problem? Or should we directly select the secondary core boot way instead of the primary on the current physical cpu? Regards, Yuye. ------------------------------------------------------------------ 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> 发送时间：2023年2月3日(星期五) 18:10 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：hafnium <hafnium(a)lists.trustedfirmware.org>; raghu.ncstate <raghu.ncstate(a)icloud.com>; Achin Gupta <Achin.Gupta(a)arm.com>; Gyorgy Szing <Gyorgy.Szing(a)arm.com> 主　题：Re: hyp_loaded Hi Yuve, I believe we missed to reply to: > In addition, the OPTEE community seems to be discussing the issue of Post-boot loading OPTEE. Does anyone know whether these two issues can be regarded as the same kind of issue? From my perspective, this is a fundamentally different approach to how OP-TEE is loaded and booted. And actually a quite orthogonal model of trust compared to usual TF-A deployments. This requires an enforcement of the bootloader and kernel to verify the filesystem contents hence this has additional assumptions about the system integration. So I believe this a different 'problem' addressed, if compared to the generic firmware update topic. Regards, Olivier. From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> Sent: 19 January 2023 18:30 To: Gyorgy Szing <Gyorgy.Szing(a)arm.com>; Achin Gupta <Achin.Gupta(a)arm.com>; raghu.ncstate <raghu.ncstate(a)icloud.com>; Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: 回复：[Hafnium] 回复：回复：回复：回复：hyp_loaded Hi, George Since I have to go home for the Spring Festival, I have delayed two days for the reply to this issue.Sorry about that. > would it be possible for you to instead of extending HF with SP loading capability, implement a loader SP instead? Yes, we have recognized that method of extanding HF is not only complex but also against the HF design principle. We have reanalysed the SP loading. Now we think that BL31 may be a good choice to replace the HF for loading the OPTEE at runtime phase. And it seems that we can benefit from some implementation of image loading in BL2 in TF-A. In addition, the OPTEE community seems to be discussing the issue of Post-boot loading OPTEE. Does anyone know whether these two issues can be regarded as the same kind of issue? Regards, Yuye ------------------------------------------------------------------ 发件人：Gyorgy Szing <Gyorgy.Szing(a)arm.com> 发送时间：2023年1月17日(星期二) 18:27 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com>; Achin Gupta <Achin.Gupta(a)arm.com>; raghu.ncstate <raghu.ncstate(a)icloud.com>; Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org> 抄　送：nd <nd(a)arm.com> 主　题：RE: [Hafnium] 回复：回复：回复：回复：hyp_loaded Hi Yuye, would it be possible for you to instead of extending HF with SP loading capability, implement a loader SP instead? This SP would be loaded by BL2 instead of OP-TEE, and would be able to "replace itself" with the real payload of the SP later (in this case OP-TEE). For that it could either host a storage driver, if boot-time loading is needed, or if storage is only accessible from the SWd, or allow the NWd to send the payload if run-time loading is more beneficial. The main benefit of this approach would be to keep extra complexity out of HF, and to run the loader compartmentalized (least privilege principle). This might need some changes in HF, and will need a new treat model and threat mitigations. But I think the same is true if the loader is implemented in HF. Experts any thoughts? Would this be feasible? Would this be a good approach? /George -----Original Message----- From: 梅建强(禹夜) via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: 17 January 2023 02:42 To: Achin Gupta <Achin.Gupta(a)arm.com>; raghu.ncstate <raghu.ncstate(a)icloud.com>; Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org> Subject: [Hafnium] 回复：回复：回复：回复：hyp_loaded Hi, > If you are looking at changing the OP-TEE image at runtime then this is effectively a firmware update right? Yes. > Are you planning to add this support to Hafnium too or will this be done on a separate controller? Yes, we intend to use Hafnium to support it now. regards, yuye ------------------------------------------------------------------ 发件人：Achin Gupta <Achin.Gupta(a)arm.com> 发送时间：2023年1月17日(星期二) 05:18 收件人：raghu.ncstate <raghu.ncstate(a)icloud.com>; Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org>; 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 主题：Re: [Hafnium] 回复：回复：回复：hyp_loaded Hi Yuye, If you are looking at changing the OP-TEE image at runtime then this is effectively a firmware update right? Apart from storage drivers you would need some support for verifying or measuring the image as well. Are you planning to add this support to Hafnium too or will this be done on a separate controller? cheers, Achin From: 梅建强(禹夜) via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: 16 January 2023 17:50 To: raghu.ncstate <raghu.ncstate(a)icloud.com>; Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org> Subject: [Hafnium] 回复：回复：回复：hyp_loaded Hi, In our current boot flow, we have implemented TF-A BL2 to load OPTEE. However, at runtime, this static loading method is not convenient for updating OPTEE, considering that we may make some changes to OPTEE on demand. So we wanted to load OPTEE with a dynamic loading solution, and Hafnium would be a good runtime component, since TF-A BL2 is not a runtime component. Before I do that, I want to implement Hafnium's static loading of OPTEE. If you have any questions about the above ideas or other solutions to this query, glad to discuss with you. Thanks for support. regards, yuye ------------------------------------------------------------------ 发件人：raghu.ncstate <raghu.ncstate(a)icloud.com> 发送时间：2023年1月17日(星期二) 01:15 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com>; Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org> 抄送：赵哲(为哲) <weizhe.zz(a)alibaba-inc.com> 主题：RE: [Hafnium] 回复：回复：hyp_loaded It would be good if consider using TF-A BL2 or equivalent to load OPTEE, that runs before hafnium, which is really the secure loader. I would recommend against hafnium including a loader, to keep it simple (and replicate the same functionality of another component), although that might be the right approach for your platform. -----Original Message----- From: 梅建强(禹夜) via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: Monday, January 16, 2023 8:37 AM To: Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org> Cc: 赵哲(为哲) <weizhe.zz(a)alibaba-inc.com> Subject: [Hafnium] 回复：回复：hyp_loaded Hi, expert It seems that if I want to implement the query, I need to implement storage drivers in hafnium by myself. Thanks for the confirmation. regards, yuye ------------------------------------------------------------------ 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> 发送时间：2023年1月17日(星期二) 00:30 收件人：hafnium <hafnium(a)lists.trustedfirmware.org>; 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄送：赵哲(为哲) <weizhe.zz(a)alibaba-inc.com> 主题：Re: 回复：[Hafnium] hyp_loaded Hi, In the reference implementation, OP-TEE is loaded (from flash to DRAM) as a partition by a bootloader running before Hafnium is launched. The bootloader can be TF-A's BL2 or another solution. Hafnium cannot "load an image/partition to DRAM" as it doesn't implement storage drivers. Regards, Olivier. From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> Sent: 16 January 2023 17:25 To: Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org> Cc: 赵哲(为哲) <weizhe.zz(a)alibaba-inc.com> Subject: 回复：[Hafnium] hyp_loaded Hi, expert For my configuration, Hafnium is used as a SPMC running on S-EL2. Is there any problems if I use Hafnium to load an OP-TEE image in the boot flow? regards, yuye ------------------------------------------------------------------ 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> 发送时间：2023年1月17日(星期二) 00:15 收件人：hafnium <hafnium(a)lists.trustedfirmware.org>; 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄送：赵哲(为哲) <weizhe.zz(a)alibaba-inc.com> 主题：Re: [Hafnium] hyp_loaded Hi, As I recall hyp_loaded option was introduced in context of Hafnium used as a NS EL2 hypervisor. Is this a configuration you use? This option is only related to normal world VMs. I don't believe it was designed for SPs or the SPMC image itself. One reason is that SEL2/SPMC starts before the NS EL2 hypervisor in the boot flow. For the record, the change that introduced this option: https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > > < < >https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > > > < < >https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > > < < >https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > > > > Regards, Olivier. From: 梅建强(禹夜) via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: 16 January 2023 13:54 To: Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org> Cc: 赵哲(为哲) <weizhe.zz(a)alibaba-inc.com> Subject: [Hafnium] hyp_loaded Hi, expert I want to confirm a problem about using hafnium to load spmc payload. That is, Dose hafnium supports hyp_loaded for spmc payload or ffa_partion (such as optee_os) in the boot phase? If the community confirms that it does not support it, I wonder, what might be the problem with doing so? I see the following code in hanfnium： if (manifest->vm[i].is_ffa_partition && !manifest->vm[i].is_hyp_loaded) { TRY(parse_ffa_partition_package(stage1_locked, &vm_node, &manifest->vm[i], vm_id, ppool)); } else { TRY(parse_vm(&vm_node, &manifest->vm[i], vm_id)); } It seems that hafnium has no handling for both is_ffa_partition and is_hyp_loaded. regards, yuye -- Hafnium mailing list -- hafnium(a)lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave(a)lists.trustedfirmware.org -- Hafnium mailing list -- hafnium(a)lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave(a)lists.trustedfirmware.org -- Hafnium mailing list -- hafnium(a)lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave(a)lists.trustedfirmware.org -- Hafnium mailing list -- hafnium(a)lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave(a)lists.trustedfirmware.org

2 years

1
0
0 0

fragment transmission while retrieving memory

by 梅建强(禹夜)

Hi, Jens, >The first is the descriptor passed with FFA_MEM_RETRIEVE_REQ_32, >this one is not likely to need fragmentation support soon. Could you tell me why? I'm a little unclear. Could you describe the difference between the retrieve process you mean and FFA-spec figure 18.4 in detail? I need to make sure that I really understand what you mean, so that I can implement the missing support for fragmented mem retrieve response as you said. Or do you mean that we just need to implement the action done by optee after it receives FFA_MEM_RETRIEVE_RESP_32? Regards, Yuye. ------------------------------------------------------------------ 发件人：Jens Wiklander <jens.wiklander(a)linaro.org> 发送时间：2023年4月14日(星期五) 14:23 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org>; op-tee <op-tee(a)lists.trustedfirmware.org> 主　题：Re: fragment transmission while retrieving memory Hi Yuye, On Fri, Apr 14, 2023 at 4:29 AM 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> wrote: > > > Hi, Jens, Olivier, > > If I understand properly, for this specific issue both optee and hafnium need to do further fix. > The following discussion and questions are based on figure 18.4 in the FFA spec. > > As I saw in the optee code, the retrieve mechanism would start with this code: > retrieve_desc = spmc_retrieve_req(cookie); > And in the function spmc_retrieve_req, > optee sets the total length to the same size as fragment0 length before sending FFA_MEM_FRAG_REQ to hafnium, > which means hafnium will only retrieve the fragment0 memory region. > > In the example process, > optee will determines the number of TX sized fragments of descriptor before sending FFA_MEM_FRAG_REQ to hafnium. > I have a question here. > How should optee calculate this quantity? > > Hafnium then receives the FFA_MEM_FRAG_REQ. > As I saw in the hafnium code, hafnium blocks the case that total length>fragment length. > if (fragment_length != length) { > dlog_verbose("Fragmentation not yet supported.\n"); > return ffa_error(FFA_INVALID_PARAMETERS); > } > Obviously it is not what we expected. > Then following the example process, hafnium should allocate handle and use it to associate fragments. > I didn't find the corresponding implementation in hafnium code for this step. > And I want to know how to implement the associate action here. > > After that, optee lacks the implementation of FFA_MEM_FRAG_RX and FFA_MEM_FRAG_TX ABI in CFG_CORE_SEL2_SPMC enable case. > Is there any support plan for the implementation of fragmented memory retrieve in the optee community? > Does the hafnium community have a plan to implement it cooperatively? If I've understood this correctly we have two different cases of eventual fragmentation of descriptors. The first is the descriptor passed with FFA_MEM_RETRIEVE_REQ_32, this one is not likely to need fragmentation support soon. The other is the descriptor received with FFA_MEM_RETRIEVE_RESP, I believe this is where you've run into trouble. From OP-TEE point of view, it would make sense if you took lead on implementing this. I can help with review etc. Thanks, Jens > > Thanks a lot for your support. > > Regards, > Yuye. > > > > > > ------------------------------------------------------------------ > 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> > 发送时间：2023年4月13日(星期四) 15:52 > 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > 抄送：hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > 主题：Re: fragment transmission while retrieving memory > > Hi Yuye, Jens, > > For the record, and If I understand properly the last comment in the github issue: > OP-TEE is missing the implementation for receipt of a fragmented retrieve response > There is no further fix to be done in Hafnium for this specific issue at this moment, please let me know otherwise. > > Thanks, Olivier. > > > ________________________________ > From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > Sent: 12 April 2023 09:27 > To: Olivier Deprez <Olivier.Deprez(a)arm.com> > Cc: hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > Subject: Re: fragment transmission while retrieving memory > > > > > Hi, Olivier, > > In our setup, > Hafnium commit: 997476a74571aec4f1a23590d45edf516f3934f4 > optee version: 3.20.0 > Thanks. > > Regards, > Yuye. > > ------------------------------------------------------------------ > 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> > 发送时间：2023年4月12日(星期三) 15:22 > 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > 抄送：hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > 主题：Re: fragment transmission while retrieving memory > > Hi Yuye, > > AFAIK concerning Hafnium, fragmented mem sharing is supported for FFA_MEM_SHARE/LEND/DONATE and FFA_MEM_RETRIEVE_RESP. > (For the sake of clarity, this isn't supported for FFA_MEM_RETRIEVE_REQ but this shouldn't be a concern as this limitation only exists in the case of mem sharing to multiple borrowers. In your case of a single borrower the mem retrieve req. shouldn't have to be fragmented). > > Can you tell which hafnium commit hash is used in your setup? > > At the moment, I cannot tell if the issue described concern a miss in Hafnium or OP-TEE. > I need to dig a bit further into both implementations and I'll let you know. > > Regards, > Olivier. > > > ________________________________ > From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > Sent: 12 April 2023 08:21 > To: Olivier Deprez <Olivier.Deprez(a)arm.com> > Cc: hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > Subject: fragment transmission while retrieving memory > > > > > Hi, Olivier, > > Recently, I've been working on this issue. > https://github.com/OP-TEE/optee_os/issues/5943 <https://github.com/OP-TEE/optee_os/issues/5943 > > Do you know any differences between hafnium's current implementation of fragment transmission while retrieving memory and the example process described in FF-A 1.1 Figure 18.4? > > Regards, > Yuye. > >

2 years

2
1
0 0

fragment transmission while retrieving memory

by 梅建强(禹夜)

Hi, Jens, Olivier, update for optee: https://github.com/OP-TEE/optee_os/pull/5966 <https://github.com/OP-TEE/optee_os/pull/5966 > update for hafnium: diff --git a/src/api.c b/src/api.c index 5f699478..7e43e305 100644 --- a/src/api.c +++ b/src/api.c @@ -3191,7 +3191,8 @@ struct ffa_value api_ffa_mem_frag_rx(ffa_memory_handle_t handle, return ffa_error(FFA_INVALID_PARAMETERS); } } - + if (to->id==0x8001 && to->mailbox.state != MAILBOX_STATE_EMPTY) + to->mailbox.state = MAILBOX_STATE_EMPTY; to_locked = vm_lock(to); if (vm_is_mailbox_busy(to_locked)) { diff --git a/src/ffa_memory.c b/src/ffa_memory.c index 3e978d23..59e71ff3 100644 --- a/src/ffa_memory.c +++ b/src/ffa_memory.c @@ -2385,7 +2385,7 @@ struct ffa_value ffa_memory_retrieve_continue(struct vm_locked to_locked, &fragment_length); CHECK(remaining_constituent_count == 0); to_locked.vm->mailbox.recv_size = fragment_length; - to_locked.vm->mailbox.recv_sender = HF_HYPERVISOR_VM_ID; + to_locked.vm->mailbox.recv_sender = to_locked.vm->id; to_locked.vm->mailbox.recv_func = FFA_MEM_FRAG_TX_32; to_locked.vm->mailbox.state = MAILBOX_STATE_FULL; It seems that to->mailbox.state needs to be set to MAILBOX_STATE_EMPTY firstly. I have not figured out why, but large TA could be loaded successfully with above fix now. Regards, Yuye. ------------------------------------------------------------------ 发件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 发送时间：2023年4月17日(星期一) 02:16 收件人：Jens Wiklander <jens.wiklander(a)linaro.org> 抄　送：Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org>; op-tee <op-tee(a)lists.trustedfirmware.org> 主　题：fragment transmission while retrieving memory Hi, Jens, I have implement the missing support for fragmented mem retrieve response as you suggested. I will push fix into the community code soon and please help review it later. Thanks. Regards, Yuye. ------------------------------------------------------------------ 发件人：Jens Wiklander <jens.wiklander(a)linaro.org> 发送时间：2023年4月14日(星期五) 14:23 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org>; op-tee <op-tee(a)lists.trustedfirmware.org> 主　题：Re: fragment transmission while retrieving memory Hi Yuye, On Fri, Apr 14, 2023 at 4:29 AM 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> wrote: > > > Hi, Jens, Olivier, > > If I understand properly, for this specific issue both optee and hafnium need to do further fix. > The following discussion and questions are based on figure 18.4 in the FFA spec. > > As I saw in the optee code, the retrieve mechanism would start with this code: > retrieve_desc = spmc_retrieve_req(cookie); > And in the function spmc_retrieve_req, > optee sets the total length to the same size as fragment0 length before sending FFA_MEM_FRAG_REQ to hafnium, > which means hafnium will only retrieve the fragment0 memory region. > > In the example process, > optee will determines the number of TX sized fragments of descriptor before sending FFA_MEM_FRAG_REQ to hafnium. > I have a question here. > How should optee calculate this quantity? > > Hafnium then receives the FFA_MEM_FRAG_REQ. > As I saw in the hafnium code, hafnium blocks the case that total length>fragment length. > if (fragment_length != length) { > dlog_verbose("Fragmentation not yet supported.\n"); > return ffa_error(FFA_INVALID_PARAMETERS); > } > Obviously it is not what we expected. > Then following the example process, hafnium should allocate handle and use it to associate fragments. > I didn't find the corresponding implementation in hafnium code for this step. > And I want to know how to implement the associate action here. > > After that, optee lacks the implementation of FFA_MEM_FRAG_RX and FFA_MEM_FRAG_TX ABI in CFG_CORE_SEL2_SPMC enable case. > Is there any support plan for the implementation of fragmented memory retrieve in the optee community? > Does the hafnium community have a plan to implement it cooperatively? If I've understood this correctly we have two different cases of eventual fragmentation of descriptors. The first is the descriptor passed with FFA_MEM_RETRIEVE_REQ_32, this one is not likely to need fragmentation support soon. The other is the descriptor received with FFA_MEM_RETRIEVE_RESP, I believe this is where you've run into trouble. From OP-TEE point of view, it would make sense if you took lead on implementing this. I can help with review etc. Thanks, Jens > > Thanks a lot for your support. > > Regards, > Yuye. > > > > > > ------------------------------------------------------------------ > 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> > 发送时间：2023年4月13日(星期四) 15:52 > 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > 抄送：hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > 主题：Re: fragment transmission while retrieving memory > > Hi Yuye, Jens, > > For the record, and If I understand properly the last comment in the github issue: > OP-TEE is missing the implementation for receipt of a fragmented retrieve response > There is no further fix to be done in Hafnium for this specific issue at this moment, please let me know otherwise. > > Thanks, Olivier. > > > ________________________________ > From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > Sent: 12 April 2023 09:27 > To: Olivier Deprez <Olivier.Deprez(a)arm.com> > Cc: hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > Subject: Re: fragment transmission while retrieving memory > > > > > Hi, Olivier, > > In our setup, > Hafnium commit: 997476a74571aec4f1a23590d45edf516f3934f4 > optee version: 3.20.0 > Thanks. > > Regards, > Yuye. > > ------------------------------------------------------------------ > 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> > 发送时间：2023年4月12日(星期三) 15:22 > 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > 抄送：hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > 主题：Re: fragment transmission while retrieving memory > > Hi Yuye, > > AFAIK concerning Hafnium, fragmented mem sharing is supported for FFA_MEM_SHARE/LEND/DONATE and FFA_MEM_RETRIEVE_RESP. > (For the sake of clarity, this isn't supported for FFA_MEM_RETRIEVE_REQ but this shouldn't be a concern as this limitation only exists in the case of mem sharing to multiple borrowers. In your case of a single borrower the mem retrieve req. shouldn't have to be fragmented). > > Can you tell which hafnium commit hash is used in your setup? > > At the moment, I cannot tell if the issue described concern a miss in Hafnium or OP-TEE. > I need to dig a bit further into both implementations and I'll let you know. > > Regards, > Olivier. > > > ________________________________ > From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > Sent: 12 April 2023 08:21 > To: Olivier Deprez <Olivier.Deprez(a)arm.com> > Cc: hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > Subject: fragment transmission while retrieving memory > > > > > Hi, Olivier, > > Recently, I've been working on this issue. > https://github.com/OP-TEE/optee_os/issues/5943 <https://github.com/OP-TEE/optee_os/issues/5943 > > Do you know any differences between hafnium's current implementation of fragment transmission while retrieving memory and the example process described in FF-A 1.1 Figure 18.4? > > Regards, > Yuye. > >

2 years

1
0
0 0

fragment transmission while retrieving memory

by 梅建强(禹夜)

Hi, Jens, I have implement the missing support for fragmented mem retrieve response as you suggested. I will push fix into the community code soon and please help review it later. Thanks. Regards, Yuye. ------------------------------------------------------------------ 发件人：Jens Wiklander <jens.wiklander(a)linaro.org> 发送时间：2023年4月14日(星期五) 14:23 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org>; op-tee <op-tee(a)lists.trustedfirmware.org> 主　题：Re: fragment transmission while retrieving memory Hi Yuye, On Fri, Apr 14, 2023 at 4:29 AM 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> wrote: > > > Hi, Jens, Olivier, > > If I understand properly, for this specific issue both optee and hafnium need to do further fix. > The following discussion and questions are based on figure 18.4 in the FFA spec. > > As I saw in the optee code, the retrieve mechanism would start with this code: > retrieve_desc = spmc_retrieve_req(cookie); > And in the function spmc_retrieve_req, > optee sets the total length to the same size as fragment0 length before sending FFA_MEM_FRAG_REQ to hafnium, > which means hafnium will only retrieve the fragment0 memory region. > > In the example process, > optee will determines the number of TX sized fragments of descriptor before sending FFA_MEM_FRAG_REQ to hafnium. > I have a question here. > How should optee calculate this quantity? > > Hafnium then receives the FFA_MEM_FRAG_REQ. > As I saw in the hafnium code, hafnium blocks the case that total length>fragment length. > if (fragment_length != length) { > dlog_verbose("Fragmentation not yet supported.\n"); > return ffa_error(FFA_INVALID_PARAMETERS); > } > Obviously it is not what we expected. > Then following the example process, hafnium should allocate handle and use it to associate fragments. > I didn't find the corresponding implementation in hafnium code for this step. > And I want to know how to implement the associate action here. > > After that, optee lacks the implementation of FFA_MEM_FRAG_RX and FFA_MEM_FRAG_TX ABI in CFG_CORE_SEL2_SPMC enable case. > Is there any support plan for the implementation of fragmented memory retrieve in the optee community? > Does the hafnium community have a plan to implement it cooperatively? If I've understood this correctly we have two different cases of eventual fragmentation of descriptors. The first is the descriptor passed with FFA_MEM_RETRIEVE_REQ_32, this one is not likely to need fragmentation support soon. The other is the descriptor received with FFA_MEM_RETRIEVE_RESP, I believe this is where you've run into trouble. From OP-TEE point of view, it would make sense if you took lead on implementing this. I can help with review etc. Thanks, Jens > > Thanks a lot for your support. > > Regards, > Yuye. > > > > > > ------------------------------------------------------------------ > 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> > 发送时间：2023年4月13日(星期四) 15:52 > 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > 抄送：hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > 主题：Re: fragment transmission while retrieving memory > > Hi Yuye, Jens, > > For the record, and If I understand properly the last comment in the github issue: > OP-TEE is missing the implementation for receipt of a fragmented retrieve response > There is no further fix to be done in Hafnium for this specific issue at this moment, please let me know otherwise. > > Thanks, Olivier. > > > ________________________________ > From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > Sent: 12 April 2023 09:27 > To: Olivier Deprez <Olivier.Deprez(a)arm.com> > Cc: hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > Subject: Re: fragment transmission while retrieving memory > > > > > Hi, Olivier, > > In our setup, > Hafnium commit: 997476a74571aec4f1a23590d45edf516f3934f4 > optee version: 3.20.0 > Thanks. > > Regards, > Yuye. > > ------------------------------------------------------------------ > 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> > 发送时间：2023年4月12日(星期三) 15:22 > 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > 抄送：hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > 主题：Re: fragment transmission while retrieving memory > > Hi Yuye, > > AFAIK concerning Hafnium, fragmented mem sharing is supported for FFA_MEM_SHARE/LEND/DONATE and FFA_MEM_RETRIEVE_RESP. > (For the sake of clarity, this isn't supported for FFA_MEM_RETRIEVE_REQ but this shouldn't be a concern as this limitation only exists in the case of mem sharing to multiple borrowers. In your case of a single borrower the mem retrieve req. shouldn't have to be fragmented). > > Can you tell which hafnium commit hash is used in your setup? > > At the moment, I cannot tell if the issue described concern a miss in Hafnium or OP-TEE. > I need to dig a bit further into both implementations and I'll let you know. > > Regards, > Olivier. > > > ________________________________ > From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > Sent: 12 April 2023 08:21 > To: Olivier Deprez <Olivier.Deprez(a)arm.com> > Cc: hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > Subject: fragment transmission while retrieving memory > > > > > Hi, Olivier, > > Recently, I've been working on this issue. > https://github.com/OP-TEE/optee_os/issues/5943 <https://github.com/OP-TEE/optee_os/issues/5943 > > Do you know any differences between hafnium's current implementation of fragment transmission while retrieving memory and the example process described in FF-A 1.1 Figure 18.4? > > Regards, > Yuye. > >

2 years

1
0
0 0

fragment transmission while retrieving memory

by 梅建强(禹夜)

Hi, Jens, Olivier, Is it possible to solve this problem by increasing the buffer size such as 64k? We plan to adopt this temporary scheme first and then implement the standard retrieve process later. If this scheme is feasible, I have a few questions. 1. Should the RXTX buffer between tee driver and hafnium the same as the one between hafnium and optee? 2. Which FFA instance is currently allocating these buffers? 3. For Hafnium, I want to increase the HF_MAILBOX_SIZE in Hafnium, but there seem to be two restrictions: static_assert(HF_MAILBOX_SIZE == PAGE_SIZE, "Currently, a page is mapped for the send and receive buffers so " "the maximum request is the size of a page."); static_assert(MM_PPOOL_ENTRY_SIZE >= HF_MAILBOX_SIZE, "The page pool entry size must be at least as big as the mailbox " "size, so that memory region descriptors can be copied from the " "mailbox for memory sharing."); I tried to increase the MM_PPOOL_ENTRY_SIZE, but optee doesn't seem to be booted properly. Do you know how to avoid the impact of these restrictions? Regards, Yuye. ------------------------------------------------------------------ 发件人：Jens Wiklander via Hafnium <hafnium(a)lists.trustedfirmware.org> 发送时间：2023年4月14日(星期五) 14:23 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org>; op-tee <op-tee(a)lists.trustedfirmware.org> 主　题：[Hafnium] Re: fragment transmission while retrieving memory Hi Yuye, On Fri, Apr 14, 2023 at 4:29 AM 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> wrote: > > > Hi, Jens, Olivier, > > If I understand properly, for this specific issue both optee and hafnium need to do further fix. > The following discussion and questions are based on figure 18.4 in the FFA spec. > > As I saw in the optee code, the retrieve mechanism would start with this code: > retrieve_desc = spmc_retrieve_req(cookie); > And in the function spmc_retrieve_req, > optee sets the total length to the same size as fragment0 length before sending FFA_MEM_FRAG_REQ to hafnium, > which means hafnium will only retrieve the fragment0 memory region. > > In the example process, > optee will determines the number of TX sized fragments of descriptor before sending FFA_MEM_FRAG_REQ to hafnium. > I have a question here. > How should optee calculate this quantity? > > Hafnium then receives the FFA_MEM_FRAG_REQ. > As I saw in the hafnium code, hafnium blocks the case that total length>fragment length. > if (fragment_length != length) { > dlog_verbose("Fragmentation not yet supported.\n"); > return ffa_error(FFA_INVALID_PARAMETERS); > } > Obviously it is not what we expected. > Then following the example process, hafnium should allocate handle and use it to associate fragments. > I didn't find the corresponding implementation in hafnium code for this step. > And I want to know how to implement the associate action here. > > After that, optee lacks the implementation of FFA_MEM_FRAG_RX and FFA_MEM_FRAG_TX ABI in CFG_CORE_SEL2_SPMC enable case. > Is there any support plan for the implementation of fragmented memory retrieve in the optee community? > Does the hafnium community have a plan to implement it cooperatively? If I've understood this correctly we have two different cases of eventual fragmentation of descriptors. The first is the descriptor passed with FFA_MEM_RETRIEVE_REQ_32, this one is not likely to need fragmentation support soon. The other is the descriptor received with FFA_MEM_RETRIEVE_RESP, I believe this is where you've run into trouble. From OP-TEE point of view, it would make sense if you took lead on implementing this. I can help with review etc. Thanks, Jens > > Thanks a lot for your support. > > Regards, > Yuye. > > > > > > ------------------------------------------------------------------ > 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> > 发送时间：2023年4月13日(星期四) 15:52 > 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > 抄送：hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > 主题：Re: fragment transmission while retrieving memory > > Hi Yuye, Jens, > > For the record, and If I understand properly the last comment in the github issue: > OP-TEE is missing the implementation for receipt of a fragmented retrieve response > There is no further fix to be done in Hafnium for this specific issue at this moment, please let me know otherwise. > > Thanks, Olivier. > > > ________________________________ > From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > Sent: 12 April 2023 09:27 > To: Olivier Deprez <Olivier.Deprez(a)arm.com> > Cc: hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > Subject: Re: fragment transmission while retrieving memory > > > > > Hi, Olivier, > > In our setup, > Hafnium commit: 997476a74571aec4f1a23590d45edf516f3934f4 > optee version: 3.20.0 > Thanks. > > Regards, > Yuye. > > ------------------------------------------------------------------ > 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> > 发送时间：2023年4月12日(星期三) 15:22 > 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > 抄送：hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > 主题：Re: fragment transmission while retrieving memory > > Hi Yuye, > > AFAIK concerning Hafnium, fragmented mem sharing is supported for FFA_MEM_SHARE/LEND/DONATE and FFA_MEM_RETRIEVE_RESP. > (For the sake of clarity, this isn't supported for FFA_MEM_RETRIEVE_REQ but this shouldn't be a concern as this limitation only exists in the case of mem sharing to multiple borrowers. In your case of a single borrower the mem retrieve req. shouldn't have to be fragmented). > > Can you tell which hafnium commit hash is used in your setup? > > At the moment, I cannot tell if the issue described concern a miss in Hafnium or OP-TEE. > I need to dig a bit further into both implementations and I'll let you know. > > Regards, > Olivier. > > > ________________________________ > From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > Sent: 12 April 2023 08:21 > To: Olivier Deprez <Olivier.Deprez(a)arm.com> > Cc: hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > Subject: fragment transmission while retrieving memory > > > > > Hi, Olivier, > > Recently, I've been working on this issue. > https://github.com/OP-TEE/optee_os/issues/5943 <https://github.com/OP-TEE/optee_os/issues/5943 > > Do you know any differences between hafnium's current implementation of fragment transmission while retrieving memory and the example process described in FF-A 1.1 Figure 18.4? > > Regards, > Yuye. > > -- Hafnium mailing list -- hafnium(a)lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave(a)lists.trustedfirmware.org

2 years

2
1
0 0

Re: fragment transmission while retrieving memory

by 梅建强(禹夜)

Hi, Jens, Olivier, If I understand properly, for this specific issue both optee and hafnium need to do further fix. The following discussion and questions are based on figure 18.4 in the FFA spec. As I saw in the optee code, the retrieve mechanism would start with this code: retrieve_desc = spmc_retrieve_req(cookie); And in the function spmc_retrieve_req, optee sets the total length to the same size as fragment0 length before sending FFA_MEM_FRAG_REQ to hafnium, which means hafnium will only retrieve the fragment0 memory region. In the example process, optee will determines the number of TX sized fragments of descriptor before sending FFA_MEM_FRAG_REQ to hafnium. I have a question here. How should optee calculate this quantity? Hafnium then receives the FFA_MEM_FRAG_REQ. As I saw in the hafnium code, hafnium blocks the case that total length>fragment length. if (fragment_length != length) { dlog_verbose("Fragmentation not yet supported.\n"); return ffa_error(FFA_INVALID_PARAMETERS); } Obviously it is not what we expected. Then following the example process, hafnium should allocate handle and use it to associate fragments. I didn't find the corresponding implementation in hafnium code for this step. And I want to know how to implement the associate action here. After that, optee lacks the implementation of FFA_MEM_FRAG_RX and FFA_MEM_FRAG_TX ABI in CFG_CORE_SEL2_SPMC enable case. Is there any support plan for the implementation of fragmented memory retrieve in the optee community? Does the hafnium community have a plan to implement it cooperatively? Thanks a lot for your support. Regards, Yuye. ------------------------------------------------------------------ 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> 发送时间：2023年4月13日(星期四) 15:52 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> 主　题：Re: fragment transmission while retrieving memory Hi Yuye, Jens, For the record, and If I understand properly the last comment in the github issue: OP-TEE is missing the implementation for receipt of a fragmented retrieve response There is no further fix to be done in Hafnium for this specific issue at this moment, please let me know otherwise. Thanks, Olivier. From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> Sent: 12 April 2023 09:27 To: Olivier Deprez <Olivier.Deprez(a)arm.com> Cc: hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> Subject: Re: fragment transmission while retrieving memory Hi, Olivier, In our setup, Hafnium commit: 997476a74571aec4f1a23590d45edf516f3934f4 optee version: 3.20.0 Thanks. Regards, Yuye. ------------------------------------------------------------------ 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> 发送时间：2023年4月12日(星期三) 15:22 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> 主　题：Re: fragment transmission while retrieving memory Hi Yuye, AFAIK concerning Hafnium, fragmented mem sharing is supported for FFA_MEM_SHARE/LEND/DONATE and FFA_MEM_RETRIEVE_RESP. (For the sake of clarity, this isn't supported for FFA_MEM_RETRIEVE_REQ but this shouldn't be a concern as this limitation only exists in the case of mem sharing to multiple borrowers. In your case of a single borrower the mem retrieve req. shouldn't have to be fragmented). Can you tell which hafnium commit hash is used in your setup? At the moment, I cannot tell if the issue described concern a miss in Hafnium or OP-TEE. I need to dig a bit further into both implementations and I'll let you know. Regards, Olivier. From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> Sent: 12 April 2023 08:21 To: Olivier Deprez <Olivier.Deprez(a)arm.com> Cc: hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> Subject: fragment transmission while retrieving memory Hi, Olivier, Recently, I've been working on this issue. https://github.com/OP-TEE/optee_os/issues/5943 <https://github.com/OP-TEE/optee_os/issues/5943 > Do you know any differences between hafnium's current implementation of fragment transmission while retrieving memory and the example process described in FF-A 1.1 Figure 18.4? Regards, Yuye.

2 years

2
1
0 0

Re: fragment transmission while retrieving memory

by 梅建强(禹夜)

Hi, Olivier, In our setup, Hafnium commit: 997476a74571aec4f1a23590d45edf516f3934f4 optee version: 3.20.0 Thanks. Regards, Yuye. ------------------------------------------------------------------ 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> 发送时间：2023年4月12日(星期三) 15:22 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> 主　题：Re: fragment transmission while retrieving memory Hi Yuye, AFAIK concerning Hafnium, fragmented mem sharing is supported for FFA_MEM_SHARE/LEND/DONATE and FFA_MEM_RETRIEVE_RESP. (For the sake of clarity, this isn't supported for FFA_MEM_RETRIEVE_REQ but this shouldn't be a concern as this limitation only exists in the case of mem sharing to multiple borrowers. In your case of a single borrower the mem retrieve req. shouldn't have to be fragmented). Can you tell which hafnium commit hash is used in your setup? At the moment, I cannot tell if the issue described concern a miss in Hafnium or OP-TEE. I need to dig a bit further into both implementations and I'll let you know. Regards, Olivier. From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> Sent: 12 April 2023 08:21 To: Olivier Deprez <Olivier.Deprez(a)arm.com> Cc: hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> Subject: fragment transmission while retrieving memory Hi, Olivier, Recently, I've been working on this issue. https://github.com/OP-TEE/optee_os/issues/5943 <https://github.com/OP-TEE/optee_os/issues/5943 > Do you know any differences between hafnium's current implementation of fragment transmission while retrieving memory and the example process described in FF-A 1.1 Figure 18.4? Regards, Yuye.

2 years

2
1
0 0

fragment transmission while retrieving memory

by 梅建强(禹夜)

Hi, Olivier, Recently, I've been working on this issue. https://github.com/OP-TEE/optee_os/issues/5943 <https://github.com/OP-TEE/optee_os/issues/5943 > Do you know any differences between hafnium's current implementation of fragment transmission while retrieving memory and the example process described in FF-A 1.1 Figure 18.4? Regards, Yuye.

2 years

2
1
0 0

Boot arguments for S-EL1 with SPMC at S-EL2

by 梅建强(禹夜)

Hi, Olivier, Whether Boot Information Blob is a file similar to manifest.dtb or sp.pkg? How do I generate this blob? Does it need to be packaged into atf firmware at compile phase？ Thanks. Regards, Yuye. ------------------------------------------------------------------ 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> 发送时间：2023年3月21日(星期二) 22:37 收件人：Jens Wiklander <jens.wiklander(a)linaro.org> 抄　送：hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org>; OP-TEE TrustedFirmware <op-tee(a)lists.trustedfirmware.org> 主　题：Re: [Hafnium] Boot arguments for S-EL1 with SPMC at S-EL2 Hi Jens, See comments inline [OD]. Regards, Olivier. ________________________________ From: Jens Wiklander via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: 21 March 2023 09:30 To: Olivier Deprez <Olivier.Deprez(a)arm.com> Cc: hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org>; OP-TEE TrustedFirmware <op-tee(a)lists.trustedfirmware.org> Subject: [Hafnium] Boot arguments for S-EL1 with SPMC at S-EL2 Hi Olivier, I'm trying to implement a relocatable OP-TEE binary so it can be loaded at different physical addresses without the need to recompile it. This means that in the case with Hafnium when changing "load-address" or "entrypoint-offset" in the OP-TEE SP manifest there's no need to recompile OP-TEE. For this to work OP-TEE must be able to figure out which memory range it's supposed to reside in. [OD] Fair enough, I believe that would conflate into some generic PIE support? I can see how this helps with the multi OP-TEE instances use case, perhaps? Currently, OP-TEE knows the entry point address from PC and "memory size" from X0. However, the "memory size" is from the "load-address" so "entrypoint-offset" must be subtracted from PC in order to know the allocated memory range. Do you have ideas on how OP-TEE at runtime can determine the allocated memory range? [OD] The standard way would be to use the FF-A boot protocol e.g. if you add this to OP-TEE's SP manifest: + /* Boot protocol */ + gp-register-num = <0x0>; + + /* Boot Info */ + boot-info { + compatible = "arm,ffa-manifest-boot-info"; + ffa_manifest; + }; See https://trustedfirmware-a.readthedocs.io/en/latest/components/secure-partit… <https://trustedfirmware-a.readthedocs.io/en/latest/components/secure-partit… > At SP entry, x0 contains the address of a 'Boot Information Blob' (FF-A v1.1 REL0 section 5.4.2) starting with a Boot Information Header (Table 5.9). The SP manifest DT address can be extracted from a Boot Information Descriptor (Table 5.8). Eventually the SP is able to parse its own SP manifest, into which it finds FF-A standard fields (load-address...) in addition to any impdef field added. Note the partition size is not standarded (it should probably be), so for starters you can add your own memsize field. There is some sample usage in TF-a-tests: https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/spm/cactus/cactus_… <https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/spm/cactus/cactus_… > and also in context of EDKII/StMM: https://github.com/odeprez/edk2/commit/7066c913cb227056d68ea99de5e92f2067fe… <https://github.com/odeprez/edk2/commit/7066c913cb227056d68ea99de5e92f2067fe… > Thanks, Jens -- Hafnium mailing list -- hafnium(a)lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave(a)lists.trustedfirmware.org

2 years, 1 month

2
1
0 0

load optee at 36bit address

by 梅建强(禹夜)

Hi, experts, We seem to have solved the problem. This problem is not caused by the load_address of optee, but by the security space configured in the ATF. It seems that the security space we have configured is too large. And why will it causes the problem needs to be further identified. Regards, Yuye. ------------------------------------------------------------------ 发件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 发送时间：2023年3月22日(星期三) 11:50 收件人：Olivier Deprez <Olivier.Deprez(a)arm.com>; Jens Wiklander <jens.wiklander(a)linaro.org> 抄　送：hafnium <hafnium(a)lists.trustedfirmware.org>; op-tee <op-tee(a)lists.trustedfirmware.org> 主　题：load optee at 36bit address Hi, experts, We are currently moving optee to a 36bit address to boot with environment that hafnium runs at sel2 as spmc and optee runs at sel1 as sp. Now we have moved hafnium to 0x880000000 and run successfully. Then we tried moving optee to a 36bit address (0x89000000) as well. Although hafnium and optee were successfully initialized on the primary cpu, psci_cpu_on does not seem to be entered into when the secondary cpu is started. The error is as follows: https://github.com/OP-TEE/optee_os/issues/5895 <https://github.com/OP-TEE/optee_os/issues/5895 > Is there any difference between the two cases where hafnium and optee initialize the secondary cpu with different load_address? The log print shows that the secondary cpu has not entered hafnium. Could Hafnium be affected by the 36bit address when dealing with psci related transactions? Regards, Yuye.

2 years, 1 month

1
0
0 0

load optee at 36bit address

by 梅建强(禹夜)

Hi, Olivier I need to explain the query in more detail. >For building/running hafnium , did you have to apply a change similar to: >https://review.trustedfirmware.org/c/hafnium/hafnium/+/18510 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/18510 > Yes. Some time ago, we used hafnium codebase based on the commit ca03054ba6a351534b93e6d64c12e671578eb340. And I verified the fix. The compilation passed, but the system cannot boot successfully. Later, we updated the hafnium codebase based on the commit dd883207ee9b31c19169adf97c918d561dcb9a5c. And I verified the fix again. The system can boot successfully. Regards, Yuye. ------------------------------------------------------------------ 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> 发送时间：2023年3月23日(星期四) 16:54 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 主　题：Re: load optee at 36bit address Hi Yuye, just to acknowledge receipt of this query. Please accept a slow response as I'm currently away from my office. I will do a few trials at my end to reproduce and try to help at my best. For building/running hafnium , did you have to apply a change similar to: https://review.trustedfirmware.org/c/hafnium/hafnium/+/18510 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/18510 > Regards, Olivier. From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> Sent: 22 March 2023 04:50 To: Olivier Deprez <Olivier.Deprez(a)arm.com>; Jens Wiklander <jens.wiklander(a)linaro.org> Cc: hafnium <hafnium(a)lists.trustedfirmware.org>; op-tee <op-tee(a)lists.trustedfirmware.org> Subject: load optee at 36bit address Hi, experts, We are currently moving optee to a 36bit address to boot with environment that hafnium runs at sel2 as spmc and optee runs at sel1 as sp. Now we have moved hafnium to 0x880000000 and run successfully. Then we tried moving optee to a 36bit address (0x89000000) as well. Although hafnium and optee were successfully initialized on the primary cpu, psci_cpu_on does not seem to be entered into when the secondary cpu is started. The error is as follows: https://github.com/OP-TEE/optee_os/issues/5895 <https://github.com/OP-TEE/optee_os/issues/5895 > Is there any difference between the two cases where hafnium and optee initialize the secondary cpu with different load_address? The log print shows that the secondary cpu has not entered hafnium. Could Hafnium be affected by the 36bit address when dealing with psci related transactions? Regards, Yuye. 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.

2 years, 1 month

1
0
0 0

OP-TEE SP / FF-A v1.1 mem sharing structs

by Olivier Deprez

Hi Jens, We're preparing for the Hafnium changes introducing FF-A v1.1 mem sharing structures, up to: https://review.trustedfirmware.org/c/hafnium/hafnium/+/17399 This is done in a backwards compatible manner, in which a FF-A v1.0 endpoint can still use former mem sharing struct definitions. The requirement is that the endpoint provides the right version either by its manifest, or by calling FFA_VERSION when booted. In order for this transition to happen smoothly it would require OP-TEE to declare the v1.0 version here: https://github.com/jenswi-linaro/build/blob/qemu_sel2/qemu_v8/optee_sp_mani… or call FFA_VERSION first thing: diff --git a/core/arch/arm/kernel/thread_spmc.c b/core/arch/arm/kernel/thread_spmc.c index 240bcffe..893cb63b 100644 --- a/core/arch/arm/kernel/thread_spmc.c +++ b/core/arch/arm/kernel/thread_spmc.c @@ -1382,6 +1382,18 @@ static uint16_t spmc_get_id(void) return args.a2; } +static uint16_t spmc_version(void) +{ + struct thread_smc_args args = { + .a0 = FFA_VERSION, + .a1 = MAKE_FFA_VERSION(FFA_VERSION_MAJOR, FFA_VERSION_MINOR), + }; + + thread_smccc(&args); + + return (uint16_t)args.a0; +} + static struct ffa_mem_transaction *spmc_retrieve_req(uint64_t cookie) { struct ffa_mem_transaction *trans_descr = nw_rxtx.tx; @@ -1519,6 +1531,10 @@ out: static TEE_Result spmc_init(void) { + DMSG("OP-TEE FF-A version %x, SPMC version %x", + MAKE_FFA_VERSION(FFA_VERSION_MAJOR, FFA_VERSION_MINOR), + spmc_version()); + spmc_rxtx_map(&nw_rxtx); my_endpoint_id = spmc_get_id(); DMSG("My endpoint ID %#x", my_endpoint_id); I also noticed PR #5359 introducing the v1.1 mem sharing structures, so this may be another way forward that I did not investigate. https://github.com/jenswi-linaro/optee_os/commit/ddd107f019386d035488e3b4e7… Let me know your opinions. Regards, Olivier.

2 years, 1 month

2
1
0 0

Boot arguments for S-EL1 with SPMC at S-EL2

by Jens Wiklander

Hi Olivier, I'm trying to implement a relocatable OP-TEE binary so it can be loaded at different physical addresses without the need to recompile it. This means that in the case with Hafnium when changing "load-address" or "entrypoint-offset" in the OP-TEE SP manifest there's no need to recompile OP-TEE. For this to work OP-TEE must be able to figure out which memory range it's supposed to reside in. Currently, OP-TEE knows the entry point address from PC and "memory size" from X0. However, the "memory size" is from the "load-address" so "entrypoint-offset" must be subtracted from PC in order to know the allocated memory range. Do you have ideas on how OP-TEE at runtime can determine the allocated memory range? Thanks, Jens

2 years, 1 month

2
2
0 0

load optee at 36bit address

by 梅建强(禹夜)

Hi, experts, We are currently moving optee to a 36bit address to boot with environment that hafnium runs at sel2 as spmc and optee runs at sel1 as sp. Now we have moved hafnium to 0x880000000 and run successfully. Then we tried moving optee to a 36bit address (0x89000000) as well. Although hafnium and optee were successfully initialized on the primary cpu, psci_cpu_on does not seem to be entered into when the secondary cpu is started. The error is as follows: https://github.com/OP-TEE/optee_os/issues/5895 <https://github.com/OP-TEE/optee_os/issues/5895 > Is there any difference between the two cases where hafnium and optee initialize the secondary cpu with different load_address? The log print shows that the secondary cpu has not entered hafnium. Could Hafnium be affected by the 36bit address when dealing with psci related transactions? Regards, Yuye.

2 years, 1 month

1
0
0 0

Re: optee xtest cannot run success stably

by 梅建强(禹夜)

Hi, Jens, We seem to have found the answer following the comment you gave in the issue: https://github.com/OP-TEE/optee_os/issues/5877 <https://github.com/OP-TEE/optee_os/issues/5877 > The reason seems to be that the system has more non-secure memory than what OP-TEE is aware of. When our system memory DRAM size is 32GB, optee has the following configuration for non-secure state memory: #define DRAM1_BASE 0x880000000UL #define DRAM1_SIZE 0x780000000UL On another device, our system memory DRAM size is 64G, optee uses the above configuration for non-secure memory. And xtest will not run stably. In addition, I would like to ask you a few questions in order to understand the problem better. 1. System has more non-secure memory than what OP-TEE is aware of, and optee will not run stably. Why? What is the root cause of TEEC_ERROR_OUT_OF_MEMORY on the issue? I'll do some research on it myself, meanwhile I hope you could give us some insights. 2. When I execute the following command, for i in {1.. 10}; do ./xtest&; done; xtest prints out of order, And the following error is reported: E/TC:032 002 mobj_ffa_get_by_cookie:356 possible spinlock deadlock reminder 1 E/TC:070 mobj_ffa_unregister_by_cookie:310 possible spinlock deadlock reminder 1 E/TC:004 003 mobj_ffa_get_by_cookie:356 possible spinlock deadlock reminder 1 E/TC:058 001 mobj_ffa_get_by_cookie:356 possible spinlock deadlock reminder 1 Then the system hangs and restarts automatically. Does optee currently support running multiple TAs in parallel? Is the maximum number of TAs running in parallel equal to the number of vcpus? 3. The values of MAX_XLAT_TABLES and CFG_CORE_HEAP_SIZE also seem to affect the stability of the system. What configurations, such as the number of cores, should I pay attention to if I want to configure appropriate values for these options? Thanks a lot. Regards, Yuye. ------------------------------------------------------------------ 发件人：Jens Wiklander <jens.wiklander(a)linaro.org> 发送时间：2023年3月20日(星期一) 15:05 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org>; op-tee <op-tee(a)lists.trustedfirmware.org> 主　题：Re: optee xtest cannot run success stably Hi Yuye, Comment below. On Mon, Mar 20, 2023 at 4:43 AM 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> wrote: > Hi, experts > > Recently, we are testing the stability for running optee xtest with environment that hafnium runs as SPMC and optee runs on SPMC as SP. > When we reboot the system, xtest failed on some cases with TEEC_ERROR_OUT_OF_MEMORY. > It seems to be that there is an insufficient memory allocation somewhere in the chain. > We tried the following: > Using Single core startup, > Increased optee MAX_XLAT_TABLES size to 16, > Increased optee CFG_CORE_HEAP_SIZE to 0x2000000, > Increasing the size of optee CFG_TEE_RAM_VA_SIZE to 0x4000000, > Increasing the size of hafnium heap_pages to 8192, > But nothing seems to be working. > Can you offer any help or suggestions? It would help if you could pinpoint the source of the out-of-memory error. I guess it happens somewhere during mobj_ffa_get_by_cookie(), where especially thread_spmc_populate_mobj_from_rx() is interesting. It could also be worth setting CFG_CORE_DUMP_OOM=y, it's easy to enable but I'm afraid it's more of a long shot. Cheers, Jens > Some other configuration for optee is attached in the issue: > https://github.com/OP-TEE/optee_os/issues/5893 <https://github.com/OP-TEE/optee_os/issues/5893 > > > Regards, > Yuye. >

2 years, 1 month

2
1
0 0

optee xtest cannot run success stably

by 梅建强(禹夜)

Hi, experts Recently, we are testing the stability for running optee xtest with environment that hafnium runs as SPMC and optee runs on SPMC as SP. When we reboot the system, xtest failed on some cases with TEEC_ERROR_OUT_OF_MEMORY. It seems to be that there is an insufficient memory allocation somewhere in the chain. We tried the following: Using Single core startup, Increased optee MAX_XLAT_TABLES size to 16, Increased optee CFG_CORE_HEAP_SIZE to 0x2000000, Increasing the size of optee CFG_TEE_RAM_VA_SIZE to 0x4000000, Increasing the size of hafnium heap_pages to 8192, But nothing seems to be working. Can you offer any help or suggestions? Some other configuration for optee is attached in the issue: https://github.com/OP-TEE/optee_os/issues/5893 <https://github.com/OP-TEE/optee_os/issues/5893 > Regards, Yuye.

2 years, 1 month

2
1
0 0

Removing support for HF_DEBUG_LOG

by Kathleen Capella

Hi, With the introduction of FFA_CONSOLE_LOG ABI [1], we are intending to replace and remove support for HF_DEBUG_LOG. This proposal is in review in the following stages: 1) Remove the dependency of hftest VMs on HF_DEBUG_LOG and move to FFA_CONSOLE_LOG [2] 2) Remove the support for HF_DEBUG_LOG (i.e. api_debug_log) from hafnium project. [3] The adoption of FFA_CONSOLE_LOG will allow us to make use of its ability to log multiple characters at a time, as opposed to HF_DEBUG_LOG which writes one character at a time. This improvement will be enabled in a future patch. Also, should [3] be adopted, we will make accompanying changes to tf-a-tests Cactus-based tests. We want to know if there are any concerns about removing support for HF_DEBUG_LOG at this time as we realize other downstream SPs may rely on its support. Thank you, Kathleen Capella [1] feat(console_log): add FFA_CONSOLE_LOG ABI https://review.trustedfirmware.org/c/hafnium/hafnium/+/15334 [2] feat(ffa_console_log): replace hf_debug_log https://review.trustedfirmware.org/c/hafnium/hafnium/+/19513 [3] refactor: remove support for HF_DEBUG_LOG https://review.trustedfirmware.org/c/hafnium/hafnium/+/19681

2 years, 1 month

3
3
0 0

Re: Multi-OPTEE run with Hafnium

by 梅建强(禹夜)

Hi, Olivier I have forgotten one thing, hafnium will invalidate the data cache for the whole image. adrp x0, ORIGIN_ADDRESS adrp x1, image_end sub x1, x1, x0 bl arch_cache_data_invalidate_range I solved this problem by using an address-fixed variable outside the data section instead of the global variabal malloced in data section. In addition, I would like to ask that if multiple optees run on the Hafnium, how to switch the vCPUs of different optees? If one of the optees is expected to be boot under the host OS (post-boot load), how to switch the vCPUs? Thanks for the support. Regards, Yuye. ------------------------------------------------------------------ 发件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 发送时间：2023年3月11日(星期六) 21:36 收件人：Olivier Deprez <Olivier.Deprez(a)arm.com> 抄　送：Jens Wiklander <jens.wiklander(a)linaro.org>; hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org> 主　题：Re: Multi-OPTEE run with Hafnium Hi, Olivier, The framework message definition that I mentioned is refered in the FF-A Specification. I hope I didn't misinterpret it. The work flow is interpreted as follows: When the system run into the host OS, I want implemented the post-boot load optee as mentioned in the email with Hafnium as SPMC https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/18635 <https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/18635 > However, when the intialization about hafnium and optee has been finished, SMC_RET8 instruction failed reback from spmd to optee driver. I suspect that there may be some special handling of context needed here. Can you provide some suggestions or help? Regards, Yuye. ------------------------------------------------------------------ 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> 发送时间：2023年3月7日(星期二) 16:55 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：Jens Wiklander <jens.wiklander(a)linaro.org>; hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org> 主　题：Re: Multi-OPTEE run with Hafnium Hi Yuye, I sense those questions are related to downstream changes of yours, and I may not be able to provide accurate answers without seeing the code. Please clarify if the questions are related to the upstream version of Hafnium. See additional comments below [OD]. Regards, Olivier. From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> Sent: 06 March 2023 14:15 To: Olivier Deprez <Olivier.Deprez(a)arm.com> Cc: Jens Wiklander <jens.wiklander(a)linaro.org> Subject: Re: Multi-OPTEE run with Hafnium Hi, Olivier, On this question, I should add something based on the results of my tests. When I enter Hafnium through framwork message, the value of the global variable remains the same. [OD] please explain what is a framework message. When I re-enter the Hafnium image_entry via spmd_init, the global variable is restored to its original value. [OD] I'm not sure about the flow here, it depends about where the variable is declared and whether you have local changes to the hafnium boot flows. Do you know why? Regards, Yuye. ------------------------------------------------------------------ 发件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 发送时间：2023年3月6日(星期一) 17:00 收件人：Olivier Deprez <olivier.deprez(a)arm.com> 抄　送：Jens Wiklander <jens.wiklander(a)linaro.org> 主　题：Multi-OPTEE run with Hafnium Hi, Olivier, I want to ask a question about variable modification. Before this, let me explain the background about the question. Now, I have run into host OS with Hafnium as spmc and OPTEE as SP. Then the optee driver will send a framwork message to Hafnium to inform it that whether the current state of the host OS is booting or running, [OD] What is a 'framework message' in this context? Is this a custom direct request from driver to optee? so that Hafnium could know which vm node(SP) it should load and init at current state. [OD] Can you please explain why this is required? This current state is represented by a global variable. [OD] do you mean a variable in Hafnium's BSS space? Will the global variable change when message flow exit Hafnium and enter it again? [OD] This depends in which section the variable is declared (see above). Regards, Yuye.

2 years, 1 month

3
2
0 0

Re: Multi-OPTEE run with Hafnium

by 梅建强(禹夜)

Hi, Olivier, The framework message definition that I mentioned is refered in the FF-A Specification. I hope I didn't misinterpret it. The work flow is interpreted as follows: When the system run into the host OS, I want implemented the post-boot load optee as mentioned in the email with Hafnium as SPMC https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/18635 <https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/18635 > However, when the intialization about hafnium and optee has been finished, SMC_RET8 instruction failed reback from spmd to optee driver. I suspect that there may be some special handling of context needed here. Can you provide some suggestions or help? Regards, Yuye. ------------------------------------------------------------------ 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> 发送时间：2023年3月7日(星期二) 16:55 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：Jens Wiklander <jens.wiklander(a)linaro.org>; hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org> 主　题：Re: Multi-OPTEE run with Hafnium Hi Yuye, I sense those questions are related to downstream changes of yours, and I may not be able to provide accurate answers without seeing the code. Please clarify if the questions are related to the upstream version of Hafnium. See additional comments below [OD]. Regards, Olivier. From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> Sent: 06 March 2023 14:15 To: Olivier Deprez <Olivier.Deprez(a)arm.com> Cc: Jens Wiklander <jens.wiklander(a)linaro.org> Subject: Re: Multi-OPTEE run with Hafnium Hi, Olivier, On this question, I should add something based on the results of my tests. When I enter Hafnium through framwork message, the value of the global variable remains the same. [OD] please explain what is a framework message. When I re-enter the Hafnium image_entry via spmd_init, the global variable is restored to its original value. [OD] I'm not sure about the flow here, it depends about where the variable is declared and whether you have local changes to the hafnium boot flows. Do you know why? Regards, Yuye. ------------------------------------------------------------------ 发件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 发送时间：2023年3月6日(星期一) 17:00 收件人：Olivier Deprez <olivier.deprez(a)arm.com> 抄　送：Jens Wiklander <jens.wiklander(a)linaro.org> 主　题：Multi-OPTEE run with Hafnium Hi, Olivier, I want to ask a question about variable modification. Before this, let me explain the background about the question. Now, I have run into host OS with Hafnium as spmc and OPTEE as SP. Then the optee driver will send a framwork message to Hafnium to inform it that whether the current state of the host OS is booting or running, [OD] What is a 'framework message' in this context? Is this a custom direct request from driver to optee? so that Hafnium could know which vm node(SP) it should load and init at current state. [OD] Can you please explain why this is required? This current state is represented by a global variable. [OD] do you mean a variable in Hafnium's BSS space? Will the global variable change when message flow exit Hafnium and enter it again? [OD] This depends in which section the variable is declared (see above). Regards, Yuye.

2 years, 1 month

1
0
0 0

Re: ffa memory problems ask for help

by Wangyuan (ange, IT)

Hi, Olivier, It means fail in ffa_send_check_transition call. Current my new problem is orig_from_mode error in ffa_send_check_transition and ffa_relinquish_check_trasition, orig_to_mode error in ffa_retrirvr_check_transition. When I run crypto xtest case in optee, there is a possibility that the check fail to be triggered. Such as: [cid:image001.png@01D951B0.8B2CC000] [cid:image002.png@01D951B0.8B2CC000] [cid:image003.jpg@01D951B1.0F4DF9D0] I'm guessing it has something to do with the fact that I don't have a VM on the ree side. Do you have some ideas about this scenario. Regards, Wangyuan 发件人: Olivier Deprez [mailto:Olivier.Deprez@arm.com] 发送时间: 2023年3月7日 20:35 收件人: Wangyuan (ange, IT) <wangyuan46(a)huawei.com> 抄送: zhouguangwei (C) <zhouguangwei5(a)huawei.com>; lingmingqiang <lingmingqiang(a)huawei.com>; hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> 主题: Re: ffa memory problems ask for help Hi Wangyuan, I believe it's likely that problem 1 is a side effect of problem 2. My guess is, after the maximum heap pages count is reached because of problem 2, it may lead to problem 1. For the sake of completion for problem 1, when you say 'mask the exception handling of this branch', does this mean that Hafnium hits some S2 page fault, or panics? Regards, Olivier. ________________________________ From: Wangyuan (ange, IT) <wangyuan46(a)huawei.com<mailto:wangyuan46@huawei.com>> Sent: 07 March 2023 12:33 To: Olivier Deprez <Olivier.Deprez(a)arm.com<mailto:Olivier.Deprez@arm.com>> Cc: zhouguangwei (C) <zhouguangwei5(a)huawei.com<mailto:zhouguangwei5@huawei.com>>; lingmingqiang <lingmingqiang(a)huawei.com<mailto:lingmingqiang@huawei.com>>; hafnium <hafnium(a)lists.trustedfirmware.org<mailto:hafnium@lists.trustedfirmware.org>>; Jens Wiklander <jens.wiklander(a)linaro.org<mailto:jens.wiklander@linaro.org>> Subject: Re: ffa memory problems ask for help Hi, Olivier, Thank you for replying. For the question 1, I don’t have a better idea. Currently, I temporarily mask the exception handling of this branch. When a problem occurs, I only print error information. The log is as follows: ERROR: mm_ptable_get_attrs_level table 0x82084032000 begin 0x7b98e000 end 0x7b990000 max_level 3 attrs 0x820840f8bf8 fail! For the question 2, I’ve solved the problem by modifying the parameter heap_pages from 60 to 180. After question 2 fixed, problem 1 seems to disappear. Regards, Wangyuan 发件人: Wangyuan (ange, IT) 发送时间: 2023年3月7日 19:30 收件人: 'Olivier Deprez' <Olivier.Deprez(a)arm.com<mailto:Olivier.Deprez@arm.com>> 抄送: zhouguangwei (C) <zhouguangwei5(a)huawei.com<mailto:zhouguangwei5@huawei.com>>; lingmingqiang <lingmingqiang(a)huawei.com<mailto:lingmingqiang@huawei.com>>; hafnium <hafnium(a)lists.trustedfirmware.org<mailto:hafnium@lists.trustedfirmware.org>>; Jens Wiklander <jens.wiklander(a)linaro.org<mailto:jens.wiklander@linaro.org>> 主题: 答复: ffa memory problems ask for help Hi, Olivier, Thank you for replying. For the question 1, I don’t have a better idea. Currently, I temporarily mask the exception handling of this branch. When a problem occurs, I only print error information. The log is as follows: ERROR: mm_ptable_get_attrs_level table 0x82084032000 begin 0x7b98e000 end 0x7b990000 max_level 3 attrs 0x820840f8bf8 fail! For the question 2, I’ve solved the problem by modifying the parameter heap_pages from 60 to 180. After question 2 fixed, problem 1 seems to disappear. Regards, Wangyuan 发件人: Olivier Deprez [mailto:Olivier.Deprez@arm.com] 发送时间: 2023年3月7日 18:10 收件人: Wangyuan (ange, IT) <wangyuan46(a)huawei.com<mailto:wangyuan46@huawei.com>> 抄送: zhouguangwei (C) <zhouguangwei5(a)huawei.com<mailto:zhouguangwei5@huawei.com>>; lingmingqiang <lingmingqiang(a)huawei.com<mailto:lingmingqiang@huawei.com>>; hafnium <hafnium(a)lists.trustedfirmware.org<mailto:hafnium@lists.trustedfirmware.org>>; Jens Wiklander <jens.wiklander(a)linaro.org<mailto:jens.wiklander@linaro.org>> 主题: Re: ffa memory problems ask for help Hi Wangyuan, Sorry for the delay. In case those issues are still relevant, problem 1: AFAIU the error message comes from additional code added on top of upstream hafnium. I cannot see a question related to problem 1, can you please elaborate about what you think is an issue? problem 2: This is probably caused by lacking "heap space", and the mm lib cannot allocate additional page tables. Did you attempt adjusting (increasing) this property for your project target: https://git.trustedfirmware.org/hafnium/project/reference.git/tree/BUILD.gn… Regards, Olivier. ________________________________ From: Wangyuan (ange, IT) <wangyuan46(a)huawei.com<mailto:wangyuan46@huawei.com>> Sent: 14 February 2023 04:32 To: hafnium <hafnium(a)lists.trustedfirmware.org<mailto:hafnium@lists.trustedfirmware.org>>; Olivier Deprez <Olivier.Deprez(a)arm.com<mailto:Olivier.Deprez@arm.com>>; Jens Wiklander <jens.wiklander(a)linaro.org<mailto:jens.wiklander@linaro.org>> Cc: zhouguangwei (C) <zhouguangwei5(a)huawei.com<mailto:zhouguangwei5@huawei.com>>; lingmingqiang <lingmingqiang(a)huawei.com<mailto:lingmingqiang@huawei.com>> Subject: ffa memory problems ask for help Hi, expert When I built test environment with hafnium v2.7 and optee 3.20.0, then execute xtest crypto cases repeatedly, several problems happened. Could you please give us some help? debug log is as follows: problem 1: regression_40VERBOSE: hafnium func 0x84000073, vm->id 0x0, args->arg1 0x50, args->arg2 0x50, args->arg3 0x0, args->arg4 0x0 Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 0 retrieved, sender's original mode: 0x7 07_ecc Test TEE Internal API Generate ECC key VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000000, args->arg4 0x0 E/TC:000 00 mobj_ffa_get_by_cookie:384 Populating mobj from rx buffer, cookie 0 VERBOSE: hafnium func 0x84000074, vm->id 0x8001, args->arg1 0x30, args->arg2 0x30, args->arg3 0x0, args->arg4 0x0 Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 0 retrieved, sender's original mode: 0x7 Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 VERBOSE: hafnium func 0x84000065, vm->id 0x8001, args->arg1 0x0, args->arg2 0x0, args->arg3 0x0, args->arg4 0x0 D/TC:??? 00 tee_ta_init_pseudo_ta_session:296 Lookup pseudo TA cb3e5ba0-adf1-11e0-998b-0002a5d5c51b D/TC:000 00 ldelf_load_ldelf:96 ldelf load address 0x40002000 D/LD: ldelf:134 Loading TS cb3e5ba0-adf1-11e0-998b-0002a5d5c51b F/TC:??? 00 trace_syscall:190 syscall #3 (syscall_get_property) F/TC:??? 00 trace_syscall:190 syscall #5 (syscall_open_ta_session) D/TC:??? 00 ldelf_syscall_open_bin:142 Lookup user TA ELF cb3e5ba0-adf1-11e0-998b-0002a5d5c51b (Secure Storage TA) VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x84000073, vm->id 0x0, args->arg1 0x50, args->arg2 0x50, args->arg3 0x0, args->arg4 0x0 Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 0 retrieved, sender's original mode: 0x7 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 E/TC:000 00 mobj_ffa_get_by_cookie:384 Populating mobj from rx buffer, cookie 0x1 VERBOSE: hafnium func 0x84000074, vm->id 0x8001, args->arg1 0x30, args->arg2 0x30, args->arg3 0x0, args->arg4 0x0 Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 0 retrieved, sender's original mode: 0x7 Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 VERBOSE: hafnium func 0x84000065, vm->id 0x8001, args->arg1 0x0, args->arg2 0x0, args->arg3 0x0, args->arg4 0x0 VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 I/TC: Cipher free ctx done! I/TC: Performing software calc! I/TC: Aead free ctx done! VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 I/TC: Performing software calc! I/TC: Aead free ctx done! VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 I/TC: Performing software calc! I/TC: Aead free ctx done! VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 I/TC: Performing software calc! I/TC: Aead free ctx done! VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 I/TC: Cipher free ctx done! I/TC: Performing software calc! I/TC: Aead free ctx done! VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 D/TC:??? 00 ldelf_syscall_open_bin:146 res=0xffff0008 D/TC:??? 00 ldelf_syscall_open_bin:142 Lookup user TA ELF cb3e5ba0-adf1-11e0-998b-0002a5d5c51b (REE) VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x84000073, vm->id 0x0, args->arg1 0x270, args->arg2 0x270, args->arg3 0x0, args->arg4 0x0 ERROR: arch_mm_pte_attrs error! INFO: begin 0x7f3cf000 end 0x7f3d0000 level 0 pte 0x82084059e78 l_end 0x7f400000 entry_size 0x1000! ERROR: mm_ptable_get_attrs_level second error! INFO: begin 0x7f3ce000 end 0x7f3d0000 level 1 pte 0x82084052fc8 l_end 0x80000000 entry_size 0x200000! ERROR: mm_ptable_get_attrs_level second error! INFO: begin 0x7f3ce000 end 0x7f3d0000 level 2 pte 0x82084051008 l_end 0x8000000000 entry_size 0x40000000! ERROR: mm_ptable_get_attrs_level second error! INFO: begin 0x7f3ce000 end 0x7f3d0000 level 3 pte 0x82084035000 l_end 0x1000000000000 entry_size 0x8000000000! ERROR: mm_ptable_get_attrs_level fail! Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x2 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 0 retrieved, sender's original mode: 0x7 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 E/TC:000 00 mobj_ffa_get_by_cookie:384 Populating mobj from rx buffer, cookie 0x2 VERBOSE: hafnium func 0x84000074, vm->id 0x8001, args->arg1 0x30, args->arg2 0x30, args->arg3 0x0, args->arg4 0x0 Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x2 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 0 retrieved, sender's original mode: 0x7 Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x2 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 VERBOSE: hafnium func 0x84000065, vm->id 0x8001, args->arg1 0x0, args->arg2 0x0, args->arg3 0x0, args->arg4 0x0 VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 D/TC:??? 00 ldelf_syscall_open_bin:146 res=0 Problem2: VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 I/TC: Cipher free ctx done! I/TC: Performing software calc! I/TC: Aead free ctx done! VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 D/TC:??? 00 ldelf_syscall_open_bin:146 res=0xffff0008 D/TC:??? 00 ldelf_syscall_open_bin:142 Lookup user TA ELF cb3e5ba0-adf1-11e0-998b-0002a5d5c51b (REE) VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x84000073, vm->id 0x0, args->arg1 0x270, args->arg2 0x270, args->arg3 0x0, args->arg4 0x0 Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x2 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 0 retrieved, sender's original mode: 0x7 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 E/TC:000 00 mobj_ffa_get_by_cookie:384 Populating mobj from rx buffer, cookie 0x2 VERBOSE: hafnium func 0x84000074, vm->id 0x8001, args->arg1 0x30, args->arg2 0x30, args->arg3 0x0, args->arg4 0x0 Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x2 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 0 retrieved, sender's original mode: 0x7 ERROR: Failed to allocate memory for page table VERBOSE: Insufficient memory to update recipient page table. Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x2 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 0 retrieved, sender's original mode: 0x7 E/TC:000 00 spmc_retrieve_req:1418 Failed to fetch cookie 0x2 error code -3 E/TC:000 00 thread_spmc_populate_mobj_from_rx:1486 Failed to retrieve cookie from rx buffer 0x2 E/TC:??? 00 mobj_ffa_get_by_cookie:423 Failed to get cookie 0x2 internal_offs 0 D/TC:??? 00 thread_rpc_alloc:1261 mobj_ffa_get_by_cookie(0x2, 0): failed D/TC:??? 00 ldelf_syscall_open_bin:146 res=0xffff000c Can anyone figure out what the problem is and give some debugging directions? Thanks! regards, wangyuan

2 years, 2 months

1
0
0 0

Re: ffa memory problems ask for help

by Wangyuan (ange, IT)

Hi, Olivier, Thank you for replying. For the question 1, I don’t have a better idea. Currently, I temporarily mask the exception handling of this branch. When a problem occurs, I only print error information. The log is as follows: ERROR: mm_ptable_get_attrs_level table 0x82084032000 begin 0x7b98e000 end 0x7b990000 max_level 3 attrs 0x820840f8bf8 fail! For the question 2, I’ve solved the problem by modifying the parameter heap_pages from 60 to 180. After question 2 fixed, problem 1 seems to disappear. Regards, Wangyuan 发件人: Wangyuan (ange, IT) 发送时间: 2023年3月7日 19:30 收件人: 'Olivier Deprez' <Olivier.Deprez(a)arm.com> 抄送: zhouguangwei (C) <zhouguangwei5(a)huawei.com>; lingmingqiang <lingmingqiang(a)huawei.com>; hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> 主题: 答复: ffa memory problems ask for help Hi, Olivier, Thank you for replying. For the question 1, I don’t have a better idea. Currently, I temporarily mask the exception handling of this branch. When a problem occurs, I only print error information. The log is as follows: ERROR: mm_ptable_get_attrs_level table 0x82084032000 begin 0x7b98e000 end 0x7b990000 max_level 3 attrs 0x820840f8bf8 fail! For the question 2, I’ve solved the problem by modifying the parameter heap_pages from 60 to 180. After question 2 fixed, problem 1 seems to disappear. Regards, Wangyuan 发件人: Olivier Deprez [mailto:Olivier.Deprez@arm.com] 发送时间: 2023年3月7日 18:10 收件人: Wangyuan (ange, IT) <wangyuan46(a)huawei.com<mailto:wangyuan46@huawei.com>> 抄送: zhouguangwei (C) <zhouguangwei5(a)huawei.com<mailto:zhouguangwei5@huawei.com>>; lingmingqiang <lingmingqiang(a)huawei.com<mailto:lingmingqiang@huawei.com>>; hafnium <hafnium(a)lists.trustedfirmware.org<mailto:hafnium@lists.trustedfirmware.org>>; Jens Wiklander <jens.wiklander(a)linaro.org<mailto:jens.wiklander@linaro.org>> 主题: Re: ffa memory problems ask for help Hi Wangyuan, Sorry for the delay. In case those issues are still relevant, problem 1: AFAIU the error message comes from additional code added on top of upstream hafnium. I cannot see a question related to problem 1, can you please elaborate about what you think is an issue? problem 2: This is probably caused by lacking "heap space", and the mm lib cannot allocate additional page tables. Did you attempt adjusting (increasing) this property for your project target: https://git.trustedfirmware.org/hafnium/project/reference.git/tree/BUILD.gn… Regards, Olivier. ________________________________ From: Wangyuan (ange, IT) <wangyuan46(a)huawei.com<mailto:wangyuan46@huawei.com>> Sent: 14 February 2023 04:32 To: hafnium <hafnium(a)lists.trustedfirmware.org<mailto:hafnium@lists.trustedfirmware.org>>; Olivier Deprez <Olivier.Deprez(a)arm.com<mailto:Olivier.Deprez@arm.com>>; Jens Wiklander <jens.wiklander(a)linaro.org<mailto:jens.wiklander@linaro.org>> Cc: zhouguangwei (C) <zhouguangwei5(a)huawei.com<mailto:zhouguangwei5@huawei.com>>; lingmingqiang <lingmingqiang(a)huawei.com<mailto:lingmingqiang@huawei.com>> Subject: ffa memory problems ask for help Hi, expert When I built test environment with hafnium v2.7 and optee 3.20.0, then execute xtest crypto cases repeatedly, several problems happened. Could you please give us some help? debug log is as follows: problem 1: regression_40VERBOSE: hafnium func 0x84000073, vm->id 0x0, args->arg1 0x50, args->arg2 0x50, args->arg3 0x0, args->arg4 0x0 Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 0 retrieved, sender's original mode: 0x7 07_ecc Test TEE Internal API Generate ECC key VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000000, args->arg4 0x0 E/TC:000 00 mobj_ffa_get_by_cookie:384 Populating mobj from rx buffer, cookie 0 VERBOSE: hafnium func 0x84000074, vm->id 0x8001, args->arg1 0x30, args->arg2 0x30, args->arg3 0x0, args->arg4 0x0 Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 0 retrieved, sender's original mode: 0x7 Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 VERBOSE: hafnium func 0x84000065, vm->id 0x8001, args->arg1 0x0, args->arg2 0x0, args->arg3 0x0, args->arg4 0x0 D/TC:??? 00 tee_ta_init_pseudo_ta_session:296 Lookup pseudo TA cb3e5ba0-adf1-11e0-998b-0002a5d5c51b D/TC:000 00 ldelf_load_ldelf:96 ldelf load address 0x40002000 D/LD: ldelf:134 Loading TS cb3e5ba0-adf1-11e0-998b-0002a5d5c51b F/TC:??? 00 trace_syscall:190 syscall #3 (syscall_get_property) F/TC:??? 00 trace_syscall:190 syscall #5 (syscall_open_ta_session) D/TC:??? 00 ldelf_syscall_open_bin:142 Lookup user TA ELF cb3e5ba0-adf1-11e0-998b-0002a5d5c51b (Secure Storage TA) VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x84000073, vm->id 0x0, args->arg1 0x50, args->arg2 0x50, args->arg3 0x0, args->arg4 0x0 Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 0 retrieved, sender's original mode: 0x7 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 E/TC:000 00 mobj_ffa_get_by_cookie:384 Populating mobj from rx buffer, cookie 0x1 VERBOSE: hafnium func 0x84000074, vm->id 0x8001, args->arg1 0x30, args->arg2 0x30, args->arg3 0x0, args->arg4 0x0 Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 0 retrieved, sender's original mode: 0x7 Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 VERBOSE: hafnium func 0x84000065, vm->id 0x8001, args->arg1 0x0, args->arg2 0x0, args->arg3 0x0, args->arg4 0x0 VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 I/TC: Cipher free ctx done! I/TC: Performing software calc! I/TC: Aead free ctx done! VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 I/TC: Performing software calc! I/TC: Aead free ctx done! VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 I/TC: Performing software calc! I/TC: Aead free ctx done! VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 I/TC: Performing software calc! I/TC: Aead free ctx done! VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 I/TC: Cipher free ctx done! I/TC: Performing software calc! I/TC: Aead free ctx done! VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 D/TC:??? 00 ldelf_syscall_open_bin:146 res=0xffff0008 D/TC:??? 00 ldelf_syscall_open_bin:142 Lookup user TA ELF cb3e5ba0-adf1-11e0-998b-0002a5d5c51b (REE) VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x84000073, vm->id 0x0, args->arg1 0x270, args->arg2 0x270, args->arg3 0x0, args->arg4 0x0 ERROR: arch_mm_pte_attrs error! INFO: begin 0x7f3cf000 end 0x7f3d0000 level 0 pte 0x82084059e78 l_end 0x7f400000 entry_size 0x1000! ERROR: mm_ptable_get_attrs_level second error! INFO: begin 0x7f3ce000 end 0x7f3d0000 level 1 pte 0x82084052fc8 l_end 0x80000000 entry_size 0x200000! ERROR: mm_ptable_get_attrs_level second error! INFO: begin 0x7f3ce000 end 0x7f3d0000 level 2 pte 0x82084051008 l_end 0x8000000000 entry_size 0x40000000! ERROR: mm_ptable_get_attrs_level second error! INFO: begin 0x7f3ce000 end 0x7f3d0000 level 3 pte 0x82084035000 l_end 0x1000000000000 entry_size 0x8000000000! ERROR: mm_ptable_get_attrs_level fail! Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x2 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 0 retrieved, sender's original mode: 0x7 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 E/TC:000 00 mobj_ffa_get_by_cookie:384 Populating mobj from rx buffer, cookie 0x2 VERBOSE: hafnium func 0x84000074, vm->id 0x8001, args->arg1 0x30, args->arg2 0x30, args->arg3 0x0, args->arg4 0x0 Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x2 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 0 retrieved, sender's original mode: 0x7 Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x2 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 VERBOSE: hafnium func 0x84000065, vm->id 0x8001, args->arg1 0x0, args->arg2 0x0, args->arg3 0x0, args->arg4 0x0 VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 D/TC:??? 00 ldelf_syscall_open_bin:146 res=0 Problem2: VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 I/TC: Cipher free ctx done! I/TC: Performing software calc! I/TC: Aead free ctx done! VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 D/TC:??? 00 ldelf_syscall_open_bin:146 res=0xffff0008 D/TC:??? 00 ldelf_syscall_open_bin:142 Lookup user TA ELF cb3e5ba0-adf1-11e0-998b-0002a5d5c51b (REE) VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x84000073, vm->id 0x0, args->arg1 0x270, args->arg2 0x270, args->arg3 0x0, args->arg4 0x0 Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x2 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 0 retrieved, sender's original mode: 0x7 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 E/TC:000 00 mobj_ffa_get_by_cookie:384 Populating mobj from rx buffer, cookie 0x2 VERBOSE: hafnium func 0x84000074, vm->id 0x8001, args->arg1 0x30, args->arg2 0x30, args->arg3 0x0, args->arg4 0x0 Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x2 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 0 retrieved, sender's original mode: 0x7 ERROR: Failed to allocate memory for page table VERBOSE: Insufficient memory to update recipient page table. Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x2 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 0 retrieved, sender's original mode: 0x7 E/TC:000 00 spmc_retrieve_req:1418 Failed to fetch cookie 0x2 error code -3 E/TC:000 00 thread_spmc_populate_mobj_from_rx:1486 Failed to retrieve cookie from rx buffer 0x2 E/TC:??? 00 mobj_ffa_get_by_cookie:423 Failed to get cookie 0x2 internal_offs 0 D/TC:??? 00 thread_rpc_alloc:1261 mobj_ffa_get_by_cookie(0x2, 0): failed D/TC:??? 00 ldelf_syscall_open_bin:146 res=0xffff000c Can anyone figure out what the problem is and give some debugging directions? Thanks! regards, wangyuan

2 years, 2 months

2
1
0 0

ffa memory problems ask for help

by Wangyuan (ange, IT)

Hi, expert When I built test environment with hafnium v2.7 and optee 3.20.0, then execute xtest crypto cases repeatedly, several problems happened. Could you please give us some help? debug log is as follows: problem 1: regression_40VERBOSE: hafnium func 0x84000073, vm->id 0x0, args->arg1 0x50, args->arg2 0x50, args->arg3 0x0, args->arg4 0x0 Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 0 retrieved, sender's original mode: 0x7 07_ecc Test TEE Internal API Generate ECC key VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000000, args->arg4 0x0 E/TC:000 00 mobj_ffa_get_by_cookie:384 Populating mobj from rx buffer, cookie 0 VERBOSE: hafnium func 0x84000074, vm->id 0x8001, args->arg1 0x30, args->arg2 0x30, args->arg3 0x0, args->arg4 0x0 Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 0 retrieved, sender's original mode: 0x7 Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 VERBOSE: hafnium func 0x84000065, vm->id 0x8001, args->arg1 0x0, args->arg2 0x0, args->arg3 0x0, args->arg4 0x0 D/TC:??? 00 tee_ta_init_pseudo_ta_session:296 Lookup pseudo TA cb3e5ba0-adf1-11e0-998b-0002a5d5c51b D/TC:000 00 ldelf_load_ldelf:96 ldelf load address 0x40002000 D/LD: ldelf:134 Loading TS cb3e5ba0-adf1-11e0-998b-0002a5d5c51b F/TC:??? 00 trace_syscall:190 syscall #3 (syscall_get_property) F/TC:??? 00 trace_syscall:190 syscall #5 (syscall_open_ta_session) D/TC:??? 00 ldelf_syscall_open_bin:142 Lookup user TA ELF cb3e5ba0-adf1-11e0-998b-0002a5d5c51b (Secure Storage TA) VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x84000073, vm->id 0x0, args->arg1 0x50, args->arg2 0x50, args->arg3 0x0, args->arg4 0x0 Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 0 retrieved, sender's original mode: 0x7 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 E/TC:000 00 mobj_ffa_get_by_cookie:384 Populating mobj from rx buffer, cookie 0x1 VERBOSE: hafnium func 0x84000074, vm->id 0x8001, args->arg1 0x30, args->arg2 0x30, args->arg3 0x0, args->arg4 0x0 Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 0 retrieved, sender's original mode: 0x7 Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 VERBOSE: hafnium func 0x84000065, vm->id 0x8001, args->arg1 0x0, args->arg2 0x0, args->arg3 0x0, args->arg4 0x0 VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 I/TC: Cipher free ctx done! I/TC: Performing software calc! I/TC: Aead free ctx done! VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 I/TC: Performing software calc! I/TC: Aead free ctx done! VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 I/TC: Performing software calc! I/TC: Aead free ctx done! VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 I/TC: Performing software calc! I/TC: Aead free ctx done! VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 I/TC: Cipher free ctx done! I/TC: Performing software calc! I/TC: Aead free ctx done! VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 D/TC:??? 00 ldelf_syscall_open_bin:146 res=0xffff0008 D/TC:??? 00 ldelf_syscall_open_bin:142 Lookup user TA ELF cb3e5ba0-adf1-11e0-998b-0002a5d5c51b (REE) VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x84000073, vm->id 0x0, args->arg1 0x270, args->arg2 0x270, args->arg3 0x0, args->arg4 0x0 ERROR: arch_mm_pte_attrs error! INFO: begin 0x7f3cf000 end 0x7f3d0000 level 0 pte 0x82084059e78 l_end 0x7f400000 entry_size 0x1000! ERROR: mm_ptable_get_attrs_level second error! INFO: begin 0x7f3ce000 end 0x7f3d0000 level 1 pte 0x82084052fc8 l_end 0x80000000 entry_size 0x200000! ERROR: mm_ptable_get_attrs_level second error! INFO: begin 0x7f3ce000 end 0x7f3d0000 level 2 pte 0x82084051008 l_end 0x8000000000 entry_size 0x40000000! ERROR: mm_ptable_get_attrs_level second error! INFO: begin 0x7f3ce000 end 0x7f3d0000 level 3 pte 0x82084035000 l_end 0x1000000000000 entry_size 0x8000000000! ERROR: mm_ptable_get_attrs_level fail! Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x2 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 0 retrieved, sender's original mode: 0x7 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 E/TC:000 00 mobj_ffa_get_by_cookie:384 Populating mobj from rx buffer, cookie 0x2 VERBOSE: hafnium func 0x84000074, vm->id 0x8001, args->arg1 0x30, args->arg2 0x30, args->arg3 0x0, args->arg4 0x0 Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x2 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 0 retrieved, sender's original mode: 0x7 Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x2 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 VERBOSE: hafnium func 0x84000065, vm->id 0x8001, args->arg1 0x0, args->arg2 0x0, args->arg3 0x0, args->arg4 0x0 VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 D/TC:??? 00 ldelf_syscall_open_bin:146 res=0 Problem2: VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 I/TC: Cipher free ctx done! I/TC: Performing software calc! I/TC: Aead free ctx done! VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 D/TC:??? 00 ldelf_syscall_open_bin:146 res=0xffff0008 D/TC:??? 00 ldelf_syscall_open_bin:142 Lookup user TA ELF cb3e5ba0-adf1-11e0-998b-0002a5d5c51b (REE) VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 VERBOSE: hafnium func 0x84000070, vm->id 0x8001, args->arg1 0x80010000, args->arg2 0x0, args->arg3 0x0, args->arg4 0x1 VERBOSE: hafnium func 0x84000073, vm->id 0x0, args->arg1 0x270, args->arg2 0x270, args->arg3 0x0, args->arg4 0x0 Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x2 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 0 retrieved, sender's original mode: 0x7 VERBOSE: hafnium func 0x8400006f, vm->id 0x0, args->arg1 0x8001, args->arg2 0x0, args->arg3 0x80000001, args->arg4 0x0 E/TC:000 00 mobj_ffa_get_by_cookie:384 Populating mobj from rx buffer, cookie 0x2 VERBOSE: hafnium func 0x84000074, vm->id 0x8001, args->arg1 0x30, args->arg2 0x30, args->arg3 0x0, args->arg4 0x0 Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x2 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 0 retrieved, sender's original mode: 0x7 ERROR: Failed to allocate memory for page table VERBOSE: Insufficient memory to update recipient page table. Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x2 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 0 retrieved, sender's original mode: 0x7 E/TC:000 00 spmc_retrieve_req:1418 Failed to fetch cookie 0x2 error code -3 E/TC:000 00 thread_spmc_populate_mobj_from_rx:1486 Failed to retrieve cookie from rx buffer 0x2 E/TC:??? 00 mobj_ffa_get_by_cookie:423 Failed to get cookie 0x2 internal_offs 0 D/TC:??? 00 thread_rpc_alloc:1261 mobj_ffa_get_by_cookie(0x2, 0): failed D/TC:??? 00 ldelf_syscall_open_bin:146 res=0xffff000c Can anyone figure out what the problem is and give some debugging directions? Thanks! regards, wangyuan

2 years, 2 months

2
1
0 0

Re: xtest 1034

by 梅建强(禹夜)

Hi, Olivier, For the question in part 3, I think I didn't express clearly. >Does Hafnium support the configuration of the location of running memory such as text, data, stacks, and heap? If yes, how? During Hafnium initialization, I can see the following memory spaces about text, rodata, data and stacks. INFO: Initializing Hafnium (SPMC) INFO: text: 0xff200000 - 0xff225000 INFO: rodata: 0xff225000 - 0xff22e000 INFO: data: 0xff22e000 - 0xffbcc000 INFO: stacks: 0xffbd0000 - 0xffcd0000 Are the sizes and start_address of these memory spaces configurable? If yes, how? In addition, I see the configuration of memory node in spmc_optee_sp_manifest.dts, and I modify it as follows: memory@0xFF200000 { device_type = "memory"; reg = <0x0 0xff200000 0x00a00000>, <0x8 0x80000000 0x10000000>;/* Trusted DRAM */ }; Is the modification reasonable? Does this node represent all the memory managed by Hafnium? Should the region specified by the memory node include the optee memory spaces? Regards, Yuye. ------------------------------------------------------------------ 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> 发送时间：2023年2月27日(星期一) 22:13 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：Jens Wiklander <jens.wiklander(a)linaro.org>; hafnium <hafnium(a)lists.trustedfirmware.org> 主　题：Re: [Hafnium] Re: Re: Re: xtest 1034 Hi Yuye, See comments inline [OD] Regards, Olivier. From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> Sent: 27 February 2023 12:52 To: Olivier Deprez <Olivier.Deprez(a)arm.com> Cc: Jens Wiklander <jens.wiklander(a)linaro.org>; hafnium <hafnium(a)lists.trustedfirmware.org> Subject: [Hafnium] Re: Re: Re: xtest 1034 Hi, Olivier, Sorry for ignoring the tips in your email. I guess the question in part 1 is no longer the trouble. [OD]No worries. Regards, Yuye. ------------------------------------------------------------------ 发件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 发送时间：2023年2月27日(星期一) 19:18 收件人：Olivier Deprez <olivier.deprez(a)arm.com> 抄　送：Jens Wiklander <jens.wiklander(a)linaro.org>; hafnium <hafnium(a)lists.trustedfirmware.org> 主　题：[Hafnium] Re: Re: xtest 1034 Hi, Olivier, 1. We solved the problem by update our Hafnium codebase on rebase of commit ca03054ba6a351534b93e6d64c12e671578eb340. The origin Hafnium codebase is on rebase of commit dd883207ee9b31c19169adf97c918d561dcb9a5c. OPTEE codebase stays with version 3.20.0. Which commit can solve this problem is still under investigation. I guess the reason may relate to that Hafnium has updated the implementation of FF-A mechanism in new commit. If you have already known the reason, please tell me. 2. In addition, although some cases run successfully, there are still many error messages generated during their running process, such as the following cases: * regression_1034 Test loading a large TA E/TC:011 0 mobj_ffa_get_by_cookie:384 Populating mobj from rx buffer, cookie 0x1 E/TC:011 0 mobj_ffa_get_by_cookie:384 Populating mobj from rx buffer, cookie 0x3 E/TC:??? 0 mobj_ffa_get_by_cookie:423 Failed to get cookie 0x3 internal_offs 0 E/LD: init_elf:486 sys_open_ta_bin(25497083-a58a-4fc5-8a72-1ad7b69b8562) E/TC:??? 0 ldelf_init_with_ldelf:131 ldelf failed with res: 0xffff000c TEEC_ERROR_OUT_OF_MEMORY - ignored regression_1034 OK [OD] I noticed this some time ago but I believe this might be related to some integration problem (e.g. lacking memory available to linux?) Moreover the test result being ignored suggests that this failure may happen but is eventually harmless from the xtest suite perspective. Jens & Jerome might know better. Note that I'm seeing this test passing with sw stack integrations targeting two different models (qemu and TC). * regression_1022 Test dlopen()/dlsym()/dlclose() API E/TC:011 0 mobj_ffa_get_by_cookie:384 Populating mobj from rx buffer, cookie 0x1 E/TC:011 0 mobj_ffa_get_by_cookie:384 Populating mobj from rx buffer, cookie 0x3 E/TC:011 0 mobj_ffa_get_by_cookie:384 Populating mobj from rx buffer, cookie 0x3 E/TC:011 0 mobj_ffa_get_by_cookie:384 Populating mobj from rx buffer, cookie 0x1 E/TC:011 0 mobj_ffa_get_by_cookie:384 Populating mobj from rx buffer, cookie 0x3 E/TC:??? 0 E/TC:??? 0 TA panicked with code 0x0 E/LD: Status of TA 5b9e0e40-2636-11e1-ad9e-0002a5d5c51b E/LD: arch: aarch64 E/LD: region 0: va 0x40006000 pa 0xf0404000 size 0x002000 flags rw-s (ldelf) E/LD: region 1: va 0x40008000 pa 0xf0406000 size 0x011000 flags r-xs (ldelf) E/LD: region 2: va 0x40019000 pa 0xf0417000 size 0x001000 flags rw-s (ldelf) E/LD: region 3: va 0x4001a000 pa 0xf0418000 size 0x004000 flags rw-s (ldelf) E/LD: region 4: va 0x4001e000 pa 0xf041c000 size 0x001000 flags r--s E/LD: region 5: va 0x4001f000 pa 0xf052e000 size 0x003000 flags rw-s (stack) E/LD: region 6: va 0x40038000 pa 0x00000000 size 0x00f000 flags r-xs [2] E/LD: region 7: va 0x40047000 pa 0x0000e000 size 0x002000 flags rw-s [2] E/LD: region 8: va 0x40054000 pa 0x00000000 size 0x00f000 flags r-xs [1] E/LD: region 9: va 0x40063000 pa 0x0000e000 size 0x002000 flags rw-s [1] E/LD: region 10: va 0x4008b000 pa 0x00001000 size 0x02a000 flags r-xs [0] E/LD: region 11: va 0x400b5000 pa 0x0002b000 size 0x0e7000 flags rw-s [0] E/LD: [0] 5b9e0e40-2636-11e1-ad9e-0002a5d5c51b @ 0x4008b000 E/LD: [1] ffd2bded-ab7d-4988-95ee-e4962fff7154 @ 0x40054000 E/LD: [2] b3091a65-9751-4784-abf7-0298a7cc35ba @ 0x40038000 E/LD: Call stack: E/LD: 0x4009e5a8 E/LD: 0x400a09b8 E/LD: 0x4009ed0c regression_1022 OK The E/TC message generated by mobj_ffa_get_by_cookie appears in almost all cases. Is this related to FFA_MEM_FRAG_RX/TX, or something else? And what is related to the E/LD message? I am currently studying the FFA specification to try to explain these problems. [OD]I have the same logs with qemu and TC platforms. I did not consider the TA panic as an issue provided the regression_1022 test result reports as 'OK'. Actually, that may be an expected behaviour from the test? Again Jens, Jerome, feel free to comment. And some related questions raised in the other email(subject: Hafnium Dynamic Shared Memory). [OD]I will come back to this other email thread, but I don't believe above 'issues' are related. You can tell me if it's convenient for you. 3. Could memory managed by Hafnium be configured in any other way except by spmc manifest? Does Hafnium support the configuration of the location of running memory such as text, data, stacks, and heap? If yes, how? [OD] I'm not sure I understand the question, perhaps can you tell in more details what you want to achieve? Thanks you for your help. Regards, Yuye. ------------------------------------------------------------------ 发件人：Olivier Deprez via Hafnium <hafnium(a)lists.trustedfirmware.org> 发送时间：2023年2月27日(星期一) 17:19 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：hafnium <hafnium(a)lists.trustedfirmware.org> 主　题：[Hafnium] Re: xtest 1034 Hi Yuye, Can you make sure to use hafnium tip of master (if that's not the case)? We confirmed this specific test passes on models from this commit onwards: https://git.trustedfirmware.org/hafnium/hafnium.git/commit/?id=fdd29277caf2… <https://git.trustedfirmware.org/hafnium/hafnium.git/commit/?id=fdd29277caf2… > We may provide further guidance if the issue persists after rebasing. Thanks, Olivier. ________________________________ From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> Sent: 26 February 2023 06:49 To: hafnium <hafnium(a)lists.trustedfirmware.org>; Olivier Deprez <Olivier.Deprez(a)arm.com>; Jens Wiklander <jens.wiklander(a)linaro.org> Subject: xtest 1034 Hi, experts, For dynamic shared memory usage, I am not very clear. So we need to consult you about the related question. I failed to run xtest 1034 when I used Hafnium as SPMC and OPTEE as SP. Here are the debug logs： #./xtest 1034& [2] 10130 Test ID: 1034 Run test suite with level=0 TEE test application started over default TEE instance ###################################################### # # regression # ###################################################### regression_1034 Test loading a large TA WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000000 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f D/TC:055 0 mobj_ffa_get_by_cookie:381 cookie 0 resurrecting D/TC:??? 0 tee_ta_init_pseudo_ta_session:296 Lookup pseudo TA 25497083-a58a-4fc5-8a72-1ad7b69b8562 D/TC:??? 0 ldelf_load_ldelf:96 ldelf load address 0x40008000 D/LD: ldelf:134 Loading TS 25497083-a58a-4fc5-8a72-1ad7b69b8562 F/TC:??? 0 trace_syscall:151 syscall Add constant time memcmp_ct function #3<https://github.com/OP-TEE/optee_os/pull/3> <https://github.com/OP-TEE/optee_os/pull/3> > (syscall_get_property) F/TC:??? 0 trace_syscall:151 syscall GitHub usage documentation #5<https://github.com/OP-TEE/optee_os/pull/5> <https://github.com/OP-TEE/optee_os/pull/5> > (syscall_open_ta_session) #D/TC:??? 0 ldelf_syscall_open_bin:143 Lookup user TA ELF 25497083-a58a-4fc5-8a72-1ad7b69b8562 (early TA) D/TC:??? 0 ldelf_syscall_open_bin:146 res=0xffff0008 D/TC:??? 0 ldelf_syscall_open_bin:143 Lookup user TA ELF 25497083-a58a-4fc5-8a72-1ad7b69b8562 (Secure Storage TA) VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(60): 0x84000073 0x50 0x50 0x0 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x84000073 VERBOSE: Marked sending complete. Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 0 retrieved, sender's original mode: 0x7 WARNING: Atf_Debug(60): 0x84000061 0x0 0x1 0x0 0x0 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f E/TC:055 0 mobj_ffa_get_by_cookie:384 Populating mobj from rx buffer, cookie 0x1 VERBOSE: Hafnium_Debug ffa_handler func:0x84000074 Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 0 retrieved, sender's original mode: 0x7 Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 VERBOSE: Hafnium_Debug ffa_handler func:0x84000065 VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f D/TC:??? 0 ldelf_syscall_open_bin:146 res=0xffff0008 D/TC:??? 0 ldelf_syscall_open_bin:143 Lookup user TA ELF 25497083-a58a-4fc5-8a72-1ad7b69b8562 (REE) VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(58): 0x84000073 0x1190 0x1000 0x0 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x84000073 Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x2 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): partially sent with 1 fragments, 0 retrieved, sender's original mode: 0x7 WARNING: Atf_Debug(58): 0x8400007a 0x2 0x0 0x1000 0x0 0x0 0x0 0x0 WARNING: Atf_Debug(58): 0x8400007b 0x2 0x0 0x190 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400007b VERBOSE: Hafnium_Debug fragment_length:0x190 VERBOSE: Hafnium_Debug fragment_copy:00000000ff30e000, from_msg:00000008bdd48000 ERROR: Data abort: pc=0xff21a688, esr=0x96000006, ec=0x25, far=0x9c Panic: EL2 exception the error occured when Hafnium run the code: api_ffa_mem_frag_tx memcpy_s(fragment_copy, MM_PPOOL_ENTRY_SIZE, from_msg, fragment_length); It seems that I did not add the page table at 0x00000000ff30e000 or 0x00000008bdd48000, but I am not quite clear about what fragment_copy and from_msg mean. Can someone help me see what the problem is? Regards, Yuye. -- Hafnium mailing list -- hafnium(a)lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave(a)lists.trustedfirmware.org

2 years, 2 months

2
1
0 0

Re: hafnium page table configuration

by 梅建强(禹夜)

Hi Olivier, Fix from https://github.com/OP-TEE/optee_os/issues/5803#issuecomment-1436084763 <https://github.com/OP-TEE/optee_os/issues/5803#issuecomment-1436084763 > has been confirmed in the comments. Regards, Yuye. ------------------------------------------------------------------ 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> 发送时间：2023年2月28日(星期二) 01:57 收件人：hafnium <hafnium(a)lists.trustedfirmware.org>; 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：高海源(码源) <haiyuan.ghy(a)alibaba-inc.com>; 王一蒙(北见) <wym389994(a)alibaba-inc.com> 主　题：Re: [Hafnium] hafnium page table configuration Hi Yuye, See comments inline [OD]. Regards, Olivier. From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> Sent: 22 February 2023 04:17 To: Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org> Cc: 高海源(码源) <haiyuan.ghy(a)alibaba-inc.com>; 王一蒙(北见) <wym389994(a)alibaba-inc.com> Subject: 回复：[Hafnium] hafnium page table configuration Hi, Olivier, Sorry for the delay in replying to this query. As I've seen in the documentation, in the case of hafnium implemented as S-EL2, NWd uses shared memory to communicate with SWd and there are two steps to register the page table. Please correct me if there are any errors in my description. Firstly, Linux sends FFA_MEM_SHARE to SPMC (Hafnium), which completes memory mapping for S-EL1's stage-2 transition. Secondly, Linux sends FFA_MSG_SEND_DIRECT_REQ to OPTEE, and OPTEE then retrieves the IPA space from SPMC according to the cookie received and then completes the memory mapping for S-EL1's stage-1 transition. [OD] That's quite correct, with the subtle difference that the region is mapped in SP's S2 page tables upon the receiver SP emitting the memory retrieve request. The SP maps the region in the S1 page tables after receiving the memory retrieve response from the SPMC. Our solution to the problem is: After the first step be completed, we add the invalidation of TLB, which seems to greatly reduce the probability of problem occurrence when testing the optee_examples. The root cause still needs to be further located. [OD] There is a probable miss with invalidating the S2 TLB entries for NS IPA space. Interestingly, this issue is not observed with models, but likely to happen on real silicon. Can you try the suggested temp. fix from https://github.com/OP-TEE/optee_os/issues/5803#issuecomment-1436084763 <https://github.com/OP-TEE/optee_os/issues/5803#issuecomment-1436084763 > ? (while reverting your own TLB invalidation fix. ?) I'm working on a cleaner fix, and prioritize if this issue is confirmed at your end. It should be noted that our OPTEE version is based on 3.19-rc, and Hafnium version is based on the commit: https://git.trustedfirmware.org/hafnium/hafnium.git/commit/?id=dd883207ee9b… <https://git.trustedfirmware.org/hafnium/hafnium.git/commit/?id=dd883207ee9b… > Anyway, thanks for the support. Regards, Yuye. ------------------------------------------------------------------ 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> 发送时间：2023年2月11日(星期六) 00:56 收件人：hafnium <hafnium(a)lists.trustedfirmware.org>; 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 主　题：Re: [Hafnium] hafnium page table configuration Hi Yuye, Quick feedback, we have a test case testing SP to SP mem sharing with a large physical address (for a NS memory region), so I expect this is covered: https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/tftf/tests/runtime… <https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/tftf/tests/runtime… > https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/spm/cactus/cactus_… <https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/spm/cactus/cactus_… > https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/spm/cactus/plat/ar… <https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/spm/cactus/plat/ar… > There may certainly be other reasons, but before investigating further, is this still an issue at your end? Regards, Olivier. From: 梅建强(禹夜) via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: 06 February 2023 07:41 To: hafnium <hafnium(a)lists.trustedfirmware.org> Subject: [Hafnium] hafnium page table configuration Hi, At present, I suspect that this may be a hafnium problem, secure_storage CA/TA may use over 34G address space before communication. May I ask, does hafnium currently support the configuration of the page table of 0x8 80000000-xxxxxxxxx address range? If yes, how to configure it? The error log is as follows: Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x2 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 WARNING: Stage-2 page fault: pc=0x40032106, vmid=0x8001, vcpu=13, vaddr=0x40046ce0, ipaddr=0x8a9b28ce0, mode=0x81 0x63 NOTICE: Injecting Data Abort exception into VM 0x8001. D/TC:013 0 abort_handler:550 [abort] abort in User mode (TA will panic) E/TC:??? 0 E/TC:??? 0 User mode data-abort at address 0x40046ce0 (translation fault) E/TC:??? 0 esr 0x94020007 ttbr0 0x20000f03061a0 ttbr1 0x00000000 cidr 0x0 E/TC:??? 0 cpu #13 cpsr 0x00000130 E/TC:??? 0 x0 000000004003e348 x1 000000004003e349 E/TC:??? 0 x2 0000000040046ce0 x3 000000004003e348 E/TC:??? 0 x4 0000000040036088 x5 0000000000000000 E/TC:??? 0 x6 0000000000000000 x7 0000000040042e28 E/TC:??? 0 x8 0000000000000000 x9 0000000000000000 E/TC:??? 0 x10 0000000000000000 x11 0000000000000000 E/TC:??? 0 x12 0000000000000000 x13 0000000040042e28 E/TC:??? 0 x14 00000000400213cf x15 0000000000000000 E/TC:??? 0 x16 0000000000000000 x17 0000000000000000 E/TC:??? 0 x18 0000000000000000 x19 0000000000000000 E/TC:??? 0 x20 0000000000000000 x21 0000000000000000 E/TC:??? 0 x22 0000000000000000 x23 0000000000000000 E/TC:??? 0 x24 0000000000000000 x25 0000000000000000 E/TC:??? 0 x26 0000000000000000 x27 0000000000000000 E/TC:??? 0 x28 0000000000000000 x29 0000000000000000 E/TC:??? 0 x30 0000000000000000 elr 0000000040032106 E/TC:??? 0 sp_el0 0000000040042f80 E/LD: Status of TA f4e750bb-1437-4fbf-8785-8d3580c34994 E/LD: arch: arm E/LD: region 0: va 0x40006000 pa 0xf0404000 size 0x002000 flags rw-s (ldelf) E/LD: region 1: va 0x40008000 pa 0xf0406000 size 0x011000 flags r-xs (ldelf) E/LD: region 2: va 0x40019000 pa 0xf0417000 size 0x001000 flags rw-s (ldelf) E/LD: region 3: va 0x4001a000 pa 0xf0418000 size 0x004000 flags rw-s (ldelf) E/LD: region 4: va 0x4001e000 pa 0xf041c000 size 0x001000 flags r--s E/LD: region 5: va 0x4001f000 pa 0x00001000 size 0x017000 flags r-xs [0] E/LD: region 6: va 0x40036000 pa 0x00018000 size 0x00c000 flags rw-s [0] E/LD: region 7: va 0x40042000 pa 0xf0440000 size 0x001000 flags rw-s (stack) E/LD: region 8: va 0x40043000 pa 0x8b9101620 size 0x003000 flags rw-- (param) E/LD: region 9: va 0x40046000 pa 0x8a9b28ce0 size 0x001000 flags rw-- (param) E/LD: [0] f4e750bb-1437-4fbf-8785-8d3580c34994 @ 0x4001f000 E/LD: Call stack Regards, Yuye ------------------------------------------------------------------ 发件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 发送时间：2023年2月4日(星期六) 11:40 收件人：op-tee <op-tee(a)lists.trustedfirmware.org> 抄　送：赵哲(为哲) <weizhe.zz(a)alibaba-inc.com>; 高海源(码源) <haiyuan.ghy(a)alibaba-inc.com>; 王一蒙(北见) <wym389994(a)alibaba-inc.com> 主　题：OPTEE TA Crash Hi, Does anyone have a good solution to this problem？ https://github.com/OP-TEE/optee_os/issues/5803 <https://github.com/OP-TEE/optee_os/issues/5803 > <https://github.com/OP-TEE/optee_os/issues/5803 <https://github.com/OP-TEE/optee_os/issues/5803 > > regards, yuye -- Hafnium mailing list -- hafnium(a)lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave(a)lists.trustedfirmware.org

2 years, 2 months

2
1
0 0

Re: Multi-OPTEE run with Hafnium

by Olivier Deprez

Hi Yuye, I sense those questions are related to downstream changes of yours, and I may not be able to provide accurate answers without seeing the code. Please clarify if the questions are related to the upstream version of Hafnium. See additional comments below [OD]. Regards, Olivier. ________________________________ From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> Sent: 06 March 2023 14:15 To: Olivier Deprez <Olivier.Deprez(a)arm.com> Cc: Jens Wiklander <jens.wiklander(a)linaro.org> Subject: Re: Multi-OPTEE run with Hafnium Hi, Olivier, On this question, I should add something based on the results of my tests. When I enter Hafnium through framwork message, the value of the global variable remains the same. [OD] please explain what is a framework message. When I re-enter the Hafnium image_entry via spmd_init, the global variable is restored to its original value. [OD] I'm not sure about the flow here, it depends about where the variable is declared and whether you have local changes to the hafnium boot flows. Do you know why? Regards, Yuye. ------------------------------------------------------------------ 发件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 发送时间：2023年3月6日(星期一) 17:00 收件人：Olivier Deprez <olivier.deprez(a)arm.com> 抄　送：Jens Wiklander <jens.wiklander(a)linaro.org> 主　题：Multi-OPTEE run with Hafnium Hi, Olivier, I want to ask a question about variable modification. Before this, let me explain the background about the question. Now, I have run into host OS with Hafnium as spmc and OPTEE as SP. Then the optee driver will send a framwork message to Hafnium to inform it that whether the current state of the host OS is booting or running, [OD] What is a 'framework message' in this context? Is this a custom direct request from driver to optee? so that Hafnium could know which vm node(SP) it should load and init at current state. [OD] Can you please explain why this is required? This current state is represented by a global variable. [OD] do you mean a variable in Hafnium's BSS space? Will the global variable change when message flow exit Hafnium and enter it again? [OD] This depends in which section the variable is declared (see above). Regards, Yuye.

2 years, 2 months

1
0
0 0

deprecating non vhe builds

by Olivier Deprez

Hi, Current Hafnium build and test configs cover both cases of non-VHE (HCR_EL2.E2H=0) and VHE (HCR_EL2.E2H=1). From an Arm architecture perspective the latter is a superset of the former. We get to know that non-VHE becomes a legacy, and other projects in general tend to always enable Armv8.1 VHE extension early at boot. Our focus being S-EL2 (Armv8.4+) it looks reasonable to assume Armv8.1's VHE is present on chipsets loading and booting Hafnium. That said we're exploring the possibility to abandon 'non-vhe' builds, and focus build and test on vhe-enabled builds. The intent to simplify build configurations, and improve build and test time. Joao made experiments in 2 steps, first on removing the said build configurations, and then runtime checks. This gives good results at least in terms of build time , and simplification in build/test scripts. https://review.trustedfirmware.org/c/hafnium/hafnium/+/18925/ https://review.trustedfirmware.org/c/hafnium/project/reference/+/18926/ This message is to poll the community for feedback, as to whether this is foreseen as an issue (or not!) for on going deployments, before we engage further in this refactoring. Thanks & Regards, Olivier.

2 years, 2 months

2
2
0 0

Re: hafnium page table configuration

by Olivier Deprez

Hi Yuye, See comments inline [OD]. Regards, Olivier. ________________________________ From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> Sent: 22 February 2023 04:17 To: Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org> Cc: 高海源(码源) <haiyuan.ghy(a)alibaba-inc.com>; 王一蒙(北见) <wym389994(a)alibaba-inc.com> Subject: 回复：[Hafnium] hafnium page table configuration Hi, Olivier, Sorry for the delay in replying to this query. As I've seen in the documentation, in the case of hafnium implemented as S-EL2, NWd uses shared memory to communicate with SWd and there are two steps to register the page table. Please correct me if there are any errors in my description. Firstly, Linux sends FFA_MEM_SHARE to SPMC (Hafnium), which completes memory mapping for S-EL1's stage-2 transition. Secondly, Linux sends FFA_MSG_SEND_DIRECT_REQ to OPTEE, and OPTEE then retrieves the IPA space from SPMC according to the cookie received and then completes the memory mapping for S-EL1's stage-1 transition. [OD] That's quite correct, with the subtle difference that the region is mapped in SP's S2 page tables upon the receiver SP emitting the memory retrieve request. The SP maps the region in the S1 page tables after receiving the memory retrieve response from the SPMC. Our solution to the problem is: After the first step be completed, we add the invalidation of TLB, which seems to greatly reduce the probability of problem occurrence when testing the optee_examples. The root cause still needs to be further located. [OD] There is a probable miss with invalidating the S2 TLB entries for NS IPA space. Interestingly, this issue is not observed with models, but likely to happen on real silicon. Can you try the suggested temp. fix from https://github.com/OP-TEE/optee_os/issues/5803#issuecomment-1436084763 ? (while reverting your own TLB invalidation fix. ?) I'm working on a cleaner fix, and prioritize if this issue is confirmed at your end. It should be noted that our OPTEE version is based on 3.19-rc, and Hafnium version is based on the commit: https://git.trustedfirmware.org/hafnium/hafnium.git/commit/?id=dd883207ee9b… Anyway, thanks for the support. Regards, Yuye. ------------------------------------------------------------------ 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> 发送时间：2023年2月11日(星期六) 00:56 收件人：hafnium <hafnium(a)lists.trustedfirmware.org>; 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 主　题：Re: [Hafnium] hafnium page table configuration Hi Yuye, Quick feedback, we have a test case testing SP to SP mem sharing with a large physical address (for a NS memory region), so I expect this is covered: https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/tftf/tests/runtime… https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/spm/cactus/cactus_… https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/spm/cactus/plat/ar… There may certainly be other reasons, but before investigating further, is this still an issue at your end? Regards, Olivier. ________________________________ From: 梅建强(禹夜) via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: 06 February 2023 07:41 To: hafnium <hafnium(a)lists.trustedfirmware.org> Subject: [Hafnium] hafnium page table configuration Hi, At present, I suspect that this may be a hafnium problem, secure_storage CA/TA may use over 34G address space before communication. May I ask, does hafnium currently support the configuration of the page table of 0x8 80000000-xxxxxxxxx address range? If yes, how to configure it? The error log is as follows: Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x2 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 WARNING: Stage-2 page fault: pc=0x40032106, vmid=0x8001, vcpu=13, vaddr=0x40046ce0, ipaddr=0x8a9b28ce0, mode=0x81 0x63 NOTICE: Injecting Data Abort exception into VM 0x8001. D/TC:013 0 abort_handler:550 [abort] abort in User mode (TA will panic) E/TC:??? 0 E/TC:??? 0 User mode data-abort at address 0x40046ce0 (translation fault) E/TC:??? 0 esr 0x94020007 ttbr0 0x20000f03061a0 ttbr1 0x00000000 cidr 0x0 E/TC:??? 0 cpu #13 cpsr 0x00000130 E/TC:??? 0 x0 000000004003e348 x1 000000004003e349 E/TC:??? 0 x2 0000000040046ce0 x3 000000004003e348 E/TC:??? 0 x4 0000000040036088 x5 0000000000000000 E/TC:??? 0 x6 0000000000000000 x7 0000000040042e28 E/TC:??? 0 x8 0000000000000000 x9 0000000000000000 E/TC:??? 0 x10 0000000000000000 x11 0000000000000000 E/TC:??? 0 x12 0000000000000000 x13 0000000040042e28 E/TC:??? 0 x14 00000000400213cf x15 0000000000000000 E/TC:??? 0 x16 0000000000000000 x17 0000000000000000 E/TC:??? 0 x18 0000000000000000 x19 0000000000000000 E/TC:??? 0 x20 0000000000000000 x21 0000000000000000 E/TC:??? 0 x22 0000000000000000 x23 0000000000000000 E/TC:??? 0 x24 0000000000000000 x25 0000000000000000 E/TC:??? 0 x26 0000000000000000 x27 0000000000000000 E/TC:??? 0 x28 0000000000000000 x29 0000000000000000 E/TC:??? 0 x30 0000000000000000 elr 0000000040032106 E/TC:??? 0 sp_el0 0000000040042f80 E/LD: Status of TA f4e750bb-1437-4fbf-8785-8d3580c34994 E/LD: arch: arm E/LD: region 0: va 0x40006000 pa 0xf0404000 size 0x002000 flags rw-s (ldelf) E/LD: region 1: va 0x40008000 pa 0xf0406000 size 0x011000 flags r-xs (ldelf) E/LD: region 2: va 0x40019000 pa 0xf0417000 size 0x001000 flags rw-s (ldelf) E/LD: region 3: va 0x4001a000 pa 0xf0418000 size 0x004000 flags rw-s (ldelf) E/LD: region 4: va 0x4001e000 pa 0xf041c000 size 0x001000 flags r--s E/LD: region 5: va 0x4001f000 pa 0x00001000 size 0x017000 flags r-xs [0] E/LD: region 6: va 0x40036000 pa 0x00018000 size 0x00c000 flags rw-s [0] E/LD: region 7: va 0x40042000 pa 0xf0440000 size 0x001000 flags rw-s (stack) E/LD: region 8: va 0x40043000 pa 0x8b9101620 size 0x003000 flags rw-- (param) E/LD: region 9: va 0x40046000 pa 0x8a9b28ce0 size 0x001000 flags rw-- (param) E/LD: [0] f4e750bb-1437-4fbf-8785-8d3580c34994 @ 0x4001f000 E/LD: Call stack Regards, Yuye ------------------------------------------------------------------ 发件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 发送时间：2023年2月4日(星期六) 11:40 收件人：op-tee <op-tee(a)lists.trustedfirmware.org> 抄　送：赵哲(为哲) <weizhe.zz(a)alibaba-inc.com>; 高海源(码源) <haiyuan.ghy(a)alibaba-inc.com>; 王一蒙(北见) <wym389994(a)alibaba-inc.com> 主　题：OPTEE TA Crash Hi, Does anyone have a good solution to this problem？ https://github.com/OP-TEE/optee_os/issues/5803 <https://github.com/OP-TEE/optee_os/issues/5803 > regards, yuye -- Hafnium mailing list -- hafnium(a)lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave(a)lists.trustedfirmware.org

2 years, 2 months

1
0
0 0

Re: xtest 1034

by 梅建强(禹夜)

Hi, Olivier, Sorry for ignoring the tips in your email. I guess the question in part 1 is no longer the trouble. Regards, Yuye. ------------------------------------------------------------------ 发件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 发送时间：2023年2月27日(星期一) 19:18 收件人：Olivier Deprez <olivier.deprez(a)arm.com> 抄　送：Jens Wiklander <jens.wiklander(a)linaro.org>; hafnium <hafnium(a)lists.trustedfirmware.org> 主　题：[Hafnium] Re: Re: xtest 1034 Hi, Olivier, 1. We solved the problem by update our Hafnium codebase on rebase of commit ca03054ba6a351534b93e6d64c12e671578eb340. The origin Hafnium codebase is on rebase of commit dd883207ee9b31c19169adf97c918d561dcb9a5c. OPTEE codebase stays with version 3.20.0. Which commit can solve this problem is still under investigation. I guess the reason may relate to that Hafnium has updated the implementation of FF-A mechanism in new commit. If you have already known the reason, please tell me. 2. In addition, although some cases run successfully, there are still many error messages generated during their running process, such as the following cases: * regression_1034 Test loading a large TA E/TC:011 0 mobj_ffa_get_by_cookie:384 Populating mobj from rx buffer, cookie 0x1 E/TC:011 0 mobj_ffa_get_by_cookie:384 Populating mobj from rx buffer, cookie 0x3 E/TC:??? 0 mobj_ffa_get_by_cookie:423 Failed to get cookie 0x3 internal_offs 0 E/LD: init_elf:486 sys_open_ta_bin(25497083-a58a-4fc5-8a72-1ad7b69b8562) E/TC:??? 0 ldelf_init_with_ldelf:131 ldelf failed with res: 0xffff000c TEEC_ERROR_OUT_OF_MEMORY - ignored regression_1034 OK * regression_1022 Test dlopen()/dlsym()/dlclose() API E/TC:011 0 mobj_ffa_get_by_cookie:384 Populating mobj from rx buffer, cookie 0x1 E/TC:011 0 mobj_ffa_get_by_cookie:384 Populating mobj from rx buffer, cookie 0x3 E/TC:011 0 mobj_ffa_get_by_cookie:384 Populating mobj from rx buffer, cookie 0x3 E/TC:011 0 mobj_ffa_get_by_cookie:384 Populating mobj from rx buffer, cookie 0x1 E/TC:011 0 mobj_ffa_get_by_cookie:384 Populating mobj from rx buffer, cookie 0x3 E/TC:??? 0 E/TC:??? 0 TA panicked with code 0x0 E/LD: Status of TA 5b9e0e40-2636-11e1-ad9e-0002a5d5c51b E/LD: arch: aarch64 E/LD: region 0: va 0x40006000 pa 0xf0404000 size 0x002000 flags rw-s (ldelf) E/LD: region 1: va 0x40008000 pa 0xf0406000 size 0x011000 flags r-xs (ldelf) E/LD: region 2: va 0x40019000 pa 0xf0417000 size 0x001000 flags rw-s (ldelf) E/LD: region 3: va 0x4001a000 pa 0xf0418000 size 0x004000 flags rw-s (ldelf) E/LD: region 4: va 0x4001e000 pa 0xf041c000 size 0x001000 flags r--s E/LD: region 5: va 0x4001f000 pa 0xf052e000 size 0x003000 flags rw-s (stack) E/LD: region 6: va 0x40038000 pa 0x00000000 size 0x00f000 flags r-xs [2] E/LD: region 7: va 0x40047000 pa 0x0000e000 size 0x002000 flags rw-s [2] E/LD: region 8: va 0x40054000 pa 0x00000000 size 0x00f000 flags r-xs [1] E/LD: region 9: va 0x40063000 pa 0x0000e000 size 0x002000 flags rw-s [1] E/LD: region 10: va 0x4008b000 pa 0x00001000 size 0x02a000 flags r-xs [0] E/LD: region 11: va 0x400b5000 pa 0x0002b000 size 0x0e7000 flags rw-s [0] E/LD: [0] 5b9e0e40-2636-11e1-ad9e-0002a5d5c51b @ 0x4008b000 E/LD: [1] ffd2bded-ab7d-4988-95ee-e4962fff7154 @ 0x40054000 E/LD: [2] b3091a65-9751-4784-abf7-0298a7cc35ba @ 0x40038000 E/LD: Call stack: E/LD: 0x4009e5a8 E/LD: 0x400a09b8 E/LD: 0x4009ed0c regression_1022 OK The E/TC message generated by mobj_ffa_get_by_cookie appears in almost all cases. Is this related to FFA_MEM_FRAG_RX/TX, or something else? And what is related to the E/LD message? I am currently studying the FFA specification to try to explain these problems. And some related questions raised in the other email(subject: Hafnium Dynamic Shared Memory). You can tell me if it's convenient for you. 3. Could memory managed by Hafnium be configured in any other way except by spmc manifest? Does Hafnium support the configuration of the location of running memory such as text, data, stacks, and heap? If yes, how? Thanks you for your help. Regards, Yuye. ------------------------------------------------------------------ 发件人：Olivier Deprez via Hafnium <hafnium(a)lists.trustedfirmware.org> 发送时间：2023年2月27日(星期一) 17:19 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：hafnium <hafnium(a)lists.trustedfirmware.org> 主　题：[Hafnium] Re: xtest 1034 Hi Yuye, Can you make sure to use hafnium tip of master (if that's not the case)? We confirmed this specific test passes on models from this commit onwards: https://git.trustedfirmware.org/hafnium/hafnium.git/commit/?id=fdd29277caf2… <https://git.trustedfirmware.org/hafnium/hafnium.git/commit/?id=fdd29277caf2… > We may provide further guidance if the issue persists after rebasing. Thanks, Olivier. ________________________________ From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> Sent: 26 February 2023 06:49 To: hafnium <hafnium(a)lists.trustedfirmware.org>; Olivier Deprez <Olivier.Deprez(a)arm.com>; Jens Wiklander <jens.wiklander(a)linaro.org> Subject: xtest 1034 Hi, experts, For dynamic shared memory usage, I am not very clear. So we need to consult you about the related question. I failed to run xtest 1034 when I used Hafnium as SPMC and OPTEE as SP. Here are the debug logs： #./xtest 1034& [2] 10130 Test ID: 1034 Run test suite with level=0 TEE test application started over default TEE instance ###################################################### # # regression # ###################################################### regression_1034 Test loading a large TA WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000000 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f D/TC:055 0 mobj_ffa_get_by_cookie:381 cookie 0 resurrecting D/TC:??? 0 tee_ta_init_pseudo_ta_session:296 Lookup pseudo TA 25497083-a58a-4fc5-8a72-1ad7b69b8562 D/TC:??? 0 ldelf_load_ldelf:96 ldelf load address 0x40008000 D/LD: ldelf:134 Loading TS 25497083-a58a-4fc5-8a72-1ad7b69b8562 F/TC:??? 0 trace_syscall:151 syscall Add constant time memcmp_ct function #3<https://github.com/OP-TEE/optee_os/pull/3> <https://github.com/OP-TEE/optee_os/pull/3> > (syscall_get_property) F/TC:??? 0 trace_syscall:151 syscall GitHub usage documentation #5<https://github.com/OP-TEE/optee_os/pull/5> <https://github.com/OP-TEE/optee_os/pull/5> > (syscall_open_ta_session) #D/TC:??? 0 ldelf_syscall_open_bin:143 Lookup user TA ELF 25497083-a58a-4fc5-8a72-1ad7b69b8562 (early TA) D/TC:??? 0 ldelf_syscall_open_bin:146 res=0xffff0008 D/TC:??? 0 ldelf_syscall_open_bin:143 Lookup user TA ELF 25497083-a58a-4fc5-8a72-1ad7b69b8562 (Secure Storage TA) VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(60): 0x84000073 0x50 0x50 0x0 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x84000073 VERBOSE: Marked sending complete. Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 0 retrieved, sender's original mode: 0x7 WARNING: Atf_Debug(60): 0x84000061 0x0 0x1 0x0 0x0 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f E/TC:055 0 mobj_ffa_get_by_cookie:384 Populating mobj from rx buffer, cookie 0x1 VERBOSE: Hafnium_Debug ffa_handler func:0x84000074 Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 0 retrieved, sender's original mode: 0x7 Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 VERBOSE: Hafnium_Debug ffa_handler func:0x84000065 VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f D/TC:??? 0 ldelf_syscall_open_bin:146 res=0xffff0008 D/TC:??? 0 ldelf_syscall_open_bin:143 Lookup user TA ELF 25497083-a58a-4fc5-8a72-1ad7b69b8562 (REE) VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(58): 0x84000073 0x1190 0x1000 0x0 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x84000073 Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x2 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): partially sent with 1 fragments, 0 retrieved, sender's original mode: 0x7 WARNING: Atf_Debug(58): 0x8400007a 0x2 0x0 0x1000 0x0 0x0 0x0 0x0 WARNING: Atf_Debug(58): 0x8400007b 0x2 0x0 0x190 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400007b VERBOSE: Hafnium_Debug fragment_length:0x190 VERBOSE: Hafnium_Debug fragment_copy:00000000ff30e000, from_msg:00000008bdd48000 ERROR: Data abort: pc=0xff21a688, esr=0x96000006, ec=0x25, far=0x9c Panic: EL2 exception the error occured when Hafnium run the code: api_ffa_mem_frag_tx memcpy_s(fragment_copy, MM_PPOOL_ENTRY_SIZE, from_msg, fragment_length); It seems that I did not add the page table at 0x00000000ff30e000 or 0x00000008bdd48000, but I am not quite clear about what fragment_copy and from_msg mean. Can someone help me see what the problem is? Regards, Yuye. -- Hafnium mailing list -- hafnium(a)lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave(a)lists.trustedfirmware.org

2 years, 2 months

2
1
0 0

Re: xtest 1034

by 梅建强(禹夜)

Hi, Olivier, 1. We solved the problem by update our Hafnium codebase on rebase of commit ca03054ba6a351534b93e6d64c12e671578eb340. The origin Hafnium codebase is on rebase of commit dd883207ee9b31c19169adf97c918d561dcb9a5c. OPTEE codebase stays with version 3.20.0. Which commit can solve this problem is still under investigation. I guess the reason may relate to that Hafnium has updated the implementation of FF-A mechanism in new commit. If you have already known the reason, please tell me. 2. In addition, although some cases run successfully, there are still many error messages generated during their running process, such as the following cases: * regression_1034 Test loading a large TA E/TC:011 0 mobj_ffa_get_by_cookie:384 Populating mobj from rx buffer, cookie 0x1 E/TC:011 0 mobj_ffa_get_by_cookie:384 Populating mobj from rx buffer, cookie 0x3 E/TC:??? 0 mobj_ffa_get_by_cookie:423 Failed to get cookie 0x3 internal_offs 0 E/LD: init_elf:486 sys_open_ta_bin(25497083-a58a-4fc5-8a72-1ad7b69b8562) E/TC:??? 0 ldelf_init_with_ldelf:131 ldelf failed with res: 0xffff000c TEEC_ERROR_OUT_OF_MEMORY - ignored regression_1034 OK * regression_1022 Test dlopen()/dlsym()/dlclose() API E/TC:011 0 mobj_ffa_get_by_cookie:384 Populating mobj from rx buffer, cookie 0x1 E/TC:011 0 mobj_ffa_get_by_cookie:384 Populating mobj from rx buffer, cookie 0x3 E/TC:011 0 mobj_ffa_get_by_cookie:384 Populating mobj from rx buffer, cookie 0x3 E/TC:011 0 mobj_ffa_get_by_cookie:384 Populating mobj from rx buffer, cookie 0x1 E/TC:011 0 mobj_ffa_get_by_cookie:384 Populating mobj from rx buffer, cookie 0x3 E/TC:??? 0 E/TC:??? 0 TA panicked with code 0x0 E/LD: Status of TA 5b9e0e40-2636-11e1-ad9e-0002a5d5c51b E/LD: arch: aarch64 E/LD: region 0: va 0x40006000 pa 0xf0404000 size 0x002000 flags rw-s (ldelf) E/LD: region 1: va 0x40008000 pa 0xf0406000 size 0x011000 flags r-xs (ldelf) E/LD: region 2: va 0x40019000 pa 0xf0417000 size 0x001000 flags rw-s (ldelf) E/LD: region 3: va 0x4001a000 pa 0xf0418000 size 0x004000 flags rw-s (ldelf) E/LD: region 4: va 0x4001e000 pa 0xf041c000 size 0x001000 flags r--s E/LD: region 5: va 0x4001f000 pa 0xf052e000 size 0x003000 flags rw-s (stack) E/LD: region 6: va 0x40038000 pa 0x00000000 size 0x00f000 flags r-xs [2] E/LD: region 7: va 0x40047000 pa 0x0000e000 size 0x002000 flags rw-s [2] E/LD: region 8: va 0x40054000 pa 0x00000000 size 0x00f000 flags r-xs [1] E/LD: region 9: va 0x40063000 pa 0x0000e000 size 0x002000 flags rw-s [1] E/LD: region 10: va 0x4008b000 pa 0x00001000 size 0x02a000 flags r-xs [0] E/LD: region 11: va 0x400b5000 pa 0x0002b000 size 0x0e7000 flags rw-s [0] E/LD: [0] 5b9e0e40-2636-11e1-ad9e-0002a5d5c51b @ 0x4008b000 E/LD: [1] ffd2bded-ab7d-4988-95ee-e4962fff7154 @ 0x40054000 E/LD: [2] b3091a65-9751-4784-abf7-0298a7cc35ba @ 0x40038000 E/LD: Call stack: E/LD: 0x4009e5a8 E/LD: 0x400a09b8 E/LD: 0x4009ed0c regression_1022 OK The E/TC message generated by mobj_ffa_get_by_cookie appears in almost all cases. Is this related to FFA_MEM_FRAG_RX/TX, or something else? And what is related to the E/LD message? I am currently studying the FFA specification to try to explain these problems. And some related questions raised in the other email(subject: Hafnium Dynamic Shared Memory). You can tell me if it's convenient for you. 3. Could memory managed by Hafnium be configured in any other way except by spmc manifest? Does Hafnium support the configuration of the location of running memory such as text, data, stacks, and heap? If yes, how? Thanks you for your help. Regards, Yuye. ------------------------------------------------------------------ 发件人：Olivier Deprez via Hafnium <hafnium(a)lists.trustedfirmware.org> 发送时间：2023年2月27日(星期一) 17:19 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：hafnium <hafnium(a)lists.trustedfirmware.org> 主　题：[Hafnium] Re: xtest 1034 Hi Yuye, Can you make sure to use hafnium tip of master (if that's not the case)? We confirmed this specific test passes on models from this commit onwards: https://git.trustedfirmware.org/hafnium/hafnium.git/commit/?id=fdd29277caf2… <https://git.trustedfirmware.org/hafnium/hafnium.git/commit/?id=fdd29277caf2… > We may provide further guidance if the issue persists after rebasing. Thanks, Olivier. ________________________________ From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> Sent: 26 February 2023 06:49 To: hafnium <hafnium(a)lists.trustedfirmware.org>; Olivier Deprez <Olivier.Deprez(a)arm.com>; Jens Wiklander <jens.wiklander(a)linaro.org> Subject: xtest 1034 Hi, experts, For dynamic shared memory usage, I am not very clear. So we need to consult you about the related question. I failed to run xtest 1034 when I used Hafnium as SPMC and OPTEE as SP. Here are the debug logs： #./xtest 1034& [2] 10130 Test ID: 1034 Run test suite with level=0 TEE test application started over default TEE instance ###################################################### # # regression # ###################################################### regression_1034 Test loading a large TA WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000000 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f D/TC:055 0 mobj_ffa_get_by_cookie:381 cookie 0 resurrecting D/TC:??? 0 tee_ta_init_pseudo_ta_session:296 Lookup pseudo TA 25497083-a58a-4fc5-8a72-1ad7b69b8562 D/TC:??? 0 ldelf_load_ldelf:96 ldelf load address 0x40008000 D/LD: ldelf:134 Loading TS 25497083-a58a-4fc5-8a72-1ad7b69b8562 F/TC:??? 0 trace_syscall:151 syscall Add constant time memcmp_ct function #3<https://github.com/OP-TEE/optee_os/pull/3> <https://github.com/OP-TEE/optee_os/pull/3> > (syscall_get_property) F/TC:??? 0 trace_syscall:151 syscall GitHub usage documentation #5<https://github.com/OP-TEE/optee_os/pull/5> <https://github.com/OP-TEE/optee_os/pull/5> > (syscall_open_ta_session) #D/TC:??? 0 ldelf_syscall_open_bin:143 Lookup user TA ELF 25497083-a58a-4fc5-8a72-1ad7b69b8562 (early TA) D/TC:??? 0 ldelf_syscall_open_bin:146 res=0xffff0008 D/TC:??? 0 ldelf_syscall_open_bin:143 Lookup user TA ELF 25497083-a58a-4fc5-8a72-1ad7b69b8562 (Secure Storage TA) VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(60): 0x84000073 0x50 0x50 0x0 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x84000073 VERBOSE: Marked sending complete. Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 0 retrieved, sender's original mode: 0x7 WARNING: Atf_Debug(60): 0x84000061 0x0 0x1 0x0 0x0 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f E/TC:055 0 mobj_ffa_get_by_cookie:384 Populating mobj from rx buffer, cookie 0x1 VERBOSE: Hafnium_Debug ffa_handler func:0x84000074 Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 0 retrieved, sender's original mode: 0x7 Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 VERBOSE: Hafnium_Debug ffa_handler func:0x84000065 VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f D/TC:??? 0 ldelf_syscall_open_bin:146 res=0xffff0008 D/TC:??? 0 ldelf_syscall_open_bin:143 Lookup user TA ELF 25497083-a58a-4fc5-8a72-1ad7b69b8562 (REE) VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(58): 0x84000073 0x1190 0x1000 0x0 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x84000073 Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x2 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): partially sent with 1 fragments, 0 retrieved, sender's original mode: 0x7 WARNING: Atf_Debug(58): 0x8400007a 0x2 0x0 0x1000 0x0 0x0 0x0 0x0 WARNING: Atf_Debug(58): 0x8400007b 0x2 0x0 0x190 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400007b VERBOSE: Hafnium_Debug fragment_length:0x190 VERBOSE: Hafnium_Debug fragment_copy:00000000ff30e000, from_msg:00000008bdd48000 ERROR: Data abort: pc=0xff21a688, esr=0x96000006, ec=0x25, far=0x9c Panic: EL2 exception the error occured when Hafnium run the code: api_ffa_mem_frag_tx memcpy_s(fragment_copy, MM_PPOOL_ENTRY_SIZE, from_msg, fragment_length); It seems that I did not add the page table at 0x00000000ff30e000 or 0x00000008bdd48000, but I am not quite clear about what fragment_copy and from_msg mean. Can someone help me see what the problem is? Regards, Yuye. -- Hafnium mailing list -- hafnium(a)lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave(a)lists.trustedfirmware.org

2 years, 2 months

1
0
0 0

xtest 1034

by 梅建强(禹夜)

Hi, experts, For dynamic shared memory usage, I am not very clear. So we need to consult you about the related question. I failed to run xtest 1034 when I used Hafnium as SPMC and OPTEE as SP. Here are the debug logs： #./xtest 1034& [2] 10130 Test ID: 1034 Run test suite with level=0 TEE test application started over default TEE instance ###################################################### # # regression # ###################################################### regression_1034 Test loading a large TA WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000000 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f D/TC:055 0 mobj_ffa_get_by_cookie:381 cookie 0 resurrecting D/TC:??? 0 tee_ta_init_pseudo_ta_session:296 Lookup pseudo TA 25497083-a58a-4fc5-8a72-1ad7b69b8562 D/TC:??? 0 ldelf_load_ldelf:96 ldelf load address 0x40008000 D/LD: ldelf:134 Loading TS 25497083-a58a-4fc5-8a72-1ad7b69b8562 F/TC:??? 0 trace_syscall:151 syscall Add constant time memcmp_ct function #3 <https://github.com/OP-TEE/optee_os/pull/3 > (syscall_get_property) F/TC:??? 0 trace_syscall:151 syscall GitHub usage documentation #5 <https://github.com/OP-TEE/optee_os/pull/5 > (syscall_open_ta_session) #D/TC:??? 0 ldelf_syscall_open_bin:143 Lookup user TA ELF 25497083-a58a-4fc5-8a72-1ad7b69b8562 (early TA) D/TC:??? 0 ldelf_syscall_open_bin:146 res=0xffff0008 D/TC:??? 0 ldelf_syscall_open_bin:143 Lookup user TA ELF 25497083-a58a-4fc5-8a72-1ad7b69b8562 (Secure Storage TA) VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(60): 0x84000073 0x50 0x50 0x0 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x84000073 VERBOSE: Marked sending complete. Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 0 retrieved, sender's original mode: 0x7 WARNING: Atf_Debug(60): 0x84000061 0x0 0x1 0x0 0x0 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f E/TC:055 0 mobj_ffa_get_by_cookie:384 Populating mobj from rx buffer, cookie 0x1 VERBOSE: Hafnium_Debug ffa_handler func:0x84000074 Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 0 retrieved, sender's original mode: 0x7 Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 VERBOSE: Hafnium_Debug ffa_handler func:0x84000065 VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f D/TC:??? 0 ldelf_syscall_open_bin:146 res=0xffff0008 D/TC:??? 0 ldelf_syscall_open_bin:143 Lookup user TA ELF 25497083-a58a-4fc5-8a72-1ad7b69b8562 (REE) VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(55): 0x8400006f 0x8001 0x0 0x80000001 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400006f VERBOSE: Hafnium_Debug ffa_handler func:0x84000070 WARNING: Atf_Debug(55): 0x84000070 0x80010000 0x0 0x0 0x1 0x0 0x0 0x0 WARNING: Atf_Debug(58): 0x84000073 0x1190 0x1000 0x0 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x84000073 Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x2 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): partially sent with 1 fragments, 0 retrieved, sender's original mode: 0x7 WARNING: Atf_Debug(58): 0x8400007a 0x2 0x0 0x1000 0x0 0x0 0x0 0x0 WARNING: Atf_Debug(58): 0x8400007b 0x2 0x0 0x190 0x0 0x0 0x0 0x0 VERBOSE: Hafnium_Debug ffa_handler func:0x8400007b VERBOSE: Hafnium_Debug fragment_length:0x190 VERBOSE: Hafnium_Debug fragment_copy:00000000ff30e000, from_msg:00000008bdd48000 ERROR: Data abort: pc=0xff21a688, esr=0x96000006, ec=0x25, far=0x9c Panic: EL2 exception the error occured when Hafnium run the code: api_ffa_mem_frag_tx memcpy_s(fragment_copy, MM_PPOOL_ENTRY_SIZE, from_msg, fragment_length); It seems that I did not add the page table at 0x00000000ff30e000 or 0x00000008bdd48000, but I am not quite clear about what fragment_copy and from_msg mean. Can someone help me see what the problem is? Regards, Yuye.

2 years, 2 months

2
1
0 0

Hafnium Dynamic Shared Memory

by 梅建强(禹夜)

Hi, experts Here are the comments I saw in the Hafnium code. /* * Hafnium doesn't support fragmentation of memory retrieve requests * (because it doesn't support caller-specified mappings, so a request * will never be larger than a single page), so this must be part of a * memory send (i.e. donate, lend or share) request. * * We can tell from the handle whether the memory transaction is for the * TEE or not. */ I have a few questions about this description. 1. In the case of Hafnium as SPMC, optee should register memory fragments allocated by linux. What does Hafnium do with these memory fragments since doesn't support fragmentation of memory retrieve requests? 2. How does Hafnium map the page tables of stage-2 in dynamic shared memory for CA/TA, and are these page tables stored in the heap, or where? 3. What does HF_MAILBOX for dynamic shared memory mean? How does it relate to RX/TX buffer? Where can I see the related introduction in detail? Regards, Yuye

2 years, 2 months

1
0
0 0

Hafnium load-address

by 梅建强(禹夜)

Hi, Olivier, This issue has not been resolved and further support is needed. Then I'll try to update our code base to see if anything changes. Regards, Yuye. ------------------------------------------------------------------ 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> 发送时间：2023年2月11日(星期六) 00:57 收件人：hafnium <hafnium(a)lists.trustedfirmware.org>; 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：常琳(特睿) <terui.cl(a)alibaba-inc.com>; 赵哲(为哲) <weizhe.zz(a)alibaba-inc.com>; 黄明(连一) <hm281385(a)alibaba-inc.com> 主　题：Re: Hafnium load-address Hi Yuye, Is this still an issue at your end? Just asking if we need to do further investigation. Regards, Olivier. From: 梅建强(禹夜) via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: 28 December 2022 10:09 To: hafnium <hafnium(a)lists.trustedfirmware.org> Cc: 常琳(特睿) <terui.cl(a)alibaba-inc.com>; 赵哲(为哲) <weizhe.zz(a)alibaba-inc.com>; 黄明(连一) <hm281385(a)alibaba-inc.com> Subject: [Hafnium] 回复：Re: Hafnium load-address Hi, Thanks for your efforts for this query. I have tried your solution. Although the Hafnium code could be built successfully, it does not work when the boot flow run into the entry of the Hafnium. I tried to debug the error with trace32 tool. And I confirmed that the Hafnium code has been loaded over 34G of free address space. However, when PC register point to the start address of Hafnium, the code data is displayed as udf #0x0. It may be a page table problem, and we are still locating the problem reason. Regards, Mei, Jianqiang. ------------------------------------------------------------------ 发件人：Olivier Deprez via Hafnium <hafnium(a)lists.trustedfirmware.org> 发送时间：2022年12月21日(星期三) 18:02 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：hafnium <hafnium(a)lists.trustedfirmware.org>; 常琳(特睿) <terui.cl(a)alibaba-inc.com>; 赵哲(为哲) <weizhe.zz(a)alibaba-inc.com>; 黄明(连一) <hm281385(a)alibaba-inc.com> 主　题：[Hafnium] Re: Hafnium load-address Hi, Sorry for the delay in replying to this query. After few trials I ended with this possible solution: https://review.trustedfirmware.org/c/hafnium/hafnium/+/18510 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/18510 > < < >https://review.trustedfirmware.org/c/hafnium/hafnium/+/18510 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/18510 > > This should permit loading the Hafnium image to an address up to 48 bits (and by updating project/reference/BUILD.gn origin_address per your suggestion). It is possible to further extend beyond 48 bits (e.g. 52 bits which is the maximum permitted VA using FEAT_LPA2). Let me know if this works for you, then I can proceed further with polishing this change. Regards, Olivier. ________________________________ From: 梅建强(禹夜) via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: 11 December 2022 09:58 To: Olivier Deprez <Olivier.Deprez(a)arm.com> Cc: hafnium <hafnium(a)lists.trustedfirmware.org>; 常琳(特睿) <terui.cl(a)alibaba-inc.com>; 赵哲(为哲) <weizhe.zz(a)alibaba-inc.com>; 黄明(连一) <hm281385(a)alibaba-inc.com> Subject: [Hafnium] Hafnium load-address Hello, expert Firstly, thanks for your answer some time ago. That's useful to our project.We combined the Hafnium (run at S-EL2) and the optee (run at S-EL1), then modified the configuration to adapt to our own environment. Now we can start the os normally. Now we want to optimize a technical point, which is to load and run hafnium over 34G of free address space. This requires hafnium to support 64-bit load-address. I tried to modify the configuration in BUILD.gn as follows: origin_address = "0x880000000" And I encountered the build error: FAILED: secure_aem_v8a_fvp_clang/hafnium.elf ld.lld -pie --gc-sections --defsym=ORIGIN_ADDRESS=0x880000000 -O2 --icf=all --fatal-warnings --color-diagnostics -T /home/yuye/hafnium/Hafnium/build/image/image.ld -o secure_aem_v8a_fvp_clang/hafnium.elf --start-group @secure_aem_v8a_fvp_clang/hafnium.elf.rsp --end-group ld.lld: error: secure_aem_v8a_fvp_clang/obj/src/arch/aarch64/entry.entry.o:(.init.entry+0xC8): relocation R_AARCH64_ABS32 out of range: 36507222016 is not in [-2147483648, 4294967295]; references ORIGIN_ADDRESS >>> defined in -defsym:1 ninja: build stopped: subcommand failed. Makefile:70: recipe for target 'all' failed make: *** [all] Error 1 + cp out/reference/secure_aem_v8a_fvp_clang/hafnium.bin ../../V2/Ali_M1_Public/Nonosi/Platform/Ali/M1/Bin/ cp: cannot stat 'out/reference/secure_aem_v8a_fvp_clang/hafnium.bin': No such file or directory In this case, it seems that the new address causes some relative addressing to reach too far. Is there any solutions or supports for this issue currently in the community? Regards, Mei, Jianqiang. -- Hafnium mailing list -- hafnium(a)lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave(a)lists.trustedfirmware.org -- Hafnium mailing list -- hafnium(a)lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave(a)lists.trustedfirmware.org -- Hafnium mailing list -- hafnium(a)lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave(a)lists.trustedfirmware.org

2 years, 2 months

1
0
0 0

hafnium page table configuration

by 梅建强(禹夜)

Hi, Olivier, Sorry for the delay in replying to this query. As I've seen in the documentation, in the case of hafnium implemented as S-EL2, NWd uses shared memory to communicate with SWd and there are two steps to register the page table. Please correct me if there are any errors in my description. Firstly, Linux sends FFA_MEM_SHARE to SPMC (Hafnium), which completes memory mapping for S-EL1's stage-2 transition. Secondly, Linux sends FFA_MSG_SEND_DIRECT_REQ to OPTEE, and OPTEE then retrieves the IPA space from SPMC according to the cookie received and then completes the memory mapping for S-EL1's stage-1 transition. Our solution to the problem is: After the first step be completed, we add the invalidation of TLB, which seems to greatly reduce the probability of problem occurrence when testing the optee_examples. The root cause still needs to be further located. It should be noted that our OPTEE version is based on 3.19-rc, and Hafnium version is based on the commit: https://git.trustedfirmware.org/hafnium/hafnium.git/commit/?id=dd883207ee9b… <https://git.trustedfirmware.org/hafnium/hafnium.git/commit/?id=dd883207ee9b… > Anyway, thanks for the support. Regards, Yuye. ------------------------------------------------------------------ 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> 发送时间：2023年2月11日(星期六) 00:56 收件人：hafnium <hafnium(a)lists.trustedfirmware.org>; 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 主　题：Re: [Hafnium] hafnium page table configuration Hi Yuye, Quick feedback, we have a test case testing SP to SP mem sharing with a large physical address (for a NS memory region), so I expect this is covered: https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/tftf/tests/runtime… <https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/tftf/tests/runtime… > https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/spm/cactus/cactus_… <https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/spm/cactus/cactus_… > https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/spm/cactus/plat/ar… <https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/spm/cactus/plat/ar… > There may certainly be other reasons, but before investigating further, is this still an issue at your end? Regards, Olivier. From: 梅建强(禹夜) via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: 06 February 2023 07:41 To: hafnium <hafnium(a)lists.trustedfirmware.org> Subject: [Hafnium] hafnium page table configuration Hi, At present, I suspect that this may be a hafnium problem, secure_storage CA/TA may use over 34G address space before communication. May I ask, does hafnium currently support the configuration of the page table of 0x8 80000000-xxxxxxxxx address range? If yes, how to configure it? The error log is as follows: Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x2 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 WARNING: Stage-2 page fault: pc=0x40032106, vmid=0x8001, vcpu=13, vaddr=0x40046ce0, ipaddr=0x8a9b28ce0, mode=0x81 0x63 NOTICE: Injecting Data Abort exception into VM 0x8001. D/TC:013 0 abort_handler:550 [abort] abort in User mode (TA will panic) E/TC:??? 0 E/TC:??? 0 User mode data-abort at address 0x40046ce0 (translation fault) E/TC:??? 0 esr 0x94020007 ttbr0 0x20000f03061a0 ttbr1 0x00000000 cidr 0x0 E/TC:??? 0 cpu #13 cpsr 0x00000130 E/TC:??? 0 x0 000000004003e348 x1 000000004003e349 E/TC:??? 0 x2 0000000040046ce0 x3 000000004003e348 E/TC:??? 0 x4 0000000040036088 x5 0000000000000000 E/TC:??? 0 x6 0000000000000000 x7 0000000040042e28 E/TC:??? 0 x8 0000000000000000 x9 0000000000000000 E/TC:??? 0 x10 0000000000000000 x11 0000000000000000 E/TC:??? 0 x12 0000000000000000 x13 0000000040042e28 E/TC:??? 0 x14 00000000400213cf x15 0000000000000000 E/TC:??? 0 x16 0000000000000000 x17 0000000000000000 E/TC:??? 0 x18 0000000000000000 x19 0000000000000000 E/TC:??? 0 x20 0000000000000000 x21 0000000000000000 E/TC:??? 0 x22 0000000000000000 x23 0000000000000000 E/TC:??? 0 x24 0000000000000000 x25 0000000000000000 E/TC:??? 0 x26 0000000000000000 x27 0000000000000000 E/TC:??? 0 x28 0000000000000000 x29 0000000000000000 E/TC:??? 0 x30 0000000000000000 elr 0000000040032106 E/TC:??? 0 sp_el0 0000000040042f80 E/LD: Status of TA f4e750bb-1437-4fbf-8785-8d3580c34994 E/LD: arch: arm E/LD: region 0: va 0x40006000 pa 0xf0404000 size 0x002000 flags rw-s (ldelf) E/LD: region 1: va 0x40008000 pa 0xf0406000 size 0x011000 flags r-xs (ldelf) E/LD: region 2: va 0x40019000 pa 0xf0417000 size 0x001000 flags rw-s (ldelf) E/LD: region 3: va 0x4001a000 pa 0xf0418000 size 0x004000 flags rw-s (ldelf) E/LD: region 4: va 0x4001e000 pa 0xf041c000 size 0x001000 flags r--s E/LD: region 5: va 0x4001f000 pa 0x00001000 size 0x017000 flags r-xs [0] E/LD: region 6: va 0x40036000 pa 0x00018000 size 0x00c000 flags rw-s [0] E/LD: region 7: va 0x40042000 pa 0xf0440000 size 0x001000 flags rw-s (stack) E/LD: region 8: va 0x40043000 pa 0x8b9101620 size 0x003000 flags rw-- (param) E/LD: region 9: va 0x40046000 pa 0x8a9b28ce0 size 0x001000 flags rw-- (param) E/LD: [0] f4e750bb-1437-4fbf-8785-8d3580c34994 @ 0x4001f000 E/LD: Call stack Regards, Yuye ------------------------------------------------------------------ 发件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 发送时间：2023年2月4日(星期六) 11:40 收件人：op-tee <op-tee(a)lists.trustedfirmware.org> 抄　送：赵哲(为哲) <weizhe.zz(a)alibaba-inc.com>; 高海源(码源) <haiyuan.ghy(a)alibaba-inc.com>; 王一蒙(北见) <wym389994(a)alibaba-inc.com> 主　题：OPTEE TA Crash Hi, Does anyone have a good solution to this problem？ https://github.com/OP-TEE/optee_os/issues/5803 <https://github.com/OP-TEE/optee_os/issues/5803 > <https://github.com/OP-TEE/optee_os/issues/5803 <https://github.com/OP-TEE/optee_os/issues/5803 > > regards, yuye -- Hafnium mailing list -- hafnium(a)lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave(a)lists.trustedfirmware.org

2 years, 2 months

1
0
0 0

(no subject)

by 梅建强(禹夜)

Hi, expert Regarding the use of optee dynamic shared memory, we have encountered some problems that cannot be solved recently. Could you please give us some help? debug log is as follows: REE OS kenrel->TEE SPMC (FFA_MEM_SHARE) WARNING: SPM(5): 0x84000073 0x50 0x50 0x0 0x0 0x0 0x0 0x0 VERBOSE: hafnium ffa_handler func:0x84000073 VERBOSE: hafnium allow for one memory region to be shared to the TEE. VERBOSE: ffa_memory_send VERBOSE: share_states->memory_region->sender:0x0 VERBOSE: share_states->memory_region->attributes:0x2f VERBOSE: share_states->share_func:0x84000073 VERBOSE: share_states->fragment_count:0x1 VERBOSE: share_states->sending_complete:0x1 VERBOSE: hanfium fragment_count:1 VERBOSE: hanfium fragment_constituent_counts[i]:1 VERBOSE: hanfium max pa_range bits:0x30 VERBOSE: hanfium pa_begin:0x8a8474000, pa_end:0x8a8475000 VERBOSE: hanfium fragment_count:1 VERBOSE: hanfium fragment_constituent_counts[i]:1 VERBOSE: hanfium max pa_range bits:0x30 VERBOSE: hanfium pa_begin:0x8a8474000, pa_end:0x8a8475000 VERBOSE: Marked sending complete. Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 0 retrieved, sender's original mode: 0x7 SHARE 0x2 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 WARNING: SPM(5): 0x84000061 0x0 0x1 0x0 0x0 0x0 0x0 0x0 ...... REE OS kenrel->TEE SP (OPTEE_FFA_YEILDING_CALL_WITH_ARG(cookie)) WARNING: SPM(5): 0x8400006f 0x8001 0x0 0x80000000 0x0 0x0 0x0 0x0 VERBOSE: hafnium ffa_handler func:0x8400006f D/TC:005 0 mobj_ffa_get_by_cookie:382 cookie 0 resurrecting E/TC:005 0 mobj_ffa_get_by_cookie:385 Populating mobj from rx buffer, cookie 0x1 TEE SPMC->TEE SPMC (FFA_MEM_RETRIEVE_REQ(cookie)) VERBOSE: hafnium ffa_handler func:0x84000074 Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 0 retrieved, sender's original mode: 0x7 SHARE 0x2 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x3 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 0 retrieved, sender's original mode: 0x7 VERBOSE: hanfium fragment_count:1 VERBOSE: hanfium fragment_constituent_counts[i]:1 VERBOSE: hanfium max pa_range bits:0x30 VERBOSE: hanfium pa_begin:0x8a8474000, pa_end:0x8a8475000 VERBOSE: hanfium fragment_count:1 VERBOSE: hanfium fragment_constituent_counts[i]:1 VERBOSE: hanfium max pa_range bits:0x30 VERBOSE: hanfium pa_begin:0x8a8474000, pa_end:0x8a8475000 Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x2 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x3 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 0 retrieved, sender's original mode: 0x7 VERBOSE: hafnium ffa_handler func:0x84000065 ...... ERROR LOG I/TA: read_raw_object enter I/TA: obj_id_sz:0x8 I/TA: obj_id in tee va:0x40086348 I/TA: obj_id in ree va:0x400229f0 I/TA: TEE_MemMove:323 TEE_MemMove enter WARNING: Stage-2 page fault: pc=0x4007a3ce, vmid=0x8001, vcpu=5, vaddr=0x400229f0, ipaddr=0x8a84749f0, mode=0x81 0x63 NOTICE: Injecting Data Abort exception into VM 0x8001. D/TC:005 0 abort_handler:550 [abort] abort in User mode (TA will panic) E/TC:??? 0 E/TC:??? 0 User mode data-abort at address 0x400229f0 (translation fault) E/TC:??? 0 esr 0x94020007 ttbr0 0x20000f03180a0 ttbr1 0x00000000 cidr 0x0 E/TC:??? 0 cpu #5 <https://github.com/OP-TEE/optee_os/pull/5 > cpsr 0x00000130 E/TC:??? 0 x0 0000000040086348 x1 0000000040086349 E/TC:??? 0 x2 00000000400229f0 x3 0000000040086348 E/TC:??? 0 x4 000000004007e088 x5 0000000000000000 E/TC:??? 0 x6 0000000000000000 x7 000000004001fe60 E/TC:??? 0 x8 0000000000000000 x9 0000000000000000 E/TC:??? 0 x10 0000000000000000 x11 0000000000000000 E/TC:??? 0 x12 0000000000000000 x13 000000004001fe60 E/TC:??? 0 x14 00000000400695ad x15 0000000000000000 E/TC:??? 0 x16 00000000f0240370 x17 0000000000000000 E/TC:??? 0 x18 0000000000000000 x19 0000000000000000 E/TC:??? 0 x20 0000000000000000 x21 0000000000000000 E/TC:??? 0 x22 0000000000000000 x23 0000000000000000 E/TC:??? 0 x24 0000000000000000 x25 0000000000000000 E/TC:??? 0 x26 0000000000000000 x27 0000000000000000 E/TC:??? 0 x28 0000000000000000 x29 0000000000000000 E/TC:??? 0 x30 0000000000000000 elr 000000004007a3ce E/TC:??? 0 sp_el0 000000004001ff80 E/LD: Status of TA f4e750bb-1437-4fbf-8785-8d3580c34994 E/LD: arch: arm E/LD: region 0: va 0x40006000 pa 0xf0404000 size 0x002000 flags rw-s (ldelf) E/LD: region 1: va 0x40008000 pa 0xf0406000 size 0x011000 flags r-xs (ldelf) E/LD: region 2: va 0x40019000 pa 0xf0417000 size 0x001000 flags rw-s (ldelf) E/LD: region 3: va 0x4001a000 pa 0xf0418000 size 0x004000 flags rw-s (ldelf) E/LD: region 4: va 0x4001e000 pa 0xf041c000 size 0x001000 flags r--s E/LD: region 5: va 0x4001f000 pa 0xf0440000 size 0x001000 flags rw-s (stack) E/LD: region 6: va 0x40020000 pa 0x8a1262340 size 0x002000 flags rw-- (param) E/LD: region 7: va 0x40022000 pa 0x8a84749f0 size 0x001000 flags rw-- (param) E/LD: region 8: va 0x40067000 pa 0x00001000 size 0x017000 flags r-xs [0] E/LD: region 9: va 0x4007e000 pa 0x00018000 size 0x00c000 flags rw-s [0] E/LD: [0] f4e750bb-1437-4fbf-8785-8d3580c34994 @ 0x40067000 ERROR CODE "optee_examples/secure_storage/ta/secure_storage_ta.c" static TEE_Result read_raw_object(uint32_t param_types, TEE_Param params[4]) { const uint32_t exp_param_types = TEE_PARAM_TYPES(TEE_PARAM_TYPE_MEMREF_INPUT, TEE_PARAM_TYPE_MEMREF_OUTPUT, TEE_PARAM_TYPE_NONE, TEE_PARAM_TYPE_NONE); char *obj_id; size_t obj_id_sz; IMSG("read_raw_object enter\n"); \/* * Safely get the invocation parameters *\/ if (param_types != exp_param_types) return TEE_ERROR_BAD_PARAMETERS; obj_id_sz = params[0].memref.size; obj_id = TEE_Malloc(obj_id_sz, 0); IMSG("obj_id_sz:%#x\n",obj_id_sz); IMSG("obj_id in tee va:%p\n",obj_id); IMSG("obj_id in ree va:%p\n",params[0].memref.buffer); if (!obj_id) return TEE_ERROR_OUT_OF_MEMORY; TEE_MemMove(obj_id, params[0].memref.buffer, obj_id_sz); //<-- ERROR OCCURED TEE_Free(obj_id); return TEE_SUCCESS; } It seems that OP-TEE tries to use an IPA which isn't mapped by Hafnium. Can anyone figure out what the problem is and give some debugging directions? Thanks! regards, yuye

2 years, 2 months

3
3
0 0

回复：Re: Hafnium load-address

by 梅建强(禹夜)

Hi, Thanks for your efforts for this query. I have tried your solution. Although the Hafnium code could be built successfully, it does not work when the boot flow run into the entry of the Hafnium. I tried to debug the error with trace32 tool. And I confirmed that the Hafnium code has been loaded over 34G of free address space. However, when PC register point to the start address of Hafnium, the code data is displayed as udf #0x0. It may be a page table problem, and we are still locating the problem reason. Regards, Mei, Jianqiang. ------------------------------------------------------------------ 发件人：Olivier Deprez via Hafnium <hafnium(a)lists.trustedfirmware.org> 发送时间：2022年12月21日(星期三) 18:02 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：hafnium <hafnium(a)lists.trustedfirmware.org>; 常琳(特睿) <terui.cl(a)alibaba-inc.com>; 赵哲(为哲) <weizhe.zz(a)alibaba-inc.com>; 黄明(连一) <hm281385(a)alibaba-inc.com> 主　题：[Hafnium] Re: Hafnium load-address Hi, Sorry for the delay in replying to this query. After few trials I ended with this possible solution: https://review.trustedfirmware.org/c/hafnium/hafnium/+/18510 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/18510 > This should permit loading the Hafnium image to an address up to 48 bits (and by updating project/reference/BUILD.gn origin_address per your suggestion). It is possible to further extend beyond 48 bits (e.g. 52 bits which is the maximum permitted VA using FEAT_LPA2). Let me know if this works for you, then I can proceed further with polishing this change. Regards, Olivier. ________________________________ From: 梅建强(禹夜) via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: 11 December 2022 09:58 To: Olivier Deprez <Olivier.Deprez(a)arm.com> Cc: hafnium <hafnium(a)lists.trustedfirmware.org>; 常琳(特睿) <terui.cl(a)alibaba-inc.com>; 赵哲(为哲) <weizhe.zz(a)alibaba-inc.com>; 黄明(连一) <hm281385(a)alibaba-inc.com> Subject: [Hafnium] Hafnium load-address Hello, expert Firstly, thanks for your answer some time ago. That's useful to our project.We combined the Hafnium (run at S-EL2) and the optee (run at S-EL1), then modified the configuration to adapt to our own environment. Now we can start the os normally. Now we want to optimize a technical point, which is to load and run hafnium over 34G of free address space. This requires hafnium to support 64-bit load-address. I tried to modify the configuration in BUILD.gn as follows: origin_address = "0x880000000" And I encountered the build error: FAILED: secure_aem_v8a_fvp_clang/hafnium.elf ld.lld -pie --gc-sections --defsym=ORIGIN_ADDRESS=0x880000000 -O2 --icf=all --fatal-warnings --color-diagnostics -T /home/yuye/hafnium/Hafnium/build/image/image.ld -o secure_aem_v8a_fvp_clang/hafnium.elf --start-group @secure_aem_v8a_fvp_clang/hafnium.elf.rsp --end-group ld.lld: error: secure_aem_v8a_fvp_clang/obj/src/arch/aarch64/entry.entry.o:(.init.entry+0xC8): relocation R_AARCH64_ABS32 out of range: 36507222016 is not in [-2147483648, 4294967295]; references ORIGIN_ADDRESS >>> defined in -defsym:1 ninja: build stopped: subcommand failed. Makefile:70: recipe for target 'all' failed make: *** [all] Error 1 + cp out/reference/secure_aem_v8a_fvp_clang/hafnium.bin ../../V2/Ali_M1_Public/Nonosi/Platform/Ali/M1/Bin/ cp: cannot stat 'out/reference/secure_aem_v8a_fvp_clang/hafnium.bin': No such file or directory In this case, it seems that the new address causes some relative addressing to reach too far. Is there any solutions or supports for this issue currently in the community? Regards, Mei, Jianqiang. -- Hafnium mailing list -- hafnium(a)lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave(a)lists.trustedfirmware.org -- Hafnium mailing list -- hafnium(a)lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave(a)lists.trustedfirmware.org

2 years, 2 months

2
1
0 0

hafnium page table configuration

by 梅建强(禹夜)

Hi, At present, I suspect that this may be a hafnium problem, secure_storage CA/TA may use over 34G address space before communication. May I ask, does hafnium currently support the configuration of the page table of 0x8 80000000-xxxxxxxxx address range? If yes, how to configure it? The error log is as follows: Current share states: SHARE 0x0 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x1 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 SHARE 0x2 (from VM 0x0, attributes 0x2f, flags 0x8, tag 0, to 1 recipients [VM 0x8001: 0x6 (offset 48)]): fully sent with 1 fragments, 1 retrieved, sender's original mode: 0x7 WARNING: Stage-2 page fault: pc=0x40032106, vmid=0x8001, vcpu=13, vaddr=0x40046ce0, ipaddr=0x8a9b28ce0, mode=0x81 0x63 NOTICE: Injecting Data Abort exception into VM 0x8001. D/TC:013 0 abort_handler:550 [abort] abort in User mode (TA will panic) E/TC:??? 0 E/TC:??? 0 User mode data-abort at address 0x40046ce0 (translation fault) E/TC:??? 0 esr 0x94020007 ttbr0 0x20000f03061a0 ttbr1 0x00000000 cidr 0x0 E/TC:??? 0 cpu #13 cpsr 0x00000130 E/TC:??? 0 x0 000000004003e348 x1 000000004003e349 E/TC:??? 0 x2 0000000040046ce0 x3 000000004003e348 E/TC:??? 0 x4 0000000040036088 x5 0000000000000000 E/TC:??? 0 x6 0000000000000000 x7 0000000040042e28 E/TC:??? 0 x8 0000000000000000 x9 0000000000000000 E/TC:??? 0 x10 0000000000000000 x11 0000000000000000 E/TC:??? 0 x12 0000000000000000 x13 0000000040042e28 E/TC:??? 0 x14 00000000400213cf x15 0000000000000000 E/TC:??? 0 x16 0000000000000000 x17 0000000000000000 E/TC:??? 0 x18 0000000000000000 x19 0000000000000000 E/TC:??? 0 x20 0000000000000000 x21 0000000000000000 E/TC:??? 0 x22 0000000000000000 x23 0000000000000000 E/TC:??? 0 x24 0000000000000000 x25 0000000000000000 E/TC:??? 0 x26 0000000000000000 x27 0000000000000000 E/TC:??? 0 x28 0000000000000000 x29 0000000000000000 E/TC:??? 0 x30 0000000000000000 elr 0000000040032106 E/TC:??? 0 sp_el0 0000000040042f80 E/LD: Status of TA f4e750bb-1437-4fbf-8785-8d3580c34994 E/LD: arch: arm E/LD: region 0: va 0x40006000 pa 0xf0404000 size 0x002000 flags rw-s (ldelf) E/LD: region 1: va 0x40008000 pa 0xf0406000 size 0x011000 flags r-xs (ldelf) E/LD: region 2: va 0x40019000 pa 0xf0417000 size 0x001000 flags rw-s (ldelf) E/LD: region 3: va 0x4001a000 pa 0xf0418000 size 0x004000 flags rw-s (ldelf) E/LD: region 4: va 0x4001e000 pa 0xf041c000 size 0x001000 flags r--s E/LD: region 5: va 0x4001f000 pa 0x00001000 size 0x017000 flags r-xs [0] E/LD: region 6: va 0x40036000 pa 0x00018000 size 0x00c000 flags rw-s [0] E/LD: region 7: va 0x40042000 pa 0xf0440000 size 0x001000 flags rw-s (stack) E/LD: region 8: va 0x40043000 pa 0x8b9101620 size 0x003000 flags rw-- (param) E/LD: region 9: va 0x40046000 pa 0x8a9b28ce0 size 0x001000 flags rw-- (param) E/LD: [0] f4e750bb-1437-4fbf-8785-8d3580c34994 @ 0x4001f000 E/LD: Call stack Regards, Yuye ------------------------------------------------------------------ 发件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 发送时间：2023年2月4日(星期六) 11:40 收件人：op-tee <op-tee(a)lists.trustedfirmware.org> 抄　送：赵哲(为哲) <weizhe.zz(a)alibaba-inc.com>; 高海源(码源) <haiyuan.ghy(a)alibaba-inc.com>; 王一蒙(北见) <wym389994(a)alibaba-inc.com> 主　题：OPTEE TA Crash Hi, Does anyone have a good solution to this problem？ https://github.com/OP-TEE/optee_os/issues/5803 <https://github.com/OP-TEE/optee_os/issues/5803 > regards, yuye

2 years, 2 months

2
1
0 0

hyp_loaded

by 梅建强(禹夜)

Hi, expert I want to confirm a problem about using hafnium to load spmc payload. That is, Dose hafnium supports hyp_loaded for spmc payload or ffa_partion (such as optee_os) in the boot phase? If the community confirms that it does not support it, I wonder, what might be the problem with doing so? I see the following code in hanfnium： if (manifest->vm[i].is_ffa_partition && !manifest->vm[i].is_hyp_loaded) { TRY(parse_ffa_partition_package(stage1_locked, &vm_node, &manifest->vm[i], vm_id, ppool)); } else { TRY(parse_vm(&vm_node, &manifest->vm[i], vm_id)); } It seems that hafnium has no handling for both is_ffa_partition and is_hyp_loaded. regards, yuye

2 years, 3 months

5
16
0 0

prebuilts gn tool update

by Olivier Deprez

Hi, Fyi we merged this gn tool prebuilt version update https://review.trustedfirmware.org/q/topic:%22od%252Fgn-update-1901%22+(sta… Essentially more recent sources were used to build the x86 host version (as the tool hasn't been updated since 2018), and this aligns to the version used on aarch64 host. 'make format' uses gn to format .gn build files, and as a consequence new formatting rules apply with the new tool version. The side effect is that changes already submitted in the hafnium dashboards would have to be rebased, and run make format again to pass the CI. Regards, Olivier.

2 years, 3 months

1
0
0 0

Hafnium CI policy change

by Olivier Deprez

Hi, Currently each patch submission automatically starts two jenkins jobs for cloning, building, running tests and static checks. The longest of the two jobs can run for 30mn - 1h depending on server load. A 10 patches stack queues as many of such jobs and it can be a long process to get all votes with a significant load applied to the servers. Along with this the Allow-CI+1 label can be used by maintainers to re-trigger a job either because it failed, or the results/logs were flushed. Per discussion with various stakeholders we come to a conclusion it would be preferable to only use the Allow-CI label and discard the automatic trigger for each and every patch. Similarly to TF-A, a change submitted by a developer requires a maintainer to apply the Allow-CI+1 label to build and run tests. For a large patch stack, the expectation is at least the top patch must pass the CI run before merging, but not necessarily all intermediate patches. It's the maintainer discretion to apply the label at different places in the patch stack to get intermediate results as required. I intend to submit a change shortly to adopt this new policy. Let me know if any concern. Regards, Olivier.

2 years, 3 months

2
2
0 0

Hafnium load-address

by 梅建强(禹夜)

Hello, expert Firstly, thanks for your answer some time ago. That's useful to our project.We combined the Hafnium (run at S-EL2) and the optee (run at S-EL1), then modified the configuration to adapt to our own environment. Now we can start the os normally. Now we want to optimize a technical point, which is to load and run hafnium over 34G of free address space. This requires hafnium to support 64-bit load-address. I tried to modify the configuration in BUILD.gn as follows: origin_address = "0x880000000" And I encountered the build error: FAILED: secure_aem_v8a_fvp_clang/hafnium.elf ld.lld -pie --gc-sections --defsym=ORIGIN_ADDRESS=0x880000000 -O2 --icf=all --fatal-warnings --color-diagnostics -T /home/yuye/hafnium/Hafnium/build/image/image.ld -o secure_aem_v8a_fvp_clang/hafnium.elf --start-group @secure_aem_v8a_fvp_clang/hafnium.elf.rsp --end-group ld.lld: error: secure_aem_v8a_fvp_clang/obj/src/arch/aarch64/entry.entry.o:(.init.entry+0xC8): relocation R_AARCH64_ABS32 out of range: 36507222016 is not in [-2147483648, 4294967295]; references ORIGIN_ADDRESS >>> defined in -defsym:1 ninja: build stopped: subcommand failed. Makefile:70: recipe for target 'all' failed make: *** [all] Error 1 + cp out/reference/secure_aem_v8a_fvp_clang/hafnium.bin ../../V2/Ali_M1_Public/Nonosi/Platform/Ali/M1/Bin/ cp: cannot stat 'out/reference/secure_aem_v8a_fvp_clang/hafnium.bin': No such file or directory In this case, it seems that the new address causes some relative addressing to reach too far. Is there any solutions or supports for this issue currently in the community? Regards, Mei, Jianqiang.

2 years, 4 months

2
1
0 0

Re: 回复：回复：SMMU Configuration

by Olivier Deprez

Hi, > Currently we bypass smmu and has finished boot process, later we will discuss whether there is a scenario for using smmu in the project. That's great news! > Yes, we use it on the server and need to support LPA. Just as a matter of clarifying, Hafnium treats FEAT_LPA by restricting the physical address space to 48 bits: https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/arch/aarch64/m… The reason is that with FEAT_LPA, only the 16KB/64KB translation granules are supported, and Hafnium only supports the 4KB translation granule. It means the normal world shall not attempt providing physical addresses (e.g. in memory sharing operations to the SPMC) where the PA uses an address size greater than 48 bits. Is this a reasonable assumption when integrating in your system? Secondly we were reported a slight issue when applying this restriction by Jens @ Linaro. I appreciate the change below might be submitted shortly for upstream. https://github.com/jenswi-linaro/hafnium/commit/659c79d5eacf32e8f5fcb1a6403… Regards, Olivier. From: 赵哲(为哲) <weizhe.zz(a)alibaba-inc.com> Sent: 06 December 2022 10:49 To: Olivier Deprez <Olivier.Deprez(a)arm.com>; 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> Cc: hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org>; 常琳(特睿) <terui.cl(a)alibaba-inc.com> Subject: 回复：回复：SMMU Configuration Hi Olivier, Thank you very much for your reply and suggestion. Currently we bypass smmu and has finished boot process, later we will discuss whether there is a scenario for using smmu in the project. Other question are you relying on FEAT_LPA/FEAT_LPA2? ---Yes, we use it on the server and need to support LPA. --------------------------------------------------------------------------------------------------------------------------------------------------------------- 本邮件及其附件含有阿里巴巴集团的商业秘密信息，仅限于发送给上面地址中列出的个人和群组，禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制或散发）本邮件及其附件中的信息，如果您错收本邮件，请您立即电话或邮件通知发件人并删除本邮件。 This email and its attachments contain confidential information from Alibaba Group, which is intended only for the person or entity whose address is listed above. Any use of information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it. ------------------------------------------------------------------ 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> 发送时间：2022年12月1日(星期四) 17:12 收件人：赵哲(为哲) <weizhe.zz(a)alibaba-inc.com>; 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org>; 常琳(特睿) <terui.cl(a)alibaba-inc.com> 主　题：Re: 回复：SMMU Configuration Hi, > Since our platform uses the server's cpu, smmu does have SMMU_S_IDR1.S_SIDSIZE=24， Thanks for confirming. > Does the smmu driver of Hafnium support 2-level Stream Table to reduce memory usage? No, as observed here: https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/arch/aarch64/a… But this is an interesting input to us, as we've validated the driver with a low STEs count and this only required a linear table. So this is an improvement we may think about. > hafnium commit hash dd883207ee9b31c19169adf97c918d561dcb9a > yes，i have set memory range security attributes by the TZC controller. Alright. Before going further, do you confirm you have use cases requiring this SMMU driver/component? In particular do you have devices upstream to this SMMU generating transactions through a secure stream ID? e.g. this can be an SPI peripheral only accessible from the secure world? What I mean here is there is no point in including the driver (and consuming a lot of resources) if there is no use case to fulfill eventually? If there are, then yes, we can go ahead and find solutions to enable such use cases. For the sake of experiment, did you attempt increasing the number of heap pages beyond 262144? I don't have a clear idea of the memory requirements for your platform. In the reference code, the default is 180 heap pages, but I assume this can increase a lot depending on the memory size, secure partitions S2 mappings etc. Other question are you relying on FEAT_LPA/FEAT_LPA2? Regards, Olivier. From: 赵哲(为哲) <weizhe.zz(a)alibaba-inc.com> Sent: 01 December 2022 04:00 To: Olivier Deprez <Olivier.Deprez(a)arm.com> Cc: hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org>; 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com>; 常琳(特睿) <terui.cl(a)alibaba-inc.com> Subject: 回复：SMMU Configuration Hi， 1、Since our platform uses the server's cpu, smmu does have SMMU_S_IDR1.S_SIDSIZE=24， Does the smmu driver of Hafnium support 2-level Stream Table to reduce memory usage？ 2、 hafnium commit hash dd883207ee9b31c19169adf97c918d561dcb9a5c 3、 yes，i have set memory range security attributes by the TZC controller. --------------------------------------------------------------------------------------------------------------------------------------------------------------- 本邮件及其附件含有阿里巴巴集团的商业秘密信息，仅限于发送给上面地址中列出的个人和群组，禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制或散发）本邮件及其附件中的信息，如果您错收本邮件，请您立即电话或邮件通知发件人并删除本邮件。 This email and its attachments contain confidential information from Alibaba Group, which is intended only for the person or entity whose address is listed above. Any use of information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it. ------------------------------------------------------------------ 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> 发送时间：2022年11月30日(星期三) 17:17 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com>; Olivier Deprez <Olivier.Deprez(a)arm.com> 抄送：赵哲(为哲) <weizhe.zz(a)alibaba-inc.com>; hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org> 主题：Re: SMMU Configuration Hi, Another out of curiosity question about: VERBOSE: SMMUv3: Memory allocated at 0000008800043000 for CMDQ Hafnium as SPMC in the secure side must allocate data structures only from secure memory. Do you confirm this memory range is marked secure by the TZASC controller? Regards, Olivier. From: Olivier Deprez via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: 30 November 2022 10:13 To: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> Cc: 赵哲(为哲) <weizhe.zz(a)alibaba-inc.com>; hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org> Subject: [Hafnium] Re: SMMU Configuration Hi, 1/ About: VERBOSE: SMMUv3 Total StreamTable entries: 16777216 I wonder if this is a realistic value suggesting SMMU_S_IDR1.S_SIDSIZE=24? In which case the stream table size would grow up to 1GB. Can you confirm this parameter value on your platform? Also can you confirm the smmu base address on your platform, as it may be that hafnium probes the smmu io space from a wrong address? 2/ can you tell which commit hash you're using for hafnium? We've observed random stack overflows corrupting data sections (in this case the smmu static data) because of stack size limitation. Can you confirm you have this change in your tree: https://git.trustedfirmware.org/hafnium/hafnium.git/commit/?id=64b421e19a06… Thanks, Olivier. ________________________________ From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> Sent: 28 November 2022 10:48 To: Olivier Deprez <Olivier.Deprez(a)arm.com> Cc: 赵哲(为哲) <weizhe.zz(a)alibaba-inc.com> Subject: SMMU Configuration Hi, when I enabled SMMU by set the config file as follows： aarch64_toolchains("secure_aem_v8a_fvp") { cpu = "cortex-a57" origin_address = "0x06000000" boot_flow = "//src/boot_flow:spmc" console = "//src/arch/aarch64/pl011" iommu = "//src/arch/aarch64/arm_smmuv3" gic_version = 3 gicd_base_address = "0x2e000000" gicr_base_address = "0x2e140000" gicr_frames = 8 heap_pages = 100000 max_cpus = 8 max_vms = 16 # branch_protection = "standard" toolchain_args = { plat_ffa = "//src/arch/aarch64/plat/ffa:spmc" plat_psci = "//src/arch/aarch64/plat/psci:spmc" plat_interrupts = "//src/arch/aarch64/plat/interrupts:gicv3" plat_prng = "//src/arch/aarch64/plat/prng:prng" secure_world = "1" pl011_base_address = "0x2A400000" smmu_base_address = "0x3FC00000" smmu_memory_size = "0x400000" # enable_mte = "1" plat_log_level = "LOG_LEVEL_VERBOSE" } } I encountered a problem，The log is as follows， there is not enough memory for init SMMU， I have define “heap_pages to 100000”， but it's still not enough，Do you have any suggestions? VERBOSE: SMMUv3 mapped at 000000003fc00000 VERBOSE: SMMUv3: write to (S_)GBPA VERBOSE: SMMUv3: write to (S_)CR0 VERBOSE: SMMUv3: Input Addr: 48-bits, Output Addr: 48-bits VERBOSE: SMMUv3: Total CMDQ entries: 524288 VERBOSE: SMMUv3: Memory allocated at 0000008800043000 for CMDQ VERBOSE: SMMUv3: write to (S_)CMDQ_BASE VERBOSE: SMMUv3: write to (S_)CMDQ_CONS, (S_)CMDQ_PROD VERBOSE: SMMUv3: Total EVTQ entries: 524288 VERBOSE: SMMUv3: Memory allocated at 0000008800844000 for EVTQ VERBOSE: SMMUv3: write to (S_)EVTQ_BASE VERBOSE: SMMUv3: write to (S_)EVTQ_PROD,(S_)EVTQ_CONS VERBOSE: SMMUv3 Total StreamTable entries: 16777216 ERROR: SMMUv3: Could not allocate memory for stream table entries ERROR: SMMUv3: Failed to initialize driver Panic: Could not initialize IOMMUs. -- Hafnium mailing list -- hafnium(a)lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave(a)lists.trustedfirmware.org

2 years, 5 months

2
1
0 0

Re: 回复：SMMU Configuration

by Olivier Deprez

Hi, > Since our platform uses the server's cpu, smmu does have SMMU_S_IDR1.S_SIDSIZE=24， Thanks for confirming. > Does the smmu driver of Hafnium support 2-level Stream Table to reduce memory usage? No, as observed here: https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/arch/aarch64/a… But this is an interesting input to us, as we've validated the driver with a low STEs count and this only required a linear table. So this is an improvement we may think about. > hafnium commit hash dd883207ee9b31c19169adf97c918d561dcb9a > yes，i have set memory range security attributes by the TZC controller. Alright. Before going further, do you confirm you have use cases requiring this SMMU driver/component? In particular do you have devices upstream to this SMMU generating transactions through a secure stream ID? e.g. this can be an SPI peripheral only accessible from the secure world? What I mean here is there is no point in including the driver (and consuming a lot of resources) if there is no use case to fulfill eventually? If there are, then yes, we can go ahead and find solutions to enable such use cases. For the sake of experiment, did you attempt increasing the number of heap pages beyond 262144? I don't have a clear idea of the memory requirements for your platform. In the reference code, the default is 180 heap pages, but I assume this can increase a lot depending on the memory size, secure partitions S2 mappings etc. Other question are you relying on FEAT_LPA/FEAT_LPA2? Regards, Olivier. From: 赵哲(为哲) <weizhe.zz(a)alibaba-inc.com> Sent: 01 December 2022 04:00 To: Olivier Deprez <Olivier.Deprez(a)arm.com> Cc: hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org>; 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com>; 常琳(特睿) <terui.cl(a)alibaba-inc.com> Subject: 回复：SMMU Configuration Hi， 1、Since our platform uses the server's cpu, smmu does have SMMU_S_IDR1.S_SIDSIZE=24， Does the smmu driver of Hafnium support 2-level Stream Table to reduce memory usage？ 2、 hafnium commit hash dd883207ee9b31c19169adf97c918d561dcb9a5c 3、 yes，i have set memory range security attributes by the TZC controller. --------------------------------------------------------------------------------------------------------------------------------------------------------------- 本邮件及其附件含有阿里巴巴集团的商业秘密信息，仅限于发送给上面地址中列出的个人和群组，禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制或散发）本邮件及其附件中的信息，如果您错收本邮件，请您立即电话或邮件通知发件人并删除本邮件。 This email and its attachments contain confidential information from Alibaba Group, which is intended only for the person or entity whose address is listed above. Any use of information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it. ------------------------------------------------------------------ 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> 发送时间：2022年11月30日(星期三) 17:17 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com>; Olivier Deprez <Olivier.Deprez(a)arm.com> 抄　送：赵哲(为哲) <weizhe.zz(a)alibaba-inc.com>; hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org> 主　题：Re: SMMU Configuration Hi, Another out of curiosity question about: VERBOSE: SMMUv3: Memory allocated at 0000008800043000 for CMDQ Hafnium as SPMC in the secure side must allocate data structures only from secure memory. Do you confirm this memory range is marked secure by the TZASC controller? Regards, Olivier. From: Olivier Deprez via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: 30 November 2022 10:13 To: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> Cc: 赵哲(为哲) <weizhe.zz(a)alibaba-inc.com>; hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org> Subject: [Hafnium] Re: SMMU Configuration Hi, 1/ About: VERBOSE: SMMUv3 Total StreamTable entries: 16777216 I wonder if this is a realistic value suggesting SMMU_S_IDR1.S_SIDSIZE=24? In which case the stream table size would grow up to 1GB. Can you confirm this parameter value on your platform? Also can you confirm the smmu base address on your platform, as it may be that hafnium probes the smmu io space from a wrong address? 2/ can you tell which commit hash you're using for hafnium? We've observed random stack overflows corrupting data sections (in this case the smmu static data) because of stack size limitation. Can you confirm you have this change in your tree: https://git.trustedfirmware.org/hafnium/hafnium.git/commit/?id=64b421e19a06… Thanks, Olivier. ________________________________ From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> Sent: 28 November 2022 10:48 To: Olivier Deprez <Olivier.Deprez(a)arm.com> Cc: 赵哲(为哲) <weizhe.zz(a)alibaba-inc.com> Subject: SMMU Configuration Hi, when I enabled SMMU by set the config file as follows： aarch64_toolchains("secure_aem_v8a_fvp") { cpu = "cortex-a57" origin_address = "0x06000000" boot_flow = "//src/boot_flow:spmc" console = "//src/arch/aarch64/pl011" iommu = "//src/arch/aarch64/arm_smmuv3" gic_version = 3 gicd_base_address = "0x2e000000" gicr_base_address = "0x2e140000" gicr_frames = 8 heap_pages = 100000 max_cpus = 8 max_vms = 16 # branch_protection = "standard" toolchain_args = { plat_ffa = "//src/arch/aarch64/plat/ffa:spmc" plat_psci = "//src/arch/aarch64/plat/psci:spmc" plat_interrupts = "//src/arch/aarch64/plat/interrupts:gicv3" plat_prng = "//src/arch/aarch64/plat/prng:prng" secure_world = "1" pl011_base_address = "0x2A400000" smmu_base_address = "0x3FC00000" smmu_memory_size = "0x400000" # enable_mte = "1" plat_log_level = "LOG_LEVEL_VERBOSE" } } I encountered a problem，The log is as follows， there is not enough memory for init SMMU， I have define “heap_pages to 100000”， but it's still not enough，Do you have any suggestions? VERBOSE: SMMUv3 mapped at 000000003fc00000 VERBOSE: SMMUv3: write to (S_)GBPA VERBOSE: SMMUv3: write to (S_)CR0 VERBOSE: SMMUv3: Input Addr: 48-bits, Output Addr: 48-bits VERBOSE: SMMUv3: Total CMDQ entries: 524288 VERBOSE: SMMUv3: Memory allocated at 0000008800043000 for CMDQ VERBOSE: SMMUv3: write to (S_)CMDQ_BASE VERBOSE: SMMUv3: write to (S_)CMDQ_CONS, (S_)CMDQ_PROD VERBOSE: SMMUv3: Total EVTQ entries: 524288 VERBOSE: SMMUv3: Memory allocated at 0000008800844000 for EVTQ VERBOSE: SMMUv3: write to (S_)EVTQ_BASE VERBOSE: SMMUv3: write to (S_)EVTQ_PROD,(S_)EVTQ_CONS VERBOSE: SMMUv3 Total StreamTable entries: 16777216 ERROR: SMMUv3: Could not allocate memory for stream table entries ERROR: SMMUv3: Failed to initialize driver Panic: Could not initialize IOMMUs. -- Hafnium mailing list -- hafnium(a)lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave(a)lists.trustedfirmware.org

2 years, 5 months

2
1
0 0

Re: SMMU Configuration

by Olivier Deprez

Hi, 1/ About: VERBOSE: SMMUv3 Total StreamTable entries: 16777216 I wonder if this is a realistic value suggesting SMMU_S_IDR1.S_SIDSIZE=24? In which case the stream table size would grow up to 1GB. Can you confirm this parameter value on your platform? Also can you confirm the smmu base address on your platform, as it may be that hafnium probes the smmu io space from a wrong address? 2/ can you tell which commit hash you're using for hafnium? We've observed random stack overflows corrupting data sections (in this case the smmu static data) because of stack size limitation. Can you confirm you have this change in your tree: https://git.trustedfirmware.org/hafnium/hafnium.git/commit/?id=64b421e19a06… Thanks, Olivier. ________________________________ From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> Sent: 28 November 2022 10:48 To: Olivier Deprez <Olivier.Deprez(a)arm.com> Cc: 赵哲(为哲) <weizhe.zz(a)alibaba-inc.com> Subject: SMMU Configuration Hi, when I enabled SMMU by set the config file as follows： aarch64_toolchains("secure_aem_v8a_fvp") { cpu = "cortex-a57" origin_address = "0x06000000" boot_flow = "//src/boot_flow:spmc" console = "//src/arch/aarch64/pl011" iommu = "//src/arch/aarch64/arm_smmuv3" gic_version = 3 gicd_base_address = "0x2e000000" gicr_base_address = "0x2e140000" gicr_frames = 8 heap_pages = 100000 max_cpus = 8 max_vms = 16 # branch_protection = "standard" toolchain_args = { plat_ffa = "//src/arch/aarch64/plat/ffa:spmc" plat_psci = "//src/arch/aarch64/plat/psci:spmc" plat_interrupts = "//src/arch/aarch64/plat/interrupts:gicv3" plat_prng = "//src/arch/aarch64/plat/prng:prng" secure_world = "1" pl011_base_address = "0x2A400000" smmu_base_address = "0x3FC00000" smmu_memory_size = "0x400000" # enable_mte = "1" plat_log_level = "LOG_LEVEL_VERBOSE" } } I encountered a problem，The log is as follows， there is not enough memory for init SMMU， I have define “heap_pages to 100000”， but it's still not enough，Do you have any suggestions? VERBOSE: SMMUv3 mapped at 000000003fc00000 VERBOSE: SMMUv3: write to (S_)GBPA VERBOSE: SMMUv3: write to (S_)CR0 VERBOSE: SMMUv3: Input Addr: 48-bits, Output Addr: 48-bits VERBOSE: SMMUv3: Total CMDQ entries: 524288 VERBOSE: SMMUv3: Memory allocated at 0000008800043000 for CMDQ VERBOSE: SMMUv3: write to (S_)CMDQ_BASE VERBOSE: SMMUv3: write to (S_)CMDQ_CONS, (S_)CMDQ_PROD VERBOSE: SMMUv3: Total EVTQ entries: 524288 VERBOSE: SMMUv3: Memory allocated at 0000008800844000 for EVTQ VERBOSE: SMMUv3: write to (S_)EVTQ_BASE VERBOSE: SMMUv3: write to (S_)EVTQ_PROD,(S_)EVTQ_CONS VERBOSE: SMMUv3 Total StreamTable entries: 16777216 ERROR: SMMUv3: Could not allocate memory for stream table entries ERROR: SMMUv3: Failed to initialize driver Panic: Could not initialize IOMMUs.

2 years, 5 months

2
2
0 0

Re: 回复：run hafnium as spmc at s-el2

by Olivier Deprez

Cc Hafnium list. ________________________________ From: Olivier Deprez <Olivier.Deprez(a)arm.com> Sent: 25 November 2022 17:41 To: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> Subject: Re: 回复：run hafnium as spmc at s-el2 Hi, See answers inline [OD] Regards, Olivier. ________________________________ From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> Sent: 25 November 2022 03:18 To: Olivier Deprez <Olivier.Deprez(a)arm.com> Subject: 回复：run hafnium as spmc at s-el2 Hello，expert I do intend to use OP-TEE as SEL1 payload / secure partition with hafnium running on SEL2 and run linux in the normal world. In my environment，when TF-A and Hafnium boot, only a single primary core runs. After the os starts, the secondary core is booted by bl31. Now, I have some other questions ： 1）When entering hafnium to initialize gic, I get the following error (the first two lines are my debug prints) : populate_redist_base_addrs:375,typer_reg:844425014019047,current_rdist_frame:2e200000 populate_redist_base_addrs:375,typer_reg:0,current_rdist_frame:2e220000 ERROR: Data abort: pc=0xff20558c, esr=0x96000007, ec=0x25, far=0x2e240008 The gic appears to be missing the corresponding page table configuration. Hafnium runs on s-el2, and according to the arm specification, it has a set of page tables for itself and only does stage 1 translation. So how to configure the page table for hafnium to include the address space where the gic resides? [OD] Are you using the Base FVP platform? The SPMC run address suggests this might be an Infra/Neoverse platform? Did you take care of creating a new platform, or update the FVP defaults for the GICD/GICR system addresses? https://git.trustedfirmware.org/hafnium/project/reference.git/tree/BUILD.gn… 2）Is smmu necessary for hanfium to run as SPMC, how much running memory does hafnium need？ And how to specify the address space where its running memory resides? [OD] This depends first if your platform implements an SMMU and it supports secure S2 translation (from >=SMMUv3.2). Second condition is if you need to protect VMs from a peripheral upstream from this SMMU. If not, you can omit the SMMU driver by removing the iommu property: https://git.trustedfirmware.org/hafnium/project/reference.git/tree/BUILD.gn… 3）When TF-A and Hafnium boot, only a single primary core runs. How to configure the cpu core to boot the hafnium? [OD] When the platform resets and starts, a single core is up (aka the primary core) and TF-A boots on this core through BL1/BL2/BL31 stages. From there BL31 launches BL32/Hafnium on the same core. There is no configurability from a SW perspective. It is up to the platform itself to tie onto which core the system boots. If running on a model, that *may* be controlled by a model parameter. In addition, there are multiple cores at runtime. How does hanfium switch cores to switch the corresponding secure partions? How does core switching relate to vCPU switching？ [OD] Hafnium is controlled by a normal world driver e.g. the linux upstream FF-A driver: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drive… and a TEE driver e.g. OP-TEE driver https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drive… The primary scheduler is linux' and Hafnium is not performing scheduling decisions. As an example, a direct request on CPU1 emitted from the normal world through an SMC, is processed by the SPMC and delivered to the SP(OP-TEE) on vCPU1. Thank you very much～ ------------------------------------------------------------------ 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> 发送时间：2022年11月25日(星期五) 03:24 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org> 主　题：Re: run hafnium as spmc at s-el2 Hi Mei Jianqiang, > In my environment, hafnium is running as spmc in s-el2, and my question is as follows: Can you tell a bit more on your setup, if possible, do you intend to use OP-TEE as SEL1 payload / secure partition? Are you running linux in the normal world? > 1) In the spmc_optee_sp_manifest.dts file, there is an attribute load_address = <0x0 0xFF200000>. > What do the two parts of load_address mean respectively? Any details on other configurations in the dts file? In the TF-A tree plat/arm/board/fvp/fdts/fvp_spmc_optee_sp_manifest.dts is a sample device tree consumed by Hafnium/SPMC to describe the system properties and declare secure partitions. Please refer to https://trustedfirmware-a.readthedocs.io/en/latest/components/secure-partit… The load_address field specifies the location at which the SPMC finds a 'partition package'. It consists of a partition's DT blob and a partition image. https://trustedfirmware-a.readthedocs.io/en/latest/components/secure-partit… In this sample 0x0 is the high 32b part of the physical address and 0xFF200000 the lower 32 bits. > 2) If only one core is available during the startup of hafnium, how to configure it? > In this case, when I set CPUS_PER_CLUSTER 1 in fvp-defs.dtsi file of ATF reference code, the building error is: Duplicate node name /cpus/cpu@20000. Why? I don't believe you should do change directly in this file, but rather provide the system topology through the TF-A command line by using FVP_MAX_CPUS_PER_CLUSTER/FVP_CLUSTER_COUNT/FVP_MAX_PE_PER_CPU The device tree should describe cpus as they exist when the system is booted at run-time. When TF-A and Hafnium boot, only a single primary core runs anyways so is this really what you intend to do? Regards, Olivier. ________________________________ From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> Sent: 24 November 2022 11:33 To: hafnium-owner <hafnium-owner(a)lists.trustedfirmware.org> Subject: run hafnium as spmc at s-el2 Hello expert, I'm a developer at Alibaba Cloud, and I'm having some problems using hafnium. In my environment, hafnium is running as spmc in s-el2, and my question is as follows: 1) In the spmc_optee_sp_manifest.dts file, there is an attribute load_address = <0x0 0xFF200000>. What do the two parts of load_address mean respectively? Any details on other configurations in the dts file? 2) If only one core is available during the startup of hafnium, how to configure it? In this case, when I set CPUS_PER_CLUSTER 1 in fvp-defs.dtsi file of ATF reference code, the building error is: Duplicate node name /cpus/cpu@20000. Why? Looking forward to your reply. Thank you very much~

2 years, 5 months

1
0
0 0

Re: run hafnium as spmc at s-el2

by Olivier Deprez

Hi Mei Jianqiang, > In my environment, hafnium is running as spmc in s-el2, and my question is as follows: Can you tell a bit more on your setup, if possible, do you intend to use OP-TEE as SEL1 payload / secure partition? Are you running linux in the normal world? > 1) In the spmc_optee_sp_manifest.dts file, there is an attribute load_address = <0x0 0xFF200000>. > What do the two parts of load_address mean respectively? Any details on other configurations in the dts file? In the TF-A tree plat/arm/board/fvp/fdts/fvp_spmc_optee_sp_manifest.dts is a sample device tree consumed by Hafnium/SPMC to describe the system properties and declare secure partitions. Please refer to https://trustedfirmware-a.readthedocs.io/en/latest/components/secure-partit… The load_address field specifies the location at which the SPMC finds a 'partition package'. It consists of a partition's DT blob and a partition image. https://trustedfirmware-a.readthedocs.io/en/latest/components/secure-partit… In this sample 0x0 is the high 32b part of the physical address and 0xFF200000 the lower 32 bits. > 2) If only one core is available during the startup of hafnium, how to configure it? > In this case, when I set CPUS_PER_CLUSTER 1 in fvp-defs.dtsi file of ATF reference code, the building error is: Duplicate node name /cpus/cpu@20000. Why? I don't believe you should do change directly in this file, but rather provide the system topology through the TF-A command line by using FVP_MAX_CPUS_PER_CLUSTER/FVP_CLUSTER_COUNT/FVP_MAX_PE_PER_CPU The device tree should describe cpus as they exist when the system is booted at run-time. When TF-A and Hafnium boot, only a single primary core runs anyways so is this really what you intend to do? Regards, Olivier. ________________________________ From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> Sent: 24 November 2022 11:33 To: hafnium-owner <hafnium-owner(a)lists.trustedfirmware.org> Subject: run hafnium as spmc at s-el2 Hello expert, I'm a developer at Alibaba Cloud, and I'm having some problems using hafnium. In my environment, hafnium is running as spmc in s-el2, and my question is as follows: 1) In the spmc_optee_sp_manifest.dts file, there is an attribute load_address = <0x0 0xFF200000>. What do the two parts of load_address mean respectively? Any details on other configurations in the dts file? 2) If only one core is available during the startup of hafnium, how to configure it? In this case, when I set CPUS_PER_CLUSTER 1 in fvp-defs.dtsi file of ATF reference code, the building error is: Duplicate node name /cpus/cpu@20000. Why? Looking forward to your reply. Thank you very much~

2 years, 5 months

1
0
0 0

Trapped access to system register and excpetion

by shiju.jose＠huawei.com

Hello, We get the following error in the non-secure terminal in the QEMU, while booting the normal world with hafnium(SPMC) at S-EL2 and SP at S-EL1. NOTICE: Trapped access to system register write: op0=1, op1=0, crn=7, crm=14, op2=2, rt=11. NOTICE: Injecting Unknown Reason exception into VM 0x8001. Above system register found as DC CISW. It found that this happened with the recent hafnium change "feat(interrupts): preferred managed exit signal" Thanks.

2 years, 6 months

2
8
0 0

removal of hypervisor S1 defrag

by Olivier Deprez

Hi Raghu, We have one failure in the TF-A CI which might be related to removal of the Hypervisor S1 defrag invocations. https://git.trustedfirmware.org/hafnium/hafnium.git/commit/?id=eb35759c2e4e… https://ci.trustedfirmware.org/job/tf-a-ci-gateway/17260/ https://ci-builds.trustedfirmware.org/static-files/HfYGa2MCjUELwyJs27G6Dgby… Would you please have a look? Thanks, Olivier.

2 years, 7 months

3
5
0 0

How to test Armv8.4 without Hafnium

by Chenxu Wang

Hi all, Sorry for asking this question, but I just want to do some tests about Armv8.4. In my scenario, I wanna boot with ATF, with Armv8.4-enabled FVP, but without Hafnium. I may need to boot a secure OS. I know how to boot it with Hafnium, but how about without Hafnium? Also, I still want some Armv8.4 features to manage my secure OS. I think I may need (1) shell commands to compile the TF-A, and (2) shell commands to boot the FVP. Could you help me? Sincerely, WANG Chenxu

2 years, 7 months

1
1
0 0

Question about HCR_EL2 reg.

by Chenxu Wang

Hi all, I want to find a register which will specifically control the Secure Stage 2 translation. But Arm document does not provide it. I find that a register, called HCR_EL2, will control the Stage 2 translation. But the document didn't mention which secure type it will control. Thus, does the Non-secure hypervisor (like KVM) influence the Secure Stage-2 address translation? For example, disabling it through HCR_EL2? Sincerely, WANG Chenxu

2 years, 11 months

3
2
0 0

How to test OPTEE+Hafnium with the new Linux kernel?

by Chenxu Wang

Hi all, I am not sure whether it is OK to ask the question here, but I still wish you can help me address the problem. I used to test Hafnium with FVP, and the Linux kernel is provided by arm-reference-platform. Recently I want to test something on an OPTEE kernel (rather than a cactus OS). But, since the provided linux kernel is a bit old (v5.3), its /drivers/tee/optee will not send FF-A calls. I find that Linux introduces FF-A ABI to OP-TEE driver since v5.16, which is a relatively new kernel. Previously I download the Linux kernel here ( https://git.linaro.org/landing-teams/working/arm/kernel-release.git), but they only provide old kernels. I also try to replace the "linux" directory with the upstream Linux v5.17 source code, and use the guide here (https://community.arm.com/oss-platforms/w/docs/459/modify-linux-kernel-conf…) to compile. But the source seems to be inconsistent with the arm-reference-platforms. Can someone help me? Sincerely, WANG Chenxu

2 years, 11 months

2
1
0 0

How to boot OPTEE(s) on Hafnium?

by Chenxu Wang

Hi all, I want to boot one or more OPTEE on SEL1, with using Hafnium (v2.4) on SEL2 and TF-A (v2.4) on EL3, and Arm FVP. Before I can boot multiple Cactus SP, but I can find little infos about booting OP-TEE. Can you provide some useful guide? Sincerely, WANG Chenxu

2 years, 12 months

3
4
0 0

Hafnium CI runs Hpervisor+SPMC FVP tests

by Olivier Deprez

Hi, Note we now have two jenkins jobs started on patch submission: The regular Hafnium builder running unit tests, hypervisor test suite on qemu, static checks and checkpatch. A new job running the test_spmc.sh script on FVP, corresponding to the Hypervisor+SPMC configuration with a single and multiple partitions. This has been a long road, thanks to everyone involved from multiple teams. Both test results are reported to the gerrit code review. It remains to fix the Verified+1 vote, based on the two above results. Hope to improve it soonish. Regards, Olivier.

3 years

2
2
0 0

How FF-A calls reach Hafnium?

by Rahul Kumar Yadav

Hi, Can someone please help me in understanding how TF-A (EL3) forwards FF-A calls to Hafnium (SEL2)? And what Hafnium code I should look into for seeing how Hafnium handles these calls? Regards, Rahul

3 years

2
1
0 0

Request for review: parse all GICR frames on a platform

by Varun Wadekar

Hi, Can I get please get some reviews on the GIC patch series [1]? It is a real problem on NVIDIA Tegra platforms and the series solves the issue. Thanks. [1] topic:"gicv3-gicr-frames" (status:open OR status:merged) * Gerrit Code Review (trustedfirmware.org)<https://review.trustedfirmware.org/q/topic:%22gicv3-gicr-frames%22+(status:…>

3 years

3
5
0 0

TrustedFirmware Code of Conduct

by Don Harbin

Hi All, Please find the link to the TrustedFirmware Community Code of Conduct here: https://developer.trustedfirmware.org/w/collaboration/community_guidelines/… Trusted Firmware has a very diverse and global developer community. It is important that we adhere to the code of conduct in all our interactions. For some of you all this may be new and for others just a gentle reminder. In either case, if you have any questions, please feel free to reach out to me directly. And thanks to you all for your contributions to the TrustedFirmware community! Best regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

3 years, 1 month

1
0
0 0

test spmc script broken on master

by Olivier Deprez

Hi, Notice the test_spmc.sh script looks broken on master (notifications vm to sp test fails). We'll investigate and hopefully provide a fix shortly. Regards, Olivier.

3 years, 1 month

1
1
0 0

Re: Trusted Compute platform BSP build

by Rahul Kumar Yadav

Hi, After the making the following change, SRC_URI_DLMALLOC = "https://raw.githubusercontent.com/ARMmbed/dlmalloc/75149a9d7c50442db0f89085…" In File, <repo_path>/bsp/layers/meta-tc/recipes-security/trusted-services/secure-partitions_git.bb I am now getting same error with this new URL, ERROR: secure-partitions-1.0+gitAUTOINC+2fc7e10c7c-r0 do_fetch: Fetcher failure for URL: 'https://raw.githubusercontent.com/ARMmbed/dlmalloc/75149a9d7c50442db0f89085…'. Unable to fetch URL from any source. I tried pasting the above URL link in browser and got "404 Not Found" there. Regards, Rahul

3 years, 2 months

1
0
0 0

Trusted Compute platform BSP build

by Rahul Kumar Yadav

Hi, I am trying to build BSP part of Total Compute platform from the following link: https://gitlab.arm.com/arm-reference-solutions/arm-reference-solutions-docs… But I am facing some issues in Board Support Package Build section, after running following command: bitbake tc0-artifacts-image I am getting the following Error during one of the executing tasks of above command: ERROR: secure-partitions-1.0+gitAUTOINC+2fc7e10c7c-r0 do_fetch: Fetcher failure for URL: 'http://gee.cs.oswego.edu/pub/misc/malloc.c;name=dlmalloc'. Unable to fetch URL from any source. Can I please get some help with this error? Regards, Rahul

3 years, 2 months

2
1
0 0

Re: S-EL1

by Friedrich Doku

Looking at the trusted firmware documentation it says that “Only Arm’s FVP platform is supported to use with the TF-A reference software stack.” Have you gotten this to work on a physical device, or do I need to add support for my own board? Thanks, Friedrich

3 years, 2 months

3
3
0 0

Re: [EXT] Re: Hafnium Getting Started

by Olivier Deprez

Hi Rahul, Notice Hafnium as an hypervisor (in the normal world) is no longer a 'supported' configuration. It's still mainly maintained as legacy and for test purposes. The project focuses on the SPM (aka Hafnium in the secure world). Adding an hypervisor is a bit beyond the scope of the project. The best reference for you is perhaps to reproduce the Total Compute platform: https://gitlab.arm.com/arm-reference-solutions/arm-reference-solutions-docs… If you build the BSP part (no Android), you get this setup: linux (NS EL1/0), no hypervisor, TF-A at EL3, Hafnium at SEL2, OP-TEE at SEL1. You can run the optee xtest suite from linux console which reaches OP-TEE as a secure partition through Hafnium. Regards, Olivier. ________________________________________ From: Rahul Kumar Yadav <rahulkumar.yadav(a)nxp.com> Sent: 23 February 2022 10:45 To: Olivier Deprez Subject: RE: [Hafnium] Re: [EXT] Re: Hafnium Getting Started Hi Olivier, I wanted to try Hafnium with FVP but could not find the clear instructions like the ones available for Hafnium with QEMU. In Hafnium Documentation, I was able to run tests with FVP with following command: $ make && kokoro/test.sh --fvp But I could not find instructions to run Hafnium and primary VM with Linux on FVP separately from Testing purposes, like in case of QEMU. If Hafnium with QEMU is not going to work in secure world, from where can I find instructions for running Hafnium with VMs (Linux, OPTEE) on FVP in normal and secure world? Regards, Rahul -----Original Message----- From: Olivier Deprez via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: Wednesday, February 23, 2022 2:38 PM To: hafnium(a)lists.trustedfirmware.org Subject: [Hafnium] Re: [EXT] Re: Hafnium Getting Started Caution: EXT Email Hi Rahul, TF-A + SEL2/Hafnium isn't supported on qemu. All our testing is done on Arm's FVP, or Total Compute platform. Regards, Olivier. ________________________________________ From: Rahul Kumar Yadav <rahulkumar.yadav(a)nxp.com> Sent: 23 February 2022 10:00 To: Olivier Deprez Subject: RE: [EXT] [Hafnium] Re: Hafnium Getting Started Hi Olivier, Thanks for helping. Also, I want to run Hafnium with QEMU in secure world. From where can I get the instructions for that purpose? Regards, Rahul -----Original Message----- From: Olivier Deprez via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: Wednesday, February 23, 2022 2:22 PM To: hafnium(a)lists.trustedfirmware.org Subject: [EXT] [Hafnium] Re: Hafnium Getting Started Caution: EXT Email Hi, In your experiment, everything runs in the normal world. Hafnium at NS EL2. The primary VM hosting linux at NS EL1. Regards, Olivier. ________________________________________ From: Rahul Kumar Yadav via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: 23 February 2022 09:16 To: hafnium(a)lists.trustedfirmware.org Subject: [Hafnium] Hafnium Getting Started Hi, I have just started to learn about Hafnium and I am following Getting Started steps of it. I built DTB with /dts-v1/; / { hypervisor { compatible = "hafnium,hafnium"; vm1 { debug_name = "Linux VM"; kernel_filename = "vmlinuz"; ramdisk_filename = "initrd.img"; }; }; }; And after setting up RAM disk, I was able to boot into Linux VM with following command: qemu-system-aarch64 -M virt,gic_version=3 -cpu cortex-a57 -nographic -machine virtualization=true -kernel out/reference/qemu_aarch64_clang/hafnium.bin -initrd initrd.img -append "rdinit=/sbin/init" But I am unable to understand whether Hafnium and Linux are running in Normal World or Secure World or At which Level (EL1, EL2, S-EL1 or S-EL2...) Hafnium and Linux are running. Can I please get some help in understanding this? Regards, Rahul -- Hafnium mailing list -- hafnium(a)lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave(a)lists.trustedfirmware.org -- Hafnium mailing list -- hafnium(a)lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave(a)lists.trustedfirmware.org -- Hafnium mailing list -- hafnium(a)lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave(a)lists.trustedfirmware.org

3 years, 2 months

1
0
0 0

Re: [EXT] Re: Hafnium Getting Started

by Olivier Deprez

Hi Rahul, TF-A + SEL2/Hafnium isn't supported on qemu. All our testing is done on Arm's FVP, or Total Compute platform. Regards, Olivier. ________________________________________ From: Rahul Kumar Yadav <rahulkumar.yadav(a)nxp.com> Sent: 23 February 2022 10:00 To: Olivier Deprez Subject: RE: [EXT] [Hafnium] Re: Hafnium Getting Started Hi Olivier, Thanks for helping. Also, I want to run Hafnium with QEMU in secure world. From where can I get the instructions for that purpose? Regards, Rahul -----Original Message----- From: Olivier Deprez via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: Wednesday, February 23, 2022 2:22 PM To: hafnium(a)lists.trustedfirmware.org Subject: [EXT] [Hafnium] Re: Hafnium Getting Started Caution: EXT Email Hi, In your experiment, everything runs in the normal world. Hafnium at NS EL2. The primary VM hosting linux at NS EL1. Regards, Olivier. ________________________________________ From: Rahul Kumar Yadav via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: 23 February 2022 09:16 To: hafnium(a)lists.trustedfirmware.org Subject: [Hafnium] Hafnium Getting Started Hi, I have just started to learn about Hafnium and I am following Getting Started steps of it. I built DTB with /dts-v1/; / { hypervisor { compatible = "hafnium,hafnium"; vm1 { debug_name = "Linux VM"; kernel_filename = "vmlinuz"; ramdisk_filename = "initrd.img"; }; }; }; And after setting up RAM disk, I was able to boot into Linux VM with following command: qemu-system-aarch64 -M virt,gic_version=3 -cpu cortex-a57 -nographic -machine virtualization=true -kernel out/reference/qemu_aarch64_clang/hafnium.bin -initrd initrd.img -append "rdinit=/sbin/init" But I am unable to understand whether Hafnium and Linux are running in Normal World or Secure World or At which Level (EL1, EL2, S-EL1 or S-EL2...) Hafnium and Linux are running. Can I please get some help in understanding this? Regards, Rahul -- Hafnium mailing list -- hafnium(a)lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave(a)lists.trustedfirmware.org -- Hafnium mailing list -- hafnium(a)lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave(a)lists.trustedfirmware.org

3 years, 2 months

1
0
0 0

Hafnium Getting Started

by Rahul Kumar Yadav

Hi, I have just started to learn about Hafnium and I am following Getting Started steps of it. I built DTB with /dts-v1/; / { hypervisor { compatible = "hafnium,hafnium"; vm1 { debug_name = "Linux VM"; kernel_filename = "vmlinuz"; ramdisk_filename = "initrd.img"; }; }; }; And after setting up RAM disk, I was able to boot into Linux VM with following command: qemu-system-aarch64 -M virt,gic_version=3 -cpu cortex-a57 -nographic -machine virtualization=true -kernel out/reference/qemu_aarch64_clang/hafnium.bin -initrd initrd.img -append "rdinit=/sbin/init" But I am unable to understand whether Hafnium and Linux are running in Normal World or Secure World or At which Level (EL1, EL2, S-EL1 or S-EL2...) Hafnium and Linux are running. Can I please get some help in understanding this? Regards, Rahul

3 years, 2 months

2
1
0 0

S-EL1

by Friedrich

How can I run my kernel in S-EL1 using hafnium? Best, Friedrich

3 years, 2 months

2
2
0 0

GICR discovery

by Varun Wadekar

Hello team, Currently the amount of memory allocated for GICR frames is determined by the number of supported CPUs. However, the GIC redistributor might have more frames than the number of PEs. In such a case, it is possible that the core index constructed from GICR_TYPER register points to a non-existent PE. For such a case, the GIC discovery and init sequence should move to the next redistributor frame. Today, the code asserts if there are holes in the CPU topology or if GICR_FRAMES > MAX_CPUS. Downstream Tegra platforms provide more GICR frames than number of CPUs and require the support posted to gerrit [1]. Request the team to review and post feedback. Thanks. [1] topic:"gicv3-gicr-frames" (status:open OR status:merged) * Gerrit Code Review (trustedfirmware.org)<https://review.trustedfirmware.org/q/topic:%22gicv3-gicr-frames%22+(status:…>

3 years, 2 months

2
4
0 0

Fw: How to stop linux from preventing access to serial?

by Joao Alves

+ Hafnium mailing list (Sorry didn't notice I had replied to you directly, and not included the mailing list. Others might have useful feedback to add.) Friedrich, Will try to come back to you on your last query ASAP. ________________________________ From: Friedrich <friedrichdoku(a)gmail.com> Sent: Sunday, February 13, 2022 6:16 PM To: Joao Alves <Joao.Alves(a)arm.com> Subject: Re: [Hafnium] How to stop linux from preventing access to serial? Hi João, I am still having trouble getting my kernel to run using a secure partition. For some reason, my kernel only runs when I give it access to all the devices, but if I do this Linux is unable to run. Linux gives me stage-2 page faults. Is there any way around thiss? Here is my dts file for my kernel. Is there something I can change here to make this work? f I thought there is emulation for basic hardware features like timers and interrupt controllers. How can I use them in my secure partition? /dts-v1/; / { compatible = "arm,ffa-manifest-1.0"; debug_name = "partition-manifest"; /* Properties */ ffa-version = <0x00010001>; /* 31:16 - Major, 15:0 - Minor */ uuid = <0xb4b5671e 0x4a904fe1 0xb81ffb13 0xdae1dacb>; execution-ctx-count = <4>; exception-level = <0>; /* S-EL1 */ execution-state = <0>; /* AARCH64 */ load-address = <0x43000000>; entrypoint-offset = <0x0000>; xlat-granule = <0>; /* 4KiB */ messaging-method = <0x3>; /* Direct messaging only */ device-regions { compatible = "arm,ffa-manifest-device-regions"; uart0 { base-address = <0x00000000 0x01c28000>; pages-count = <1>; attributes = <0x3>; /* read-write */ }; }; }; Best, Friedrich On Mon, Feb 7, 2022 at 4:56 AM Joao Alves <Joao.Alves(a)arm.com<mailto:Joao.Alves@arm.com>> wrote: Hi Friederich, It seems the problem you're facing has to do with Stage 2 translation faults. The UART needs to be mapped in the S2 translation of the respective partition that tries to use it. The given platform that you're using is likely to have more than one UART device assigned with different memory regions. Each device should be assigned to only one partition/kernel. Unmapping the UART from Linux shouldn't help on its own, as you're simply refraining Linux from using the UART. Depending on how you configured your Linux partition, it might still try to access it at a certain address and hit a page fault at Stage 2 translation. If you are using Hafnium with FF-A partitions, you can map different UART devices through the FF-A partition manifest, as shown in the following link: https://review.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/refs/h… The support for this (I think) might depend on the version that you're currently using. Hafnium owns a UART device, that makes (indirectly) accessible to the VMs through an HVC call. Hafnium receives the bytes to write to the UART TX buffers through the GP registers through the HVC call interface. If you're trying to log the behaviour of your partition, this might be enough, and probably the easiest option to start with. Find the HVC call function helper: https://review.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/refs/h… You can look for uses of the referred call. Hope this helps. Let me know if you have further questions. Best regards, João Alves ________________________________ From: Friedrich via Hafnium <hafnium(a)lists.trustedfirmware.org<mailto:hafnium@lists.trustedfirmware.org>> Sent: Thursday, February 3, 2022 5:59 PM To: hafnium(a)lists.trustedfirmware.org<mailto:hafnium@lists.trustedfirmware.org> <hafnium(a)lists.trustedfirmware.org<mailto:hafnium@lists.trustedfirmware.org>> Subject: [Hafnium] How to stop linux from preventing access to serial? Hi, I am working with the hafnium hypervisor. I am running Linux alongside another kernel, and I need access to the serial device UART on the other kernel. When I am trying to output serial from the other kernel, hafnium says there is a stage 2 page fault. I tried disabling the serial device in linux, but now I am getting a different result. When I load the hafnium driver, I get a page fault. For some reason, if the device is not in /proc/iomem it throws an error. How can I use my device in my kernel and disable it in Linux. Linux is the primary VM and my kernel is the secondary VM. Thanks, Friedrich -- Hafnium mailing list -- hafnium(a)lists.trustedfirmware.org<mailto:hafnium@lists.trustedfirmware.org> To unsubscribe send an email to hafnium-leave(a)lists.trustedfirmware.org<mailto:hafnium-leave@lists.trustedfirmware.org> 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.

3 years, 2 months

1
0
0 0

How to stop linux from preventing access to serial?

by Friedrich

Hi, I am working with the hafnium hypervisor. I am running Linux alongside another kernel, and I need access to the serial device UART on the other kernel. When I am trying to output serial from the other kernel, hafnium says there is a stage 2 page fault. I tried disabling the serial device in linux, but now I am getting a different result. When I load the hafnium driver, I get a page fault. For some reason, if the device is not in /proc/iomem it throws an error. How can I use my device in my kernel and disable it in Linux. Linux is the primary VM and my kernel is the secondary VM. Thanks, Friedrich

3 years, 3 months

1
0
0 0

Re: .git submodules increase hafnium code size

by Varun Wadekar

<Cc mailing list> Thanks Olivier. For NVIDIA, the main goal is to have the flexibility to use an out of tree toolchain and remove the hard dependency on the prebuilts folder. Internally, we have pruned the prebuilts to remove dtc, googletest too. With vacations, we have not verified the latest patches - will test and report in a week. -----Original Message----- From: Olivier Deprez <Olivier.Deprez(a)arm.com> Sent: Monday, 3 January 2022 2:08 PM To: Bo Yan <byan(a)nvidia.com>; raghu.ncstate(a)icloud.com Cc: Varun Wadekar <vwadekar(a)nvidia.com> Subject: Re: [Hafnium] .git submodules increase hafnium code size External email: Use caution opening links or attachments Hi Bo, Raghu, I knew this change would be a bit controversial :) We've had the following main queries: 1/ submodule(s) size is too large (see Varun's very first message in this thread). Starting with prebuilts, it turns out that llvm+gnu toolchains are top contributors. The mentioned change (on top of earlier clang migration changes) introduced the ability to remove a hard dependency to those toolchains. 2/ Ability to build on arm64 host. The change removes the compiler/linker/tools hard coded paths to the x86 prebuilt toolchain from the build system. 3/ toolchain is hardcoded to a fixed version and buried into the project along with sources. This fits developer habits but it is not suitable to a production environment. Addressing few of the concerns below: > The default built at the top of tree seems broken. Typing make does not work any more. I tried to export the clang path and I see issues with standard headers...docs/GettingStarted is incomplete? This is the glitch I expected to happen when pulling latest changes. Hence the reason for the earlier heads up on the ML. Hopefully this recovers after cleaning the tree once, or restarting from a freshly cloned tree. > I'm not sure I like the idea of removing the prebuilts. We need one tool chain that we know is supported and tested with to create reproducible builds. ATM the CI still points to the hafnium prebuilt toolchain. Hence builds are still 'reproducible'. It could be proposed that the CI environment itself provides the toolchain. > We can remove the dependency on the prebuilt in that it should be > possible for someone to NOT require downloading the upstream tool > chain if they want to use an alternate chain, I get the idea, but we have two orthogonal asks (use an external toolchain and remove from prebuilts, or keep in prebuilt but clone conditionally). The .gitmodules does not provide this flexibility AFAIK. I was thinking of using some partial clone command like below omitting prebuilts: git submodule update --init driver/linux project/reference third_party/dtc third_party/googletest third_party/linux (but this doesn't look great from an UX perspective). > for reference platforms like FVP, the toolchain should be a part of > the build Not sure this is a hard dependency. Comparing with TF-A (or other firmware projects), the toolchain is certainly not held within the tree. The developer or the CI environment provides the toolchain to build the project. > The current method was ideal but it seems like some latest changes have broken the dev flow... Ideal for a developer sticking to the provided fixed-version android-based prebuilt toolchain, and building on an x86 host. Not ideal if one needs to build on arm64, or in a production build when hafnium is considered one component among many others within a (yocto-like) distribution. > I agree on the point that keeping prebuilts brings benefits, but the build system should be flexible enough such that an out-of-tree toolchain can be easily selected. This is what this first set of changes provide. Regards, Olivier. ________________________________________ From: Bo Yan <byan(a)nvidia.com> Sent: 21 December 2021 00:45 To: raghu.ncstate(a)icloud.com; Varun Wadekar; Olivier Deprez Cc: 'Raghu Krishnamurthy via Hafnium' Subject: RE: [Hafnium] .git submodules increase hafnium code size I agree on the point that keeping prebuilts brings benefits, but the build system should be flexible enough such that an out-of-tree toolchain can be easily selected. > -----Original Message----- > From: raghu.ncstate(a)icloud.com <raghu.ncstate(a)icloud.com> > Sent: Saturday, December 18, 2021 1:22 PM > To: raghu.ncstate(a)icloud.com; Varun Wadekar <vwadekar(a)nvidia.com>; > 'Olivier Deprez' <Olivier.Deprez(a)arm.com> > Cc: Bo Yan <byan(a)nvidia.com>; 'Raghu Krishnamurthy via Hafnium' > <hafnium(a)lists.trustedfirmware.org> > Subject: RE: [Hafnium] .git submodules increase hafnium code size > > Never mind. Sorry for the false alarm. Had to use make clobber( found > out once I caught up on the email list...). > Other comments about continuing to have a prebuilts directory like we > have today still apply. > > -----Original Message----- > From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> On Behalf Of > Raghu Krishnamurthy via Hafnium > Sent: Saturday, December 18, 2021 1:08 PM > To: 'Varun Wadekar' <vwadekar(a)nvidia.com>; 'Olivier Deprez' > <Olivier.Deprez(a)arm.com> > Cc: 'Bo Yan' <byan(a)nvidia.com>; 'Raghu Krishnamurthy via Hafnium' > <hafnium(a)lists.trustedfirmware.org> > Subject: Re: [Hafnium] .git submodules increase hafnium code size > > Add hafnium list. > > Fix for broken build at - > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Frevi > e w.trustedfirmware.org%2Fc%2Fhafnium%2Fhafnium%2F%2B%2F13150&am > p;data=04%7C01%7Cbyan%40nvidia.com%7C030b52fc55094b6fa3b008d9c26 > c6bdf%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C63775459320 > 6358976%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV > 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=9C%2F0A6 > 1IlusyOnozlGCclZN13YPjaRm1TenBDpemK8M%3D&reserved=0 > > > -----Original Message----- > From: raghu.ncstate(a)icloud.com <raghu.ncstate(a)icloud.com> > Sent: Saturday, December 18, 2021 12:51 PM > To: 'Varun Wadekar' <vwadekar(a)nvidia.com>; 'Olivier Deprez' > <Olivier.Deprez(a)arm.com> > Cc: 'Bo Yan' <byan(a)nvidia.com> > Subject: RE: [Hafnium] .git submodules increase hafnium code size > > The default built at the top of tree seems broken. Typing make does > not work any more. I tried to export the clang path and I see issues > with standard headers...docs/GettingStarted is incomplete? > I'm not sure I like the idea of removing the prebuilts. We need one > tool chain that we know is supported and tested with to create reproducible builds. > We can remove the dependency on the prebuilt in that it should be > possible for someone to NOT require downloading the upstream tool > chain if they want to use an alternate chain, but for reference > platforms like FVP, the toolchain should be a part of the build. The > current method was ideal but it seems like some latest changes have broken the dev flow... > > -----Original Message----- > From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> On Behalf Of > Varun Wadekar via Hafnium > Sent: Friday, December 17, 2021 7:58 AM > To: Olivier Deprez <Olivier.Deprez(a)arm.com> > Cc: Bo Yan <byan(a)nvidia.com>; hafnium(a)lists.trustedfirmware.org > Subject: Re: [Hafnium] .git submodules increase hafnium code size > > Thanks Olivier. Makes sense to me. We are deploying these changes to > our build system. Will let you know. > > -----Original Message----- > From: Olivier Deprez <Olivier.Deprez(a)arm.com> > Sent: Friday, 17 December 2021 3:32 PM > To: Varun Wadekar <vwadekar(a)nvidia.com> > Cc: Bo Yan <byan(a)nvidia.com>; hafnium(a)lists.trustedfirmware.org > Subject: Re: .git submodules increase hafnium code size > > External email: Use caution opening links or attachments > > > Hi Varun, > > I don't believe the prebuilt submodule would be fully removed. There > are libraries and binaries required by the build in any case in the > linux-aarch64 directory. I rather thought the toolchains within it > might be removed. They are the main contributor in terms of disk space > savings which is the problem if I understood properly. > > As an intermediate step, before removing the toolchain, I would like > to confirm that you are able to switch to another toolchain and there > is no longer a dependency to the toolchain stored in prebuilt. > > Regards, > Olivier. > > ________________________________________ > From: Varun Wadekar <vwadekar(a)nvidia.com> > Sent: 17 December 2021 15:18 > To: Olivier Deprez > Cc: Bo Yan; hafnium(a)lists.trustedfirmware.org > Subject: RE: .git submodules increase hafnium code size > > Thanks Olivier. We hit the toolchain changes yesterday and still > navigating a course to enable it internally. > > When do you plan to remove the prebuilt submodule completely? > > -----Original Message----- > From: Olivier Deprez <Olivier.Deprez(a)arm.com> > Sent: Friday, 17 December 2021 12:00 PM > To: Varun Wadekar <vwadekar(a)nvidia.com> > Cc: Bo Yan <byan(a)nvidia.com>; hafnium(a)lists.trustedfirmware.org > Subject: Re: .git submodules increase hafnium code size > > External email: Use caution opening links or attachments > > > Hi Varun, > > Just a quick sync on what's been going since this last email. > > A number of changes have been made to: > -remove the gcc dependency, hafnium now only requires clang to build. > -ability to provide a toolchain different from the one stored in > prebuilt submodule (merged yesterday) -migrated and tested with recent > clang versions (was clang 9) -ability to build on arm64 host (our > need) > > The prebuilt submodule still exists but the dependency to hardcoded > toolchains has weakened. > > I intend to tell more about those recent changes and what remains > during a tech forum early next year, among: > -remove toolchains from prebuilt? > -split the hypervisor and spmc test configs into separate project/* > directories -lessen the dependency to other 3rd party projects > > Regards, > Olivier. > > ________________________________________ > From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of > Olivier Deprez via Hafnium <hafnium(a)lists.trustedfirmware.org> > Sent: 08 June 2021 16:00 > To: Varun Wadekar > Cc: Bo Yan; hafnium(a)lists.trustedfirmware.org > Subject: Re: [Hafnium] .git submodules increase hafnium code size > > Hi Varun, > > As indicated earlier, we (Arm side) don't expect to progress on this > front before Q3. > > I'm gathering requirements and expect to discuss through a short > presentation later in a tech forum or the ML. > > Regards, > Olivier. > > ________________________________________ > From: Varun Wadekar <vwadekar(a)nvidia.com> > Sent: 08 June 2021 15:21 > To: Arunachalam Ganapathy; Olivier Deprez > Cc: Bo Yan; hafnium(a)lists.trustedfirmware.org > Subject: RE: .git submodules increase hafnium code size > > Thanks Arun. We have taken the same approach. The changes I posted > earlier expect all dependencies to be out of tree and provide > mechanisms to pass the locations to the make system during compilation. > > This is a real problem for us, and we would like a solution that works > for the community too. @Olivier how should we move forward? > > -----Original Message----- > From: Arunachalam Ganapathy <Arunachalam.Ganapathy(a)arm.com> > Sent: Tuesday, June 8, 2021 2:08 PM > To: Varun Wadekar <vwadekar(a)nvidia.com>; Olivier Deprez > <Olivier.Deprez(a)arm.com> > Cc: Bo Yan <byan(a)nvidia.com>; hafnium(a)lists.trustedfirmware.org > Subject: Re: .git submodules increase hafnium code size > > External email: Use caution opening links or attachments > > > Hi Varun, > > >> 1- First in context of Total Compute delivery from Arm OSS platforms: > >> a. ability to build only the SPMC on TC0 platform (not all > >> reference > targets such as qemu, rpi4, fvp) > >> b. use a Yocto provided toolchain. > >> @Arun, your view on how those two items were solved is > >> beneficial to > further elaborate our plans. > > For Total Compute we wanted to skip cloning submodules (like > driver/linux, linux, > dtc) as only secure_hafnium.bin was required. Basically build only > reference spm. > Like: make PROJECT=reference_spm PLAT=TC this builds only secure > hafnium for one platform. > > There were some efforts put on 1.a and was able to build reference_spm > for one platform. But Hafnium build inside yocto forced to clone all > submodules (due to dependencies on prebuilt toolchains), so the > changes were dropped and also the changes weren't clean enough to be upstreamed. > Regarding 1.b we didn't try hafnium build using yocto toolchain. > > Thanks, > Arun > > -----Original Message----- > From: Varun Wadekar <vwadekar(a)nvidia.com> > Sent: Monday, June 7, 2021 14:43 > To: Varun Wadekar <vwadekar(a)nvidia.com>; Olivier Deprez > <Olivier.Deprez(a)arm.com>; Arunachalam Ganapathy > <Arunachalam.Ganapathy(a)arm.com> > Cc: Bo Yan <byan(a)nvidia.com>; hafnium(a)lists.trustedfirmware.org > <hafnium(a)lists.trustedfirmware.org> > Subject: RE: .git submodules increase hafnium code size > > Hi, > > >> @Arun, your view on how those two items were solved is beneficial > >> to > further elaborate our plans. > > @Arunachalam Ganapathy your comments on this topic would be very > helpful. > > Thanks. > > -----Original Message----- > From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> On Behalf Of > Varun Wadekar via Hafnium > Sent: Monday, May 31, 2021 1:49 PM > To: Olivier Deprez <Olivier.Deprez(a)arm.com>; > hafnium(a)lists.trustedfirmware.org; Arunachalam Ganapathy > <Arunachalam.Ganapathy(a)arm.com> > Cc: Bo Yan <byan(a)nvidia.com> > Subject: Re: [Hafnium] .git submodules increase hafnium code size > > External email: Use caution opening links or attachments > > > Hi Olivier, > > Thanks for answering my queries. > > We are looking to deploy the following use case at NVIDIA. > > <snip> > > -ability to build only the SPMC (not all reference targets such as > qemu, rpi4, > fvp) -A distribution only requiring the Hypervisor/SPMC output binary > ("out/reference/.../hafnium.bin") using any toolchain (be it arm64 or > x86 host, and arbitrary clang version). > > <snip> > > >> As you noticed, the Hafnium Hypervisor/SPMC and test environment > builds are closely coupled by the use of ninja/gn flow and scripts. We > intend to approach those problems in the course of Q3 in Arm OSS roadmap. > > [VW] Are there any local changes to decouple hafnium from its dependencies? > We can evaluate Arm;s approach against what we use internally. Our > changes moved the dependencies out of the tree and passed file > locations to the build system with the help of command line arguments. > > -Varun > > -----Original Message----- > From: Olivier Deprez <Olivier.Deprez(a)arm.com> > Sent: Monday, May 31, 2021 11:03 AM > To: hafnium(a)lists.trustedfirmware.org; Varun Wadekar > <vwadekar(a)nvidia.com>; Arunachalam Ganapathy > <Arunachalam.Ganapathy(a)arm.com> > Cc: Bo Yan <byan(a)nvidia.com> > Subject: Re: .git submodules increase hafnium code size > > External email: Use caution opening links or attachments > > > Hi Varun, > > We had similar requests raised internally. > 1- First in context of Total Compute delivery from Arm OSS platforms: > a. ability to build only the SPMC on TC0 platform (not all > reference targets such as qemu, rpi4, fvp) > b. use a Yocto provided toolchain. > @Arun, your view on how those two items were solved is beneficial > to further elaborate our plans. > 2- A similar request as 1.b to build Hafnium as part of a distribution > on > arm64 host: > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeve > loper.trustedfirmware.org%2FT898&data=04%7C01%7Cbyan%40nvidia. > com%7C030b52fc55094b6fa3b008d9c26c6bdf%7C43083d15727340c1b7db39 > efd9ccc17a%7C0%7C0%7C637754593206358976%7CUnknown%7CTWFpbGZs > b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn > 0%3D%7C3000&sdata=AtMec%2BNFfhA14xeMZT992icEj6SLAhwLnB2co5 > VXFNM%3D&reserved=0 > > In my view there are two consumers: > -A distribution only requiring the Hypervisor/SPMC output binary > ("out/reference/.../hafnium.bin") using any toolchain (be it arm64 or > x86 host, and arbitrary clang version). > -The Hf CI framework/automation needs the above, plus the test > framework and tests (dependency on googletest, linux submodules etc). > It's important to keep this item alive while trying to solve above item. > > As you noticed, the Hafnium Hypervisor/SPMC and test environment > builds are closely coupled by the use of ninja/gn flow and scripts. > They are using a fixed toolchain version through prebuilts to ensure > builds are "reproducible", in particular with regards to the Hafnium CI. > > We intend to approach those problems in the course of Q3 in Arm OSS > roadmap. > As an early exploration we already have: > -clang 12 compiler upgrade. This is necessary if wiling to use any > arbitrary clang version: > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Frevi > e > w.trustedfirmware.org%2Fq%2Ftopic%3A%2522od%25252Fhf- > clang12%2522&data=04%7C01%7Cbyan%40nvidia.com%7C030b52fc550 > 94b6fa3b008d9c26c6bdf%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C > 0%7C637754593206358976%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp > ;sdata=t7KJjvv2o8EHKBpPdUEIrJ%2F7Vy7KFEODdnQMrL4LpaU%3D&res > erved=0+(status:open%20OR%20status:merged) > -Ability to build on arm64 host (done, internally). > -Identify the flow/script changes such that external dependencies can > be used (on-going, internally). > I thought of localizing common dependencies to python/shell scripts by > the use of definition files included in the mentioned scripts. This is > only an early investigation, I will check how this intersects the changes you provided. > > Regards, > Olivier. > > > > From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of > Varun Wadekar via Hafnium <hafnium(a)lists.trustedfirmware.org> > Sent: 28 May 2021 16:47 > To: hafnium(a)lists.trustedfirmware.org > <hafnium(a)lists.trustedfirmware.org> > Cc: Bo Yan <byan(a)nvidia.com> > Subject: [Hafnium] .git submodules increase hafnium code size > > Hi, > > We at NVIDIA are evaluating Hafnium. During the initial investigation, > we found out that the repository size (in terms of MB) is huge. This > is mostly because of the "git submodules" used by the project. This is > a great way to deliver Hafnium with its dependencies in one go. > > But we think that the size can be trimmed by moving the toolchain, > linux folder, googletest and dtc compiler out, leaving just the > Hafnium code in the project. This way, companies like us can pick and > choose instead of having to use everything. In a bid to ease the pain > internally and only use the Hafnium code base we have crafted the following changes: > > > 1. hafnium: support external projects (I10a07de3) * Gerrit Code > Review > (trustedfirmware.org)<https://nam11.safelinks.protection.outlook.com/? > url =https%3A%2F%2Freview.trustedfirmware.org%2Fc%2Fhafnium%2Fhafnium > %2F%2B%2F10142&data=04%7C01%7Cbyan%40nvidia.com%7C030b52f > c55094b6fa3b008d9c26c6bdf%7C43083d15727340c1b7db39efd9ccc17a%7C0 > %7C0%7C637754593206358976%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC > 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000& > amp;sdata=7PWBcTXxP6HtqN%2BTGz3cEnnfabSzlyjo0RNZOjvOL4A%3D&amp > ;reserved=0> > 2. hafnium: build with dtc and googletest out of tree (I057c9ad6) * > Gerrit Code Review > (trustedfirmware.org)<https://nam11.safelinks.protection.outlook.com/? > url =https%3A%2F%2Freview.trustedfirmware.org%2Fc%2Fhafnium%2Fhafnium > %2F%2B%2F10144&data=04%7C01%7Cbyan%40nvidia.com%7C030b52f > c55094b6fa3b008d9c26c6bdf%7C43083d15727340c1b7db39efd9ccc17a%7C0 > %7C0%7C637754593206358976%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC > 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000& > amp;sdata=Ql8XW8FAEQ%2FereVjB3glccWJLR7sQ3yg0v9%2FSptCnyk%3D&a > mp;reserved=0> > 3. build: support external toolchain (Iafd029c1) * Gerrit Code > Review > (trustedfirmware.org)<https://nam11.safelinks.protection.outlook.com/? > url =https%3A%2F%2Freview.trustedfirmware.org%2Fc%2Fhafnium%2Fhafnium > %2F%2B%2F10145&data=04%7C01%7Cbyan%40nvidia.com%7C030b52f > c55094b6fa3b008d9c26c6bdf%7C43083d15727340c1b7db39efd9ccc17a%7C0 > %7C0%7C637754593206358976%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC > 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000& > amp;sdata=X%2FNE1WmrcQvqRzEBq8UXdA02y9rl%2BS%2Fs1btuRAAlacM%3 > D&reserved=0> > > This series does not have the patch to use an out of tree linux > codebase. I assume these patches wont be acceptable in their current > state, so would like to know how the community plans to handle this situation. > > The code size is a real concern for us, as we already have copies of > the dependencies in our codebase, so have no use for these duplicates. > > Thanks. > -- > Hafnium mailing list > Hafnium(a)lists.trustedfirmware.org > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.t%2F&data=04%7C01%7Cvwadekar%40nvidia.com%7Cb9b5a4a5f7034f3e68ac > 08d9cec2749e%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637768156850 > 567117%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ > BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Szglo5hCctZ6EMQIgkKd0Ya0F > aygD4b77ubvxnnOFyg%3D&reserved=0 > rustedfirmware.org%2Fmailman%2Flistinfo%2Fhafnium&data=04%7C0 > 1%7Cbyan%40nvidia.com%7C030b52fc55094b6fa3b008d9c26c6bdf%7C4308 > 3d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637754593206358976%7CUn > known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I > k1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=tBM%2FCZq%2FjMDpp60Y > ZN5sounTBfkkRjylu%2Fes3IpZBaE%3D&reserved=0 > -- > Hafnium mailing list > Hafnium(a)lists.trustedfirmware.org > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.t%2F&data=04%7C01%7Cvwadekar%40nvidia.com%7Cb9b5a4a5f7034f3e68ac > 08d9cec2749e%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637768156850 > 567117%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ > BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Szglo5hCctZ6EMQIgkKd0Ya0F > aygD4b77ubvxnnOFyg%3D&reserved=0 > rustedfirmware.org%2Fmailman%2Flistinfo%2Fhafnium&data=04%7C0 > 1%7Cbyan%40nvidia.com%7C030b52fc55094b6fa3b008d9c26c6bdf%7C4308 > 3d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637754593206358976%7CUn > known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I > k1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=tBM%2FCZq%2FjMDpp60Y > ZN5sounTBfkkRjylu%2Fes3IpZBaE%3D&reserved=0 > -- > Hafnium mailing list > Hafnium(a)lists.trustedfirmware.org > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.t%2F&data=04%7C01%7Cvwadekar%40nvidia.com%7Cb9b5a4a5f7034f3e68ac > 08d9cec2749e%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637768156850 > 567117%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ > BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Szglo5hCctZ6EMQIgkKd0Ya0F > aygD4b77ubvxnnOFyg%3D&reserved=0 > rustedfirmware.org%2Fmailman%2Flistinfo%2Fhafnium&data=04%7C0 > 1%7Cbyan%40nvidia.com%7C030b52fc55094b6fa3b008d9c26c6bdf%7C4308 > 3d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637754593206358976%7CUn > known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I > k1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=tBM%2FCZq%2FjMDpp60Y > ZN5sounTBfkkRjylu%2Fes3IpZBaE%3D&reserved=0 > -- > Hafnium mailing list > Hafnium(a)lists.trustedfirmware.org > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.t%2F&data=04%7C01%7Cvwadekar%40nvidia.com%7Cb9b5a4a5f7034f3e68ac > 08d9cec2749e%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637768156850 > 567117%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ > BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Szglo5hCctZ6EMQIgkKd0Ya0F > aygD4b77ubvxnnOFyg%3D&reserved=0 > rustedfirmware.org%2Fmailman%2Flistinfo%2Fhafnium&data=04%7C0 > 1%7Cbyan%40nvidia.com%7C030b52fc55094b6fa3b008d9c26c6bdf%7C4308 > 3d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637754593206358976%7CUn > known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I > k1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=tBM%2FCZq%2FjMDpp60Y > ZN5sounTBfkkRjylu%2Fes3IpZBaE%3D&reserved=0 > > -- > Hafnium mailing list > Hafnium(a)lists.trustedfirmware.org > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.t%2F&data=04%7C01%7Cvwadekar%40nvidia.com%7Cb9b5a4a5f7034f3e68ac > 08d9cec2749e%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637768156850 > 567117%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ > BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Szglo5hCctZ6EMQIgkKd0Ya0F > aygD4b77ubvxnnOFyg%3D&reserved=0 > rustedfirmware.org%2Fmailman%2Flistinfo%2Fhafnium&data=04%7C0 > 1%7Cbyan%40nvidia.com%7C030b52fc55094b6fa3b008d9c26c6bdf%7C4308 > 3d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637754593206358976%7CUn > known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I > k1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=tBM%2FCZq%2FjMDpp60Y > ZN5sounTBfkkRjylu%2Fes3IpZBaE%3D&reserved=0 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.

3 years, 3 months

1
1
0 0

ffa_msg_send from Linux Primary to Secondary Fails

by Friedrich

Hi, Can someone help me figure this out? I am trying to send a message from my Linux primary VM to a secondary VM, but for some reason ffa_msg_send keeps on failing and I keep getting an EAGAIN error: resource temporarily unavailable. Any suggestions? Best, Friedrich

3 years, 4 months

2
2
0 0

Re: .git submodules increase hafnium code size

by Olivier Deprez

+ ML ________________________________________ From: Olivier Deprez <Olivier.Deprez(a)arm.com> Sent: 03 January 2022 15:07 To: Bo Yan; raghu.ncstate(a)icloud.com Cc: Varun Wadekar Subject: Re: [Hafnium] .git submodules increase hafnium code size Hi Bo, Raghu, I knew this change would be a bit controversial :) We've had the following main queries: 1/ submodule(s) size is too large (see Varun's very first message in this thread). Starting with prebuilts, it turns out that llvm+gnu toolchains are top contributors. The mentioned change (on top of earlier clang migration changes) introduced the ability to remove a hard dependency to those toolchains. 2/ Ability to build on arm64 host. The change removes the compiler/linker/tools hard coded paths to the x86 prebuilt toolchain from the build system. 3/ toolchain is hardcoded to a fixed version and buried into the project along with sources. This fits developer habits but it is not suitable to a production environment. Addressing few of the concerns below: > The default built at the top of tree seems broken. Typing make does not work any more. I tried to export the clang path and I see issues with standard headers...docs/GettingStarted is incomplete? This is the glitch I expected to happen when pulling latest changes. Hence the reason for the earlier heads up on the ML. Hopefully this recovers after cleaning the tree once, or restarting from a freshly cloned tree. > I'm not sure I like the idea of removing the prebuilts. We need one tool chain that we know is supported and tested with to create reproducible builds. ATM the CI still points to the hafnium prebuilt toolchain. Hence builds are still 'reproducible'. It could be proposed that the CI environment itself provides the toolchain. > We can remove the dependency on the prebuilt in that it should be possible for someone to NOT require downloading the upstream tool chain if they want to use an alternate chain, I get the idea, but we have two orthogonal asks (use an external toolchain and remove from prebuilts, or keep in prebuilt but clone conditionally). The .gitmodules does not provide this flexibility AFAIK. I was thinking of using some partial clone command like below omitting prebuilts: git submodule update --init driver/linux project/reference third_party/dtc third_party/googletest third_party/linux (but this doesn't look great from an UX perspective). > for reference platforms like FVP, the toolchain should be a part of the build Not sure this is a hard dependency. Comparing with TF-A (or other firmware projects), the toolchain is certainly not held within the tree. The developer or the CI environment provides the toolchain to build the project. > The current method was ideal but it seems like some latest changes have broken the dev flow... Ideal for a developer sticking to the provided fixed-version android-based prebuilt toolchain, and building on an x86 host. Not ideal if one needs to build on arm64, or in a production build when hafnium is considered one component among many others within a (yocto-like) distribution. > I agree on the point that keeping prebuilts brings benefits, but the build system should be flexible enough such that an out-of-tree toolchain can be easily selected. This is what this first set of changes provide. Regards, Olivier. ________________________________________ From: Bo Yan <byan(a)nvidia.com> Sent: 21 December 2021 00:45 To: raghu.ncstate(a)icloud.com; Varun Wadekar; Olivier Deprez Cc: 'Raghu Krishnamurthy via Hafnium' Subject: RE: [Hafnium] .git submodules increase hafnium code size I agree on the point that keeping prebuilts brings benefits, but the build system should be flexible enough such that an out-of-tree toolchain can be easily selected. > -----Original Message----- > From: raghu.ncstate(a)icloud.com <raghu.ncstate(a)icloud.com> > Sent: Saturday, December 18, 2021 1:22 PM > To: raghu.ncstate(a)icloud.com; Varun Wadekar <vwadekar(a)nvidia.com>; > 'Olivier Deprez' <Olivier.Deprez(a)arm.com> > Cc: Bo Yan <byan(a)nvidia.com>; 'Raghu Krishnamurthy via Hafnium' > <hafnium(a)lists.trustedfirmware.org> > Subject: RE: [Hafnium] .git submodules increase hafnium code size > > Never mind. Sorry for the false alarm. Had to use make clobber( found out > once I caught up on the email list...). > Other comments about continuing to have a prebuilts directory like we have > today still apply. > > -----Original Message----- > From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> On Behalf Of > Raghu Krishnamurthy via Hafnium > Sent: Saturday, December 18, 2021 1:08 PM > To: 'Varun Wadekar' <vwadekar(a)nvidia.com>; 'Olivier Deprez' > <Olivier.Deprez(a)arm.com> > Cc: 'Bo Yan' <byan(a)nvidia.com>; 'Raghu Krishnamurthy via Hafnium' > <hafnium(a)lists.trustedfirmware.org> > Subject: Re: [Hafnium] .git submodules increase hafnium code size > > Add hafnium list. > > Fix for broken build at - > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Frevie > w.trustedfirmware.org%2Fc%2Fhafnium%2Fhafnium%2F%2B%2F13150&am > p;data=04%7C01%7Cbyan%40nvidia.com%7C030b52fc55094b6fa3b008d9c26 > c6bdf%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C63775459320 > 6358976%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV > 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=9C%2F0A6 > 1IlusyOnozlGCclZN13YPjaRm1TenBDpemK8M%3D&reserved=0 > > > -----Original Message----- > From: raghu.ncstate(a)icloud.com <raghu.ncstate(a)icloud.com> > Sent: Saturday, December 18, 2021 12:51 PM > To: 'Varun Wadekar' <vwadekar(a)nvidia.com>; 'Olivier Deprez' > <Olivier.Deprez(a)arm.com> > Cc: 'Bo Yan' <byan(a)nvidia.com> > Subject: RE: [Hafnium] .git submodules increase hafnium code size > > The default built at the top of tree seems broken. Typing make does not work > any more. I tried to export the clang path and I see issues with standard > headers...docs/GettingStarted is incomplete? > I'm not sure I like the idea of removing the prebuilts. We need one tool chain > that we know is supported and tested with to create reproducible builds. > We can remove the dependency on the prebuilt in that it should be possible > for someone to NOT require downloading the upstream tool chain if they > want to use an alternate chain, but for reference platforms like FVP, the > toolchain should be a part of the build. The current method was ideal but it > seems like some latest changes have broken the dev flow... > > -----Original Message----- > From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> On Behalf Of > Varun Wadekar via Hafnium > Sent: Friday, December 17, 2021 7:58 AM > To: Olivier Deprez <Olivier.Deprez(a)arm.com> > Cc: Bo Yan <byan(a)nvidia.com>; hafnium(a)lists.trustedfirmware.org > Subject: Re: [Hafnium] .git submodules increase hafnium code size > > Thanks Olivier. Makes sense to me. We are deploying these changes to our > build system. Will let you know. > > -----Original Message----- > From: Olivier Deprez <Olivier.Deprez(a)arm.com> > Sent: Friday, 17 December 2021 3:32 PM > To: Varun Wadekar <vwadekar(a)nvidia.com> > Cc: Bo Yan <byan(a)nvidia.com>; hafnium(a)lists.trustedfirmware.org > Subject: Re: .git submodules increase hafnium code size > > External email: Use caution opening links or attachments > > > Hi Varun, > > I don't believe the prebuilt submodule would be fully removed. There are > libraries and binaries required by the build in any case in the linux-aarch64 > directory. I rather thought the toolchains within it might be removed. They > are the main contributor in terms of disk space savings which is the problem > if I understood properly. > > As an intermediate step, before removing the toolchain, I would like to > confirm that you are able to switch to another toolchain and there is no > longer a dependency to the toolchain stored in prebuilt. > > Regards, > Olivier. > > ________________________________________ > From: Varun Wadekar <vwadekar(a)nvidia.com> > Sent: 17 December 2021 15:18 > To: Olivier Deprez > Cc: Bo Yan; hafnium(a)lists.trustedfirmware.org > Subject: RE: .git submodules increase hafnium code size > > Thanks Olivier. We hit the toolchain changes yesterday and still navigating a > course to enable it internally. > > When do you plan to remove the prebuilt submodule completely? > > -----Original Message----- > From: Olivier Deprez <Olivier.Deprez(a)arm.com> > Sent: Friday, 17 December 2021 12:00 PM > To: Varun Wadekar <vwadekar(a)nvidia.com> > Cc: Bo Yan <byan(a)nvidia.com>; hafnium(a)lists.trustedfirmware.org > Subject: Re: .git submodules increase hafnium code size > > External email: Use caution opening links or attachments > > > Hi Varun, > > Just a quick sync on what's been going since this last email. > > A number of changes have been made to: > -remove the gcc dependency, hafnium now only requires clang to build. > -ability to provide a toolchain different from the one stored in prebuilt > submodule (merged yesterday) -migrated and tested with recent clang > versions (was clang 9) -ability to build on arm64 host (our need) > > The prebuilt submodule still exists but the dependency to hardcoded > toolchains has weakened. > > I intend to tell more about those recent changes and what remains during a > tech forum early next year, among: > -remove toolchains from prebuilt? > -split the hypervisor and spmc test configs into separate project/* directories > -lessen the dependency to other 3rd party projects > > Regards, > Olivier. > > ________________________________________ > From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of > Olivier Deprez via Hafnium <hafnium(a)lists.trustedfirmware.org> > Sent: 08 June 2021 16:00 > To: Varun Wadekar > Cc: Bo Yan; hafnium(a)lists.trustedfirmware.org > Subject: Re: [Hafnium] .git submodules increase hafnium code size > > Hi Varun, > > As indicated earlier, we (Arm side) don't expect to progress on this front > before Q3. > > I'm gathering requirements and expect to discuss through a short > presentation later in a tech forum or the ML. > > Regards, > Olivier. > > ________________________________________ > From: Varun Wadekar <vwadekar(a)nvidia.com> > Sent: 08 June 2021 15:21 > To: Arunachalam Ganapathy; Olivier Deprez > Cc: Bo Yan; hafnium(a)lists.trustedfirmware.org > Subject: RE: .git submodules increase hafnium code size > > Thanks Arun. We have taken the same approach. The changes I posted > earlier expect all dependencies to be out of tree and provide mechanisms to > pass the locations to the make system during compilation. > > This is a real problem for us, and we would like a solution that works for the > community too. @Olivier how should we move forward? > > -----Original Message----- > From: Arunachalam Ganapathy <Arunachalam.Ganapathy(a)arm.com> > Sent: Tuesday, June 8, 2021 2:08 PM > To: Varun Wadekar <vwadekar(a)nvidia.com>; Olivier Deprez > <Olivier.Deprez(a)arm.com> > Cc: Bo Yan <byan(a)nvidia.com>; hafnium(a)lists.trustedfirmware.org > Subject: Re: .git submodules increase hafnium code size > > External email: Use caution opening links or attachments > > > Hi Varun, > > >> 1- First in context of Total Compute delivery from Arm OSS platforms: > >> a. ability to build only the SPMC on TC0 platform (not all reference > targets such as qemu, rpi4, fvp) > >> b. use a Yocto provided toolchain. > >> @Arun, your view on how those two items were solved is beneficial to > further elaborate our plans. > > For Total Compute we wanted to skip cloning submodules (like driver/linux, > linux, > dtc) as only secure_hafnium.bin was required. Basically build only reference > spm. > Like: make PROJECT=reference_spm PLAT=TC this builds only secure hafnium > for one platform. > > There were some efforts put on 1.a and was able to build reference_spm for > one platform. But Hafnium build inside yocto forced to clone all submodules > (due to dependencies on prebuilt toolchains), so the changes were dropped > and also the changes weren't clean enough to be upstreamed. > Regarding 1.b we didn't try hafnium build using yocto toolchain. > > Thanks, > Arun > > -----Original Message----- > From: Varun Wadekar <vwadekar(a)nvidia.com> > Sent: Monday, June 7, 2021 14:43 > To: Varun Wadekar <vwadekar(a)nvidia.com>; Olivier Deprez > <Olivier.Deprez(a)arm.com>; Arunachalam Ganapathy > <Arunachalam.Ganapathy(a)arm.com> > Cc: Bo Yan <byan(a)nvidia.com>; hafnium(a)lists.trustedfirmware.org > <hafnium(a)lists.trustedfirmware.org> > Subject: RE: .git submodules increase hafnium code size > > Hi, > > >> @Arun, your view on how those two items were solved is beneficial to > further elaborate our plans. > > @Arunachalam Ganapathy your comments on this topic would be very > helpful. > > Thanks. > > -----Original Message----- > From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> On Behalf Of > Varun Wadekar via Hafnium > Sent: Monday, May 31, 2021 1:49 PM > To: Olivier Deprez <Olivier.Deprez(a)arm.com>; > hafnium(a)lists.trustedfirmware.org; Arunachalam Ganapathy > <Arunachalam.Ganapathy(a)arm.com> > Cc: Bo Yan <byan(a)nvidia.com> > Subject: Re: [Hafnium] .git submodules increase hafnium code size > > External email: Use caution opening links or attachments > > > Hi Olivier, > > Thanks for answering my queries. > > We are looking to deploy the following use case at NVIDIA. > > <snip> > > -ability to build only the SPMC (not all reference targets such as qemu, rpi4, > fvp) -A distribution only requiring the Hypervisor/SPMC output binary > ("out/reference/.../hafnium.bin") using any toolchain (be it arm64 or x86 > host, and arbitrary clang version). > > <snip> > > >> As you noticed, the Hafnium Hypervisor/SPMC and test environment > builds are closely coupled by the use of ninja/gn flow and scripts. We intend > to approach those problems in the course of Q3 in Arm OSS roadmap. > > [VW] Are there any local changes to decouple hafnium from its dependencies? > We can evaluate Arm;s approach against what we use internally. Our > changes moved the dependencies out of the tree and passed file locations to > the build system with the help of command line arguments. > > -Varun > > -----Original Message----- > From: Olivier Deprez <Olivier.Deprez(a)arm.com> > Sent: Monday, May 31, 2021 11:03 AM > To: hafnium(a)lists.trustedfirmware.org; Varun Wadekar > <vwadekar(a)nvidia.com>; Arunachalam Ganapathy > <Arunachalam.Ganapathy(a)arm.com> > Cc: Bo Yan <byan(a)nvidia.com> > Subject: Re: .git submodules increase hafnium code size > > External email: Use caution opening links or attachments > > > Hi Varun, > > We had similar requests raised internally. > 1- First in context of Total Compute delivery from Arm OSS platforms: > a. ability to build only the SPMC on TC0 platform (not all reference targets > such as qemu, rpi4, fvp) > b. use a Yocto provided toolchain. > @Arun, your view on how those two items were solved is beneficial to > further elaborate our plans. > 2- A similar request as 1.b to build Hafnium as part of a distribution on > arm64 host: > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeve > loper.trustedfirmware.org%2FT898&data=04%7C01%7Cbyan%40nvidia. > com%7C030b52fc55094b6fa3b008d9c26c6bdf%7C43083d15727340c1b7db39 > efd9ccc17a%7C0%7C0%7C637754593206358976%7CUnknown%7CTWFpbGZs > b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn > 0%3D%7C3000&sdata=AtMec%2BNFfhA14xeMZT992icEj6SLAhwLnB2co5 > VXFNM%3D&reserved=0 > > In my view there are two consumers: > -A distribution only requiring the Hypervisor/SPMC output binary > ("out/reference/.../hafnium.bin") using any toolchain (be it arm64 or x86 > host, and arbitrary clang version). > -The Hf CI framework/automation needs the above, plus the test framework > and tests (dependency on googletest, linux submodules etc). It's important to > keep this item alive while trying to solve above item. > > As you noticed, the Hafnium Hypervisor/SPMC and test environment builds > are closely coupled by the use of ninja/gn flow and scripts. > They are using a fixed toolchain version through prebuilts to ensure builds > are "reproducible", in particular with regards to the Hafnium CI. > > We intend to approach those problems in the course of Q3 in Arm OSS > roadmap. > As an early exploration we already have: > -clang 12 compiler upgrade. This is necessary if wiling to use any arbitrary > clang version: > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Frevie > w.trustedfirmware.org%2Fq%2Ftopic%3A%2522od%25252Fhf- > clang12%2522&data=04%7C01%7Cbyan%40nvidia.com%7C030b52fc550 > 94b6fa3b008d9c26c6bdf%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C > 0%7C637754593206358976%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp > ;sdata=t7KJjvv2o8EHKBpPdUEIrJ%2F7Vy7KFEODdnQMrL4LpaU%3D&res > erved=0+(status:open%20OR%20status:merged) > -Ability to build on arm64 host (done, internally). > -Identify the flow/script changes such that external dependencies can be > used (on-going, internally). > I thought of localizing common dependencies to python/shell scripts by the > use of definition files included in the mentioned scripts. This is only an early > investigation, I will check how this intersects the changes you provided. > > Regards, > Olivier. > > > > From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of > Varun Wadekar via Hafnium <hafnium(a)lists.trustedfirmware.org> > Sent: 28 May 2021 16:47 > To: hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org> > Cc: Bo Yan <byan(a)nvidia.com> > Subject: [Hafnium] .git submodules increase hafnium code size > > Hi, > > We at NVIDIA are evaluating Hafnium. During the initial investigation, we > found out that the repository size (in terms of MB) is huge. This is mostly > because of the "git submodules" used by the project. This is a great way to > deliver Hafnium with its dependencies in one go. > > But we think that the size can be trimmed by moving the toolchain, linux > folder, googletest and dtc compiler out, leaving just the Hafnium code in the > project. This way, companies like us can pick and choose instead of having to > use everything. In a bid to ease the pain internally and only use the Hafnium > code base we have crafted the following changes: > > > 1. hafnium: support external projects (I10a07de3) * Gerrit Code Review > (trustedfirmware.org)<https://nam11.safelinks.protection.outlook.com/?url > =https%3A%2F%2Freview.trustedfirmware.org%2Fc%2Fhafnium%2Fhafnium > %2F%2B%2F10142&data=04%7C01%7Cbyan%40nvidia.com%7C030b52f > c55094b6fa3b008d9c26c6bdf%7C43083d15727340c1b7db39efd9ccc17a%7C0 > %7C0%7C637754593206358976%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC > 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000& > amp;sdata=7PWBcTXxP6HtqN%2BTGz3cEnnfabSzlyjo0RNZOjvOL4A%3D&amp > ;reserved=0> > 2. hafnium: build with dtc and googletest out of tree (I057c9ad6) * Gerrit > Code Review > (trustedfirmware.org)<https://nam11.safelinks.protection.outlook.com/?url > =https%3A%2F%2Freview.trustedfirmware.org%2Fc%2Fhafnium%2Fhafnium > %2F%2B%2F10144&data=04%7C01%7Cbyan%40nvidia.com%7C030b52f > c55094b6fa3b008d9c26c6bdf%7C43083d15727340c1b7db39efd9ccc17a%7C0 > %7C0%7C637754593206358976%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC > 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000& > amp;sdata=Ql8XW8FAEQ%2FereVjB3glccWJLR7sQ3yg0v9%2FSptCnyk%3D&a > mp;reserved=0> > 3. build: support external toolchain (Iafd029c1) * Gerrit Code Review > (trustedfirmware.org)<https://nam11.safelinks.protection.outlook.com/?url > =https%3A%2F%2Freview.trustedfirmware.org%2Fc%2Fhafnium%2Fhafnium > %2F%2B%2F10145&data=04%7C01%7Cbyan%40nvidia.com%7C030b52f > c55094b6fa3b008d9c26c6bdf%7C43083d15727340c1b7db39efd9ccc17a%7C0 > %7C0%7C637754593206358976%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC > 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000& > amp;sdata=X%2FNE1WmrcQvqRzEBq8UXdA02y9rl%2BS%2Fs1btuRAAlacM%3 > D&reserved=0> > > This series does not have the patch to use an out of tree linux codebase. I > assume these patches wont be acceptable in their current state, so would > like to know how the community plans to handle this situation. > > The code size is a real concern for us, as we already have copies of the > dependencies in our codebase, so have no use for these duplicates. > > Thanks. > -- > Hafnium mailing list > Hafnium(a)lists.trustedfirmware.org > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.t > rustedfirmware.org%2Fmailman%2Flistinfo%2Fhafnium&data=04%7C0 > 1%7Cbyan%40nvidia.com%7C030b52fc55094b6fa3b008d9c26c6bdf%7C4308 > 3d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637754593206358976%7CUn > known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I > k1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=tBM%2FCZq%2FjMDpp60Y > ZN5sounTBfkkRjylu%2Fes3IpZBaE%3D&reserved=0 > -- > Hafnium mailing list > Hafnium(a)lists.trustedfirmware.org > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.t > rustedfirmware.org%2Fmailman%2Flistinfo%2Fhafnium&data=04%7C0 > 1%7Cbyan%40nvidia.com%7C030b52fc55094b6fa3b008d9c26c6bdf%7C4308 > 3d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637754593206358976%7CUn > known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I > k1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=tBM%2FCZq%2FjMDpp60Y > ZN5sounTBfkkRjylu%2Fes3IpZBaE%3D&reserved=0 > -- > Hafnium mailing list > Hafnium(a)lists.trustedfirmware.org > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.t > rustedfirmware.org%2Fmailman%2Flistinfo%2Fhafnium&data=04%7C0 > 1%7Cbyan%40nvidia.com%7C030b52fc55094b6fa3b008d9c26c6bdf%7C4308 > 3d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637754593206358976%7CUn > known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I > k1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=tBM%2FCZq%2FjMDpp60Y > ZN5sounTBfkkRjylu%2Fes3IpZBaE%3D&reserved=0 > -- > Hafnium mailing list > Hafnium(a)lists.trustedfirmware.org > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.t > rustedfirmware.org%2Fmailman%2Flistinfo%2Fhafnium&data=04%7C0 > 1%7Cbyan%40nvidia.com%7C030b52fc55094b6fa3b008d9c26c6bdf%7C4308 > 3d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637754593206358976%7CUn > known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I > k1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=tBM%2FCZq%2FjMDpp60Y > ZN5sounTBfkkRjylu%2Fes3IpZBaE%3D&reserved=0 > > -- > Hafnium mailing list > Hafnium(a)lists.trustedfirmware.org > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.t > rustedfirmware.org%2Fmailman%2Flistinfo%2Fhafnium&data=04%7C0 > 1%7Cbyan%40nvidia.com%7C030b52fc55094b6fa3b008d9c26c6bdf%7C4308 > 3d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637754593206358976%7CUn > known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I > k1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=tBM%2FCZq%2FjMDpp60Y > ZN5sounTBfkkRjylu%2Fes3IpZBaE%3D&reserved=0

3 years, 4 months

1
0
0 0

How to debug with pc value?

by Chenxu Wang

Hi all, When data or instruction abort happens, Hafnium provides the esr_el2, far, pc values and etc. I think this info is useful, but I want to know how to debug with the PC value. I know TF-A provides some dump files (e.g., bl31.dump). So, when some panic or errors happen, I can locate the "bug instruction", its functions, and other useful context quickly. Will Hafnium provides similar dump files? If not, can we create them? How? Sincerely, Wang

3 years, 4 months

2
1
0 0

Re: [Hafnium] .git submodules increase hafnium code size

by Olivier Deprez

Hi Varun, Just a quick sync on what's been going since this last email. A number of changes have been made to: -remove the gcc dependency, hafnium now only requires clang to build. -ability to provide a toolchain different from the one stored in prebuilt submodule (merged yesterday) -migrated and tested with recent clang versions (was clang 9) -ability to build on arm64 host (our need) The prebuilt submodule still exists but the dependency to hardcoded toolchains has weakened. I intend to tell more about those recent changes and what remains during a tech forum early next year, among: -remove toolchains from prebuilt? -split the hypervisor and spmc test configs into separate project/* directories -lessen the dependency to other 3rd party projects Regards, Olivier. ________________________________________ From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of Olivier Deprez via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: 08 June 2021 16:00 To: Varun Wadekar Cc: Bo Yan; hafnium(a)lists.trustedfirmware.org Subject: Re: [Hafnium] .git submodules increase hafnium code size Hi Varun, As indicated earlier, we (Arm side) don't expect to progress on this front before Q3. I'm gathering requirements and expect to discuss through a short presentation later in a tech forum or the ML. Regards, Olivier. ________________________________________ From: Varun Wadekar <vwadekar(a)nvidia.com> Sent: 08 June 2021 15:21 To: Arunachalam Ganapathy; Olivier Deprez Cc: Bo Yan; hafnium(a)lists.trustedfirmware.org Subject: RE: .git submodules increase hafnium code size Thanks Arun. We have taken the same approach. The changes I posted earlier expect all dependencies to be out of tree and provide mechanisms to pass the locations to the make system during compilation. This is a real problem for us, and we would like a solution that works for the community too. @Olivier how should we move forward? -----Original Message----- From: Arunachalam Ganapathy <Arunachalam.Ganapathy(a)arm.com> Sent: Tuesday, June 8, 2021 2:08 PM To: Varun Wadekar <vwadekar(a)nvidia.com>; Olivier Deprez <Olivier.Deprez(a)arm.com> Cc: Bo Yan <byan(a)nvidia.com>; hafnium(a)lists.trustedfirmware.org Subject: Re: .git submodules increase hafnium code size External email: Use caution opening links or attachments Hi Varun, >> 1- First in context of Total Compute delivery from Arm OSS platforms: >> a. ability to build only the SPMC on TC0 platform (not all reference targets such as qemu, rpi4, fvp) >> b. use a Yocto provided toolchain. >> @Arun, your view on how those two items were solved is beneficial to further elaborate our plans. For Total Compute we wanted to skip cloning submodules (like driver/linux, linux, dtc) as only secure_hafnium.bin was required. Basically build only reference spm. Like: make PROJECT=reference_spm PLAT=TC this builds only secure hafnium for one platform. There were some efforts put on 1.a and was able to build reference_spm for one platform. But Hafnium build inside yocto forced to clone all submodules (due to dependencies on prebuilt toolchains), so the changes were dropped and also the changes weren't clean enough to be upstreamed. Regarding 1.b we didn't try hafnium build using yocto toolchain. Thanks, Arun -----Original Message----- From: Varun Wadekar <vwadekar(a)nvidia.com> Sent: Monday, June 7, 2021 14:43 To: Varun Wadekar <vwadekar(a)nvidia.com>; Olivier Deprez <Olivier.Deprez(a)arm.com>; Arunachalam Ganapathy <Arunachalam.Ganapathy(a)arm.com> Cc: Bo Yan <byan(a)nvidia.com>; hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org> Subject: RE: .git submodules increase hafnium code size Hi, >> @Arun, your view on how those two items were solved is beneficial to further elaborate our plans. @Arunachalam Ganapathy your comments on this topic would be very helpful. Thanks. -----Original Message----- From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> On Behalf Of Varun Wadekar via Hafnium Sent: Monday, May 31, 2021 1:49 PM To: Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium(a)lists.trustedfirmware.org; Arunachalam Ganapathy <Arunachalam.Ganapathy(a)arm.com> Cc: Bo Yan <byan(a)nvidia.com> Subject: Re: [Hafnium] .git submodules increase hafnium code size External email: Use caution opening links or attachments Hi Olivier, Thanks for answering my queries. We are looking to deploy the following use case at NVIDIA. <snip> -ability to build only the SPMC (not all reference targets such as qemu, rpi4, fvp) -A distribution only requiring the Hypervisor/SPMC output binary ("out/reference/.../hafnium.bin") using any toolchain (be it arm64 or x86 host, and arbitrary clang version). <snip> >> As you noticed, the Hafnium Hypervisor/SPMC and test environment builds are closely coupled by the use of ninja/gn flow and scripts. We intend to approach those problems in the course of Q3 in Arm OSS roadmap. [VW] Are there any local changes to decouple hafnium from its dependencies? We can evaluate Arm;s approach against what we use internally. Our changes moved the dependencies out of the tree and passed file locations to the build system with the help of command line arguments. -Varun -----Original Message----- From: Olivier Deprez <Olivier.Deprez(a)arm.com> Sent: Monday, May 31, 2021 11:03 AM To: hafnium(a)lists.trustedfirmware.org; Varun Wadekar <vwadekar(a)nvidia.com>; Arunachalam Ganapathy <Arunachalam.Ganapathy(a)arm.com> Cc: Bo Yan <byan(a)nvidia.com> Subject: Re: .git submodules increase hafnium code size External email: Use caution opening links or attachments Hi Varun, We had similar requests raised internally. 1- First in context of Total Compute delivery from Arm OSS platforms: a. ability to build only the SPMC on TC0 platform (not all reference targets such as qemu, rpi4, fvp) b. use a Yocto provided toolchain. @Arun, your view on how those two items were solved is beneficial to further elaborate our plans. 2- A similar request as 1.b to build Hafnium as part of a distribution on arm64 host: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper… In my view there are two consumers: -A distribution only requiring the Hypervisor/SPMC output binary ("out/reference/.../hafnium.bin") using any toolchain (be it arm64 or x86 host, and arbitrary clang version). -The Hf CI framework/automation needs the above, plus the test framework and tests (dependency on googletest, linux submodules etc). It's important to keep this item alive while trying to solve above item. As you noticed, the Hafnium Hypervisor/SPMC and test environment builds are closely coupled by the use of ninja/gn flow and scripts. They are using a fixed toolchain version through prebuilts to ensure builds are "reproducible", in particular with regards to the Hafnium CI. We intend to approach those problems in the course of Q3 in Arm OSS roadmap. As an early exploration we already have: -clang 12 compiler upgrade. This is necessary if wiling to use any arbitrary clang version: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr… -Ability to build on arm64 host (done, internally). -Identify the flow/script changes such that external dependencies can be used (on-going, internally). I thought of localizing common dependencies to python/shell scripts by the use of definition files included in the mentioned scripts. This is only an early investigation, I will check how this intersects the changes you provided. Regards, Olivier. From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of Varun Wadekar via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: 28 May 2021 16:47 To: hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org> Cc: Bo Yan <byan(a)nvidia.com> Subject: [Hafnium] .git submodules increase hafnium code size Hi, We at NVIDIA are evaluating Hafnium. During the initial investigation, we found out that the repository size (in terms of MB) is huge. This is mostly because of the "git submodules" used by the project. This is a great way to deliver Hafnium with its dependencies in one go. But we think that the size can be trimmed by moving the toolchain, linux folder, googletest and dtc compiler out, leaving just the Hafnium code in the project. This way, companies like us can pick and choose instead of having to use everything. In a bid to ease the pain internally and only use the Hafnium code base we have crafted the following changes: 1. hafnium: support external projects (I10a07de3) * Gerrit Code Review (trustedfirmware.org)<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…> 2. hafnium: build with dtc and googletest out of tree (I057c9ad6) * Gerrit Code Review (trustedfirmware.org)<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…> 3. build: support external toolchain (Iafd029c1) * Gerrit Code Review (trustedfirmware.org)<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…> This series does not have the patch to use an out of tree linux codebase. I assume these patches wont be acceptable in their current state, so would like to know how the community plans to handle this situation. The code size is a real concern for us, as we already have copies of the dependencies in our codebase, so have no use for these duplicates. Thanks. -- Hafnium mailing list Hafnium(a)lists.trustedfirmware.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- Hafnium mailing list Hafnium(a)lists.trustedfirmware.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- Hafnium mailing list Hafnium(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/hafnium

3 years, 4 months

4
6
0 0

Re: [Hafnium] Bug in hftest.py

by Federico Recanati

Hi Raghu, a fix for hftest.py has been merged: https://review.trustedfirmware.org/c/hafnium/hafnium/+/12481 addressing the random failures of both-world tests and supporting connection to telnet ports other than 5000 Cheers, Federico ____________________________________ > From: raghu.ncstate(a)icloud.com <raghu.ncstate(a)icloud.com> > Sent: 04 August 2021 21:01 > To: Olivier Deprez; 'Raghu Krishnamurthy via Hafnium' > Subject: RE: [Hafnium] Bug in hftest.py > > Thanks Olivier. I've created https://developer.trustedfirmware.org/T955 to > track. Understood all of this is new. I do have local fixes to get around > the issue so not a hurry to have a fix merged, but something to consider and > fix since it will eventually show up. > >>> the both worlds test scenario is not 100% stable on my machine > [RK] Likewise. I've noticed that this is caused by lingering FVP processes. > Usually I ps -ax | grep for FVP instances, kill and then run tests and I > never see failures after that. The issue that I faced was that the lingering > FVP would take up telnet ports and the newly spawned ones use different > ports(>5004) than what hftest.py expects. It appears that when tests fail, > we may not be cleaning up/exiting processes properly, but I haven't checked. > Or the code may be just fine and a ctrl+c leaves those processes lingering. > > Thanks > Raghu > > -----Original Message----- > From: Olivier Deprez <Olivier.Deprez(a)arm.com> > Sent: Tuesday, August 3, 2021 11:51 PM > To: 'Raghu Krishnamurthy via Hafnium' <hafnium(a)lists.trustedfirmware.org>; > raghu.ncstate(a)icloud.com > Subject: Re: [Hafnium] Bug in hftest.py > > Hi Raghu, > > Thanks for reporting. > This part of the test infrastructure (testing the SPMC) is still very fresh > and requires improvement iterations so please bear with us. Also a reason > it's not yet part of the automated non-regression with jenkins (as opposed > to the legacy kokoro/test.sh). For the time being we still mostly rely on > the TF-A CI for testing on the secure side. > > IIUC this change was made to help with the test time as the FVP takes long > to reload on every test. > But indeed it might have the side effect you describe. > So either we revert the FVP reloading on every test. > Or another (somewhat hackish) possibility is to clear the mentioned > variables from within the test (or make them part of BSS)? > > To be fair, the both worlds test scenario is not 100% stable on my machine > (for some reason the connection is not always successful between the FVP and > hftest) hence limiting confidence/robustness of my testing and > investigations. So I wonder is the scripting is still somewhat a bit > fragile. > > Regards, > Olivier. > > ________________________________________ > From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of Raghu > Krishnamurthy via Hafnium <hafnium(a)lists.trustedfirmware.org> > Sent: 03 August 2021 23:47 > To: 'Raghu Krishnamurthy via Hafnium' > Subject: [Hafnium] Bug in hftest.py > > Hi All, > > > > Wanted to report to you that commit 18a25f9241f86ba2d637011ff465ce3869e8651b > in hafnium "appears" broken. The issue with the optimization in this patch > is that the partition images are not reloaded for each test run, which means > a previous test could have written data to say SRAM, and the following test > would use the old values from the previous test, when the same image is > executed again from SRAM for a following test. This would be a problem for > pretty much anything in the data section of a partition. In my case, I have > a counter in the data section of my partition, which does not get reset back > to its original value. > > I've attached a patch to help repro the issue. Fix is to disable the > optimization or somehow reload the images for each run. This affects only > "both world" tests. > > Let me know if I'm missing something here. > > > > Apply patch and run timeout --foreground 300s ./test/hftest/hftest.py > --out_partitions out/reference/secure_aem_v8a_fvp_vm_clang --log > out/reference/kokoro_log --spmc > out/reference/secure_aem_v8a_fvp_clang/hafnium.bin --driver=fvp --hypervisor > out/reference/aem_v8a_fvp_clang/hafnium.bin --partitions_json > test/vmapi/ffa_secure_partitions/ffa_both_world_partitions_test.json > > > > The command line is from kokoro/test_spmc.sh. > > > > Thanks > > Raghu > > > > -- > Hafnium mailing list > Hafnium(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/hafnium >

3 years, 4 months

4
8
0 0

Hafnium toolchain switch

by Olivier Deprez

Hi, A small heads up that from this change: https://review.trustedfirmware.org/c/hafnium/hafnium/+/11613 a developer needs to provide the LLVM/clang toolchain through the PATH environment variable. See the documentation update: https://review.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/HEAD/d… Until then the toolchain was hardcoded to use the version stored in the prebuilt submodule. >From now, this weakens the dependency to the prebuilt toolchain and provides flexibility with providing an alternate toolchain on a x86 host. This also opens to building on an aarch64 host. This has been tested with different combinations of hosts, ubuntu releases and toolchains downloaded from https://releases.llvm.org/download.html x86_64 Ubuntu 18.04 / 20.04 clang/llvm 12.0.0 , 13.0.0 aarch64 Ubuntu 19.04 (Ampere eMAG) / 20.04, 21.04 (Rpi4) clang/llvm 12.0.0 , 12.0.1, 13.0.0 It is still possible to point PATH to the prebuilt toolchain version (Android llvm/clang 12.0.5) as indicated in the documentation. If you have a live tree, please clean the out directory or run make clobber, once you update master. Builds run as before after the switch. Limitations: -the build breaks if using a native toolchain installed on the host (apt-get install clang..) -the build breaks with Ubuntu 21.10/AArch64 (under investigation). Regards, Olivier.

3 years, 4 months

1
0
0 0

Re: [Hafnium] [TF-A] A problem about assert failed in TF-A

by Joanna Farley

TF-A List. This issue has also been discussed on Hafnium list before being posted here. Cross posting so we can have a single thread to track going forward. See https://lists.trustedfirmware.org/pipermail/hafnium/2021-December/000209.ht… with Olivier's last reply copied below. But see the archive above for full history of the thread. > Hi Wang, > > With this level of details; this is difficult to say. You can extend to the TF-A ML if you wish. I'm hinting the SPMD because you are mentioning spmd_smc_forward and cm_el1/2_sysregs_context_restore which are within the SPMD/EL3 space. I wouldn't expect such assert to happen in any regular use case of the reference implementation (because this is a hard EL3 failure). But yes, the problem can be elsewhere in Hafnium or Cactus, but I'd say less likely to alter the EL3 state. Unless Hafnium has a bug leading to corrupting a secure memory region which doesn't belong to it. > Beyond this, notice the assert is taken in cm_el1_sysregs_context_restore. It is called by cm_prepare_el3_exit which means it can be related to power management e.g. on a psci resume event. This can be a hint as you say this is occurring 'randomly'. > > Regards, > Olivier. Joanna On 14/12/2021, 19:39, "TF-A on behalf of Chenxu Wang via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi all, I am running FVP with 2CPUs, Cactus SP (SEL1), Hafnium (SEL2) and KVM VHE. Sometimes I send the "FFA_MSG_SEND_DIRECT_REQ" smc call from KVM (I fill 0x8400006f in x0, then VMID and SP ID in x1, let x2 as 0). It says assert failed, like this: ASSERT: lib/el3_runtime/aarch64/context_mgmt.c:651 BACKTRACE: START: assert 0: EL3: 0x4005cac 1: EL3: 0x400323c 2: EL3: 0x400620c 3: EL3: 0x400e180 4: EL3: 0x4005a94 BACKTRACE: END: assert After I check the bl31.dump, I notice that: when services/std_svc/spmd/spmd_main.c sends the FFA call (from NS to S) via "spmd_smc_forward(smc_fid, secure_origin,x1, x2, x3, x4, handle)", it will go to cm_el1_sysregs_context_restore(secure_state_out) and cm_el2_sysregs_context_restore(secure_state_out), then it will assert the cm_get_context(). it gets the NULL context, so assert failed. Before the problem appeared, I have modified many codes on a dirty TF-A v2.4 (commit hash is 0aa70f4c4c023ca58dea2d093d3c08c69b652113), Hafnium and TF-A-TESTS. I also mail with Hafnium MailList, they consider it can be a problem in EL3. Such assert is NOT ALWAYS failed. I mean, maybe when I run FVP and send "smc" now, it is failed. But when I shut down, run FVP, and send the same instruction with the same parameter again, it is OK. I want to know, what is the possible reasons for suddenly losing the secure context. Can you give me some advice on debugging? e.g., where should I check? Need I provide more info? Sincerely, Wang -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

3 years, 4 months

3
2
0 0

A problem about assert failed in TF-A

by Chenxu Wang

Hi all, I am running Hafnium on FVP, with Cactus SP in SEL1 and KVM VHE enabled. Sometimes I send the "FFA_MSG_SEND_DIRECT_REQ" smc call in KVM (I fill 0x8400006f in x0, then VMID and SP ID in x1, let x2 as 0). It says assert failed, like this: ASSERT: lib/el3_runtime/aarch64/context_mgmt.c:651 BACKTRACE: START: assert 0: EL3: 0x4005cac 1: EL3: 0x400323c 2: EL3: 0x400620c 3: EL3: 0x400e180 4: EL3: 0x4005a94 BACKTRACE: END: assert I notice that when services/std_svc/spmd/spmd_main.c sends the FFA call (from NS to S) via "spmd_smc_forward(smc_fid, secure_origin,x1, x2, x3, x4, handle)", it will go to cm_el1_sysregs_context_restore(secure_state_out) and cm_el2_sysregs_context_restore(secure_state_out), then it will assert the cm_get_context(). it gets the NULL context, so assert failed. Such assert is NOT ALWAYS failed, but I still want to solve this problem. Since I have modified many lines of code in Hafnium and Cactus SP, I cannot show them here. Can you give me some advice on debugging? e.g., where should I check?

3 years, 4 months

2
5
0 0

Re: [Hafnium] Virtualising OP-TEE with Hafnium at S-EL2

by Olivier Deprez

Hi Xiangyi Xu For some reason your email was discarded by mailman, did you miss registering to the list? See few comments inline [OD] Regards, Olivier. ________________________________________ From: xiangyi xu <xuxiangyi666(a)gmail.com> Sent: 27 November 2021 14:13 To: hafnium(a)lists.trustedfirmware.org Subject: Virtualising OP-TEE with Hafnium at S-EL2 HI ALL: I am trying to setup Hafnium environment which loads OP-TEE in Security World and Linux in Normal World. I follow this instruction: https://lists.trustedfirmware.org/pipermail/hafnium/2021-January/000130.html. I can load the OP-TEE test successfully. But the BL33 payload is TF-A-tests example (BL33=../tf-a-tests/build/fvp/debug/tftf.bin). Could you share with us the tutorial to boot linux including the FF-A driver in the NS world while loading OP-TEE with Hafnium S-EL2? The presentation PPT is here: https://static.linaro.org/connect/lvc21/presentations/lvc21-305.pdf. [OD] The mentioned presentation is in context of the Total Compute platform (as opposed to FVP). It works great for what you want to do, and you can reproduce by following the user manual: https://gitlab.arm.com/arm-reference-solutions/arm-reference-solutions-docs… There is also work in progress at Linaro to provide a similar environment using the FVP. @Jens, are there public instructions on how to build the end to end scenario targeting the FVP incl. Linux, FF-A driver, TF-A, Hafnium, OP-TEE ? If not, I reckon this is in your mid term roadmap? Secondly, I can boot Linux with QEMU and Hafnium. But it seems Hafnium only supports NS world partition while using QEMU. Is any instruction to boot OP_TEE in Security world with Hafnium S-EL2. Since, QEMU 6.0 already supports S-EL2. However, I could not compile ATF successfully with SPD=spmd CTX_INCLUDE_EL2_REGS=1 PLAT=qemu ... [OD] qemu is not 'officially' supported for booting Hafnium at S-EL2. Although I have few changes in progress which may help. This is not a priority from Arm perspective, but let me come back on this. By following https://teaclave.apache.org/trustzone-sdk-docs/getting-started-with-optee-f… , I can boot Linux in NS and OP-TEE in Trustzone with QEMU, but it doesn't work when I add Hafnium. Thanks! Xiangyi Xu

3 years, 5 months

1
0
0 0

How to allow Hafnium to access a DRAM address space

by Chenxu Wang

Hi all, I try to use Hafnium (deployed in SEL2) to access a DRAM address, e.g. 0xa000_0000, but failed. I think the TTBR0_EL2 does not map this address space, or something wrong with TZASC. To solve this problem, I first add the DRAM region in TZASC and TTBR0_EL3 (by modifying TF-A), and EL3 can access this address. But Hafnium cannot read or write it. So, must I modify the .S files in Hafnium to add a page mapping to the DRAM space? Can I add this page in some C files? Or should I do something else? Sincerely, Wang Chenxu

3 years, 7 months

2
3
0 0

TF-A Tech Forum Agenda: Thu 12th August 2021 16:00 – 17:00 (BST)

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 12th August 2021 16:00 – 17:00 (BST). Agenda: * Enabling S-EL0 FF-A partitions on Hafnium using ARMv8.1 FEAT_VHE – Presented by Raghupathy Krishnamurthy * Summary: Present and discuss enabling S-EL0 FF-A partitions on Hafnium using ARMv8.1 FEAT_VHE. The goal is to present an ARM server centric view point on the requirements in Secure World, the solution space explored to meet these requirements and why/how FF-A S-EL0 partition on hafnium using FEAT_VHE appear to fit these requirements. 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: 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 on the TF-A mailing list. You have been invited to the following event. TF-A Tech Forum When Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time Calendar tf-a(a)lists.trustedfirmware.org Who • Bill Fletcher- creator • tf-a(a)lists.trustedfirmware.org more details »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…> Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…> Meeting ID: 915 970 4974 One tap mobile +16465588656,,9159704974# US (New York) +16699009128,,9159704974# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> Going (tf-a(a)lists.trustedfirmware.org)? All events in this series: Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> Invitation from Google Calendar<https://www.google.com/calendar/> You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more<https://support.google.com/calendar/answer/37135#forwarding>. Thanks Joanna

3 years, 9 months

1
0
0 0

Re: [Hafnium] Bug in hftest.py

by Olivier Deprez

Hi Raghu, Thanks for reporting. This part of the test infrastructure (testing the SPMC) is still very fresh and requires improvement iterations so please bear with us. Also a reason it's not yet part of the automated non-regression with jenkins (as opposed to the legacy kokoro/test.sh). For the time being we still mostly rely on the TF-A CI for testing on the secure side. IIUC this change was made to help with the test time as the FVP takes long to reload on every test. But indeed it might have the side effect you describe. So either we revert the FVP reloading on every test. Or another (somewhat hackish) possibility is to clear the mentioned variables from within the test (or make them part of BSS)? To be fair, the both worlds test scenario is not 100% stable on my machine (for some reason the connection is not always successful between the FVP and hftest) hence limiting confidence/robustness of my testing and investigations. So I wonder is the scripting is still somewhat a bit fragile. Regards, Olivier. ________________________________________ From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of Raghu Krishnamurthy via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: 03 August 2021 23:47 To: 'Raghu Krishnamurthy via Hafnium' Subject: [Hafnium] Bug in hftest.py Hi All, Wanted to report to you that commit 18a25f9241f86ba2d637011ff465ce3869e8651b in hafnium "appears" broken. The issue with the optimization in this patch is that the partition images are not reloaded for each test run, which means a previous test could have written data to say SRAM, and the following test would use the old values from the previous test, when the same image is executed again from SRAM for a following test. This would be a problem for pretty much anything in the data section of a partition. In my case, I have a counter in the data section of my partition, which does not get reset back to its original value. I've attached a patch to help repro the issue. Fix is to disable the optimization or somehow reload the images for each run. This affects only "both world" tests. Let me know if I'm missing something here. Apply patch and run timeout --foreground 300s ./test/hftest/hftest.py --out_partitions out/reference/secure_aem_v8a_fvp_vm_clang --log out/reference/kokoro_log --spmc out/reference/secure_aem_v8a_fvp_clang/hafnium.bin --driver=fvp --hypervisor out/reference/aem_v8a_fvp_clang/hafnium.bin --partitions_json test/vmapi/ffa_secure_partitions/ffa_both_world_partitions_test.json The command line is from kokoro/test_spmc.sh. Thanks Raghu -- Hafnium mailing list Hafnium(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/hafnium

3 years, 9 months

2
1
0 0

Bug in hftest.py

by raghu.ncstate＠icloud.com

Hi All, Wanted to report to you that commit 18a25f9241f86ba2d637011ff465ce3869e8651b in hafnium "appears" broken. The issue with the optimization in this patch is that the partition images are not reloaded for each test run, which means a previous test could have written data to say SRAM, and the following test would use the old values from the previous test, when the same image is executed again from SRAM for a following test. This would be a problem for pretty much anything in the data section of a partition. In my case, I have a counter in the data section of my partition, which does not get reset back to its original value. I've attached a patch to help repro the issue. Fix is to disable the optimization or somehow reload the images for each run. This affects only "both world" tests. Let me know if I'm missing something here. Apply patch and run timeout --foreground 300s ./test/hftest/hftest.py --out_partitions out/reference/secure_aem_v8a_fvp_vm_clang --log out/reference/kokoro_log --spmc out/reference/secure_aem_v8a_fvp_clang/hafnium.bin --driver=fvp --hypervisor out/reference/aem_v8a_fvp_clang/hafnium.bin --partitions_json test/vmapi/ffa_secure_partitions/ffa_both_world_partitions_test.json The command line is from kokoro/test_spmc.sh. Thanks Raghu

3 years, 9 months

1
0
0 0

Re: [Hafnium] Hafnium - Memory attributes precedence checks for mem share

by Joao Alves

Hi Andrew, I don't think Hafnium implements the different cacheability and shareability types for memory sharing at all does it? [JA] No, it doesn't. At least that is my understanding as well. I noticed mostly due to lack of support in the mm library. Asking was a means to confirm. The point (at least for now) was just about validation of the respective fields in the memory transaction descriptor. Thank you for this! 🙂 Best regards, João ________________________________ From: Andrew Walbran Sent: Wednesday, July 14, 2021 5:29 PM To: Joao Alves Cc: hafnium(a)lists.trustedfirmware.org; Olivier Deprez; Achin Gupta; Mahesh Reddy Bireddy; Jaykumar Pitambarbhai Patel Subject: Re: Hafnium - Memory attributes precedence checks for mem share I don't think Hafnium implements the different cacheability and shareability types for memory sharing at all does it? We just didn't have a need for it, if you want to add support that should be fine. This is mentioned in https://developer.trustedfirmware.org/T827, you can assign that to yourself if you want to take it on. On Wed, 14 Jul 2021 at 13:50, Joao Alves <Joao.Alves(a)arm.com<mailto:Joao.Alves@arm.com>> wrote: Hi Andrew, We have been revising some aspects of the memory sharing implementation. The specification describes a set of precedence rules for the memory attributes specified in the memory transaction descriptor, including: Memory type, cacheability, shareability. The sender would fill the memory attributes for the region to be shared. After memory send, the receiver should retrieve the regions, filling the memory attributes on its transaction descriptor that comply with the referred precedence rules. The referred rules can be found in section 10.10.4 of the newly release FF-A v1.1 beta spec<https://developer.arm.com/documentation/den0077/c/?lang=en>, as follows. Memory type precedence rules ( < reads as is less permissive than): * Device-nGnRnE < Device-nGnRE < Device-nGRE < Device-GRE < Normal Cacheability precedence rules: * Non-cacheable < Write-Back Cacheable Shareability precedence rules: * Non-Shareable < Inner Shareable < Outer shareable These checks are not part of the handling of FFA_MEMORY_RETRIEVE_REQ. Was there an implementation defined reason for this? If so, could you please provide the rationale? Thank you in advance for your help. Best regards, João Alves

3 years, 9 months

1
0
0 0

Hafnium - Memory attributes precedence checks for mem share

by Joao Alves

Hi Andrew, We have been revising some aspects of the memory sharing implementation. The specification describes a set of precedence rules for the memory attributes specified in the memory transaction descriptor, including: Memory type, cacheability, shareability. The sender would fill the memory attributes for the region to be shared. After memory send, the receiver should retrieve the regions, filling the memory attributes on its transaction descriptor that comply with the referred precedence rules. The referred rules can be found in section 10.10.4 of the newly release FF-A v1.1 beta spec<https://developer.arm.com/documentation/den0077/c/?lang=en>, as follows. Memory type precedence rules ( < reads as is less permissive than): * Device-nGnRnE < Device-nGnRE < Device-nGRE < Device-GRE < Normal Cacheability precedence rules: * Non-cacheable < Write-Back Cacheable Shareability precedence rules: * Non-Shareable < Inner Shareable < Outer shareable These checks are not part of the handling of FFA_MEMORY_RETRIEVE_REQ. Was there an implementation defined reason for this? If so, could you please provide the rationale? Thank you in advance for your help. Best regards, João Alves

3 years, 9 months

2
1
0 0

Re: [Hafnium] .git submodules increase hafnium code size

by Varun Wadekar

Hi, >> @Arun, your view on how those two items were solved is beneficial to further elaborate our plans. @Arunachalam Ganapathy your comments on this topic would be very helpful. Thanks. -----Original Message----- From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> On Behalf Of Varun Wadekar via Hafnium Sent: Monday, May 31, 2021 1:49 PM To: Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium(a)lists.trustedfirmware.org; Arunachalam Ganapathy <Arunachalam.Ganapathy(a)arm.com> Cc: Bo Yan <byan(a)nvidia.com> Subject: Re: [Hafnium] .git submodules increase hafnium code size External email: Use caution opening links or attachments Hi Olivier, Thanks for answering my queries. We are looking to deploy the following use case at NVIDIA. <snip> -ability to build only the SPMC (not all reference targets such as qemu, rpi4, fvp) -A distribution only requiring the Hypervisor/SPMC output binary ("out/reference/.../hafnium.bin") using any toolchain (be it arm64 or x86 host, and arbitrary clang version). <snip> >> As you noticed, the Hafnium Hypervisor/SPMC and test environment builds are closely coupled by the use of ninja/gn flow and scripts. We intend to approach those problems in the course of Q3 in Arm OSS roadmap. [VW] Are there any local changes to decouple hafnium from its dependencies? We can evaluate Arm;s approach against what we use internally. Our changes moved the dependencies out of the tree and passed file locations to the build system with the help of command line arguments. -Varun -----Original Message----- From: Olivier Deprez <Olivier.Deprez(a)arm.com> Sent: Monday, May 31, 2021 11:03 AM To: hafnium(a)lists.trustedfirmware.org; Varun Wadekar <vwadekar(a)nvidia.com>; Arunachalam Ganapathy <Arunachalam.Ganapathy(a)arm.com> Cc: Bo Yan <byan(a)nvidia.com> Subject: Re: .git submodules increase hafnium code size External email: Use caution opening links or attachments Hi Varun, We had similar requests raised internally. 1- First in context of Total Compute delivery from Arm OSS platforms: a. ability to build only the SPMC on TC0 platform (not all reference targets such as qemu, rpi4, fvp) b. use a Yocto provided toolchain. @Arun, your view on how those two items were solved is beneficial to further elaborate our plans. 2- A similar request as 1.b to build Hafnium as part of a distribution on arm64 host: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper… In my view there are two consumers: -A distribution only requiring the Hypervisor/SPMC output binary ("out/reference/.../hafnium.bin") using any toolchain (be it arm64 or x86 host, and arbitrary clang version). -The Hf CI framework/automation needs the above, plus the test framework and tests (dependency on googletest, linux submodules etc). It's important to keep this item alive while trying to solve above item. As you noticed, the Hafnium Hypervisor/SPMC and test environment builds are closely coupled by the use of ninja/gn flow and scripts. They are using a fixed toolchain version through prebuilts to ensure builds are "reproducible", in particular with regards to the Hafnium CI. We intend to approach those problems in the course of Q3 in Arm OSS roadmap. As an early exploration we already have: -clang 12 compiler upgrade. This is necessary if wiling to use any arbitrary clang version: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr… -Ability to build on arm64 host (done, internally). -Identify the flow/script changes such that external dependencies can be used (on-going, internally). I thought of localizing common dependencies to python/shell scripts by the use of definition files included in the mentioned scripts. This is only an early investigation, I will check how this intersects the changes you provided. Regards, Olivier. From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of Varun Wadekar via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: 28 May 2021 16:47 To: hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org> Cc: Bo Yan <byan(a)nvidia.com> Subject: [Hafnium] .git submodules increase hafnium code size Hi, We at NVIDIA are evaluating Hafnium. During the initial investigation, we found out that the repository size (in terms of MB) is huge. This is mostly because of the "git submodules" used by the project. This is a great way to deliver Hafnium with its dependencies in one go. But we think that the size can be trimmed by moving the toolchain, linux folder, googletest and dtc compiler out, leaving just the Hafnium code in the project. This way, companies like us can pick and choose instead of having to use everything. In a bid to ease the pain internally and only use the Hafnium code base we have crafted the following changes: 1. hafnium: support external projects (I10a07de3) * Gerrit Code Review (trustedfirmware.org)<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…> 2. hafnium: build with dtc and googletest out of tree (I057c9ad6) * Gerrit Code Review (trustedfirmware.org)<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…> 3. build: support external toolchain (Iafd029c1) * Gerrit Code Review (trustedfirmware.org)<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…> This series does not have the patch to use an out of tree linux codebase. I assume these patches wont be acceptable in their current state, so would like to know how the community plans to handle this situation. The code size is a real concern for us, as we already have copies of the dependencies in our codebase, so have no use for these duplicates. Thanks. -- Hafnium mailing list Hafnium(a)lists.trustedfirmware.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- Hafnium mailing list Hafnium(a)lists.trustedfirmware.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

3 years, 11 months

3
3
0 0

Re: [Hafnium] .git submodules increase hafnium code size

by Olivier Deprez

Hi Varun, We had similar requests raised internally. 1- First in context of Total Compute delivery from Arm OSS platforms: a. ability to build only the SPMC on TC0 platform (not all reference targets such as qemu, rpi4, fvp) b. use a Yocto provided toolchain. @Arun, your view on how those two items were solved is beneficial to further elaborate our plans. 2- A similar request as 1.b to build Hafnium as part of a distribution on arm64 host: https://developer.trustedfirmware.org/T898 In my view there are two consumers: -A distribution only requiring the Hypervisor/SPMC output binary ("out/reference/.../hafnium.bin") using any toolchain (be it arm64 or x86 host, and arbitrary clang version). -The Hf CI framework/automation needs the above, plus the test framework and tests (dependency on googletest, linux submodules etc). It's important to keep this item alive while trying to solve above item. As you noticed, the Hafnium Hypervisor/SPMC and test environment builds are closely coupled by the use of ninja/gn flow and scripts. They are using a fixed toolchain version through prebuilts to ensure builds are "reproducible", in particular with regards to the Hafnium CI. We intend to approach those problems in the course of Q3 in Arm OSS roadmap. As an early exploration we already have: -clang 12 compiler upgrade. This is necessary if wiling to use any arbitrary clang version: https://review.trustedfirmware.org/q/topic:%22od%252Fhf-clang12%22+(status:… -Ability to build on arm64 host (done, internally). -Identify the flow/script changes such that external dependencies can be used (on-going, internally). I thought of localizing common dependencies to python/shell scripts by the use of definition files included in the mentioned scripts. This is only an early investigation, I will check how this intersects the changes you provided. Regards, Olivier. From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of Varun Wadekar via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: 28 May 2021 16:47 To: hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org> Cc: Bo Yan <byan(a)nvidia.com> Subject: [Hafnium] .git submodules increase hafnium code size Hi, We at NVIDIA are evaluating Hafnium. During the initial investigation, we found out that the repository size (in terms of MB) is huge. This is mostly because of the "git submodules" used by the project. This is a great way to deliver Hafnium with its dependencies in one go. But we think that the size can be trimmed by moving the toolchain, linux folder, googletest and dtc compiler out, leaving just the Hafnium code in the project. This way, companies like us can pick and choose instead of having to use everything. In a bid to ease the pain internally and only use the Hafnium code base we have crafted the following changes: 1. hafnium: support external projects (I10a07de3) * Gerrit Code Review (trustedfirmware.org)<https://review.trustedfirmware.org/c/hafnium/hafnium/+/10142> 2. hafnium: build with dtc and googletest out of tree (I057c9ad6) * Gerrit Code Review (trustedfirmware.org)<https://review.trustedfirmware.org/c/hafnium/hafnium/+/10144> 3. build: support external toolchain (Iafd029c1) * Gerrit Code Review (trustedfirmware.org)<https://review.trustedfirmware.org/c/hafnium/hafnium/+/10145> This series does not have the patch to use an out of tree linux codebase. I assume these patches wont be acceptable in their current state, so would like to know how the community plans to handle this situation. The code size is a real concern for us, as we already have copies of the dependencies in our codebase, so have no use for these duplicates. Thanks. -- Hafnium mailing list Hafnium(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/hafnium

3 years, 11 months

2
1
0 0

.git submodules increase hafnium code size

by Varun Wadekar

Hi, We at NVIDIA are evaluating Hafnium. During the initial investigation, we found out that the repository size (in terms of MB) is huge. This is mostly because of the "git submodules" used by the project. This is a great way to deliver Hafnium with its dependencies in one go. But we think that the size can be trimmed by moving the toolchain, linux folder, googletest and dtc compiler out, leaving just the Hafnium code in the project. This way, companies like us can pick and choose instead of having to use everything. In a bid to ease the pain internally and only use the Hafnium code base we have crafted the following changes: 1. hafnium: support external projects (I10a07de3) * Gerrit Code Review (trustedfirmware.org)<https://review.trustedfirmware.org/c/hafnium/hafnium/+/10142> 2. hafnium: build with dtc and googletest out of tree (I057c9ad6) * Gerrit Code Review (trustedfirmware.org)<https://review.trustedfirmware.org/c/hafnium/hafnium/+/10144> 3. build: support external toolchain (Iafd029c1) * Gerrit Code Review (trustedfirmware.org)<https://review.trustedfirmware.org/c/hafnium/hafnium/+/10145> This series does not have the patch to use an out of tree linux codebase. I assume these patches wont be acceptable in their current state, so would like to know how the community plans to handle this situation. The code size is a real concern for us, as we already have copies of the dependencies in our codebase, so have no use for these duplicates. Thanks.

3 years, 11 months

1
0
0 0

Re: [Hafnium] Problems running Hafnium at S-EL2 with TF-A master

by Olivier Deprez

Hi Rebecca, No problem asking. Not immediately related to the TF-A log, but the image specified as BL32 shall rather be the secure Hafnium build (hafnium/out/reference/secure_aem_v8a_fvp_clang/hafnium.bin). The TF-A boot log suggests that the first secure partition is not found within the FIP image. So there is a problem in terms of provisioning the SP into the FIP and have the BL2 loader finding it. It can be a mismatch with UUIDs, or related to the contents of the json layout file. If that's an information you can share, let us know the nature of the secure partition image you wish to have TF-A loaded and booted by Hafnium. If you wish to reproduce a known working setup you can use below command lines using master for each tree: TF-a-tests: make CROSS_COMPILE=aarch64-none-elf- PLAT=fvp DEBUG=1 TESTS=spm -j8 Hafnium: make PROJECT=reference TF-A: make CROSS_COMPILE=aarch64-none-elf- SPD=spmd CTX_INCLUDE_EL2_REGS=1 ARM_ARCH_MINOR=5 BRANCH_PROTECTION=1 CTX_INCLUDE_PAUTH_REGS=1 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 Run the model: <path-to-fvp>/FVP_Base_RevC-2xAEMv8A -C pctl.startup=0.0.0.0 -C cluster0.NUM_CORES=4 -C cluster1.NUM_CORES=4 -C bp.secure_memory=1 -C bp.secureflashloader.fname=trusted-firmware-a/build/fvp/debug/bl1.bin -C bp.flashloader0.fname=trusted-firmware-a/build/fvp/debug/fip.bin -C cluster0.has_arm_v8-5=1 -C cluster1.has_arm_v8-5=1 -C cluster0.has_branch_target_exception=1 -C cluster1.has_branch_target_exception=1 -C cluster0.has_pointer_authentication=2 -C cluster1.has_pointer_authentication=2 -C cluster0.restriction_on_speculative_execution=2 -C cluster1.restriction_on_speculative_execution=2 -C pci.pci_smmuv3.mmu.SMMU_AIDR=2 -C pci.pci_smmuv3.mmu.SMMU_IDR0=0x0046123B -C pci.pci_smmuv3.mmu.SMMU_IDR1=0x00600002 -C pci.pci_smmuv3.mmu.SMMU_IDR3=0x1714 -C pci.pci_smmuv3.mmu.SMMU_IDR5=0xFFFF0472 -C pci.pci_smmuv3.mmu.SMMU_S_IDR1=0xA0000002 -C pci.pci_smmuv3.mmu.SMMU_S_IDR2=0 -C pci.pci_smmuv3.mmu.SMMU_S_IDR3=0 It should end up with the following test results: ******************************* Summary ******************************* > Test suite 'FF-A Version' Passed > Test suite 'FF-A RXTX Mapping' Passed > Test suite 'FF-A Direct messaging' Passed > Test suite 'FF-A Power management' Passed > Test suite 'FF-A Memory Sharing' Passed > Test suite 'FF-A features' Passed > Test suite 'SIMD,SVE Registers context' Passed > Test suite 'FF-A Interrupt' Passed > Test suite 'SMMUv3 tests' Passed ================================= Tests Skipped : 0 Tests Passed : 20 Tests Failed : 0 Tests Crashed : 0 Total tests : 20 ================================= NOTICE: Exiting tests. Regards, Olivier. From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of Rebecca Cran via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: 25 May 2021 19:43 To: hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org> Subject: [Hafnium] Problems running Hafnium at S-EL2 with TF-A master I'm having problems running TF-A / Hafnium with S-EL2 support. I can run Hafnium fine using the prebuilt TF-A binary in prebuilts/linux-aarch64/trusted-firmware-a-trusty/ but it doesn't work if I use TF-A master. I'm building TF-A with: make PLAT=fvp LOG_LEVEL=80 DEBUG=1 SPD=spmd CTX_INCLUDE_EL2_REGS=1 ARM_ARCH_MINOR=5 BRANCH_PROTECTION=1 CTX_INCLUDE_PAUTH_REGS=1 all fip BL32=../hafnium/out/reference/aem_v8a_fvp_clang/hafnium.bin BL33=../uefi/Build/ArmVExpress-FVP-AArch64/DEBUG_GCC5/FV/FVP_AARCH64_EFI.fd SP_LAYOUT_FILE=sp_layout.json And running it with: ../Base_RevC_AEMv8A_pkg/models/Linux64_GCC-6.4/FVP_Base_RevC-2xAEMv8A \ -C pctl.startup=0.0.0.0 \ -C cluster0.NUM_CORES=4 -C cluster1.NUM_CORES=4 -C bp.secure_memory=1 \ -C bp.secureflashloader.fname=../trusted-firmware-a/build/fvp/debug/bl1.bin \ -C bp.flashloader0.fname=../trusted-firmware-a/build/fvp/debug/fip.bin \ -C bp.pl011_uart0.out_file=fvp-uart0.log -C bp.pl011_uart1.out_file=fvp-uart1.log \ -C bp.pl011_uart2.out_file=fvp-uart2.log \ -C cluster0.has_arm_v8-5=1 -C cluster1.has_arm_v8-5=1 -C pci.pci_smmuv3.mmu.SMMU_AIDR=2 \ -C pci.pci_smmuv3.mmu.SMMU_IDR0=0x0046123B -C pci.pci_smmuv3.mmu.SMMU_IDR1=0x00600002 \ -C pci.pci_smmuv3.mmu.SMMU_IDR3=0x1714 -C pci.pci_smmuv3.mmu.SMMU_IDR5=0xFFFF0472 \ -C pci.pci_smmuv3.mmu.SMMU_S_IDR1=0xA0000002 -C pci.pci_smmuv3.mmu.SMMU_S_IDR2=0 \ -C pci.pci_smmuv3.mmu.SMMU_S_IDR3=0 \ -C cluster0.has_branch_target_exception=1 \ -C cluster1.has_branch_target_exception=1 \ -C cluster0.restriction_on_speculative_execution=2 \ -C cluster1.restriction_on_speculative_execution=2 TF-A prints this and then stops for a minute or two before resetting: INFO: Loading image id=5 at address 0x88000000 INFO: Image id=5 loaded: 0x88000000 - 0x88280000 INFO: BL2: Skip loading image id 27 INFO: BL2: Loading image id 34 VERBOSE: Using Memmap VERBOSE: FIP header looks OK. VERBOSE: Trying alternative IO I'm fairly new to working with Hafnium, TF-A _and_ Arm's FVP so there's probably something obvious I'm doing wrong? -- Rebecca Cran -- Hafnium mailing list Hafnium(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/hafnium

3 years, 11 months

1
0
0 0

Problems running Hafnium at S-EL2 with TF-A master

by Rebecca Cran

I'm having problems running TF-A / Hafnium with S-EL2 support. I can run Hafnium fine using the prebuilt TF-A binary in prebuilts/linux-aarch64/trusted-firmware-a-trusty/ but it doesn't work if I use TF-A master. I'm building TF-A with: make PLAT=fvp LOG_LEVEL=80 DEBUG=1 SPD=spmd CTX_INCLUDE_EL2_REGS=1 ARM_ARCH_MINOR=5 BRANCH_PROTECTION=1 CTX_INCLUDE_PAUTH_REGS=1 all fip BL32=../hafnium/out/reference/aem_v8a_fvp_clang/hafnium.bin BL33=../uefi/Build/ArmVExpress-FVP-AArch64/DEBUG_GCC5/FV/FVP_AARCH64_EFI.fd SP_LAYOUT_FILE=sp_layout.json And running it with: ../Base_RevC_AEMv8A_pkg/models/Linux64_GCC-6.4/FVP_Base_RevC-2xAEMv8A \ -C pctl.startup=0.0.0.0 \ -C cluster0.NUM_CORES=4 -C cluster1.NUM_CORES=4 -C bp.secure_memory=1 \ -C bp.secureflashloader.fname=../trusted-firmware-a/build/fvp/debug/bl1.bin \ -C bp.flashloader0.fname=../trusted-firmware-a/build/fvp/debug/fip.bin \ -C bp.pl011_uart0.out_file=fvp-uart0.log -C bp.pl011_uart1.out_file=fvp-uart1.log \ -C bp.pl011_uart2.out_file=fvp-uart2.log \ -C cluster0.has_arm_v8-5=1 -C cluster1.has_arm_v8-5=1 -C pci.pci_smmuv3.mmu.SMMU_AIDR=2 \ -C pci.pci_smmuv3.mmu.SMMU_IDR0=0x0046123B -C pci.pci_smmuv3.mmu.SMMU_IDR1=0x00600002 \ -C pci.pci_smmuv3.mmu.SMMU_IDR3=0x1714 -C pci.pci_smmuv3.mmu.SMMU_IDR5=0xFFFF0472 \ -C pci.pci_smmuv3.mmu.SMMU_S_IDR1=0xA0000002 -C pci.pci_smmuv3.mmu.SMMU_S_IDR2=0 \ -C pci.pci_smmuv3.mmu.SMMU_S_IDR3=0 \ -C cluster0.has_branch_target_exception=1 \ -C cluster1.has_branch_target_exception=1 \ -C cluster0.restriction_on_speculative_execution=2 \ -C cluster1.restriction_on_speculative_execution=2 TF-A prints this and then stops for a minute or two before resetting: INFO: Loading image id=5 at address 0x88000000 INFO: Image id=5 loaded: 0x88000000 - 0x88280000 INFO: BL2: Skip loading image id 27 INFO: BL2: Loading image id 34 VERBOSE: Using Memmap VERBOSE: FIP header looks OK. VERBOSE: Trying alternative IO I'm fairly new to working with Hafnium, TF-A _and_ Arm's FVP so there's probably something obvious I'm doing wrong? -- Rebecca Cran

3 years, 11 months

1
0
0 0

Re: [Hafnium] SMMUv3 Driver issue when running FVP tests

by Olivier Deprez

Hi Raghu, The second problem about FVP CI test suite goes away by applying the slight change below on top of master. I will submit an appropriate change by Monday. diff --git a/test/hftest/hftest.py b/test/hftest/hftest.py index 2e70abf9..c63c2d18 100755 --- a/test/hftest/hftest.py +++ b/test/hftest/hftest.py @@ -392,7 +392,7 @@ class FvpDriverHypervisor(FvpDriver): Driver which runs tests in Arm FVP emulator, with hafnium as hypervisor """ INITRD_START= 0x84000000 - INITRD_END = 0x85000000 #Default value, however may change if initrd in args + INITRD_END = 0x86000000 #Default value, however may change if initrd in args def __init__(self, args): self.vms_in_partitions_json = args.partitions and args.partitions["VMs"] Regards, Olivier. ________________________________________ From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of Olivier Deprez via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: 30 April 2021 08:48 To: 'Raghu Krishnamurthy via Hafnium'; raghu.ncstate(a)icloud.com Subject: Re: [Hafnium] SMMUv3 Driver issue when running FVP tests Hi, Can you cherry pick: https://review.trustedfirmware.org/c/hafnium/hafnium/+/9791 This will solve this first problem. Though I'm seeing a second failure occurring later in the test run. We're looking at it. Regards, Olivier. ________________________________________ From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of Raghu Krishnamurthy via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: 30 April 2021 02:52 To: 'Raghu Krishnamurthy via Hafnium' Subject: [Hafnium] SMMUv3 Driver issue when running FVP tests When I run kokoro/test.sh -fvp at the tip of the master brach(as of today), I see the following failures when running the aarch64 tests. The test command line that fails is: timeout --foreground 300s ./test/hftest/hftest.py --driver=fvp --out out/reference/aem_v8a_fvp_clang --out_initrd out/reference/aem_v8a_fvp_vm_clang --out_partitions out/reference/aem_v8a_fvp_vm_clang --log out/reference/kokoro_log hafnium --initrd test/vmapi/arch/aarch64/aarch64_test Error log is: ERROR: SMMUv3: Linear Stream Table cannot be supported when StreamID bits > 7 ERROR: SMMUv3: Failed to initialize driver Panic: Could not initialize IOMMUs. Has anybody seen this issue? I'll try to debug but thought I'll send an email in case somebody already knows the answer to this. Wondering if I'm missing a knob in the FVP. -Raghu -- 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

4 years

2
2
0 0

Re: [Hafnium] SMMUv3 Driver issue when running FVP tests

by Olivier Deprez

Hi, Can you cherry pick: https://review.trustedfirmware.org/c/hafnium/hafnium/+/9791 This will solve this first problem. Though I'm seeing a second failure occurring later in the test run. We're looking at it. Regards, Olivier. ________________________________________ From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of Raghu Krishnamurthy via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: 30 April 2021 02:52 To: 'Raghu Krishnamurthy via Hafnium' Subject: [Hafnium] SMMUv3 Driver issue when running FVP tests When I run kokoro/test.sh -fvp at the tip of the master brach(as of today), I see the following failures when running the aarch64 tests. The test command line that fails is: timeout --foreground 300s ./test/hftest/hftest.py --driver=fvp --out out/reference/aem_v8a_fvp_clang --out_initrd out/reference/aem_v8a_fvp_vm_clang --out_partitions out/reference/aem_v8a_fvp_vm_clang --log out/reference/kokoro_log hafnium --initrd test/vmapi/arch/aarch64/aarch64_test Error log is: ERROR: SMMUv3: Linear Stream Table cannot be supported when StreamID bits > 7 ERROR: SMMUv3: Failed to initialize driver Panic: Could not initialize IOMMUs. Has anybody seen this issue? I'll try to debug but thought I'll send an email in case somebody already knows the answer to this. Wondering if I'm missing a knob in the FVP. -Raghu -- Hafnium mailing list Hafnium(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/hafnium

4 years

1
0
0 0

SMMUv3 Driver issue when running FVP tests

by raghu.ncstate＠icloud.com

When I run kokoro/test.sh -fvp at the tip of the master brach(as of today), I see the following failures when running the aarch64 tests. The test command line that fails is: timeout --foreground 300s ./test/hftest/hftest.py --driver=fvp --out out/reference/aem_v8a_fvp_clang --out_initrd out/reference/aem_v8a_fvp_vm_clang --out_partitions out/reference/aem_v8a_fvp_vm_clang --log out/reference/kokoro_log hafnium --initrd test/vmapi/arch/aarch64/aarch64_test Error log is: ERROR: SMMUv3: Linear Stream Table cannot be supported when StreamID bits > 7 ERROR: SMMUv3: Failed to initialize driver Panic: Could not initialize IOMMUs. Has anybody seen this issue? I'll try to debug but thought I'll send an email in case somebody already knows the answer to this. Wondering if I'm missing a knob in the FVP. -Raghu

4 years

1
0
0 0

Re: [Hafnium] Getting Started page: problem with the command under "Getting the source code"

by Olivier Deprez

Hi Rebecca, Thanks for reporting. Can you try with the updated command: https://review.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/refs/c… Thanks, Olivier. ________________________________________ From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of Rebecca Cran via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: 21 April 2021 04:39 To: hafnium(a)lists.trustedfirmware.org Subject: [Hafnium] Getting Started page: problem with the command under "Getting the source code" On the Getting Started document (https://review.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/HEAD/d…) there's a command listed to get the source code: git clone --recurse-submodules https://git.trustedfirmware.org/hafnium/hafnium.git && (cd hafnium && f=`git rev-parse --git-dir`/hooks/commit-msg ; curl -Lo $f https://review.trustedfirmware.org/tools/hooks/commit-msg ; chmod +x $f ; for m in `git rev-parse --git-dir`/modules/*; do cp $f $m/hooks/commit-msg; done) However, on my system it's erroring out because the 'hooks' directory it tries to write to doesn't exist: % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 2174 100 2174 0 0 4221 0 --:--:-- --:--:-- --:--:-- 4221 cp: cannot create regular file '.git/modules/driver/hooks/commit-msg': No such file or directory cp: cannot create regular file '.git/modules/project/hooks/commit-msg': No such file or directory cp: cannot create regular file '.git/modules/third_party/hooks/commit-msg': No such file or directory -- Rebecca Cran -- Hafnium mailing list Hafnium(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/hafnium

4 years

2
3
0 0

Getting Started page: problem with the command under "Getting the source code"

by Rebecca Cran

On the Getting Started document (https://review.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/HEAD/d…) there's a command listed to get the source code: git clone --recurse-submodules https://git.trustedfirmware.org/hafnium/hafnium.git && (cd hafnium && f=`git rev-parse --git-dir`/hooks/commit-msg ; curl -Lo $f https://review.trustedfirmware.org/tools/hooks/commit-msg ; chmod +x $f ; for m in `git rev-parse --git-dir`/modules/*; do cp $f $m/hooks/commit-msg; done) However, on my system it's erroring out because the 'hooks' directory it tries to write to doesn't exist: % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 2174 100 2174 0 0 4221 0 --:--:-- --:--:-- --:--:-- 4221 cp: cannot create regular file '.git/modules/driver/hooks/commit-msg': No such file or directory cp: cannot create regular file '.git/modules/project/hooks/commit-msg': No such file or directory cp: cannot create regular file '.git/modules/third_party/hooks/commit-msg': No such file or directory -- Rebecca Cran

4 years

1
0
0 0

Re: [Hafnium] Broken hftest.py

by Olivier Deprez

Hi I think it's a missing python lib pip3 install fdt may do it Agree this needs a doc update. Regards, Olivier. ________________________________ From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of Raghu Krishnamurthy via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: 19 March 2021 18:44 To: hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org> Subject: [Hafnium] Broken hftest.py Hi All, Hftest.py appears to be broken due to a recent change to "import fdt". What package needs to be installed to be able to run this? The documentation does not appear to be updated either to account for the new package. Anybody know what exactly I need to install to meet that dependency? Thanks Raghu -- Hafnium mailing list Hafnium(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/hafnium

4 years, 1 month

2
1
0 0

Broken hftest.py

by raghu.ncstate＠icloud.com

Hi All, Hftest.py appears to be broken due to a recent change to "import fdt". What package needs to be installed to be able to run this? The documentation does not appear to be updated either to account for the new package. Anybody know what exactly I need to install to meet that dependency? Thanks Raghu

4 years, 1 month

1
0
0 0

Re: [Hafnium] Test setup handling multiple bare metal SPs

by Olivier Deprez

Hi Yinhua, Sorry for the delay. Assuming Hafnium, TF-A and TF-a-tests are cloned in the same workspace directory. Instructions below permit launching a simulation with TFTF payload at NS-EL2, Hafnium at S-EL2 and three "cactus" bare metal partitions at S-EL1. TFTF runs a number of FF-A related tests demonstrating NWd<=>SWd protocols, including sending messages back and forth to the three partitions and exercising memory sharing. Hafnium: master make PROJECT=reference TF-A-tests: master make CROSS_COMPILE=aarch64-none-elf- PLAT=fvp DEBUG=1 TESTS=spm -j8 TF-A: master 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 run the FVP with: <path-to-fvp>/FVP_Base_RevC-2xAEMv8A -C pctl.startup=0.0.0.0 -C cluster0.NUM_CORES=4 -C cluster1.NUM_CORES=4 -C bp.secure_memory=1 -C bp.secureflashloader.fname=trusted-firmware-a/build/fvp/debug/bl1.bin -C bp.flashloader0.fname=trusted-firmware-a/build/fvp/debug/fip.bin -C cluster0.has_arm_v8-4=1 -C cluster1.has_arm_v8-4=1 Regards, Olivier. ________________________________________ From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of yinhua_chen--- via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: 04 March 2021 07:36 To: hafnium(a)lists.trustedfirmware.org Subject: [Hafnium] Test setup handling multiple bare metal SPs Hi all, Can anyone please provide with a test setup handling multiple bare metal SPs (TF-A-tests framework) ? This is the part I am most interested in, but it is very hard for myself to build the multiple-SPs-model from the documents and source code. Sincerely, Yinhua -- Hafnium mailing list Hafnium(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/hafnium

4 years, 2 months

2
3
0 0

Re: [Hafnium] Test setup handling multiple bare metal SPs

by Olivier Deprez

Notice this information is shared in the TF-A documentation: https://trustedfirmware-a.readthedocs.io/en/latest/components/secure-partit… ________________________________________ From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of Olivier Deprez via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: 04 March 2021 09:10 To: hafnium(a)lists.trustedfirmware.org; yinhua_chen(a)outlook.com Subject: Re: [Hafnium] Test setup handling multiple bare metal SPs Hi Yinhua, Sorry for the delay. Assuming Hafnium, TF-A and TF-a-tests are cloned in the same workspace directory. Instructions below permit launching a simulation with TFTF payload at NS-EL2, Hafnium at S-EL2 and three "cactus" bare metal partitions at S-EL1. TFTF runs a number of FF-A related tests demonstrating NWd<=>SWd protocols, including sending messages back and forth to the three partitions and exercising memory sharing. Hafnium: master make PROJECT=reference TF-A-tests: master make CROSS_COMPILE=aarch64-none-elf- PLAT=fvp DEBUG=1 TESTS=spm -j8 TF-A: master 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 run the FVP with: <path-to-fvp>/FVP_Base_RevC-2xAEMv8A -C pctl.startup=0.0.0.0 -C cluster0.NUM_CORES=4 -C cluster1.NUM_CORES=4 -C bp.secure_memory=1 -C bp.secureflashloader.fname=trusted-firmware-a/build/fvp/debug/bl1.bin -C bp.flashloader0.fname=trusted-firmware-a/build/fvp/debug/fip.bin -C cluster0.has_arm_v8-4=1 -C cluster1.has_arm_v8-4=1 Regards, Olivier. ________________________________________ From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of yinhua_chen--- via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: 04 March 2021 07:36 To: hafnium(a)lists.trustedfirmware.org Subject: [Hafnium] Test setup handling multiple bare metal SPs Hi all, Can anyone please provide with a test setup handling multiple bare metal SPs (TF-A-tests framework) ? This is the part I am most interested in, but it is very hard for myself to build the multiple-SPs-model from the documents and source code. Sincerely, Yinhua -- 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

4 years, 2 months

2
1
0 0

Test setup handling multiple bare metal SPs

by yinhua_chen＠outlook.com

Hi all, Can anyone please provide with a test setup handling multiple bare metal SPs (TF-A-tests framework) ? This is the part I am most interested in, but it is very hard for myself to build the multiple-SPs-model from the documents and source code. Sincerely, Yinhua

4 years, 2 months

1
0
0 0

Re: [Hafnium] Trying to load two OPTEEs on hafnium

by raghu.ncstate＠icloud.com

Hi Oilvier, Want some clarification on this statement: " A configuration with multiple OP-TEE instances is valid although (to my knowledge) this probably lacks the appropriate OP-TEE support and has never been tested." Not sure I understand why OPTEE needs support for multiple OPTEE vm's to run on SPMC. If OPTEE needs to be aware that there are other OPTEE partitions, then we are likely doing something wrong with the abstractions. If SPMC supports booting multiple SP's, it should not matter how many other partitions are there or booted unless there is a dependency(which in this case should not exist). Having said that, I assume you mainly wanted to point out that this has never been tested? If not, what support would OPTEE require to boot as multiple instances on an SPMC beyond what Yinhua is doing? What is being done *should* be supported with the latest code base. Thanks Raghu -----Original Message----- From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> On Behalf Of Olivier Deprez via Hafnium Sent: Sunday, February 28, 2021 7:02 AM To: hafnium(a)lists.trustedfirmware.org; 胤桦陈 <yinhua_chen(a)outlook.com> Subject: Re: [Hafnium] Trying to load two OPTEEs on hafnium Hi, For the first problem: on the FVP platform, Hafnium (SPMC) and Secure Partitions are meant to reside in the "32MB Trusted DRAM" region (0x6000000-0x7ffffff). The memory node in SPMC manifest describes the (collection of) system memory range(s) that the SPMC and SPs are allowed to use. This region is always marked secure on this platform. Using other regions is possible provided they're marked as secure (e.g. by the TZC400 controller) and declared in the memory node (list of start addresses and sizes). For the second problem: the Hafnium code base used in this sample is rather old and the properties specified in the SPMC manifest are different for the first and other SPs. The first SP fixes vCPU count to number of PEs and maps the full system memory. Other SPs must declare the number of vCPUs and SP memory size in the manifest (https://review.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/HEAD/d…) In your sample case you need: vm2 { is_ffa_partition; debug_name = "op-tee2"; load_address = <0x7280000>; smc_whitelist = <0xce000000>; vcpu_count = <8>; mem_size = <1048576>; }; Using recent Hafnium master, all SPs including the first one declare a vCPU count and SP size in the manifest (http://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/arm/bo…) Note you'd also want to use different UUIDs for both partitions. You can get more details on secure partitions loading from https://trustedfirmware-a.readthedocs.io/en/latest/components/secure-partit… On the rationale for this experiment: Hafnium effectively supports booting multiple partitions. OP-TEE has a build option to run as a single SP on top of the SPMC. A configuration with multiple OP-TEE instances is valid although (to my knowledge) this probably lacks the appropriate OP-TEE support and has never been tested. It may be good understanding your use case better, whether you wish to strictly demo the Hafnium multiple partitions support, or you really need to bring up multiple OP-TEE instances. In other words, would it be enough to host services in bare metal SPs? Would a single OP-TEE partition (redirecting FF-A messages to Trusted Applications implementing secure services) also be acceptable? Regards, Olivier. ________________________________________ From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of 胤桦陈 via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: 27 February 2021 04:11 To: raghu.ncstate(a)icloud.com; hafnium(a)lists.trustedfirmware.org Subject: Re: [Hafnium] Trying to load two OPTEEs on hafnium Hi raghu, For the second problem, the memory range is set by myself. The corresponding property is memory@6000000 { device_type = "memory"; reg = <0x0 0x6000000 0x5000000>; /* Trusted DRAM */ }; in the file fvp_spmc_optee_sp_manifest.dts. The original setting is reg = <0x0 0x6000000 0x2000000>. Since I find that OPTEE only works fine when loaded at address between 0x6000000 and 0x2000000, I guess the reason is that 0x9280000 is not in the "Trusted DRAM", so I try to reset it to reg = <0x0 0x6000000 0x5000000>. However, it seems not to be the solution. And, I try to load OPTEE at 0x7281000 and it works fine, no matter with reg = <0x0 0x6000000 0x2000000> or reg = <0x0 0x6000000 0x5000000>. Appreciate for your help. Sincerely, Yinhua ________________________________ From: raghu.ncstate(a)icloud.com <raghu.ncstate(a)icloud.com> Sent: Saturday, February 27, 2021 2:40 To: 'Manish Pandey2' <Manish.Pandey2(a)arm.com>; hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org>; '胤桦陈' <yinhua_chen(a)outlook.com> Subject: RE: [Hafnium] Trying to load two OPTEEs on hafnium Yep, I was just about to reply. First problem is likely because of loading at 0x9280000. For the second problem, I see “INFO: Memory range: 0x6000000 - 0xaffffff”. On a good run, it should show the memory range as 0x6000000 – 0x7FFFFFF(see the long in your original email). So either your spmc manifest is incorrect or there is something overwriting the memory location of manifest, which may or may not be related to a problem, but needs to be addressed anyway Would it be possible to run a single OPTEE but loaded at 0x7281000 and see if it works fine? That would also give another data point to diagnose the issue. From: Manish Pandey2 <Manish.Pandey2(a)arm.com> Sent: Friday, February 26, 2021 10:14 AM To: raghu.ncstate(a)icloud.com; hafnium(a)lists.trustedfirmware.org; 胤桦陈 <yinhua_chen(a)outlook.com> Subject: Re: [Hafnium] Trying to load two OPTEEs on hafnium Hi Yinhua, I reproduced the first problem at my end, please find my analysis below If you look at FVP memory map https://developer.arm.com/documentation/100966/1111-00/Arm-Neoverse-referen… address 0x9280000 is part of NOR flash which is read-only. Ideally this should have been mapped as RO in BL2's page table, but it is currently mapped as RW at plat/arm/board/fvp/fvp_common.c +83 (mostly a bug, will investigate it) I did a quick experiment and changed this mapping to RO and system stuck while loading SP INFO: Loading image id=34 at address 0x9280000 INFO: Image id=34 loaded: 0x9280000 - 0x92e2050 What's happening is, BL2 writes at RO area and thinks that write has been successful and when hafnium tries to match the SP MAGIC it fails. Will try to investigate your second problem on Monday and let you know. Thanks Manish ________________________________ From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org<mailto:hafnium-bounces@lists.trustedfirmware.org>> on behalf of 胤桦陈 via Hafnium <hafnium(a)lists.trustedfirmware.org<mailto:hafnium@lists.trustedfirmware.org>> Sent: 26 February 2021 08:59 To: raghu.ncstate(a)icloud.com<mailto:raghu.ncstate@icloud.com> <raghu.ncstate(a)icloud.com<mailto:raghu.ncstate@icloud.com>>; hafnium(a)lists.trustedfirmware.org<mailto:hafnium@lists.trustedfirmware.org> <hafnium(a)lists.trustedfirmware.org<mailto:hafnium@lists.trustedfirmware.org>> Subject: Re: [Hafnium] Trying to load two OPTEEs on hafnium This is the part "My effort and logs for the second problem" ================================My effort and logs for the second problem=================================== 1. copy the optee_os directory: cp -r <path-to-workspace>/optee_os <path-to-workspace>/optee_os2 mv <path-to-workspace>/optee_os <path-to-workspace>/optee_os1 2. Set both OPTEE's conf.mk file In the file <path-to-workspace>/optee_os1/core/arch/arm/plat-vexpress/conf.mk set CFG_TZDRAM_START ?=0x06281000 In the file <path-to-workspace>/optee_os2/core/arch/arm/plat-vexpress/conf.mk set CFG_TZDRAM_START ?=0x07281000 3. Set both OPTEE's optee_sp_manifest.dts cp <path-to-workspace>/trusted-firmware-a/fdts/optee_sp_manifest.dts <path-to-workspace>/trusted-firmware-a/fdts/optee2_sp_manifest.dts mv <path-to-workspace>/trusted-firmware-a/fdts/optee_sp_manifest.dts <path-to-workspace>/trusted-firmware-a/fdts/optee1_sp_manifest.dts In the file <path-to-workspace>/trusted-firmware-a/fdts/optee1_sp_manifest.dts set id = <1>; load-address = <0x6280000>; In the file <path-to-workspace>/trusted-firmware-a/fdts/optee2_sp_manifest.dts set id = <2>; load-address = <0x7280000>; 4. In the file <path-to-workspace>/trusted-firmware-a/plat/arm/board/fvp/fdts/fvp_spmc_optee_sp_manifest.dts Set "hypervisor" node like following hypervisor { compatible = "hafnium,hafnium"; vm1 { is_ffa_partition; debug_name = "op-tee1"; load_address = <0x6280000>; smc_whitelist = <0xbe000000>; }; vm2 { is_ffa_partition; debug_name = "op-tee2"; load_address = <0x7280000>; smc_whitelist = <0xce000000>; }; }; 5. In the file <path-to-workspace>/trusted-firmware-a/plat/arm/board/fvp/fdts/fvp_tb_fw_config.dts Set "secure-partitions" node like following secure-partitions { compatible = "arm,sp"; #ifdef OPTEE_SP_FW_CONFIG op-tee1 { uuid = <0x486178e0 0xe7f811e3 0xbc5e0002 0xa5d5c51b>; load-address = <0x6280000>; }; op-tee2 { uuid = <0x486178e0 0xe7f811e3 0xbc5e0002 0xa5d5c51b>; load-address = <0x7280000>; }; #else . . (cactus) . #endif }; 6. Compile OPTEE1 and OPTEE2 7. Compile ATF 8. Run FVP Logs from fvp-uart0.log (fvp-uart1.log is empty) NOTICE: Booting Trusted Firmware NOTICE: BL1: v2.4(debug):v2.4-79-gb4b23c780-dirty NOTICE: BL1: Built : 15:36:13, Feb 26 2021 INFO: BL1: RAM 0x4035000 - 0x403c000 INFO: Loading image id=31 at address 0x4001010 INFO: Image id=31 loaded: 0x4001010 - 0x4001234 INFO: FCONF: Config file with image ID:31 loaded at address = 0x4001010 INFO: Loading image id=24 at address 0x4001300 INFO: Image id=24 loaded: 0x4001300 - 0x40014a2 INFO: FCONF: Config file with image ID:24 loaded at address = 0x4001300 INFO: BL1: Loading BL2 INFO: Loading image id=1 at address 0x4022000 INFO: Image id=1 loaded: 0x4022000 - 0x402bb49 NOTICE: BL1: Booting BL2 INFO: Entry point address = 0x4022000 INFO: SPSR = 0x3c5 INFO: FCONF: Reading FW_CONFIG firmware configuration file from: 0x4001010 INFO: FCONF: Reading firmware configuration information for: dyn_cfg INFO: FCONF: Reading TB_FW firmware configuration file from: 0x4001300 INFO: FCONF: Reading firmware configuration information for: arm_sp NOTICE: BL2: v2.4(debug):v2.4-79-gb4b23c780-dirty NOTICE: BL2: Built : 15:36:16, Feb 26 2021 INFO: BL2: Doing platform setup INFO: Configuring TrustZone Controller INFO: Total 4 regions set. INFO: BL2: Loading image id 3 INFO: Loading image id=3 at address 0x4003000 INFO: Image id=3 loaded: 0x4003000 - 0x401722c INFO: BL2: Loading image id 23 INFO: Loading image id=23 at address 0x82000000 INFO: Image id=23 loaded: 0x82000000 - 0x82002348 INFO: BL2: Loading image id 25 INFO: Loading image id=25 at address 0x4001300 INFO: Image id=25 loaded: 0x4001300 - 0x4001348 INFO: BL2: Loading image id 4 INFO: Loading image id=4 at address 0x6000000 INFO: Image id=4 loaded: 0x6000000 - 0x601e250 INFO: BL2: Skip loading image id 21 INFO: BL2: Skip loading image id 22 INFO: BL2: Loading image id 26 INFO: Loading image id=26 at address 0x4001500 INFO: Image id=26 loaded: 0x4001500 - 0x4001b1b INFO: BL2: Loading image id 5 INFO: Loading image id=5 at address 0x88000000 INFO: Image id=5 loaded: 0x88000000 - 0x8800b2b0 INFO: BL2: Loading image id 34 INFO: Loading image id=34 at address 0x6280000 INFO: Image id=34 loaded: 0x6280000 - 0x62e2050 INFO: BL2: Loading image id 35 INFO: Loading image id=35 at address 0x7280000 INFO: Image id=35 loaded: 0x7280000 - 0x72e2050 NOTICE: BL1: Booting BL31 INFO: Entry point address = 0x4003000 INFO: SPSR = 0x3cd INFO: FCONF: Reading HW_CONFIG firmware configuration file from: 0x82000000 INFO: FCONF: Reading firmware configuration information for: cpu_timer INFO: FCONF: Reading firmware configuration information for: uart_config INFO: FCONF: Reading firmware configuration information for: topology INFO: FCONF: Reading firmware configuration information for: gicv3_config NOTICE: BL31: v2.4(debug):v2.4-79-gb4b23c780-dirty NOTICE: BL31: Built : 15:36:21, Feb 26 2021 INFO: GICv3 with legacy support detected. INFO: ARM GICv3 driver initialized in EL3 INFO: BL31: Initializing runtime services INFO: SPM Core setup done. INFO: BL31: Initializing BL32 NOTICE: Initialising hafnium INFO: text: 0x6000000 - 0x601a000 INFO: rodata: 0x601a000 - 0x601e000 INFO: data: 0x601e000 - 0x60a0000 INFO: Supported bits in physical address: 40 INFO: Stage 2 has 3 page table levels with 2 pages at the root. INFO: SPM: 0x84000069 0x0 0x0 0x0 0x0 0x0 0x0 0x0 INFO: Memory range: 0x6000000 - 0xaffffff INFO: Valid SP package magic. the valid magic number is 0x474b5053 Panic: Could not parse manifest: Property not found. ====================================================================== Now I am trying to be deep into the code to solve the problems by myself. But if anyone have any idea, I appreciate for your sharing. Sincerely, Yinhua ________________________________ From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org<mailto:hafnium-bounces@lists.trustedfirmware.org>> on behalf of 胤桦陈 via Hafnium <hafnium(a)lists.trustedfirmware.org<mailto:hafnium@lists.trustedfirmware.org>> Sent: Friday, February 26, 2021 16:48 To: raghu.ncstate(a)icloud.com<mailto:raghu.ncstate@icloud.com> <raghu.ncstate(a)icloud.com<mailto:raghu.ncstate@icloud.com>>; hafnium(a)lists.trustedfirmware.org<mailto:hafnium@lists.trustedfirmware.org> <hafnium(a)lists.trustedfirmware.org<mailto:hafnium@lists.trustedfirmware.org>> Subject: Re: [Hafnium] Trying to load two OPTEEs on hafnium Hi raghu, Thanks for your guidance! I have never heard of fvp_tb_fw_config.dts before! I will spend much more of time on solving my problems without your help! Now I can load one OPTEE on at addresses between 0x6000000 and 0x8000000 successfully. Now I meet two problems, I am trying to be deep into the code to solve the problems by myself. But if you have any idea, I appreciate for your sharing. Two Problems I met: 1. If I load the OPTEE at address not between 0x6000000 and 0x8000000, like 0x9280000, then there will be error "Invalid SP package magic". 2. I try to load two OPTEEs, the first at address 0x6280000, the second at address 0x7280000, and there is an error "Panic: Could not parse manifest: Property not found." My effort and the detailed logs are as follows. ==================================My effort and logs for the first problem==================================== 1. In the file <path-to-workspace>/optee_os/core/arch/arm/plat-vexpress/conf.mk change "CFG_TZDRAM_START ?=0x06281000" to "CFG_TZDRAM_START ?= 0x09281000" 2. In the file <path-to-workspace>/trusted-firmware-a/fdts/optee_sp_manifest.dts change "load-address = <0x6280000>" to "load-address = <0x9280000>" 3. In the file <path-to-workspace>/trusted-firmware-a/plat/arm/board/fvp/fdts/fvp_tb_fw_config.dts change load-address of op-tee from 0x6280000 to 0x9280000 4. In the file <path-to-workspace>/trusted-firmware-a/plat/arm/board/fvp/fdts/fvp_spmc_optee_sp_manifest.dts change load_address of vm1 from 0x6280000 to 0x9280000 5. Compile OPTEE CROSS_COMPILE64=aarch64-none-elf- PLATFORM=vexpress PLATFORM_FLAVOR=fvp CFG_ARM_GICV3=y CFG_CORE_SEL2_SPMC=y CFG_ARM64_core=y CFG_USER_TA_TARGETS=ta_arm64 CFG_TEE_CORE_DEBUG=y CFG_TEE_CORE_LOG_LEVEL=4 CFG_TEE_BENCHMARK=n CFG_WITH_STATS=y make 6. Compile ATF make CROSS_COMPILE=aarch64-none-elf- SPD=spmd CTX_INCLUDE_EL2_REGS=1 PLAT=fvp BL33=../tf-a-tests/build/fvp/debug/tftf.bin DEBUG=1 BL32=../hafnium/out/reference/secure_aem_v8a_fvp_clang/hafnium.bin ARM_ARCH_MINOR=4 SP_LAYOUT_FILE=sp_layout.json ARM_SPMC_MANIFEST_DTS=plat/arm/board/fvp/fdts/fvp_spmc_optee_sp_manifest.dts all fip 7. Run FVP ../fvp/Base_RevC_AEMv8A_pkg/models/Linux64_GCC-6.4/FVP_Base_RevC-2xAEMv8A -C pctl.startup=0.0.0.0 -C cluster0.NUM_CORES=4 -C cluster1.NUM_CORES=4 -C bp.secure_memory=1 -C bp.secureflashloader.fname=trusted-firmware-a/build/fvp/debug/bl1.bin -C bp.flashloader0.fname=trusted-firmware-a/build/fvp/debug/fip.bin -C cluster0.has_arm_v8-4=1 -C cluster1.has_arm_v8-4=1 -C cache_state_modelled=0 -C bp.pl011_uart0.out_file=fvp-uart0.log -C bp.pl011_uart1.out_file=fvp-uart1.log -C bp.vis.disable_visualisation=1 Logs from fvp-uart0.log (fvp-uart1.log is empty) NOTICE: Booting Trusted Firmware NOTICE: BL1: v2.4(debug):v2.4-79-gb4b23c780-dirty NOTICE: BL1: Built : 15:36:13, Feb 26 2021 INFO: BL1: RAM 0x4035000 - 0x403c000 INFO: Loading image id=31 at address 0x4001010 INFO: Image id=31 loaded: 0x4001010 - 0x4001234 INFO: FCONF: Config file with image ID:31 loaded at address = 0x4001010 INFO: Loading image id=24 at address 0x4001300 INFO: Image id=24 loaded: 0x4001300 - 0x4001466 INFO: FCONF: Config file with image ID:24 loaded at address = 0x4001300 INFO: BL1: Loading BL2 INFO: Loading image id=1 at address 0x4022000 INFO: Image id=1 loaded: 0x4022000 - 0x402bb49 NOTICE: BL1: Booting BL2 INFO: Entry point address = 0x4022000 INFO: SPSR = 0x3c5 INFO: FCONF: Reading FW_CONFIG firmware configuration file from: 0x4001010 INFO: FCONF: Reading firmware configuration information for: dyn_cfg INFO: FCONF: Reading TB_FW firmware configuration file from: 0x4001300 INFO: FCONF: Reading firmware configuration information for: arm_sp NOTICE: BL2: v2.4(debug):v2.4-79-gb4b23c780-dirty NOTICE: BL2: Built : 15:36:16, Feb 26 2021 INFO: BL2: Doing platform setup INFO: Configuring TrustZone Controller INFO: Total 4 regions set. INFO: BL2: Loading image id 3 INFO: Loading image id=3 at address 0x4003000 INFO: Image id=3 loaded: 0x4003000 - 0x401722c INFO: BL2: Loading image id 23 INFO: Loading image id=23 at address 0x82000000 INFO: Image id=23 loaded: 0x82000000 - 0x82002348 INFO: BL2: Loading image id 25 INFO: Loading image id=25 at address 0x4001300 INFO: Image id=25 loaded: 0x4001300 - 0x4001348 INFO: BL2: Loading image id 4 INFO: Loading image id=4 at address 0x6000000 INFO: Image id=4 loaded: 0x6000000 - 0x601e250 INFO: BL2: Skip loading image id 21 INFO: BL2: Skip loading image id 22 INFO: BL2: Loading image id 26 INFO: Loading image id=26 at address 0x4001500 INFO: Image id=26 loaded: 0x4001500 - 0x4001acf INFO: BL2: Loading image id 5 INFO: Loading image id=5 at address 0x88000000 INFO: Image id=5 loaded: 0x88000000 - 0x8800b2b0 INFO: BL2: Loading image id 34 INFO: Loading image id=34 at address 0x9280000 INFO: Image id=34 loaded: 0x9280000 - 0x92e2050 NOTICE: BL1: Booting BL31 INFO: Entry point address = 0x4003000 INFO: SPSR = 0x3cd INFO: FCONF: Reading HW_CONFIG firmware configuration file from: 0x82000000 INFO: FCONF: Reading firmware configuration information for: cpu_timer INFO: FCONF: Reading firmware configuration information for: uart_config INFO: FCONF: Reading firmware configuration information for: topology INFO: FCONF: Reading firmware configuration information for: gicv3_config NOTICE: BL31: v2.4(debug):v2.4-79-gb4b23c780-dirty NOTICE: BL31: Built : 15:36:21, Feb 26 2021 INFO: GICv3 with legacy support detected. INFO: ARM GICv3 driver initialized in EL3 INFO: BL31: Initializing runtime services INFO: SPM Core setup done. INFO: BL31: Initializing BL32 NOTICE: Initialising hafnium INFO: text: 0x6000000 - 0x601a000 INFO: rodata: 0x601a000 - 0x601e000 INFO: data: 0x601e000 - 0x60a0000 INFO: Supported bits in physical address: 40 INFO: Stage 2 has 3 page table levels with 2 pages at the root. INFO: SPM: 0x84000069 0x0 0x0 0x0 0x0 0x0 0x0 0x0 INFO: Memory range: 0x6000000 - 0xaffffff ERROR: Invalid SP package magic. the invalid magic number is 0xe7ff0010 Panic: Could not parse manifest: Hypervisor manifest entry not compatible with Hafnium. ================================My effort and logs for the second problem=================================== This part is sent by another email because of the limit of body length ===================================================================================================== Now I am trying to be deep into the code to solve the problems by myself. But if anyone have any idea, I appreciate for your sharing. Sincerely, Yinhua ________________________________ From: raghu.ncstate(a)icloud.com<mailto:raghu.ncstate@icloud.com> <raghu.ncstate(a)icloud.com<mailto:raghu.ncstate@icloud.com>> Sent: Friday, February 26, 2021 5:35 To: yinhua_chen(a)outlook.com<mailto:yinhua_chen@outlook.com> <yinhua_chen(a)outlook.com<mailto:yinhua_chen@outlook.com>>; hafnium(a)lists.trustedfirmware.org<mailto:hafnium@lists.trustedfirmware.org> <hafnium(a)lists.trustedfirmware.org<mailto:hafnium@lists.trustedfirmware.org>> Subject: RE: [Hafnium] Trying to load two OPTEEs on hafnium >From the log it looks like there was nothing loaded at 0x8001000. Possible that you are missing the second entry for OPTEE in the SPMC manifest(fvp_spmc_optee_sp_manifest.dts). Might want to use the sptool to check if both your optee images were packaged. If not, you likely have your answer. If it is present, might want to make sure that fvp_tb_fw_config.dts has an entry for the second OPTEE partition to be loaded by BL2 at 0x8001000. For the partition to run, both OPTEE images have to be loaded by BL2, and both OPTEE images have processed by hafnium during initialization(when it processes the SPMC manifest). Thanks Raghu -----Original Message----- From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org<mailto:hafnium-bounces@lists.trustedfirmware.org>> On Behalf Of yinhua_chen--- via Hafnium Sent: Wednesday, February 24, 2021 7:23 PM To: hafnium(a)lists.trustedfirmware.org<mailto:hafnium@lists.trustedfirmware.org> Subject: [Hafnium] Trying to load two OPTEEs on hafnium Hi all, I am trying to load two OPTEEs on hafnium. Thanks to the help from Hafnium open source community, now I can load one OPTEE on hafnium. The guidance I am following is attached at the end. In the guidance, the OPTEE is loaded at address 0x06280000. I think the first step to load two OPTEEs is to load an OPTEE at an address other than 0x06280000. I tried but failed. If there is anyone who can give me some advice, I would be very grateful. =====================The following is the effort I made=============== # NOTE: make sure gcc-arm-9.2-2019.12-x86_64-aarch64-none-elf/bin is in PATH 1. Loading one OPTEE at address 0x06280000 successfully by following the guidance attached below. 2. In the file <path-to-workspace>/optee_os/core/arch/arm/plat-vexpress/conf.mk change "CFG_TZDRAM_START ?=0x06281000" to "CFG_TZDRAM_START ?= 0x08002000" 3. In the file <path-to-workspace>//trusted-firmware-a/fdts/optee_sp_manifest.dts change "load-address = <0x6280000>" to "load-address = <0x8001000>" 4. Compile OPTEE CROSS_COMPILE64=aarch64-none-elf- PLATFORM=vexpress PLATFORM_FLAVOR=fvp CFG_ARM_GICV3=y CFG_CORE_SEL2_SPMC=y CFG_ARM64_core=y CFG_USER_TA_TARGETS=ta_arm64 CFG_TEE_CORE_DEBUG=y CFG_TEE_CORE_LOG_LEVEL=4 CFG_TEE_BENCHMARK=n CFG_WITH_STATS=y make 5. Compile ATF make CROSS_COMPILE=aarch64-none-elf- SPD=spmd CTX_INCLUDE_EL2_REGS=1 PLAT=fvp BL33=../tf-a-tests/build/fvp/debug/tftf.bin DEBUG=1 BL32=../hafnium/out/reference/secure_aem_v8a_fvp_clang/hafnium.bin ARM_ARCH_MINOR=4 SP_LAYOUT_FILE=sp_layout.json ARM_SPMC_MANIFEST_DTS=plat/arm/board/fvp/fdts/fvp_spmc_optee_sp_manifest.dts all fip 6. Run FVP ../fvp/Base_RevC_AEMv8A_pkg/models/Linux64_GCC-6.4/FVP_Base_RevC-2xAEMv8A -C pctl.startup=0.0.0.0 -C cluster0.NUM_CORES=4 -C cluster1.NUM_CORES=4 -C bp.secure_memory=1 -C bp.secureflashloader.fname=trusted-firmware-a/build/fvp/debug/bl1.bin -C bp.flashloader0.fname=trusted-firmware-a/build/fvp/debug/fip.bin -C cluster0.has_arm_v8-4=1 -C cluster1.has_arm_v8-4=1 -C cache_state_modelled=0 -C bp.pl011_uart0.out_file=fvp-uart0.log -C bp.pl011_uart1.out_file=fvp-uart1.log -C bp.vis.disable_visualisation=1 7. The error message from fvp-uart0.log (fvp-uart1.log is empty) NOTICE: Booting Trusted Firmware NOTICE: BL1: v2.4(debug):v2.4-79-gb4b23c780-dirty NOTICE: BL1: Built : 09:39:24, Feb 25 2021 INFO: BL1: RAM 0x4035000 - 0x403c000 INFO: Loading image id=31 at address 0x4001010 INFO: Image id=31 loaded: 0x4001010 - 0x4001234 INFO: FCONF: Config file with image ID:31 loaded at address = 0x4001010 INFO: Loading image id=24 at address 0x4001300 INFO: Image id=24 loaded: 0x4001300 - 0x4001466 INFO: FCONF: Config file with image ID:24 loaded at address = 0x4001300 INFO: BL1: Loading BL2 INFO: Loading image id=1 at address 0x4022000 INFO: Image id=1 loaded: 0x4022000 - 0x402bb49 NOTICE: BL1: Booting BL2 INFO: Entry point address = 0x4022000 INFO: SPSR = 0x3c5 INFO: FCONF: Reading FW_CONFIG firmware configuration file from: 0x4001010 INFO: FCONF: Reading firmware configuration information for: dyn_cfg INFO: FCONF: Reading TB_FW firmware configuration file from: 0x4001300 INFO: FCONF: Reading firmware configuration information for: arm_sp NOTICE: BL2: v2.4(debug):v2.4-79-gb4b23c780-dirty NOTICE: BL2: Built : 09:39:26, Feb 25 2021 INFO: BL2: Doing platform setup INFO: Configuring TrustZone Controller INFO: Total 4 regions set. INFO: BL2: Loading image id 3 INFO: Loading image id=3 at address 0x4003000 INFO: Image id=3 loaded: 0x4003000 - 0x401722c INFO: BL2: Loading image id 23 INFO: Loading image id=23 at address 0x82000000 INFO: Image id=23 loaded: 0x82000000 - 0x82002348 INFO: BL2: Loading image id 25 INFO: Loading image id=25 at address 0x4001300 INFO: Image id=25 loaded: 0x4001300 - 0x4001348 INFO: BL2: Loading image id 4 INFO: Loading image id=4 at address 0x6000000 INFO: Image id=4 loaded: 0x6000000 - 0x601e250 INFO: BL2: Skip loading image id 21 INFO: BL2: Skip loading image id 22 INFO: BL2: Loading image id 26 INFO: Loading image id=26 at address 0x4001500 INFO: Image id=26 loaded: 0x4001500 - 0x4001acf INFO: BL2: Loading image id 5 INFO: Loading image id=5 at address 0x88000000 INFO: Image id=5 loaded: 0x88000000 - 0x8800b2b0 INFO: BL2: Loading image id 34 INFO: Loading image id=34 at address 0x6280000 INFO: Image id=34 loaded: 0x6280000 - 0x62e2050 NOTICE: BL1: Booting BL31 INFO: Entry point address = 0x4003000 INFO: SPSR = 0x3cd INFO: FCONF: Reading HW_CONFIG firmware configuration file from: 0x82000000 INFO: FCONF: Reading firmware configuration information for: cpu_timer INFO: FCONF: Reading firmware configuration information for: uart_config INFO: FCONF: Reading firmware configuration information for: topology INFO: FCONF: Reading firmware configuration information for: gicv3_config NOTICE: BL31: v2.4(debug):v2.4-79-gb4b23c780-dirty NOTICE: BL31: Built : 09:39:31, Feb 25 2021 INFO: GICv3 with legacy support detected. INFO: ARM GICv3 driver initialized in EL3 INFO: BL31: Initializing runtime services INFO: SPM Core setup done. INFO: BL31: Initializing BL32 NOTICE: Initialising hafnium INFO: text: 0x6000000 - 0x601a000 INFO: rodata: 0x601a000 - 0x601e000 INFO: data: 0x601e000 - 0x60a0000 INFO: Supported bits in physical address: 40 INFO: Stage 2 has 3 page table levels with 2 pages at the root. INFO: SPM: 0x84000069 0x0 0x0 0x0 0x0 0x0 0x0 0x0 INFO: Memory range: 0x6000000 - 0x7ffffff INFO: SPM: 0x8400006f 0xffffffff8000ffff 0x0 0x1 0x0 0x6001340 0x601e000 0x0 INFO: In case FFA_MSG_SEND_DIRECT_REQ_SMC32, branch1 (this message is added by myself) INFO: SPM: 0x8400006f 0xffffffff8000ffff 0x0 0x1 0x10300 0x6001340 0x601e0a8 0x0 INFO: In case FFA_MSG_SEND_DIRECT_REQ_SMC32, branch1 (this message is added by myself) INFO: SPM: 0x8400006f 0xffffffff8000ffff 0x0 0x1 0x10200 0x6001340 0x601e090 0x0 INFO: In case FFA_MSG_SEND_DIRECT_REQ_SMC32, branch1 (this message is added by myself) INFO: SPM: 0x8400006f 0xffffffff8000ffff 0x0 0x1 0x10100 0x6001340 0x601e078 0x0 INFO: In case FFA_MSG_SEND_DIRECT_REQ_SMC32, branch1 (this message is added by myself) INFO: SPM: 0x8400006f 0xffffffff8000ffff 0x0 0x1 0x10000 0x6001340 0x601e060 0x0 INFO: In case FFA_MSG_SEND_DIRECT_REQ_SMC32, branch1 (this message is added by myself) INFO: SPM: 0x8400006f 0xffffffff8000ffff 0x0 0x1 0x300 0x6001340 0x601e048 0x0 INFO: In case FFA_MSG_SEND_DIRECT_REQ_SMC32, branch1 (this message is added by myself) INFO: SPM: 0x8400006f 0xffffffff8000ffff 0x0 0x1 0x200 0x6001340 0x601e030 0x0 INFO: In case FFA_MSG_SEND_DIRECT_REQ_SMC32, branch1 (this message is added by myself) INFO: SPM: 0x8400006f 0xffffffff8000ffff 0x0 0x1 0x100 0x6001340 0x601e018 0x0 INFO: In case FFA_MSG_SEND_DIRECT_REQ_SMC32, branch1 (this message is added by myself) INFO: Loaded primary VM with 8 vCPUs, entry at 0x8001000. INFO: Hafnium initialisation completed WARNING: Stage-2 page fault: pc=0x8002000, vmid=32769, vcpu=0, vaddr=0x8002000, ipaddr=0x0, mode=0x4 NOTICE: Injecting Instruction Abort exception into VM32769. WARNING: Stage-2 page fault: pc=0x200, vmid=32769, vcpu=0, vaddr=0x200, ipaddr=0x200, mode=0x4 NOTICE: Injecting Instruction Abort exception into VM32769. WARNING: Stage-2 page fault: pc=0x200, vmid=32769, vcpu=0, vaddr=0x200, ipaddr=0x200, mode=0x4 NOTICE: Injecting Instruction Abort exception into VM32769. WARNING: Stage-2 page fault: pc=0x200, vmid=32769, vcpu=0, vaddr=0x200, ipaddr=0x200, mode=0x4 NOTICE: Injecting Instruction Abort exception into VM32769. . . . (infinite loop . . .) ============The guidance from Oliver Deprez to load one OPTEE============ # NOTE: make sure gcc-arm-9.2-2019.12-x86_64-aarch64-none-elf/bin is in PATH mkdir workspace; cd workspace # Hafnium # https://review.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/HEAD/d… git clone https://git.trustedfirmware.org/hafnium/hafnium.git; cd hafnium git fetch "https://review.trustedfirmware.org/hafnium/hafnium" refs/changes/11/6011/16 && git checkout FETCH_HEAD git checkout -b spmc git submodule update --init make PROJECT=reference cd .. # OPTEE # https://optee.readthedocs.io/en/latest/building/prerequisites.html#prerequi… git clone https://git.trustedfirmware.org/OP-TEE/optee_os.git -b ffa_rel_proto; cd optee_os # Adjust TEE start address perl -pi -e 's/CFG_TZDRAM_START \?= 0x06280000/CFG_TZDRAM_START \?= 0x06281000/' core/arch/arm/plat-vexpress/conf.mk CROSS_COMPILE64=aarch64-none-elf- PLATFORM=vexpress PLATFORM_FLAVOR=fvp CFG_ARM_GICV3=y CFG_CORE_SEL2_SPMC=y CFG_ARM64_core=y CFG_USER_TA_TARGETS=ta_arm64 CFG_TEE_CORE_DEBUG=y CFG_TEE_CORE_LOG_LEVEL=4 CFG_TEE_BENCHMARK=n CFG_WITH_STATS=y make cd .. # TF-A-tests git clone https://git.trustedfirmware.org/TF-A/tf-a-tests.git; cd tf-a-tests make CROSS_COMPILE=aarch64-none-elf- PLAT=fvp DEBUG=1 TESTS=spm -j4 cd .. # TF-A # git clone https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git; cd trusted-firmware-a git checkout b4b23c780c0763ce01ac21de1a0e79287677405f -b spmc #{ # "op-tee" : { # "image": "../optee_os/out/arm-plat-vexpress/core/tee-pager_v2.bin", # "pm": "fdts/optee_sp_manifest.dts" # } #} echo \ "{ \ \"op-tee\" : { \ \"image\": \"../optee_os/out/arm-plat-vexpress/core/tee-pager_v2.bin\", \ \"pm\": \"fdts/optee_sp_manifest.dts\" \ } }" > sp_layout.json make CROSS_COMPILE=aarch64-none-elf- SPD=spmd CTX_INCLUDE_EL2_REGS=1 PLAT=fvp BL33=../tf-a-tests/build/fvp/debug/tftf.bin DEBUG=1 BL32=../hafnium/out/reference/secure_aem_v8a_fvp_clang/hafnium.bin ARM_ARCH_MINOR=4 SP_LAYOUT_FILE=sp_layout.json ARM_SPMC_MANIFEST_DTS=plat/arm/board/fvp/fdts/fvp_spmc_optee_sp_manifest.dts all fip cd .. # Run FVP ../fvp/Base_RevC_AEMv8A_pkg/models/Linux64_GCC-6.4/FVP_Base_RevC-2xAEMv8A -C pctl.startup=0.0.0.0 -C cluster0.NUM_CORES=4 -C cluster1.NUM_CORES=4 -C bp.secure_memory=1 -C bp.secureflashloader.fname=trusted-firmware-a/build/fvp/debug/bl1.bin -C bp.flashloader0.fname=trusted-firmware-a/build/fvp/debug/fip.bin -C cluster0.has_arm_v8-4=1 -C cluster1.has_arm_v8-4=1 -C cache_state_modelled=0 -C bp.pl011_uart0.out_file=fvp-uart0.log -C bp.pl011_uart1.out_file=fvp-uart1.log -C bp.vis.disable_visualisation=1 ============================= I appreciate for any possible help! Thanks Yinhua -- 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<mailto:Hafnium@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/hafnium

4 years, 2 months

2
2
0 0

Re: [Hafnium] Trying to load two OPTEEs on hafnium

by Olivier Deprez

Hi, For the first problem: on the FVP platform, Hafnium (SPMC) and Secure Partitions are meant to reside in the "32MB Trusted DRAM" region (0x6000000-0x7ffffff). The memory node in SPMC manifest describes the (collection of) system memory range(s) that the SPMC and SPs are allowed to use. This region is always marked secure on this platform. Using other regions is possible provided they're marked as secure (e.g. by the TZC400 controller) and declared in the memory node (list of start addresses and sizes). For the second problem: the Hafnium code base used in this sample is rather old and the properties specified in the SPMC manifest are different for the first and other SPs. The first SP fixes vCPU count to number of PEs and maps the full system memory. Other SPs must declare the number of vCPUs and SP memory size in the manifest (https://review.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/HEAD/d…) In your sample case you need: vm2 { is_ffa_partition; debug_name = "op-tee2"; load_address = <0x7280000>; smc_whitelist = <0xce000000>; vcpu_count = <8>; mem_size = <1048576>; }; Using recent Hafnium master, all SPs including the first one declare a vCPU count and SP size in the manifest (http://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/arm/bo…) Note you'd also want to use different UUIDs for both partitions. You can get more details on secure partitions loading from https://trustedfirmware-a.readthedocs.io/en/latest/components/secure-partit… On the rationale for this experiment: Hafnium effectively supports booting multiple partitions. OP-TEE has a build option to run as a single SP on top of the SPMC. A configuration with multiple OP-TEE instances is valid although (to my knowledge) this probably lacks the appropriate OP-TEE support and has never been tested. It may be good understanding your use case better, whether you wish to strictly demo the Hafnium multiple partitions support, or you really need to bring up multiple OP-TEE instances. In other words, would it be enough to host services in bare metal SPs? Would a single OP-TEE partition (redirecting FF-A messages to Trusted Applications implementing secure services) also be acceptable? Regards, Olivier. ________________________________________ From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of ط�� via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: 27 February 2021 04:11 To: raghu.ncstate(a)icloud.com; hafnium(a)lists.trustedfirmware.org Subject: Re: [Hafnium] Trying to load two OPTEEs on hafnium Hi raghu, For the second problem, the memory range is set by myself. The corresponding property is memory@6000000 { device_type = "memory"; reg = <0x0 0x6000000 0x5000000>; /* Trusted DRAM */ }; in the file fvp_spmc_optee_sp_manifest.dts. The original setting is reg = <0x0 0x6000000 0x2000000>. Since I find that OPTEE only works fine when loaded at address between 0x6000000 and 0x2000000, I guess the reason is that 0x9280000 is not in the "Trusted DRAM", so I try to reset it to reg = <0x0 0x6000000 0x5000000>. However, it seems not to be the solution. And, I try to load OPTEE at 0x7281000 and it works fine, no matter with reg = <0x0 0x6000000 0x2000000> or reg = <0x0 0x6000000 0x5000000>. Appreciate for your help. Sincerely, Yinhua ________________________________ From: raghu.ncstate(a)icloud.com <raghu.ncstate(a)icloud.com> Sent: Saturday, February 27, 2021 2:40 To: 'Manish Pandey2' <Manish.Pandey2(a)arm.com>; hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org>; 'ط�� ' <yinhua_chen(a)outlook.com> Subject: RE: [Hafnium] Trying to load two OPTEEs on hafnium Yep, I was just about to reply. First problem is likely because of loading at 0x9280000. For the second problem, I see ��INFO: Memory range: 0x6000000 - 0xaffffff��. On a good run, it should show the memory range as 0x6000000 �C 0x7FFFFFF(see the long in your original email). So either your spmc manifest is incorrect or there is something overwriting the memory location of manifest, which may or may not be related to a problem, but needs to be addressed anyway Would it be possible to run a single OPTEE but loaded at 0x7281000 and see if it works fine? That would also give another data point to diagnose the issue. From: Manish Pandey2 <Manish.Pandey2(a)arm.com> Sent: Friday, February 26, 2021 10:14 AM To: raghu.ncstate(a)icloud.com; hafnium(a)lists.trustedfirmware.org; ط�� <yinhua_chen(a)outlook.com> Subject: Re: [Hafnium] Trying to load two OPTEEs on hafnium Hi Yinhua, I reproduced the first problem at my end, please find my analysis below If you look at FVP memory map https://developer.arm.com/documentation/100966/1111-00/Arm-Neoverse-referen… address 0x9280000 is part of NOR flash which is read-only. Ideally this should have been mapped as RO in BL2's page table, but it is currently mapped as RW at plat/arm/board/fvp/fvp_common.c +83 (mostly a bug, will investigate it) I did a quick experiment and changed this mapping to RO and system stuck while loading SP INFO: Loading image id=34 at address 0x9280000 INFO: Image id=34 loaded: 0x9280000 - 0x92e2050 What's happening is, BL2 writes at RO area and thinks that write has been successful and when hafnium tries to match the SP MAGIC it fails. Will try to investigate your second problem on Monday and let you know. Thanks Manish ________________________________ From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org<mailto:hafnium-bounces@lists.trustedfirmware.org>> on behalf of ط�� via Hafnium <hafnium(a)lists.trustedfirmware.org<mailto:hafnium@lists.trustedfirmware.org>> Sent: 26 February 2021 08:59 To: raghu.ncstate(a)icloud.com<mailto:raghu.ncstate@icloud.com> <raghu.ncstate(a)icloud.com<mailto:raghu.ncstate@icloud.com>>; hafnium(a)lists.trustedfirmware.org<mailto:hafnium@lists.trustedfirmware.org> <hafnium(a)lists.trustedfirmware.org<mailto:hafnium@lists.trustedfirmware.org>> Subject: Re: [Hafnium] Trying to load two OPTEEs on hafnium This is the part "My effort and logs for the second problem" ================================My effort and logs for the second problem=================================== 1. copy the optee_os directory: cp -r <path-to-workspace>/optee_os <path-to-workspace>/optee_os2 mv <path-to-workspace>/optee_os <path-to-workspace>/optee_os1 2. Set both OPTEE's conf.mk file In the file <path-to-workspace>/optee_os1/core/arch/arm/plat-vexpress/conf.mk set CFG_TZDRAM_START ?=0x06281000 In the file <path-to-workspace>/optee_os2/core/arch/arm/plat-vexpress/conf.mk set CFG_TZDRAM_START ?=0x07281000 3. Set both OPTEE's optee_sp_manifest.dts cp <path-to-workspace>/trusted-firmware-a/fdts/optee_sp_manifest.dts <path-to-workspace>/trusted-firmware-a/fdts/optee2_sp_manifest.dts mv <path-to-workspace>/trusted-firmware-a/fdts/optee_sp_manifest.dts <path-to-workspace>/trusted-firmware-a/fdts/optee1_sp_manifest.dts In the file <path-to-workspace>/trusted-firmware-a/fdts/optee1_sp_manifest.dts set id = <1>; load-address = <0x6280000>; In the file <path-to-workspace>/trusted-firmware-a/fdts/optee2_sp_manifest.dts set id = <2>; load-address = <0x7280000>; 4. In the file <path-to-workspace>/trusted-firmware-a/plat/arm/board/fvp/fdts/fvp_spmc_optee_sp_manifest.dts Set "hypervisor" node like following hypervisor { compatible = "hafnium,hafnium"; vm1 { is_ffa_partition; debug_name = "op-tee1"; load_address = <0x6280000>; smc_whitelist = <0xbe000000>; }; vm2 { is_ffa_partition; debug_name = "op-tee2"; load_address = <0x7280000>; smc_whitelist = <0xce000000>; }; }; 5. In the file <path-to-workspace>/trusted-firmware-a/plat/arm/board/fvp/fdts/fvp_tb_fw_config.dts Set "secure-partitions" node like following secure-partitions { compatible = "arm,sp"; #ifdef OPTEE_SP_FW_CONFIG op-tee1 { uuid = <0x486178e0 0xe7f811e3 0xbc5e0002 0xa5d5c51b>; load-address = <0x6280000>; }; op-tee2 { uuid = <0x486178e0 0xe7f811e3 0xbc5e0002 0xa5d5c51b>; load-address = <0x7280000>; }; #else . . (cactus) . #endif }; 6. Compile OPTEE1 and OPTEE2 7. Compile ATF 8. Run FVP Logs from fvp-uart0.log (fvp-uart1.log is empty) NOTICE: Booting Trusted Firmware NOTICE: BL1: v2.4(debug):v2.4-79-gb4b23c780-dirty NOTICE: BL1: Built : 15:36:13, Feb 26 2021 INFO: BL1: RAM 0x4035000 - 0x403c000 INFO: Loading image id=31 at address 0x4001010 INFO: Image id=31 loaded: 0x4001010 - 0x4001234 INFO: FCONF: Config file with image ID:31 loaded at address = 0x4001010 INFO: Loading image id=24 at address 0x4001300 INFO: Image id=24 loaded: 0x4001300 - 0x40014a2 INFO: FCONF: Config file with image ID:24 loaded at address = 0x4001300 INFO: BL1: Loading BL2 INFO: Loading image id=1 at address 0x4022000 INFO: Image id=1 loaded: 0x4022000 - 0x402bb49 NOTICE: BL1: Booting BL2 INFO: Entry point address = 0x4022000 INFO: SPSR = 0x3c5 INFO: FCONF: Reading FW_CONFIG firmware configuration file from: 0x4001010 INFO: FCONF: Reading firmware configuration information for: dyn_cfg INFO: FCONF: Reading TB_FW firmware configuration file from: 0x4001300 INFO: FCONF: Reading firmware configuration information for: arm_sp NOTICE: BL2: v2.4(debug):v2.4-79-gb4b23c780-dirty NOTICE: BL2: Built : 15:36:16, Feb 26 2021 INFO: BL2: Doing platform setup INFO: Configuring TrustZone Controller INFO: Total 4 regions set. INFO: BL2: Loading image id 3 INFO: Loading image id=3 at address 0x4003000 INFO: Image id=3 loaded: 0x4003000 - 0x401722c INFO: BL2: Loading image id 23 INFO: Loading image id=23 at address 0x82000000 INFO: Image id=23 loaded: 0x82000000 - 0x82002348 INFO: BL2: Loading image id 25 INFO: Loading image id=25 at address 0x4001300 INFO: Image id=25 loaded: 0x4001300 - 0x4001348 INFO: BL2: Loading image id 4 INFO: Loading image id=4 at address 0x6000000 INFO: Image id=4 loaded: 0x6000000 - 0x601e250 INFO: BL2: Skip loading image id 21 INFO: BL2: Skip loading image id 22 INFO: BL2: Loading image id 26 INFO: Loading image id=26 at address 0x4001500 INFO: Image id=26 loaded: 0x4001500 - 0x4001b1b INFO: BL2: Loading image id 5 INFO: Loading image id=5 at address 0x88000000 INFO: Image id=5 loaded: 0x88000000 - 0x8800b2b0 INFO: BL2: Loading image id 34 INFO: Loading image id=34 at address 0x6280000 INFO: Image id=34 loaded: 0x6280000 - 0x62e2050 INFO: BL2: Loading image id 35 INFO: Loading image id=35 at address 0x7280000 INFO: Image id=35 loaded: 0x7280000 - 0x72e2050 NOTICE: BL1: Booting BL31 INFO: Entry point address = 0x4003000 INFO: SPSR = 0x3cd INFO: FCONF: Reading HW_CONFIG firmware configuration file from: 0x82000000 INFO: FCONF: Reading firmware configuration information for: cpu_timer INFO: FCONF: Reading firmware configuration information for: uart_config INFO: FCONF: Reading firmware configuration information for: topology INFO: FCONF: Reading firmware configuration information for: gicv3_config NOTICE: BL31: v2.4(debug):v2.4-79-gb4b23c780-dirty NOTICE: BL31: Built : 15:36:21, Feb 26 2021 INFO: GICv3 with legacy support detected. INFO: ARM GICv3 driver initialized in EL3 INFO: BL31: Initializing runtime services INFO: SPM Core setup done. INFO: BL31: Initializing BL32 NOTICE: Initialising hafnium INFO: text: 0x6000000 - 0x601a000 INFO: rodata: 0x601a000 - 0x601e000 INFO: data: 0x601e000 - 0x60a0000 INFO: Supported bits in physical address: 40 INFO: Stage 2 has 3 page table levels with 2 pages at the root. INFO: SPM: 0x84000069 0x0 0x0 0x0 0x0 0x0 0x0 0x0 INFO: Memory range: 0x6000000 - 0xaffffff INFO: Valid SP package magic. the valid magic number is 0x474b5053 Panic: Could not parse manifest: Property not found. ====================================================================== Now I am trying to be deep into the code to solve the problems by myself. But if anyone have any idea, I appreciate for your sharing. Sincerely, Yinhua ________________________________ From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org<mailto:hafnium-bounces@lists.trustedfirmware.org>> on behalf of ط�� via Hafnium <hafnium(a)lists.trustedfirmware.org<mailto:hafnium@lists.trustedfirmware.org>> Sent: Friday, February 26, 2021 16:48 To: raghu.ncstate(a)icloud.com<mailto:raghu.ncstate@icloud.com> <raghu.ncstate(a)icloud.com<mailto:raghu.ncstate@icloud.com>>; hafnium(a)lists.trustedfirmware.org<mailto:hafnium@lists.trustedfirmware.org> <hafnium(a)lists.trustedfirmware.org<mailto:hafnium@lists.trustedfirmware.org>> Subject: Re: [Hafnium] Trying to load two OPTEEs on hafnium Hi raghu, Thanks for your guidance! I have never heard of fvp_tb_fw_config.dts before! I will spend much more of time on solving my problems without your help! Now I can load one OPTEE on at addresses between 0x6000000 and 0x8000000 successfully. Now I meet two problems, I am trying to be deep into the code to solve the problems by myself. But if you have any idea, I appreciate for your sharing. Two Problems I met: 1. If I load the OPTEE at address not between 0x6000000 and 0x8000000, like 0x9280000, then there will be error "Invalid SP package magic". 2. I try to load two OPTEEs, the first at address 0x6280000, the second at address 0x7280000, and there is an error "Panic: Could not parse manifest: Property not found." My effort and the detailed logs are as follows. ==================================My effort and logs for the first problem==================================== 1. In the file <path-to-workspace>/optee_os/core/arch/arm/plat-vexpress/conf.mk change "CFG_TZDRAM_START ?=0x06281000" to "CFG_TZDRAM_START ?= 0x09281000" 2. In the file <path-to-workspace>/trusted-firmware-a/fdts/optee_sp_manifest.dts change "load-address = <0x6280000>" to "load-address = <0x9280000>" 3. In the file <path-to-workspace>/trusted-firmware-a/plat/arm/board/fvp/fdts/fvp_tb_fw_config.dts change load-address of op-tee from 0x6280000 to 0x9280000 4. In the file <path-to-workspace>/trusted-firmware-a/plat/arm/board/fvp/fdts/fvp_spmc_optee_sp_manifest.dts change load_address of vm1 from 0x6280000 to 0x9280000 5. Compile OPTEE CROSS_COMPILE64=aarch64-none-elf- PLATFORM=vexpress PLATFORM_FLAVOR=fvp CFG_ARM_GICV3=y CFG_CORE_SEL2_SPMC=y CFG_ARM64_core=y CFG_USER_TA_TARGETS=ta_arm64 CFG_TEE_CORE_DEBUG=y CFG_TEE_CORE_LOG_LEVEL=4 CFG_TEE_BENCHMARK=n CFG_WITH_STATS=y make 6. Compile ATF make CROSS_COMPILE=aarch64-none-elf- SPD=spmd CTX_INCLUDE_EL2_REGS=1 PLAT=fvp BL33=../tf-a-tests/build/fvp/debug/tftf.bin DEBUG=1 BL32=../hafnium/out/reference/secure_aem_v8a_fvp_clang/hafnium.bin ARM_ARCH_MINOR=4 SP_LAYOUT_FILE=sp_layout.json ARM_SPMC_MANIFEST_DTS=plat/arm/board/fvp/fdts/fvp_spmc_optee_sp_manifest.dts all fip 7. Run FVP ../fvp/Base_RevC_AEMv8A_pkg/models/Linux64_GCC-6.4/FVP_Base_RevC-2xAEMv8A -C pctl.startup=0.0.0.0 -C cluster0.NUM_CORES=4 -C cluster1.NUM_CORES=4 -C bp.secure_memory=1 -C bp.secureflashloader.fname=trusted-firmware-a/build/fvp/debug/bl1.bin -C bp.flashloader0.fname=trusted-firmware-a/build/fvp/debug/fip.bin -C cluster0.has_arm_v8-4=1 -C cluster1.has_arm_v8-4=1 -C cache_state_modelled=0 -C bp.pl011_uart0.out_file=fvp-uart0.log -C bp.pl011_uart1.out_file=fvp-uart1.log -C bp.vis.disable_visualisation=1 Logs from fvp-uart0.log (fvp-uart1.log is empty) NOTICE: Booting Trusted Firmware NOTICE: BL1: v2.4(debug):v2.4-79-gb4b23c780-dirty NOTICE: BL1: Built : 15:36:13, Feb 26 2021 INFO: BL1: RAM 0x4035000 - 0x403c000 INFO: Loading image id=31 at address 0x4001010 INFO: Image id=31 loaded: 0x4001010 - 0x4001234 INFO: FCONF: Config file with image ID:31 loaded at address = 0x4001010 INFO: Loading image id=24 at address 0x4001300 INFO: Image id=24 loaded: 0x4001300 - 0x4001466 INFO: FCONF: Config file with image ID:24 loaded at address = 0x4001300 INFO: BL1: Loading BL2 INFO: Loading image id=1 at address 0x4022000 INFO: Image id=1 loaded: 0x4022000 - 0x402bb49 NOTICE: BL1: Booting BL2 INFO: Entry point address = 0x4022000 INFO: SPSR = 0x3c5 INFO: FCONF: Reading FW_CONFIG firmware configuration file from: 0x4001010 INFO: FCONF: Reading firmware configuration information for: dyn_cfg INFO: FCONF: Reading TB_FW firmware configuration file from: 0x4001300 INFO: FCONF: Reading firmware configuration information for: arm_sp NOTICE: BL2: v2.4(debug):v2.4-79-gb4b23c780-dirty NOTICE: BL2: Built : 15:36:16, Feb 26 2021 INFO: BL2: Doing platform setup INFO: Configuring TrustZone Controller INFO: Total 4 regions set. INFO: BL2: Loading image id 3 INFO: Loading image id=3 at address 0x4003000 INFO: Image id=3 loaded: 0x4003000 - 0x401722c INFO: BL2: Loading image id 23 INFO: Loading image id=23 at address 0x82000000 INFO: Image id=23 loaded: 0x82000000 - 0x82002348 INFO: BL2: Loading image id 25 INFO: Loading image id=25 at address 0x4001300 INFO: Image id=25 loaded: 0x4001300 - 0x4001348 INFO: BL2: Loading image id 4 INFO: Loading image id=4 at address 0x6000000 INFO: Image id=4 loaded: 0x6000000 - 0x601e250 INFO: BL2: Skip loading image id 21 INFO: BL2: Skip loading image id 22 INFO: BL2: Loading image id 26 INFO: Loading image id=26 at address 0x4001500 INFO: Image id=26 loaded: 0x4001500 - 0x4001acf INFO: BL2: Loading image id 5 INFO: Loading image id=5 at address 0x88000000 INFO: Image id=5 loaded: 0x88000000 - 0x8800b2b0 INFO: BL2: Loading image id 34 INFO: Loading image id=34 at address 0x9280000 INFO: Image id=34 loaded: 0x9280000 - 0x92e2050 NOTICE: BL1: Booting BL31 INFO: Entry point address = 0x4003000 INFO: SPSR = 0x3cd INFO: FCONF: Reading HW_CONFIG firmware configuration file from: 0x82000000 INFO: FCONF: Reading firmware configuration information for: cpu_timer INFO: FCONF: Reading firmware configuration information for: uart_config INFO: FCONF: Reading firmware configuration information for: topology INFO: FCONF: Reading firmware configuration information for: gicv3_config NOTICE: BL31: v2.4(debug):v2.4-79-gb4b23c780-dirty NOTICE: BL31: Built : 15:36:21, Feb 26 2021 INFO: GICv3 with legacy support detected. INFO: ARM GICv3 driver initialized in EL3 INFO: BL31: Initializing runtime services INFO: SPM Core setup done. INFO: BL31: Initializing BL32 NOTICE: Initialising hafnium INFO: text: 0x6000000 - 0x601a000 INFO: rodata: 0x601a000 - 0x601e000 INFO: data: 0x601e000 - 0x60a0000 INFO: Supported bits in physical address: 40 INFO: Stage 2 has 3 page table levels with 2 pages at the root. INFO: SPM: 0x84000069 0x0 0x0 0x0 0x0 0x0 0x0 0x0 INFO: Memory range: 0x6000000 - 0xaffffff ERROR: Invalid SP package magic. the invalid magic number is 0xe7ff0010 Panic: Could not parse manifest: Hypervisor manifest entry not compatible with Hafnium. ================================My effort and logs for the second problem=================================== This part is sent by another email because of the limit of body length ===================================================================================================== Now I am trying to be deep into the code to solve the problems by myself. But if anyone have any idea, I appreciate for your sharing. Sincerely, Yinhua ________________________________ From: raghu.ncstate(a)icloud.com<mailto:raghu.ncstate@icloud.com> <raghu.ncstate(a)icloud.com<mailto:raghu.ncstate@icloud.com>> Sent: Friday, February 26, 2021 5:35 To: yinhua_chen(a)outlook.com<mailto:yinhua_chen@outlook.com> <yinhua_chen(a)outlook.com<mailto:yinhua_chen@outlook.com>>; hafnium(a)lists.trustedfirmware.org<mailto:hafnium@lists.trustedfirmware.org> <hafnium(a)lists.trustedfirmware.org<mailto:hafnium@lists.trustedfirmware.org>> Subject: RE: [Hafnium] Trying to load two OPTEEs on hafnium From the log it looks like there was nothing loaded at 0x8001000. Possible that you are missing the second entry for OPTEE in the SPMC manifest(fvp_spmc_optee_sp_manifest.dts). Might want to use the sptool to check if both your optee images were packaged. If not, you likely have your answer. If it is present, might want to make sure that fvp_tb_fw_config.dts has an entry for the second OPTEE partition to be loaded by BL2 at 0x8001000. For the partition to run, both OPTEE images have to be loaded by BL2, and both OPTEE images have processed by hafnium during initialization(when it processes the SPMC manifest). Thanks Raghu -----Original Message----- From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org<mailto:hafnium-bounces@lists.trustedfirmware.org>> On Behalf Of yinhua_chen--- via Hafnium Sent: Wednesday, February 24, 2021 7:23 PM To: hafnium(a)lists.trustedfirmware.org<mailto:hafnium@lists.trustedfirmware.org> Subject: [Hafnium] Trying to load two OPTEEs on hafnium Hi all, I am trying to load two OPTEEs on hafnium. Thanks to the help from Hafnium open source community, now I can load one OPTEE on hafnium. The guidance I am following is attached at the end. In the guidance, the OPTEE is loaded at address 0x06280000. I think the first step to load two OPTEEs is to load an OPTEE at an address other than 0x06280000. I tried but failed. If there is anyone who can give me some advice, I would be very grateful. =====================The following is the effort I made=============== # NOTE: make sure gcc-arm-9.2-2019.12-x86_64-aarch64-none-elf/bin is in PATH 1. Loading one OPTEE at address 0x06280000 successfully by following the guidance attached below. 2. In the file <path-to-workspace>/optee_os/core/arch/arm/plat-vexpress/conf.mk change "CFG_TZDRAM_START ?=0x06281000" to "CFG_TZDRAM_START ?= 0x08002000" 3. In the file <path-to-workspace>//trusted-firmware-a/fdts/optee_sp_manifest.dts change "load-address = <0x6280000>" to "load-address = <0x8001000>" 4. Compile OPTEE CROSS_COMPILE64=aarch64-none-elf- PLATFORM=vexpress PLATFORM_FLAVOR=fvp CFG_ARM_GICV3=y CFG_CORE_SEL2_SPMC=y CFG_ARM64_core=y CFG_USER_TA_TARGETS=ta_arm64 CFG_TEE_CORE_DEBUG=y CFG_TEE_CORE_LOG_LEVEL=4 CFG_TEE_BENCHMARK=n CFG_WITH_STATS=y make 5. Compile ATF make CROSS_COMPILE=aarch64-none-elf- SPD=spmd CTX_INCLUDE_EL2_REGS=1 PLAT=fvp BL33=../tf-a-tests/build/fvp/debug/tftf.bin DEBUG=1 BL32=../hafnium/out/reference/secure_aem_v8a_fvp_clang/hafnium.bin ARM_ARCH_MINOR=4 SP_LAYOUT_FILE=sp_layout.json ARM_SPMC_MANIFEST_DTS=plat/arm/board/fvp/fdts/fvp_spmc_optee_sp_manifest.dts all fip 6. Run FVP ../fvp/Base_RevC_AEMv8A_pkg/models/Linux64_GCC-6.4/FVP_Base_RevC-2xAEMv8A -C pctl.startup=0.0.0.0 -C cluster0.NUM_CORES=4 -C cluster1.NUM_CORES=4 -C bp.secure_memory=1 -C bp.secureflashloader.fname=trusted-firmware-a/build/fvp/debug/bl1.bin -C bp.flashloader0.fname=trusted-firmware-a/build/fvp/debug/fip.bin -C cluster0.has_arm_v8-4=1 -C cluster1.has_arm_v8-4=1 -C cache_state_modelled=0 -C bp.pl011_uart0.out_file=fvp-uart0.log -C bp.pl011_uart1.out_file=fvp-uart1.log -C bp.vis.disable_visualisation=1 7. The error message from fvp-uart0.log (fvp-uart1.log is empty) NOTICE: Booting Trusted Firmware NOTICE: BL1: v2.4(debug):v2.4-79-gb4b23c780-dirty NOTICE: BL1: Built : 09:39:24, Feb 25 2021 INFO: BL1: RAM 0x4035000 - 0x403c000 INFO: Loading image id=31 at address 0x4001010 INFO: Image id=31 loaded: 0x4001010 - 0x4001234 INFO: FCONF: Config file with image ID:31 loaded at address = 0x4001010 INFO: Loading image id=24 at address 0x4001300 INFO: Image id=24 loaded: 0x4001300 - 0x4001466 INFO: FCONF: Config file with image ID:24 loaded at address = 0x4001300 INFO: BL1: Loading BL2 INFO: Loading image id=1 at address 0x4022000 INFO: Image id=1 loaded: 0x4022000 - 0x402bb49 NOTICE: BL1: Booting BL2 INFO: Entry point address = 0x4022000 INFO: SPSR = 0x3c5 INFO: FCONF: Reading FW_CONFIG firmware configuration file from: 0x4001010 INFO: FCONF: Reading firmware configuration information for: dyn_cfg INFO: FCONF: Reading TB_FW firmware configuration file from: 0x4001300 INFO: FCONF: Reading firmware configuration information for: arm_sp NOTICE: BL2: v2.4(debug):v2.4-79-gb4b23c780-dirty NOTICE: BL2: Built : 09:39:26, Feb 25 2021 INFO: BL2: Doing platform setup INFO: Configuring TrustZone Controller INFO: Total 4 regions set. INFO: BL2: Loading image id 3 INFO: Loading image id=3 at address 0x4003000 INFO: Image id=3 loaded: 0x4003000 - 0x401722c INFO: BL2: Loading image id 23 INFO: Loading image id=23 at address 0x82000000 INFO: Image id=23 loaded: 0x82000000 - 0x82002348 INFO: BL2: Loading image id 25 INFO: Loading image id=25 at address 0x4001300 INFO: Image id=25 loaded: 0x4001300 - 0x4001348 INFO: BL2: Loading image id 4 INFO: Loading image id=4 at address 0x6000000 INFO: Image id=4 loaded: 0x6000000 - 0x601e250 INFO: BL2: Skip loading image id 21 INFO: BL2: Skip loading image id 22 INFO: BL2: Loading image id 26 INFO: Loading image id=26 at address 0x4001500 INFO: Image id=26 loaded: 0x4001500 - 0x4001acf INFO: BL2: Loading image id 5 INFO: Loading image id=5 at address 0x88000000 INFO: Image id=5 loaded: 0x88000000 - 0x8800b2b0 INFO: BL2: Loading image id 34 INFO: Loading image id=34 at address 0x6280000 INFO: Image id=34 loaded: 0x6280000 - 0x62e2050 NOTICE: BL1: Booting BL31 INFO: Entry point address = 0x4003000 INFO: SPSR = 0x3cd INFO: FCONF: Reading HW_CONFIG firmware configuration file from: 0x82000000 INFO: FCONF: Reading firmware configuration information for: cpu_timer INFO: FCONF: Reading firmware configuration information for: uart_config INFO: FCONF: Reading firmware configuration information for: topology INFO: FCONF: Reading firmware configuration information for: gicv3_config NOTICE: BL31: v2.4(debug):v2.4-79-gb4b23c780-dirty NOTICE: BL31: Built : 09:39:31, Feb 25 2021 INFO: GICv3 with legacy support detected. INFO: ARM GICv3 driver initialized in EL3 INFO: BL31: Initializing runtime services INFO: SPM Core setup done. INFO: BL31: Initializing BL32 NOTICE: Initialising hafnium INFO: text: 0x6000000 - 0x601a000 INFO: rodata: 0x601a000 - 0x601e000 INFO: data: 0x601e000 - 0x60a0000 INFO: Supported bits in physical address: 40 INFO: Stage 2 has 3 page table levels with 2 pages at the root. INFO: SPM: 0x84000069 0x0 0x0 0x0 0x0 0x0 0x0 0x0 INFO: Memory range: 0x6000000 - 0x7ffffff INFO: SPM: 0x8400006f 0xffffffff8000ffff 0x0 0x1 0x0 0x6001340 0x601e000 0x0 INFO: In case FFA_MSG_SEND_DIRECT_REQ_SMC32, branch1 (this message is added by myself) INFO: SPM: 0x8400006f 0xffffffff8000ffff 0x0 0x1 0x10300 0x6001340 0x601e0a8 0x0 INFO: In case FFA_MSG_SEND_DIRECT_REQ_SMC32, branch1 (this message is added by myself) INFO: SPM: 0x8400006f 0xffffffff8000ffff 0x0 0x1 0x10200 0x6001340 0x601e090 0x0 INFO: In case FFA_MSG_SEND_DIRECT_REQ_SMC32, branch1 (this message is added by myself) INFO: SPM: 0x8400006f 0xffffffff8000ffff 0x0 0x1 0x10100 0x6001340 0x601e078 0x0 INFO: In case FFA_MSG_SEND_DIRECT_REQ_SMC32, branch1 (this message is added by myself) INFO: SPM: 0x8400006f 0xffffffff8000ffff 0x0 0x1 0x10000 0x6001340 0x601e060 0x0 INFO: In case FFA_MSG_SEND_DIRECT_REQ_SMC32, branch1 (this message is added by myself) INFO: SPM: 0x8400006f 0xffffffff8000ffff 0x0 0x1 0x300 0x6001340 0x601e048 0x0 INFO: In case FFA_MSG_SEND_DIRECT_REQ_SMC32, branch1 (this message is added by myself) INFO: SPM: 0x8400006f 0xffffffff8000ffff 0x0 0x1 0x200 0x6001340 0x601e030 0x0 INFO: In case FFA_MSG_SEND_DIRECT_REQ_SMC32, branch1 (this message is added by myself) INFO: SPM: 0x8400006f 0xffffffff8000ffff 0x0 0x1 0x100 0x6001340 0x601e018 0x0 INFO: In case FFA_MSG_SEND_DIRECT_REQ_SMC32, branch1 (this message is added by myself) INFO: Loaded primary VM with 8 vCPUs, entry at 0x8001000. INFO: Hafnium initialisation completed WARNING: Stage-2 page fault: pc=0x8002000, vmid=32769, vcpu=0, vaddr=0x8002000, ipaddr=0x0, mode=0x4 NOTICE: Injecting Instruction Abort exception into VM32769. WARNING: Stage-2 page fault: pc=0x200, vmid=32769, vcpu=0, vaddr=0x200, ipaddr=0x200, mode=0x4 NOTICE: Injecting Instruction Abort exception into VM32769. WARNING: Stage-2 page fault: pc=0x200, vmid=32769, vcpu=0, vaddr=0x200, ipaddr=0x200, mode=0x4 NOTICE: Injecting Instruction Abort exception into VM32769. WARNING: Stage-2 page fault: pc=0x200, vmid=32769, vcpu=0, vaddr=0x200, ipaddr=0x200, mode=0x4 NOTICE: Injecting Instruction Abort exception into VM32769. . . . (infinite loop . . .) ============The guidance from Oliver Deprez to load one OPTEE============ # NOTE: make sure gcc-arm-9.2-2019.12-x86_64-aarch64-none-elf/bin is in PATH mkdir workspace; cd workspace # Hafnium # https://review.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/HEAD/d… git clone https://git.trustedfirmware.org/hafnium/hafnium.git; cd hafnium git fetch "https://review.trustedfirmware.org/hafnium/hafnium" refs/changes/11/6011/16 && git checkout FETCH_HEAD git checkout -b spmc git submodule update --init make PROJECT=reference cd .. # OPTEE # https://optee.readthedocs.io/en/latest/building/prerequisites.html#prerequi… git clone https://git.trustedfirmware.org/OP-TEE/optee_os.git -b ffa_rel_proto; cd optee_os # Adjust TEE start address perl -pi -e 's/CFG_TZDRAM_START \?= 0x06280000/CFG_TZDRAM_START \?= 0x06281000/' core/arch/arm/plat-vexpress/conf.mk CROSS_COMPILE64=aarch64-none-elf- PLATFORM=vexpress PLATFORM_FLAVOR=fvp CFG_ARM_GICV3=y CFG_CORE_SEL2_SPMC=y CFG_ARM64_core=y CFG_USER_TA_TARGETS=ta_arm64 CFG_TEE_CORE_DEBUG=y CFG_TEE_CORE_LOG_LEVEL=4 CFG_TEE_BENCHMARK=n CFG_WITH_STATS=y make cd .. # TF-A-tests git clone https://git.trustedfirmware.org/TF-A/tf-a-tests.git; cd tf-a-tests make CROSS_COMPILE=aarch64-none-elf- PLAT=fvp DEBUG=1 TESTS=spm -j4 cd .. # TF-A # git clone https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git; cd trusted-firmware-a git checkout b4b23c780c0763ce01ac21de1a0e79287677405f -b spmc #{ # "op-tee" : { # "image": "../optee_os/out/arm-plat-vexpress/core/tee-pager_v2.bin", # "pm": "fdts/optee_sp_manifest.dts" # } #} echo \ "{ \ \"op-tee\" : { \ \"image\": \"../optee_os/out/arm-plat-vexpress/core/tee-pager_v2.bin\", \ \"pm\": \"fdts/optee_sp_manifest.dts\" \ } }" > sp_layout.json make CROSS_COMPILE=aarch64-none-elf- SPD=spmd CTX_INCLUDE_EL2_REGS=1 PLAT=fvp BL33=../tf-a-tests/build/fvp/debug/tftf.bin DEBUG=1 BL32=../hafnium/out/reference/secure_aem_v8a_fvp_clang/hafnium.bin ARM_ARCH_MINOR=4 SP_LAYOUT_FILE=sp_layout.json ARM_SPMC_MANIFEST_DTS=plat/arm/board/fvp/fdts/fvp_spmc_optee_sp_manifest.dts all fip cd .. # Run FVP ../fvp/Base_RevC_AEMv8A_pkg/models/Linux64_GCC-6.4/FVP_Base_RevC-2xAEMv8A -C pctl.startup=0.0.0.0 -C cluster0.NUM_CORES=4 -C cluster1.NUM_CORES=4 -C bp.secure_memory=1 -C bp.secureflashloader.fname=trusted-firmware-a/build/fvp/debug/bl1.bin -C bp.flashloader0.fname=trusted-firmware-a/build/fvp/debug/fip.bin -C cluster0.has_arm_v8-4=1 -C cluster1.has_arm_v8-4=1 -C cache_state_modelled=0 -C bp.pl011_uart0.out_file=fvp-uart0.log -C bp.pl011_uart1.out_file=fvp-uart1.log -C bp.vis.disable_visualisation=1 ============================= I appreciate for any possible help! Thanks Yinhua -- 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<mailto:Hafnium@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/hafnium

4 years, 2 months

2
1
0 0

Re: [Hafnium] Trying to load two OPTEEs on hafnium

by Manish Pandey2

Hi Yinhua, I reproduced the first problem at my end, please find my analysis below If you look at FVP memory map https://developer.arm.com/documentation/100966/1111-00/Arm-Neoverse-referen… address 0x9280000 is part of NOR flash which is read-only. Ideally this should have been mapped as RO in BL2's page table, but it is currently mapped as RW at plat/arm/board/fvp/fvp_common.c +83 (mostly a bug, will investigate it) I did a quick experiment and changed this mapping to RO and system stuck while loading SP INFO: Loading image id=34 at address 0x9280000 INFO: Image id=34 loaded: 0x9280000 - 0x92e2050 What's happening is, BL2 writes at RO area and thinks that write has been successful and when hafnium tries to match the SP MAGIC it fails. Will try to investigate your second problem on Monday and let you know. Thanks Manish ________________________________ From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of 胤桦陈 via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: 26 February 2021 08:59 To: raghu.ncstate(a)icloud.com <raghu.ncstate(a)icloud.com>; hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org> Subject: Re: [Hafnium] Trying to load two OPTEEs on hafnium This is the part "My effort and logs for the second problem" ================================My effort and logs for the second problem=================================== 1. copy the optee_os directory: cp -r <path-to-workspace>/optee_os <path-to-workspace>/optee_os2 mv <path-to-workspace>/optee_os <path-to-workspace>/optee_os1 2. Set both OPTEE's conf.mk file In the file <path-to-workspace>/optee_os1/core/arch/arm/plat-vexpress/conf.mk set CFG_TZDRAM_START ?=0x06281000 In the file <path-to-workspace>/optee_os2/core/arch/arm/plat-vexpress/conf.mk set CFG_TZDRAM_START ?=0x07281000 3. Set both OPTEE's optee_sp_manifest.dts cp <path-to-workspace>/trusted-firmware-a/fdts/optee_sp_manifest.dts <path-to-workspace>/trusted-firmware-a/fdts/optee2_sp_manifest.dts mv <path-to-workspace>/trusted-firmware-a/fdts/optee_sp_manifest.dts <path-to-workspace>/trusted-firmware-a/fdts/optee1_sp_manifest.dts In the file <path-to-workspace>/trusted-firmware-a/fdts/optee1_sp_manifest.dts set id = <1>; load-address = <0x6280000>; In the file <path-to-workspace>/trusted-firmware-a/fdts/optee2_sp_manifest.dts set id = <2>; load-address = <0x7280000>; 4. In the file <path-to-workspace>/trusted-firmware-a/plat/arm/board/fvp/fdts/fvp_spmc_optee_sp_manifest.dts Set "hypervisor" node like following hypervisor { compatible = "hafnium,hafnium"; vm1 { is_ffa_partition; debug_name = "op-tee1"; load_address = <0x6280000>; smc_whitelist = <0xbe000000>; }; vm2 { is_ffa_partition; debug_name = "op-tee2"; load_address = <0x7280000>; smc_whitelist = <0xce000000>; }; }; 5. In the file <path-to-workspace>/trusted-firmware-a/plat/arm/board/fvp/fdts/fvp_tb_fw_config.dts Set "secure-partitions" node like following secure-partitions { compatible = "arm,sp"; #ifdef OPTEE_SP_FW_CONFIG op-tee1 { uuid = <0x486178e0 0xe7f811e3 0xbc5e0002 0xa5d5c51b>; load-address = <0x6280000>; }; op-tee2 { uuid = <0x486178e0 0xe7f811e3 0xbc5e0002 0xa5d5c51b>; load-address = <0x7280000>; }; #else . . (cactus) . #endif }; 6. Compile OPTEE1 and OPTEE2 7. Compile ATF 8. Run FVP Logs from fvp-uart0.log (fvp-uart1.log is empty) NOTICE: Booting Trusted Firmware NOTICE: BL1: v2.4(debug):v2.4-79-gb4b23c780-dirty NOTICE: BL1: Built : 15:36:13, Feb 26 2021 INFO: BL1: RAM 0x4035000 - 0x403c000 INFO: Loading image id=31 at address 0x4001010 INFO: Image id=31 loaded: 0x4001010 - 0x4001234 INFO: FCONF: Config file with image ID:31 loaded at address = 0x4001010 INFO: Loading image id=24 at address 0x4001300 INFO: Image id=24 loaded: 0x4001300 - 0x40014a2 INFO: FCONF: Config file with image ID:24 loaded at address = 0x4001300 INFO: BL1: Loading BL2 INFO: Loading image id=1 at address 0x4022000 INFO: Image id=1 loaded: 0x4022000 - 0x402bb49 NOTICE: BL1: Booting BL2 INFO: Entry point address = 0x4022000 INFO: SPSR = 0x3c5 INFO: FCONF: Reading FW_CONFIG firmware configuration file from: 0x4001010 INFO: FCONF: Reading firmware configuration information for: dyn_cfg INFO: FCONF: Reading TB_FW firmware configuration file from: 0x4001300 INFO: FCONF: Reading firmware configuration information for: arm_sp NOTICE: BL2: v2.4(debug):v2.4-79-gb4b23c780-dirty NOTICE: BL2: Built : 15:36:16, Feb 26 2021 INFO: BL2: Doing platform setup INFO: Configuring TrustZone Controller INFO: Total 4 regions set. INFO: BL2: Loading image id 3 INFO: Loading image id=3 at address 0x4003000 INFO: Image id=3 loaded: 0x4003000 - 0x401722c INFO: BL2: Loading image id 23 INFO: Loading image id=23 at address 0x82000000 INFO: Image id=23 loaded: 0x82000000 - 0x82002348 INFO: BL2: Loading image id 25 INFO: Loading image id=25 at address 0x4001300 INFO: Image id=25 loaded: 0x4001300 - 0x4001348 INFO: BL2: Loading image id 4 INFO: Loading image id=4 at address 0x6000000 INFO: Image id=4 loaded: 0x6000000 - 0x601e250 INFO: BL2: Skip loading image id 21 INFO: BL2: Skip loading image id 22 INFO: BL2: Loading image id 26 INFO: Loading image id=26 at address 0x4001500 INFO: Image id=26 loaded: 0x4001500 - 0x4001b1b INFO: BL2: Loading image id 5 INFO: Loading image id=5 at address 0x88000000 INFO: Image id=5 loaded: 0x88000000 - 0x8800b2b0 INFO: BL2: Loading image id 34 INFO: Loading image id=34 at address 0x6280000 INFO: Image id=34 loaded: 0x6280000 - 0x62e2050 INFO: BL2: Loading image id 35 INFO: Loading image id=35 at address 0x7280000 INFO: Image id=35 loaded: 0x7280000 - 0x72e2050 NOTICE: BL1: Booting BL31 INFO: Entry point address = 0x4003000 INFO: SPSR = 0x3cd INFO: FCONF: Reading HW_CONFIG firmware configuration file from: 0x82000000 INFO: FCONF: Reading firmware configuration information for: cpu_timer INFO: FCONF: Reading firmware configuration information for: uart_config INFO: FCONF: Reading firmware configuration information for: topology INFO: FCONF: Reading firmware configuration information for: gicv3_config NOTICE: BL31: v2.4(debug):v2.4-79-gb4b23c780-dirty NOTICE: BL31: Built : 15:36:21, Feb 26 2021 INFO: GICv3 with legacy support detected. INFO: ARM GICv3 driver initialized in EL3 INFO: BL31: Initializing runtime services INFO: SPM Core setup done. INFO: BL31: Initializing BL32 NOTICE: Initialising hafnium INFO: text: 0x6000000 - 0x601a000 INFO: rodata: 0x601a000 - 0x601e000 INFO: data: 0x601e000 - 0x60a0000 INFO: Supported bits in physical address: 40 INFO: Stage 2 has 3 page table levels with 2 pages at the root. INFO: SPM: 0x84000069 0x0 0x0 0x0 0x0 0x0 0x0 0x0 INFO: Memory range: 0x6000000 - 0xaffffff INFO: Valid SP package magic. the valid magic number is 0x474b5053 Panic: Could not parse manifest: Property not found. ====================================================================== Now I am trying to be deep into the code to solve the problems by myself. But if anyone have any idea, I appreciate for your sharing. Sincerely, Yinhua ________________________________ From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of 胤桦陈 via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: Friday, February 26, 2021 16:48 To: raghu.ncstate(a)icloud.com <raghu.ncstate(a)icloud.com>; hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org> Subject: Re: [Hafnium] Trying to load two OPTEEs on hafnium Hi raghu, Thanks for your guidance! I have never heard of fvp_tb_fw_config.dts before! I will spend much more of time on solving my problems without your help! Now I can load one OPTEE on at addresses between 0x6000000 and 0x8000000 successfully. Now I meet two problems, I am trying to be deep into the code to solve the problems by myself. But if you have any idea, I appreciate for your sharing. Two Problems I met: 1. If I load the OPTEE at address not between 0x6000000 and 0x8000000, like 0x9280000, then there will be error "Invalid SP package magic". 2. I try to load two OPTEEs, the first at address 0x6280000, the second at address 0x7280000, and there is an error "Panic: Could not parse manifest: Property not found." My effort and the detailed logs are as follows. ==================================My effort and logs for the first problem==================================== 1. In the file <path-to-workspace>/optee_os/core/arch/arm/plat-vexpress/conf.mk change "CFG_TZDRAM_START ?=0x06281000" to "CFG_TZDRAM_START ?= 0x09281000" 2. In the file <path-to-workspace>/trusted-firmware-a/fdts/optee_sp_manifest.dts change "load-address = <0x6280000>" to "load-address = <0x9280000>" 3. In the file <path-to-workspace>/trusted-firmware-a/plat/arm/board/fvp/fdts/fvp_tb_fw_config.dts change load-address of op-tee from 0x6280000 to 0x9280000 4. In the file <path-to-workspace>/trusted-firmware-a/plat/arm/board/fvp/fdts/fvp_spmc_optee_sp_manifest.dts change load_address of vm1 from 0x6280000 to 0x9280000 5. Compile OPTEE CROSS_COMPILE64=aarch64-none-elf- PLATFORM=vexpress PLATFORM_FLAVOR=fvp CFG_ARM_GICV3=y CFG_CORE_SEL2_SPMC=y CFG_ARM64_core=y CFG_USER_TA_TARGETS=ta_arm64 CFG_TEE_CORE_DEBUG=y CFG_TEE_CORE_LOG_LEVEL=4 CFG_TEE_BENCHMARK=n CFG_WITH_STATS=y make 6. Compile ATF make CROSS_COMPILE=aarch64-none-elf- SPD=spmd CTX_INCLUDE_EL2_REGS=1 PLAT=fvp BL33=../tf-a-tests/build/fvp/debug/tftf.bin DEBUG=1 BL32=../hafnium/out/reference/secure_aem_v8a_fvp_clang/hafnium.bin ARM_ARCH_MINOR=4 SP_LAYOUT_FILE=sp_layout.json ARM_SPMC_MANIFEST_DTS=plat/arm/board/fvp/fdts/fvp_spmc_optee_sp_manifest.dts all fip 7. Run FVP ../fvp/Base_RevC_AEMv8A_pkg/models/Linux64_GCC-6.4/FVP_Base_RevC-2xAEMv8A -C pctl.startup=0.0.0.0 -C cluster0.NUM_CORES=4 -C cluster1.NUM_CORES=4 -C bp.secure_memory=1 -C bp.secureflashloader.fname=trusted-firmware-a/build/fvp/debug/bl1.bin -C bp.flashloader0.fname=trusted-firmware-a/build/fvp/debug/fip.bin -C cluster0.has_arm_v8-4=1 -C cluster1.has_arm_v8-4=1 -C cache_state_modelled=0 -C bp.pl011_uart0.out_file=fvp-uart0.log -C bp.pl011_uart1.out_file=fvp-uart1.log -C bp.vis.disable_visualisation=1 Logs from fvp-uart0.log (fvp-uart1.log is empty) NOTICE: Booting Trusted Firmware NOTICE: BL1: v2.4(debug):v2.4-79-gb4b23c780-dirty NOTICE: BL1: Built : 15:36:13, Feb 26 2021 INFO: BL1: RAM 0x4035000 - 0x403c000 INFO: Loading image id=31 at address 0x4001010 INFO: Image id=31 loaded: 0x4001010 - 0x4001234 INFO: FCONF: Config file with image ID:31 loaded at address = 0x4001010 INFO: Loading image id=24 at address 0x4001300 INFO: Image id=24 loaded: 0x4001300 - 0x4001466 INFO: FCONF: Config file with image ID:24 loaded at address = 0x4001300 INFO: BL1: Loading BL2 INFO: Loading image id=1 at address 0x4022000 INFO: Image id=1 loaded: 0x4022000 - 0x402bb49 NOTICE: BL1: Booting BL2 INFO: Entry point address = 0x4022000 INFO: SPSR = 0x3c5 INFO: FCONF: Reading FW_CONFIG firmware configuration file from: 0x4001010 INFO: FCONF: Reading firmware configuration information for: dyn_cfg INFO: FCONF: Reading TB_FW firmware configuration file from: 0x4001300 INFO: FCONF: Reading firmware configuration information for: arm_sp NOTICE: BL2: v2.4(debug):v2.4-79-gb4b23c780-dirty NOTICE: BL2: Built : 15:36:16, Feb 26 2021 INFO: BL2: Doing platform setup INFO: Configuring TrustZone Controller INFO: Total 4 regions set. INFO: BL2: Loading image id 3 INFO: Loading image id=3 at address 0x4003000 INFO: Image id=3 loaded: 0x4003000 - 0x401722c INFO: BL2: Loading image id 23 INFO: Loading image id=23 at address 0x82000000 INFO: Image id=23 loaded: 0x82000000 - 0x82002348 INFO: BL2: Loading image id 25 INFO: Loading image id=25 at address 0x4001300 INFO: Image id=25 loaded: 0x4001300 - 0x4001348 INFO: BL2: Loading image id 4 INFO: Loading image id=4 at address 0x6000000 INFO: Image id=4 loaded: 0x6000000 - 0x601e250 INFO: BL2: Skip loading image id 21 INFO: BL2: Skip loading image id 22 INFO: BL2: Loading image id 26 INFO: Loading image id=26 at address 0x4001500 INFO: Image id=26 loaded: 0x4001500 - 0x4001acf INFO: BL2: Loading image id 5 INFO: Loading image id=5 at address 0x88000000 INFO: Image id=5 loaded: 0x88000000 - 0x8800b2b0 INFO: BL2: Loading image id 34 INFO: Loading image id=34 at address 0x9280000 INFO: Image id=34 loaded: 0x9280000 - 0x92e2050 NOTICE: BL1: Booting BL31 INFO: Entry point address = 0x4003000 INFO: SPSR = 0x3cd INFO: FCONF: Reading HW_CONFIG firmware configuration file from: 0x82000000 INFO: FCONF: Reading firmware configuration information for: cpu_timer INFO: FCONF: Reading firmware configuration information for: uart_config INFO: FCONF: Reading firmware configuration information for: topology INFO: FCONF: Reading firmware configuration information for: gicv3_config NOTICE: BL31: v2.4(debug):v2.4-79-gb4b23c780-dirty NOTICE: BL31: Built : 15:36:21, Feb 26 2021 INFO: GICv3 with legacy support detected. INFO: ARM GICv3 driver initialized in EL3 INFO: BL31: Initializing runtime services INFO: SPM Core setup done. INFO: BL31: Initializing BL32 NOTICE: Initialising hafnium INFO: text: 0x6000000 - 0x601a000 INFO: rodata: 0x601a000 - 0x601e000 INFO: data: 0x601e000 - 0x60a0000 INFO: Supported bits in physical address: 40 INFO: Stage 2 has 3 page table levels with 2 pages at the root. INFO: SPM: 0x84000069 0x0 0x0 0x0 0x0 0x0 0x0 0x0 INFO: Memory range: 0x6000000 - 0xaffffff ERROR: Invalid SP package magic. the invalid magic number is 0xe7ff0010 Panic: Could not parse manifest: Hypervisor manifest entry not compatible with Hafnium. ================================My effort and logs for the second problem=================================== This part is sent by another email because of the limit of body length ===================================================================================================== Now I am trying to be deep into the code to solve the problems by myself. But if anyone have any idea, I appreciate for your sharing. Sincerely, Yinhua ________________________________ From: raghu.ncstate(a)icloud.com <raghu.ncstate(a)icloud.com> Sent: Friday, February 26, 2021 5:35 To: yinhua_chen(a)outlook.com <yinhua_chen(a)outlook.com>; hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org> Subject: RE: [Hafnium] Trying to load two OPTEEs on hafnium From the log it looks like there was nothing loaded at 0x8001000. Possible that you are missing the second entry for OPTEE in the SPMC manifest(fvp_spmc_optee_sp_manifest.dts). Might want to use the sptool to check if both your optee images were packaged. If not, you likely have your answer. If it is present, might want to make sure that fvp_tb_fw_config.dts has an entry for the second OPTEE partition to be loaded by BL2 at 0x8001000. For the partition to run, both OPTEE images have to be loaded by BL2, and both OPTEE images have processed by hafnium during initialization(when it processes the SPMC manifest). Thanks Raghu -----Original Message----- From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> On Behalf Of yinhua_chen--- via Hafnium Sent: Wednesday, February 24, 2021 7:23 PM To: hafnium(a)lists.trustedfirmware.org Subject: [Hafnium] Trying to load two OPTEEs on hafnium Hi all, I am trying to load two OPTEEs on hafnium. Thanks to the help from Hafnium open source community, now I can load one OPTEE on hafnium. The guidance I am following is attached at the end. In the guidance, the OPTEE is loaded at address 0x06280000. I think the first step to load two OPTEEs is to load an OPTEE at an address other than 0x06280000. I tried but failed. If there is anyone who can give me some advice, I would be very grateful. =====================The following is the effort I made=============== # NOTE: make sure gcc-arm-9.2-2019.12-x86_64-aarch64-none-elf/bin is in PATH 1. Loading one OPTEE at address 0x06280000 successfully by following the guidance attached below. 2. In the file <path-to-workspace>/optee_os/core/arch/arm/plat-vexpress/conf.mk change "CFG_TZDRAM_START ?=0x06281000" to "CFG_TZDRAM_START ?= 0x08002000" 3. In the file <path-to-workspace>//trusted-firmware-a/fdts/optee_sp_manifest.dts change "load-address = <0x6280000>" to "load-address = <0x8001000>" 4. Compile OPTEE CROSS_COMPILE64=aarch64-none-elf- PLATFORM=vexpress PLATFORM_FLAVOR=fvp CFG_ARM_GICV3=y CFG_CORE_SEL2_SPMC=y CFG_ARM64_core=y CFG_USER_TA_TARGETS=ta_arm64 CFG_TEE_CORE_DEBUG=y CFG_TEE_CORE_LOG_LEVEL=4 CFG_TEE_BENCHMARK=n CFG_WITH_STATS=y make 5. Compile ATF make CROSS_COMPILE=aarch64-none-elf- SPD=spmd CTX_INCLUDE_EL2_REGS=1 PLAT=fvp BL33=../tf-a-tests/build/fvp/debug/tftf.bin DEBUG=1 BL32=../hafnium/out/reference/secure_aem_v8a_fvp_clang/hafnium.bin ARM_ARCH_MINOR=4 SP_LAYOUT_FILE=sp_layout.json ARM_SPMC_MANIFEST_DTS=plat/arm/board/fvp/fdts/fvp_spmc_optee_sp_manifest.dts all fip 6. Run FVP ../fvp/Base_RevC_AEMv8A_pkg/models/Linux64_GCC-6.4/FVP_Base_RevC-2xAEMv8A -C pctl.startup=0.0.0.0 -C cluster0.NUM_CORES=4 -C cluster1.NUM_CORES=4 -C bp.secure_memory=1 -C bp.secureflashloader.fname=trusted-firmware-a/build/fvp/debug/bl1.bin -C bp.flashloader0.fname=trusted-firmware-a/build/fvp/debug/fip.bin -C cluster0.has_arm_v8-4=1 -C cluster1.has_arm_v8-4=1 -C cache_state_modelled=0 -C bp.pl011_uart0.out_file=fvp-uart0.log -C bp.pl011_uart1.out_file=fvp-uart1.log -C bp.vis.disable_visualisation=1 7. The error message from fvp-uart0.log (fvp-uart1.log is empty) NOTICE: Booting Trusted Firmware NOTICE: BL1: v2.4(debug):v2.4-79-gb4b23c780-dirty NOTICE: BL1: Built : 09:39:24, Feb 25 2021 INFO: BL1: RAM 0x4035000 - 0x403c000 INFO: Loading image id=31 at address 0x4001010 INFO: Image id=31 loaded: 0x4001010 - 0x4001234 INFO: FCONF: Config file with image ID:31 loaded at address = 0x4001010 INFO: Loading image id=24 at address 0x4001300 INFO: Image id=24 loaded: 0x4001300 - 0x4001466 INFO: FCONF: Config file with image ID:24 loaded at address = 0x4001300 INFO: BL1: Loading BL2 INFO: Loading image id=1 at address 0x4022000 INFO: Image id=1 loaded: 0x4022000 - 0x402bb49 NOTICE: BL1: Booting BL2 INFO: Entry point address = 0x4022000 INFO: SPSR = 0x3c5 INFO: FCONF: Reading FW_CONFIG firmware configuration file from: 0x4001010 INFO: FCONF: Reading firmware configuration information for: dyn_cfg INFO: FCONF: Reading TB_FW firmware configuration file from: 0x4001300 INFO: FCONF: Reading firmware configuration information for: arm_sp NOTICE: BL2: v2.4(debug):v2.4-79-gb4b23c780-dirty NOTICE: BL2: Built : 09:39:26, Feb 25 2021 INFO: BL2: Doing platform setup INFO: Configuring TrustZone Controller INFO: Total 4 regions set. INFO: BL2: Loading image id 3 INFO: Loading image id=3 at address 0x4003000 INFO: Image id=3 loaded: 0x4003000 - 0x401722c INFO: BL2: Loading image id 23 INFO: Loading image id=23 at address 0x82000000 INFO: Image id=23 loaded: 0x82000000 - 0x82002348 INFO: BL2: Loading image id 25 INFO: Loading image id=25 at address 0x4001300 INFO: Image id=25 loaded: 0x4001300 - 0x4001348 INFO: BL2: Loading image id 4 INFO: Loading image id=4 at address 0x6000000 INFO: Image id=4 loaded: 0x6000000 - 0x601e250 INFO: BL2: Skip loading image id 21 INFO: BL2: Skip loading image id 22 INFO: BL2: Loading image id 26 INFO: Loading image id=26 at address 0x4001500 INFO: Image id=26 loaded: 0x4001500 - 0x4001acf INFO: BL2: Loading image id 5 INFO: Loading image id=5 at address 0x88000000 INFO: Image id=5 loaded: 0x88000000 - 0x8800b2b0 INFO: BL2: Loading image id 34 INFO: Loading image id=34 at address 0x6280000 INFO: Image id=34 loaded: 0x6280000 - 0x62e2050 NOTICE: BL1: Booting BL31 INFO: Entry point address = 0x4003000 INFO: SPSR = 0x3cd INFO: FCONF: Reading HW_CONFIG firmware configuration file from: 0x82000000 INFO: FCONF: Reading firmware configuration information for: cpu_timer INFO: FCONF: Reading firmware configuration information for: uart_config INFO: FCONF: Reading firmware configuration information for: topology INFO: FCONF: Reading firmware configuration information for: gicv3_config NOTICE: BL31: v2.4(debug):v2.4-79-gb4b23c780-dirty NOTICE: BL31: Built : 09:39:31, Feb 25 2021 INFO: GICv3 with legacy support detected. INFO: ARM GICv3 driver initialized in EL3 INFO: BL31: Initializing runtime services INFO: SPM Core setup done. INFO: BL31: Initializing BL32 NOTICE: Initialising hafnium INFO: text: 0x6000000 - 0x601a000 INFO: rodata: 0x601a000 - 0x601e000 INFO: data: 0x601e000 - 0x60a0000 INFO: Supported bits in physical address: 40 INFO: Stage 2 has 3 page table levels with 2 pages at the root. INFO: SPM: 0x84000069 0x0 0x0 0x0 0x0 0x0 0x0 0x0 INFO: Memory range: 0x6000000 - 0x7ffffff INFO: SPM: 0x8400006f 0xffffffff8000ffff 0x0 0x1 0x0 0x6001340 0x601e000 0x0 INFO: In case FFA_MSG_SEND_DIRECT_REQ_SMC32, branch1 (this message is added by myself) INFO: SPM: 0x8400006f 0xffffffff8000ffff 0x0 0x1 0x10300 0x6001340 0x601e0a8 0x0 INFO: In case FFA_MSG_SEND_DIRECT_REQ_SMC32, branch1 (this message is added by myself) INFO: SPM: 0x8400006f 0xffffffff8000ffff 0x0 0x1 0x10200 0x6001340 0x601e090 0x0 INFO: In case FFA_MSG_SEND_DIRECT_REQ_SMC32, branch1 (this message is added by myself) INFO: SPM: 0x8400006f 0xffffffff8000ffff 0x0 0x1 0x10100 0x6001340 0x601e078 0x0 INFO: In case FFA_MSG_SEND_DIRECT_REQ_SMC32, branch1 (this message is added by myself) INFO: SPM: 0x8400006f 0xffffffff8000ffff 0x0 0x1 0x10000 0x6001340 0x601e060 0x0 INFO: In case FFA_MSG_SEND_DIRECT_REQ_SMC32, branch1 (this message is added by myself) INFO: SPM: 0x8400006f 0xffffffff8000ffff 0x0 0x1 0x300 0x6001340 0x601e048 0x0 INFO: In case FFA_MSG_SEND_DIRECT_REQ_SMC32, branch1 (this message is added by myself) INFO: SPM: 0x8400006f 0xffffffff8000ffff 0x0 0x1 0x200 0x6001340 0x601e030 0x0 INFO: In case FFA_MSG_SEND_DIRECT_REQ_SMC32, branch1 (this message is added by myself) INFO: SPM: 0x8400006f 0xffffffff8000ffff 0x0 0x1 0x100 0x6001340 0x601e018 0x0 INFO: In case FFA_MSG_SEND_DIRECT_REQ_SMC32, branch1 (this message is added by myself) INFO: Loaded primary VM with 8 vCPUs, entry at 0x8001000. INFO: Hafnium initialisation completed WARNING: Stage-2 page fault: pc=0x8002000, vmid=32769, vcpu=0, vaddr=0x8002000, ipaddr=0x0, mode=0x4 NOTICE: Injecting Instruction Abort exception into VM32769. WARNING: Stage-2 page fault: pc=0x200, vmid=32769, vcpu=0, vaddr=0x200, ipaddr=0x200, mode=0x4 NOTICE: Injecting Instruction Abort exception into VM32769. WARNING: Stage-2 page fault: pc=0x200, vmid=32769, vcpu=0, vaddr=0x200, ipaddr=0x200, mode=0x4 NOTICE: Injecting Instruction Abort exception into VM32769. WARNING: Stage-2 page fault: pc=0x200, vmid=32769, vcpu=0, vaddr=0x200, ipaddr=0x200, mode=0x4 NOTICE: Injecting Instruction Abort exception into VM32769. . . . (infinite loop . . .) ============The guidance from Oliver Deprez to load one OPTEE============ # NOTE: make sure gcc-arm-9.2-2019.12-x86_64-aarch64-none-elf/bin is in PATH mkdir workspace; cd workspace # Hafnium # https://review.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/HEAD/d… git clone https://git.trustedfirmware.org/hafnium/hafnium.git; cd hafnium git fetch "https://review.trustedfirmware.org/hafnium/hafnium" refs/changes/11/6011/16 && git checkout FETCH_HEAD git checkout -b spmc git submodule update --init make PROJECT=reference cd .. # OPTEE # https://optee.readthedocs.io/en/latest/building/prerequisites.html#prerequi… git clone https://git.trustedfirmware.org/OP-TEE/optee_os.git -b ffa_rel_proto; cd optee_os # Adjust TEE start address perl -pi -e 's/CFG_TZDRAM_START \?= 0x06280000/CFG_TZDRAM_START \?= 0x06281000/' core/arch/arm/plat-vexpress/conf.mk CROSS_COMPILE64=aarch64-none-elf- PLATFORM=vexpress PLATFORM_FLAVOR=fvp CFG_ARM_GICV3=y CFG_CORE_SEL2_SPMC=y CFG_ARM64_core=y CFG_USER_TA_TARGETS=ta_arm64 CFG_TEE_CORE_DEBUG=y CFG_TEE_CORE_LOG_LEVEL=4 CFG_TEE_BENCHMARK=n CFG_WITH_STATS=y make cd .. # TF-A-tests git clone https://git.trustedfirmware.org/TF-A/tf-a-tests.git; cd tf-a-tests make CROSS_COMPILE=aarch64-none-elf- PLAT=fvp DEBUG=1 TESTS=spm -j4 cd .. # TF-A # git clone https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git; cd trusted-firmware-a git checkout b4b23c780c0763ce01ac21de1a0e79287677405f -b spmc #{ # "op-tee" : { # "image": "../optee_os/out/arm-plat-vexpress/core/tee-pager_v2.bin", # "pm": "fdts/optee_sp_manifest.dts" # } #} echo \ "{ \ \"op-tee\" : { \ \"image\": \"../optee_os/out/arm-plat-vexpress/core/tee-pager_v2.bin\", \ \"pm\": \"fdts/optee_sp_manifest.dts\" \ } }" > sp_layout.json make CROSS_COMPILE=aarch64-none-elf- SPD=spmd CTX_INCLUDE_EL2_REGS=1 PLAT=fvp BL33=../tf-a-tests/build/fvp/debug/tftf.bin DEBUG=1 BL32=../hafnium/out/reference/secure_aem_v8a_fvp_clang/hafnium.bin ARM_ARCH_MINOR=4 SP_LAYOUT_FILE=sp_layout.json ARM_SPMC_MANIFEST_DTS=plat/arm/board/fvp/fdts/fvp_spmc_optee_sp_manifest.dts all fip cd .. # Run FVP ../fvp/Base_RevC_AEMv8A_pkg/models/Linux64_GCC-6.4/FVP_Base_RevC-2xAEMv8A -C pctl.startup=0.0.0.0 -C cluster0.NUM_CORES=4 -C cluster1.NUM_CORES=4 -C bp.secure_memory=1 -C bp.secureflashloader.fname=trusted-firmware-a/build/fvp/debug/bl1.bin -C bp.flashloader0.fname=trusted-firmware-a/build/fvp/debug/fip.bin -C cluster0.has_arm_v8-4=1 -C cluster1.has_arm_v8-4=1 -C cache_state_modelled=0 -C bp.pl011_uart0.out_file=fvp-uart0.log -C bp.pl011_uart1.out_file=fvp-uart1.log -C bp.vis.disable_visualisation=1 ============================= I appreciate for any possible help! Thanks Yinhua -- 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 -- Hafnium mailing list Hafnium(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/hafnium

4 years, 2 months

3
3
0 0

Re: [Hafnium] Trying to load two OPTEEs on hafnium

by 胤桦陈

This is the part "My effort and logs for the second problem" ================================My effort and logs for the second problem=================================== 1. copy the optee_os directory: cp -r <path-to-workspace>/optee_os <path-to-workspace>/optee_os2 mv <path-to-workspace>/optee_os <path-to-workspace>/optee_os1 2. Set both OPTEE's conf.mk file In the file <path-to-workspace>/optee_os1/core/arch/arm/plat-vexpress/conf.mk set CFG_TZDRAM_START ?=0x06281000 In the file <path-to-workspace>/optee_os2/core/arch/arm/plat-vexpress/conf.mk set CFG_TZDRAM_START ?=0x07281000 3. Set both OPTEE's optee_sp_manifest.dts cp <path-to-workspace>/trusted-firmware-a/fdts/optee_sp_manifest.dts <path-to-workspace>/trusted-firmware-a/fdts/optee2_sp_manifest.dts mv <path-to-workspace>/trusted-firmware-a/fdts/optee_sp_manifest.dts <path-to-workspace>/trusted-firmware-a/fdts/optee1_sp_manifest.dts In the file <path-to-workspace>/trusted-firmware-a/fdts/optee1_sp_manifest.dts set id = <1>; load-address = <0x6280000>; In the file <path-to-workspace>/trusted-firmware-a/fdts/optee2_sp_manifest.dts set id = <2>; load-address = <0x7280000>; 4. In the file <path-to-workspace>/trusted-firmware-a/plat/arm/board/fvp/fdts/fvp_spmc_optee_sp_manifest.dts Set "hypervisor" node like following hypervisor { compatible = "hafnium,hafnium"; vm1 { is_ffa_partition; debug_name = "op-tee1"; load_address = <0x6280000>; smc_whitelist = <0xbe000000>; }; vm2 { is_ffa_partition; debug_name = "op-tee2"; load_address = <0x7280000>; smc_whitelist = <0xce000000>; }; }; 5. In the file <path-to-workspace>/trusted-firmware-a/plat/arm/board/fvp/fdts/fvp_tb_fw_config.dts Set "secure-partitions" node like following secure-partitions { compatible = "arm,sp"; #ifdef OPTEE_SP_FW_CONFIG op-tee1 { uuid = <0x486178e0 0xe7f811e3 0xbc5e0002 0xa5d5c51b>; load-address = <0x6280000>; }; op-tee2 { uuid = <0x486178e0 0xe7f811e3 0xbc5e0002 0xa5d5c51b>; load-address = <0x7280000>; }; #else . . (cactus) . #endif }; 6. Compile OPTEE1 and OPTEE2 7. Compile ATF 8. Run FVP Logs from fvp-uart0.log (fvp-uart1.log is empty) NOTICE: Booting Trusted Firmware NOTICE: BL1: v2.4(debug):v2.4-79-gb4b23c780-dirty NOTICE: BL1: Built : 15:36:13, Feb 26 2021 INFO: BL1: RAM 0x4035000 - 0x403c000 INFO: Loading image id=31 at address 0x4001010 INFO: Image id=31 loaded: 0x4001010 - 0x4001234 INFO: FCONF: Config file with image ID:31 loaded at address = 0x4001010 INFO: Loading image id=24 at address 0x4001300 INFO: Image id=24 loaded: 0x4001300 - 0x40014a2 INFO: FCONF: Config file with image ID:24 loaded at address = 0x4001300 INFO: BL1: Loading BL2 INFO: Loading image id=1 at address 0x4022000 INFO: Image id=1 loaded: 0x4022000 - 0x402bb49 NOTICE: BL1: Booting BL2 INFO: Entry point address = 0x4022000 INFO: SPSR = 0x3c5 INFO: FCONF: Reading FW_CONFIG firmware configuration file from: 0x4001010 INFO: FCONF: Reading firmware configuration information for: dyn_cfg INFO: FCONF: Reading TB_FW firmware configuration file from: 0x4001300 INFO: FCONF: Reading firmware configuration information for: arm_sp NOTICE: BL2: v2.4(debug):v2.4-79-gb4b23c780-dirty NOTICE: BL2: Built : 15:36:16, Feb 26 2021 INFO: BL2: Doing platform setup INFO: Configuring TrustZone Controller INFO: Total 4 regions set. INFO: BL2: Loading image id 3 INFO: Loading image id=3 at address 0x4003000 INFO: Image id=3 loaded: 0x4003000 - 0x401722c INFO: BL2: Loading image id 23 INFO: Loading image id=23 at address 0x82000000 INFO: Image id=23 loaded: 0x82000000 - 0x82002348 INFO: BL2: Loading image id 25 INFO: Loading image id=25 at address 0x4001300 INFO: Image id=25 loaded: 0x4001300 - 0x4001348 INFO: BL2: Loading image id 4 INFO: Loading image id=4 at address 0x6000000 INFO: Image id=4 loaded: 0x6000000 - 0x601e250 INFO: BL2: Skip loading image id 21 INFO: BL2: Skip loading image id 22 INFO: BL2: Loading image id 26 INFO: Loading image id=26 at address 0x4001500 INFO: Image id=26 loaded: 0x4001500 - 0x4001b1b INFO: BL2: Loading image id 5 INFO: Loading image id=5 at address 0x88000000 INFO: Image id=5 loaded: 0x88000000 - 0x8800b2b0 INFO: BL2: Loading image id 34 INFO: Loading image id=34 at address 0x6280000 INFO: Image id=34 loaded: 0x6280000 - 0x62e2050 INFO: BL2: Loading image id 35 INFO: Loading image id=35 at address 0x7280000 INFO: Image id=35 loaded: 0x7280000 - 0x72e2050 NOTICE: BL1: Booting BL31 INFO: Entry point address = 0x4003000 INFO: SPSR = 0x3cd INFO: FCONF: Reading HW_CONFIG firmware configuration file from: 0x82000000 INFO: FCONF: Reading firmware configuration information for: cpu_timer INFO: FCONF: Reading firmware configuration information for: uart_config INFO: FCONF: Reading firmware configuration information for: topology INFO: FCONF: Reading firmware configuration information for: gicv3_config NOTICE: BL31: v2.4(debug):v2.4-79-gb4b23c780-dirty NOTICE: BL31: Built : 15:36:21, Feb 26 2021 INFO: GICv3 with legacy support detected. INFO: ARM GICv3 driver initialized in EL3 INFO: BL31: Initializing runtime services INFO: SPM Core setup done. INFO: BL31: Initializing BL32 NOTICE: Initialising hafnium INFO: text: 0x6000000 - 0x601a000 INFO: rodata: 0x601a000 - 0x601e000 INFO: data: 0x601e000 - 0x60a0000 INFO: Supported bits in physical address: 40 INFO: Stage 2 has 3 page table levels with 2 pages at the root. INFO: SPM: 0x84000069 0x0 0x0 0x0 0x0 0x0 0x0 0x0 INFO: Memory range: 0x6000000 - 0xaffffff INFO: Valid SP package magic. the valid magic number is 0x474b5053 Panic: Could not parse manifest: Property not found. ====================================================================== Now I am trying to be deep into the code to solve the problems by myself. But if anyone have any idea, I appreciate for your sharing. Sincerely, Yinhua ________________________________ From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of 胤桦陈 via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: Friday, February 26, 2021 16:48 To: raghu.ncstate(a)icloud.com <raghu.ncstate(a)icloud.com>; hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org> Subject: Re: [Hafnium] Trying to load two OPTEEs on hafnium Hi raghu, Thanks for your guidance! I have never heard of fvp_tb_fw_config.dts before! I will spend much more of time on solving my problems without your help! Now I can load one OPTEE on at addresses between 0x6000000 and 0x8000000 successfully. Now I meet two problems, I am trying to be deep into the code to solve the problems by myself. But if you have any idea, I appreciate for your sharing. Two Problems I met: 1. If I load the OPTEE at address not between 0x6000000 and 0x8000000, like 0x9280000, then there will be error "Invalid SP package magic". 2. I try to load two OPTEEs, the first at address 0x6280000, the second at address 0x7280000, and there is an error "Panic: Could not parse manifest: Property not found." My effort and the detailed logs are as follows. ==================================My effort and logs for the first problem==================================== 1. In the file <path-to-workspace>/optee_os/core/arch/arm/plat-vexpress/conf.mk change "CFG_TZDRAM_START ?=0x06281000" to "CFG_TZDRAM_START ?= 0x09281000" 2. In the file <path-to-workspace>/trusted-firmware-a/fdts/optee_sp_manifest.dts change "load-address = <0x6280000>" to "load-address = <0x9280000>" 3. In the file <path-to-workspace>/trusted-firmware-a/plat/arm/board/fvp/fdts/fvp_tb_fw_config.dts change load-address of op-tee from 0x6280000 to 0x9280000 4. In the file <path-to-workspace>/trusted-firmware-a/plat/arm/board/fvp/fdts/fvp_spmc_optee_sp_manifest.dts change load_address of vm1 from 0x6280000 to 0x9280000 5. Compile OPTEE CROSS_COMPILE64=aarch64-none-elf- PLATFORM=vexpress PLATFORM_FLAVOR=fvp CFG_ARM_GICV3=y CFG_CORE_SEL2_SPMC=y CFG_ARM64_core=y CFG_USER_TA_TARGETS=ta_arm64 CFG_TEE_CORE_DEBUG=y CFG_TEE_CORE_LOG_LEVEL=4 CFG_TEE_BENCHMARK=n CFG_WITH_STATS=y make 6. Compile ATF make CROSS_COMPILE=aarch64-none-elf- SPD=spmd CTX_INCLUDE_EL2_REGS=1 PLAT=fvp BL33=../tf-a-tests/build/fvp/debug/tftf.bin DEBUG=1 BL32=../hafnium/out/reference/secure_aem_v8a_fvp_clang/hafnium.bin ARM_ARCH_MINOR=4 SP_LAYOUT_FILE=sp_layout.json ARM_SPMC_MANIFEST_DTS=plat/arm/board/fvp/fdts/fvp_spmc_optee_sp_manifest.dts all fip 7. Run FVP ../fvp/Base_RevC_AEMv8A_pkg/models/Linux64_GCC-6.4/FVP_Base_RevC-2xAEMv8A -C pctl.startup=0.0.0.0 -C cluster0.NUM_CORES=4 -C cluster1.NUM_CORES=4 -C bp.secure_memory=1 -C bp.secureflashloader.fname=trusted-firmware-a/build/fvp/debug/bl1.bin -C bp.flashloader0.fname=trusted-firmware-a/build/fvp/debug/fip.bin -C cluster0.has_arm_v8-4=1 -C cluster1.has_arm_v8-4=1 -C cache_state_modelled=0 -C bp.pl011_uart0.out_file=fvp-uart0.log -C bp.pl011_uart1.out_file=fvp-uart1.log -C bp.vis.disable_visualisation=1 Logs from fvp-uart0.log (fvp-uart1.log is empty) NOTICE: Booting Trusted Firmware NOTICE: BL1: v2.4(debug):v2.4-79-gb4b23c780-dirty NOTICE: BL1: Built : 15:36:13, Feb 26 2021 INFO: BL1: RAM 0x4035000 - 0x403c000 INFO: Loading image id=31 at address 0x4001010 INFO: Image id=31 loaded: 0x4001010 - 0x4001234 INFO: FCONF: Config file with image ID:31 loaded at address = 0x4001010 INFO: Loading image id=24 at address 0x4001300 INFO: Image id=24 loaded: 0x4001300 - 0x4001466 INFO: FCONF: Config file with image ID:24 loaded at address = 0x4001300 INFO: BL1: Loading BL2 INFO: Loading image id=1 at address 0x4022000 INFO: Image id=1 loaded: 0x4022000 - 0x402bb49 NOTICE: BL1: Booting BL2 INFO: Entry point address = 0x4022000 INFO: SPSR = 0x3c5 INFO: FCONF: Reading FW_CONFIG firmware configuration file from: 0x4001010 INFO: FCONF: Reading firmware configuration information for: dyn_cfg INFO: FCONF: Reading TB_FW firmware configuration file from: 0x4001300 INFO: FCONF: Reading firmware configuration information for: arm_sp NOTICE: BL2: v2.4(debug):v2.4-79-gb4b23c780-dirty NOTICE: BL2: Built : 15:36:16, Feb 26 2021 INFO: BL2: Doing platform setup INFO: Configuring TrustZone Controller INFO: Total 4 regions set. INFO: BL2: Loading image id 3 INFO: Loading image id=3 at address 0x4003000 INFO: Image id=3 loaded: 0x4003000 - 0x401722c INFO: BL2: Loading image id 23 INFO: Loading image id=23 at address 0x82000000 INFO: Image id=23 loaded: 0x82000000 - 0x82002348 INFO: BL2: Loading image id 25 INFO: Loading image id=25 at address 0x4001300 INFO: Image id=25 loaded: 0x4001300 - 0x4001348 INFO: BL2: Loading image id 4 INFO: Loading image id=4 at address 0x6000000 INFO: Image id=4 loaded: 0x6000000 - 0x601e250 INFO: BL2: Skip loading image id 21 INFO: BL2: Skip loading image id 22 INFO: BL2: Loading image id 26 INFO: Loading image id=26 at address 0x4001500 INFO: Image id=26 loaded: 0x4001500 - 0x4001acf INFO: BL2: Loading image id 5 INFO: Loading image id=5 at address 0x88000000 INFO: Image id=5 loaded: 0x88000000 - 0x8800b2b0 INFO: BL2: Loading image id 34 INFO: Loading image id=34 at address 0x9280000 INFO: Image id=34 loaded: 0x9280000 - 0x92e2050 NOTICE: BL1: Booting BL31 INFO: Entry point address = 0x4003000 INFO: SPSR = 0x3cd INFO: FCONF: Reading HW_CONFIG firmware configuration file from: 0x82000000 INFO: FCONF: Reading firmware configuration information for: cpu_timer INFO: FCONF: Reading firmware configuration information for: uart_config INFO: FCONF: Reading firmware configuration information for: topology INFO: FCONF: Reading firmware configuration information for: gicv3_config NOTICE: BL31: v2.4(debug):v2.4-79-gb4b23c780-dirty NOTICE: BL31: Built : 15:36:21, Feb 26 2021 INFO: GICv3 with legacy support detected. INFO: ARM GICv3 driver initialized in EL3 INFO: BL31: Initializing runtime services INFO: SPM Core setup done. INFO: BL31: Initializing BL32 NOTICE: Initialising hafnium INFO: text: 0x6000000 - 0x601a000 INFO: rodata: 0x601a000 - 0x601e000 INFO: data: 0x601e000 - 0x60a0000 INFO: Supported bits in physical address: 40 INFO: Stage 2 has 3 page table levels with 2 pages at the root. INFO: SPM: 0x84000069 0x0 0x0 0x0 0x0 0x0 0x0 0x0 INFO: Memory range: 0x6000000 - 0xaffffff ERROR: Invalid SP package magic. the invalid magic number is 0xe7ff0010 Panic: Could not parse manifest: Hypervisor manifest entry not compatible with Hafnium. ================================My effort and logs for the second problem=================================== This part is sent by another email because of the limit of body length ===================================================================================================== Now I am trying to be deep into the code to solve the problems by myself. But if anyone have any idea, I appreciate for your sharing. Sincerely, Yinhua ________________________________ From: raghu.ncstate(a)icloud.com <raghu.ncstate(a)icloud.com> Sent: Friday, February 26, 2021 5:35 To: yinhua_chen(a)outlook.com <yinhua_chen(a)outlook.com>; hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org> Subject: RE: [Hafnium] Trying to load two OPTEEs on hafnium From the log it looks like there was nothing loaded at 0x8001000. Possible that you are missing the second entry for OPTEE in the SPMC manifest(fvp_spmc_optee_sp_manifest.dts). Might want to use the sptool to check if both your optee images were packaged. If not, you likely have your answer. If it is present, might want to make sure that fvp_tb_fw_config.dts has an entry for the second OPTEE partition to be loaded by BL2 at 0x8001000. For the partition to run, both OPTEE images have to be loaded by BL2, and both OPTEE images have processed by hafnium during initialization(when it processes the SPMC manifest). Thanks Raghu -----Original Message----- From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> On Behalf Of yinhua_chen--- via Hafnium Sent: Wednesday, February 24, 2021 7:23 PM To: hafnium(a)lists.trustedfirmware.org Subject: [Hafnium] Trying to load two OPTEEs on hafnium Hi all, I am trying to load two OPTEEs on hafnium. Thanks to the help from Hafnium open source community, now I can load one OPTEE on hafnium. The guidance I am following is attached at the end. In the guidance, the OPTEE is loaded at address 0x06280000. I think the first step to load two OPTEEs is to load an OPTEE at an address other than 0x06280000. I tried but failed. If there is anyone who can give me some advice, I would be very grateful. =====================The following is the effort I made=============== # NOTE: make sure gcc-arm-9.2-2019.12-x86_64-aarch64-none-elf/bin is in PATH 1. Loading one OPTEE at address 0x06280000 successfully by following the guidance attached below. 2. In the file <path-to-workspace>/optee_os/core/arch/arm/plat-vexpress/conf.mk change "CFG_TZDRAM_START ?=0x06281000" to "CFG_TZDRAM_START ?= 0x08002000" 3. In the file <path-to-workspace>//trusted-firmware-a/fdts/optee_sp_manifest.dts change "load-address = <0x6280000>" to "load-address = <0x8001000>" 4. Compile OPTEE CROSS_COMPILE64=aarch64-none-elf- PLATFORM=vexpress PLATFORM_FLAVOR=fvp CFG_ARM_GICV3=y CFG_CORE_SEL2_SPMC=y CFG_ARM64_core=y CFG_USER_TA_TARGETS=ta_arm64 CFG_TEE_CORE_DEBUG=y CFG_TEE_CORE_LOG_LEVEL=4 CFG_TEE_BENCHMARK=n CFG_WITH_STATS=y make 5. Compile ATF make CROSS_COMPILE=aarch64-none-elf- SPD=spmd CTX_INCLUDE_EL2_REGS=1 PLAT=fvp BL33=../tf-a-tests/build/fvp/debug/tftf.bin DEBUG=1 BL32=../hafnium/out/reference/secure_aem_v8a_fvp_clang/hafnium.bin ARM_ARCH_MINOR=4 SP_LAYOUT_FILE=sp_layout.json ARM_SPMC_MANIFEST_DTS=plat/arm/board/fvp/fdts/fvp_spmc_optee_sp_manifest.dts all fip 6. Run FVP ../fvp/Base_RevC_AEMv8A_pkg/models/Linux64_GCC-6.4/FVP_Base_RevC-2xAEMv8A -C pctl.startup=0.0.0.0 -C cluster0.NUM_CORES=4 -C cluster1.NUM_CORES=4 -C bp.secure_memory=1 -C bp.secureflashloader.fname=trusted-firmware-a/build/fvp/debug/bl1.bin -C bp.flashloader0.fname=trusted-firmware-a/build/fvp/debug/fip.bin -C cluster0.has_arm_v8-4=1 -C cluster1.has_arm_v8-4=1 -C cache_state_modelled=0 -C bp.pl011_uart0.out_file=fvp-uart0.log -C bp.pl011_uart1.out_file=fvp-uart1.log -C bp.vis.disable_visualisation=1 7. The error message from fvp-uart0.log (fvp-uart1.log is empty) NOTICE: Booting Trusted Firmware NOTICE: BL1: v2.4(debug):v2.4-79-gb4b23c780-dirty NOTICE: BL1: Built : 09:39:24, Feb 25 2021 INFO: BL1: RAM 0x4035000 - 0x403c000 INFO: Loading image id=31 at address 0x4001010 INFO: Image id=31 loaded: 0x4001010 - 0x4001234 INFO: FCONF: Config file with image ID:31 loaded at address = 0x4001010 INFO: Loading image id=24 at address 0x4001300 INFO: Image id=24 loaded: 0x4001300 - 0x4001466 INFO: FCONF: Config file with image ID:24 loaded at address = 0x4001300 INFO: BL1: Loading BL2 INFO: Loading image id=1 at address 0x4022000 INFO: Image id=1 loaded: 0x4022000 - 0x402bb49 NOTICE: BL1: Booting BL2 INFO: Entry point address = 0x4022000 INFO: SPSR = 0x3c5 INFO: FCONF: Reading FW_CONFIG firmware configuration file from: 0x4001010 INFO: FCONF: Reading firmware configuration information for: dyn_cfg INFO: FCONF: Reading TB_FW firmware configuration file from: 0x4001300 INFO: FCONF: Reading firmware configuration information for: arm_sp NOTICE: BL2: v2.4(debug):v2.4-79-gb4b23c780-dirty NOTICE: BL2: Built : 09:39:26, Feb 25 2021 INFO: BL2: Doing platform setup INFO: Configuring TrustZone Controller INFO: Total 4 regions set. INFO: BL2: Loading image id 3 INFO: Loading image id=3 at address 0x4003000 INFO: Image id=3 loaded: 0x4003000 - 0x401722c INFO: BL2: Loading image id 23 INFO: Loading image id=23 at address 0x82000000 INFO: Image id=23 loaded: 0x82000000 - 0x82002348 INFO: BL2: Loading image id 25 INFO: Loading image id=25 at address 0x4001300 INFO: Image id=25 loaded: 0x4001300 - 0x4001348 INFO: BL2: Loading image id 4 INFO: Loading image id=4 at address 0x6000000 INFO: Image id=4 loaded: 0x6000000 - 0x601e250 INFO: BL2: Skip loading image id 21 INFO: BL2: Skip loading image id 22 INFO: BL2: Loading image id 26 INFO: Loading image id=26 at address 0x4001500 INFO: Image id=26 loaded: 0x4001500 - 0x4001acf INFO: BL2: Loading image id 5 INFO: Loading image id=5 at address 0x88000000 INFO: Image id=5 loaded: 0x88000000 - 0x8800b2b0 INFO: BL2: Loading image id 34 INFO: Loading image id=34 at address 0x6280000 INFO: Image id=34 loaded: 0x6280000 - 0x62e2050 NOTICE: BL1: Booting BL31 INFO: Entry point address = 0x4003000 INFO: SPSR = 0x3cd INFO: FCONF: Reading HW_CONFIG firmware configuration file from: 0x82000000 INFO: FCONF: Reading firmware configuration information for: cpu_timer INFO: FCONF: Reading firmware configuration information for: uart_config INFO: FCONF: Reading firmware configuration information for: topology INFO: FCONF: Reading firmware configuration information for: gicv3_config NOTICE: BL31: v2.4(debug):v2.4-79-gb4b23c780-dirty NOTICE: BL31: Built : 09:39:31, Feb 25 2021 INFO: GICv3 with legacy support detected. INFO: ARM GICv3 driver initialized in EL3 INFO: BL31: Initializing runtime services INFO: SPM Core setup done. INFO: BL31: Initializing BL32 NOTICE: Initialising hafnium INFO: text: 0x6000000 - 0x601a000 INFO: rodata: 0x601a000 - 0x601e000 INFO: data: 0x601e000 - 0x60a0000 INFO: Supported bits in physical address: 40 INFO: Stage 2 has 3 page table levels with 2 pages at the root. INFO: SPM: 0x84000069 0x0 0x0 0x0 0x0 0x0 0x0 0x0 INFO: Memory range: 0x6000000 - 0x7ffffff INFO: SPM: 0x8400006f 0xffffffff8000ffff 0x0 0x1 0x0 0x6001340 0x601e000 0x0 INFO: In case FFA_MSG_SEND_DIRECT_REQ_SMC32, branch1 (this message is added by myself) INFO: SPM: 0x8400006f 0xffffffff8000ffff 0x0 0x1 0x10300 0x6001340 0x601e0a8 0x0 INFO: In case FFA_MSG_SEND_DIRECT_REQ_SMC32, branch1 (this message is added by myself) INFO: SPM: 0x8400006f 0xffffffff8000ffff 0x0 0x1 0x10200 0x6001340 0x601e090 0x0 INFO: In case FFA_MSG_SEND_DIRECT_REQ_SMC32, branch1 (this message is added by myself) INFO: SPM: 0x8400006f 0xffffffff8000ffff 0x0 0x1 0x10100 0x6001340 0x601e078 0x0 INFO: In case FFA_MSG_SEND_DIRECT_REQ_SMC32, branch1 (this message is added by myself) INFO: SPM: 0x8400006f 0xffffffff8000ffff 0x0 0x1 0x10000 0x6001340 0x601e060 0x0 INFO: In case FFA_MSG_SEND_DIRECT_REQ_SMC32, branch1 (this message is added by myself) INFO: SPM: 0x8400006f 0xffffffff8000ffff 0x0 0x1 0x300 0x6001340 0x601e048 0x0 INFO: In case FFA_MSG_SEND_DIRECT_REQ_SMC32, branch1 (this message is added by myself) INFO: SPM: 0x8400006f 0xffffffff8000ffff 0x0 0x1 0x200 0x6001340 0x601e030 0x0 INFO: In case FFA_MSG_SEND_DIRECT_REQ_SMC32, branch1 (this message is added by myself) INFO: SPM: 0x8400006f 0xffffffff8000ffff 0x0 0x1 0x100 0x6001340 0x601e018 0x0 INFO: In case FFA_MSG_SEND_DIRECT_REQ_SMC32, branch1 (this message is added by myself) INFO: Loaded primary VM with 8 vCPUs, entry at 0x8001000. INFO: Hafnium initialisation completed WARNING: Stage-2 page fault: pc=0x8002000, vmid=32769, vcpu=0, vaddr=0x8002000, ipaddr=0x0, mode=0x4 NOTICE: Injecting Instruction Abort exception into VM32769. WARNING: Stage-2 page fault: pc=0x200, vmid=32769, vcpu=0, vaddr=0x200, ipaddr=0x200, mode=0x4 NOTICE: Injecting Instruction Abort exception into VM32769. WARNING: Stage-2 page fault: pc=0x200, vmid=32769, vcpu=0, vaddr=0x200, ipaddr=0x200, mode=0x4 NOTICE: Injecting Instruction Abort exception into VM32769. WARNING: Stage-2 page fault: pc=0x200, vmid=32769, vcpu=0, vaddr=0x200, ipaddr=0x200, mode=0x4 NOTICE: Injecting Instruction Abort exception into VM32769. . . . (infinite loop . . .) ============The guidance from Oliver Deprez to load one OPTEE============ # NOTE: make sure gcc-arm-9.2-2019.12-x86_64-aarch64-none-elf/bin is in PATH mkdir workspace; cd workspace # Hafnium # https://review.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/HEAD/d… git clone https://git.trustedfirmware.org/hafnium/hafnium.git; cd hafnium git fetch "https://review.trustedfirmware.org/hafnium/hafnium" refs/changes/11/6011/16 && git checkout FETCH_HEAD git checkout -b spmc git submodule update --init make PROJECT=reference cd .. # OPTEE # https://optee.readthedocs.io/en/latest/building/prerequisites.html#prerequi… git clone https://git.trustedfirmware.org/OP-TEE/optee_os.git -b ffa_rel_proto; cd optee_os # Adjust TEE start address perl -pi -e 's/CFG_TZDRAM_START \?= 0x06280000/CFG_TZDRAM_START \?= 0x06281000/' core/arch/arm/plat-vexpress/conf.mk CROSS_COMPILE64=aarch64-none-elf- PLATFORM=vexpress PLATFORM_FLAVOR=fvp CFG_ARM_GICV3=y CFG_CORE_SEL2_SPMC=y CFG_ARM64_core=y CFG_USER_TA_TARGETS=ta_arm64 CFG_TEE_CORE_DEBUG=y CFG_TEE_CORE_LOG_LEVEL=4 CFG_TEE_BENCHMARK=n CFG_WITH_STATS=y make cd .. # TF-A-tests git clone https://git.trustedfirmware.org/TF-A/tf-a-tests.git; cd tf-a-tests make CROSS_COMPILE=aarch64-none-elf- PLAT=fvp DEBUG=1 TESTS=spm -j4 cd .. # TF-A # git clone https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git; cd trusted-firmware-a git checkout b4b23c780c0763ce01ac21de1a0e79287677405f -b spmc #{ # "op-tee" : { # "image": "../optee_os/out/arm-plat-vexpress/core/tee-pager_v2.bin", # "pm": "fdts/optee_sp_manifest.dts" # } #} echo \ "{ \ \"op-tee\" : { \ \"image\": \"../optee_os/out/arm-plat-vexpress/core/tee-pager_v2.bin\", \ \"pm\": \"fdts/optee_sp_manifest.dts\" \ } }" > sp_layout.json make CROSS_COMPILE=aarch64-none-elf- SPD=spmd CTX_INCLUDE_EL2_REGS=1 PLAT=fvp BL33=../tf-a-tests/build/fvp/debug/tftf.bin DEBUG=1 BL32=../hafnium/out/reference/secure_aem_v8a_fvp_clang/hafnium.bin ARM_ARCH_MINOR=4 SP_LAYOUT_FILE=sp_layout.json ARM_SPMC_MANIFEST_DTS=plat/arm/board/fvp/fdts/fvp_spmc_optee_sp_manifest.dts all fip cd .. # Run FVP ../fvp/Base_RevC_AEMv8A_pkg/models/Linux64_GCC-6.4/FVP_Base_RevC-2xAEMv8A -C pctl.startup=0.0.0.0 -C cluster0.NUM_CORES=4 -C cluster1.NUM_CORES=4 -C bp.secure_memory=1 -C bp.secureflashloader.fname=trusted-firmware-a/build/fvp/debug/bl1.bin -C bp.flashloader0.fname=trusted-firmware-a/build/fvp/debug/fip.bin -C cluster0.has_arm_v8-4=1 -C cluster1.has_arm_v8-4=1 -C cache_state_modelled=0 -C bp.pl011_uart0.out_file=fvp-uart0.log -C bp.pl011_uart1.out_file=fvp-uart1.log -C bp.vis.disable_visualisation=1 ============================= I appreciate for any possible help! Thanks Yinhua -- 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

4 years, 2 months

1
0
0 0

Re: [Hafnium] Trying to load two OPTEEs on hafnium

by raghu.ncstate＠icloud.com

>From the log it looks like there was nothing loaded at 0x8001000. Possible that you are missing the second entry for OPTEE in the SPMC manifest(fvp_spmc_optee_sp_manifest.dts). Might want to use the sptool to check if both your optee images were packaged. If not, you likely have your answer. If it is present, might want to make sure that fvp_tb_fw_config.dts has an entry for the second OPTEE partition to be loaded by BL2 at 0x8001000. For the partition to run, both OPTEE images have to be loaded by BL2, and both OPTEE images have processed by hafnium during initialization(when it processes the SPMC manifest). Thanks Raghu -----Original Message----- From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> On Behalf Of yinhua_chen--- via Hafnium Sent: Wednesday, February 24, 2021 7:23 PM To: hafnium(a)lists.trustedfirmware.org Subject: [Hafnium] Trying to load two OPTEEs on hafnium Hi all, I am trying to load two OPTEEs on hafnium. Thanks to the help from Hafnium open source community, now I can load one OPTEE on hafnium. The guidance I am following is attached at the end. In the guidance, the OPTEE is loaded at address 0x06280000. I think the first step to load two OPTEEs is to load an OPTEE at an address other than 0x06280000. I tried but failed. If there is anyone who can give me some advice, I would be very grateful. =====================The following is the effort I made=============== # NOTE: make sure gcc-arm-9.2-2019.12-x86_64-aarch64-none-elf/bin is in PATH 1. Loading one OPTEE at address 0x06280000 successfully by following the guidance attached below. 2. In the file <path-to-workspace>/optee_os/core/arch/arm/plat-vexpress/conf.mk change "CFG_TZDRAM_START ?=0x06281000" to "CFG_TZDRAM_START ?= 0x08002000" 3. In the file <path-to-workspace>//trusted-firmware-a/fdts/optee_sp_manifest.dts change "load-address = <0x6280000>" to "load-address = <0x8001000>" 4. Compile OPTEE CROSS_COMPILE64=aarch64-none-elf- PLATFORM=vexpress PLATFORM_FLAVOR=fvp CFG_ARM_GICV3=y CFG_CORE_SEL2_SPMC=y CFG_ARM64_core=y CFG_USER_TA_TARGETS=ta_arm64 CFG_TEE_CORE_DEBUG=y CFG_TEE_CORE_LOG_LEVEL=4 CFG_TEE_BENCHMARK=n CFG_WITH_STATS=y make 5. Compile ATF make CROSS_COMPILE=aarch64-none-elf- SPD=spmd CTX_INCLUDE_EL2_REGS=1 PLAT=fvp BL33=../tf-a-tests/build/fvp/debug/tftf.bin DEBUG=1 BL32=../hafnium/out/reference/secure_aem_v8a_fvp_clang/hafnium.bin ARM_ARCH_MINOR=4 SP_LAYOUT_FILE=sp_layout.json ARM_SPMC_MANIFEST_DTS=plat/arm/board/fvp/fdts/fvp_spmc_optee_sp_manifest.dts all fip 6. Run FVP ../fvp/Base_RevC_AEMv8A_pkg/models/Linux64_GCC-6.4/FVP_Base_RevC-2xAEMv8A -C pctl.startup=0.0.0.0 -C cluster0.NUM_CORES=4 -C cluster1.NUM_CORES=4 -C bp.secure_memory=1 -C bp.secureflashloader.fname=trusted-firmware-a/build/fvp/debug/bl1.bin -C bp.flashloader0.fname=trusted-firmware-a/build/fvp/debug/fip.bin -C cluster0.has_arm_v8-4=1 -C cluster1.has_arm_v8-4=1 -C cache_state_modelled=0 -C bp.pl011_uart0.out_file=fvp-uart0.log -C bp.pl011_uart1.out_file=fvp-uart1.log -C bp.vis.disable_visualisation=1 7. The error message from fvp-uart0.log (fvp-uart1.log is empty) NOTICE: Booting Trusted Firmware NOTICE: BL1: v2.4(debug):v2.4-79-gb4b23c780-dirty NOTICE: BL1: Built : 09:39:24, Feb 25 2021 INFO: BL1: RAM 0x4035000 - 0x403c000 INFO: Loading image id=31 at address 0x4001010 INFO: Image id=31 loaded: 0x4001010 - 0x4001234 INFO: FCONF: Config file with image ID:31 loaded at address = 0x4001010 INFO: Loading image id=24 at address 0x4001300 INFO: Image id=24 loaded: 0x4001300 - 0x4001466 INFO: FCONF: Config file with image ID:24 loaded at address = 0x4001300 INFO: BL1: Loading BL2 INFO: Loading image id=1 at address 0x4022000 INFO: Image id=1 loaded: 0x4022000 - 0x402bb49 NOTICE: BL1: Booting BL2 INFO: Entry point address = 0x4022000 INFO: SPSR = 0x3c5 INFO: FCONF: Reading FW_CONFIG firmware configuration file from: 0x4001010 INFO: FCONF: Reading firmware configuration information for: dyn_cfg INFO: FCONF: Reading TB_FW firmware configuration file from: 0x4001300 INFO: FCONF: Reading firmware configuration information for: arm_sp NOTICE: BL2: v2.4(debug):v2.4-79-gb4b23c780-dirty NOTICE: BL2: Built : 09:39:26, Feb 25 2021 INFO: BL2: Doing platform setup INFO: Configuring TrustZone Controller INFO: Total 4 regions set. INFO: BL2: Loading image id 3 INFO: Loading image id=3 at address 0x4003000 INFO: Image id=3 loaded: 0x4003000 - 0x401722c INFO: BL2: Loading image id 23 INFO: Loading image id=23 at address 0x82000000 INFO: Image id=23 loaded: 0x82000000 - 0x82002348 INFO: BL2: Loading image id 25 INFO: Loading image id=25 at address 0x4001300 INFO: Image id=25 loaded: 0x4001300 - 0x4001348 INFO: BL2: Loading image id 4 INFO: Loading image id=4 at address 0x6000000 INFO: Image id=4 loaded: 0x6000000 - 0x601e250 INFO: BL2: Skip loading image id 21 INFO: BL2: Skip loading image id 22 INFO: BL2: Loading image id 26 INFO: Loading image id=26 at address 0x4001500 INFO: Image id=26 loaded: 0x4001500 - 0x4001acf INFO: BL2: Loading image id 5 INFO: Loading image id=5 at address 0x88000000 INFO: Image id=5 loaded: 0x88000000 - 0x8800b2b0 INFO: BL2: Loading image id 34 INFO: Loading image id=34 at address 0x6280000 INFO: Image id=34 loaded: 0x6280000 - 0x62e2050 NOTICE: BL1: Booting BL31 INFO: Entry point address = 0x4003000 INFO: SPSR = 0x3cd INFO: FCONF: Reading HW_CONFIG firmware configuration file from: 0x82000000 INFO: FCONF: Reading firmware configuration information for: cpu_timer INFO: FCONF: Reading firmware configuration information for: uart_config INFO: FCONF: Reading firmware configuration information for: topology INFO: FCONF: Reading firmware configuration information for: gicv3_config NOTICE: BL31: v2.4(debug):v2.4-79-gb4b23c780-dirty NOTICE: BL31: Built : 09:39:31, Feb 25 2021 INFO: GICv3 with legacy support detected. INFO: ARM GICv3 driver initialized in EL3 INFO: BL31: Initializing runtime services INFO: SPM Core setup done. INFO: BL31: Initializing BL32 NOTICE: Initialising hafnium INFO: text: 0x6000000 - 0x601a000 INFO: rodata: 0x601a000 - 0x601e000 INFO: data: 0x601e000 - 0x60a0000 INFO: Supported bits in physical address: 40 INFO: Stage 2 has 3 page table levels with 2 pages at the root. INFO: SPM: 0x84000069 0x0 0x0 0x0 0x0 0x0 0x0 0x0 INFO: Memory range: 0x6000000 - 0x7ffffff INFO: SPM: 0x8400006f 0xffffffff8000ffff 0x0 0x1 0x0 0x6001340 0x601e000 0x0 INFO: In case FFA_MSG_SEND_DIRECT_REQ_SMC32, branch1 (this message is added by myself) INFO: SPM: 0x8400006f 0xffffffff8000ffff 0x0 0x1 0x10300 0x6001340 0x601e0a8 0x0 INFO: In case FFA_MSG_SEND_DIRECT_REQ_SMC32, branch1 (this message is added by myself) INFO: SPM: 0x8400006f 0xffffffff8000ffff 0x0 0x1 0x10200 0x6001340 0x601e090 0x0 INFO: In case FFA_MSG_SEND_DIRECT_REQ_SMC32, branch1 (this message is added by myself) INFO: SPM: 0x8400006f 0xffffffff8000ffff 0x0 0x1 0x10100 0x6001340 0x601e078 0x0 INFO: In case FFA_MSG_SEND_DIRECT_REQ_SMC32, branch1 (this message is added by myself) INFO: SPM: 0x8400006f 0xffffffff8000ffff 0x0 0x1 0x10000 0x6001340 0x601e060 0x0 INFO: In case FFA_MSG_SEND_DIRECT_REQ_SMC32, branch1 (this message is added by myself) INFO: SPM: 0x8400006f 0xffffffff8000ffff 0x0 0x1 0x300 0x6001340 0x601e048 0x0 INFO: In case FFA_MSG_SEND_DIRECT_REQ_SMC32, branch1 (this message is added by myself) INFO: SPM: 0x8400006f 0xffffffff8000ffff 0x0 0x1 0x200 0x6001340 0x601e030 0x0 INFO: In case FFA_MSG_SEND_DIRECT_REQ_SMC32, branch1 (this message is added by myself) INFO: SPM: 0x8400006f 0xffffffff8000ffff 0x0 0x1 0x100 0x6001340 0x601e018 0x0 INFO: In case FFA_MSG_SEND_DIRECT_REQ_SMC32, branch1 (this message is added by myself) INFO: Loaded primary VM with 8 vCPUs, entry at 0x8001000. INFO: Hafnium initialisation completed WARNING: Stage-2 page fault: pc=0x8002000, vmid=32769, vcpu=0, vaddr=0x8002000, ipaddr=0x0, mode=0x4 NOTICE: Injecting Instruction Abort exception into VM32769. WARNING: Stage-2 page fault: pc=0x200, vmid=32769, vcpu=0, vaddr=0x200, ipaddr=0x200, mode=0x4 NOTICE: Injecting Instruction Abort exception into VM32769. WARNING: Stage-2 page fault: pc=0x200, vmid=32769, vcpu=0, vaddr=0x200, ipaddr=0x200, mode=0x4 NOTICE: Injecting Instruction Abort exception into VM32769. WARNING: Stage-2 page fault: pc=0x200, vmid=32769, vcpu=0, vaddr=0x200, ipaddr=0x200, mode=0x4 NOTICE: Injecting Instruction Abort exception into VM32769. . . . (infinite loop . . .) ============The guidance from Oliver Deprez to load one OPTEE============ # NOTE: make sure gcc-arm-9.2-2019.12-x86_64-aarch64-none-elf/bin is in PATH mkdir workspace; cd workspace # Hafnium # https://review.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/HEAD/d… git clone https://git.trustedfirmware.org/hafnium/hafnium.git; cd hafnium git fetch "https://review.trustedfirmware.org/hafnium/hafnium" refs/changes/11/6011/16 && git checkout FETCH_HEAD git checkout -b spmc git submodule update --init make PROJECT=reference cd .. # OPTEE # https://optee.readthedocs.io/en/latest/building/prerequisites.html#prerequi… git clone https://git.trustedfirmware.org/OP-TEE/optee_os.git -b ffa_rel_proto; cd optee_os # Adjust TEE start address perl -pi -e 's/CFG_TZDRAM_START \?= 0x06280000/CFG_TZDRAM_START \?= 0x06281000/' core/arch/arm/plat-vexpress/conf.mk CROSS_COMPILE64=aarch64-none-elf- PLATFORM=vexpress PLATFORM_FLAVOR=fvp CFG_ARM_GICV3=y CFG_CORE_SEL2_SPMC=y CFG_ARM64_core=y CFG_USER_TA_TARGETS=ta_arm64 CFG_TEE_CORE_DEBUG=y CFG_TEE_CORE_LOG_LEVEL=4 CFG_TEE_BENCHMARK=n CFG_WITH_STATS=y make cd .. # TF-A-tests git clone https://git.trustedfirmware.org/TF-A/tf-a-tests.git; cd tf-a-tests make CROSS_COMPILE=aarch64-none-elf- PLAT=fvp DEBUG=1 TESTS=spm -j4 cd .. # TF-A # git clone https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git; cd trusted-firmware-a git checkout b4b23c780c0763ce01ac21de1a0e79287677405f -b spmc #{ # "op-tee" : { # "image": "../optee_os/out/arm-plat-vexpress/core/tee-pager_v2.bin", # "pm": "fdts/optee_sp_manifest.dts" # } #} echo \ "{ \ \"op-tee\" : { \ \"image\": \"../optee_os/out/arm-plat-vexpress/core/tee-pager_v2.bin\", \ \"pm\": \"fdts/optee_sp_manifest.dts\" \ } }" > sp_layout.json make CROSS_COMPILE=aarch64-none-elf- SPD=spmd CTX_INCLUDE_EL2_REGS=1 PLAT=fvp BL33=../tf-a-tests/build/fvp/debug/tftf.bin DEBUG=1 BL32=../hafnium/out/reference/secure_aem_v8a_fvp_clang/hafnium.bin ARM_ARCH_MINOR=4 SP_LAYOUT_FILE=sp_layout.json ARM_SPMC_MANIFEST_DTS=plat/arm/board/fvp/fdts/fvp_spmc_optee_sp_manifest.dts all fip cd .. # Run FVP ../fvp/Base_RevC_AEMv8A_pkg/models/Linux64_GCC-6.4/FVP_Base_RevC-2xAEMv8A -C pctl.startup=0.0.0.0 -C cluster0.NUM_CORES=4 -C cluster1.NUM_CORES=4 -C bp.secure_memory=1 -C bp.secureflashloader.fname=trusted-firmware-a/build/fvp/debug/bl1.bin -C bp.flashloader0.fname=trusted-firmware-a/build/fvp/debug/fip.bin -C cluster0.has_arm_v8-4=1 -C cluster1.has_arm_v8-4=1 -C cache_state_modelled=0 -C bp.pl011_uart0.out_file=fvp-uart0.log -C bp.pl011_uart1.out_file=fvp-uart1.log -C bp.vis.disable_visualisation=1 ============================= I appreciate for any possible help! Thanks Yinhua -- Hafnium mailing list Hafnium(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/hafnium

4 years, 2 months

2
1
0 0

Trying to load two OPTEEs on hafnium

by yinhua_chen＠outlook.com

Hi all, I am trying to load two OPTEEs on hafnium. Thanks to the help from Hafnium open source community, now I can load one OPTEE on hafnium. The guidance I am following is attached at the end. In the guidance, the OPTEE is loaded at address 0x06280000. I think the first step to load two OPTEEs is to load an OPTEE at an address other than 0x06280000. I tried but failed. If there is anyone who can give me some advice, I would be very grateful. =====================The following is the effort I made=============== # NOTE: make sure gcc-arm-9.2-2019.12-x86_64-aarch64-none-elf/bin is in PATH 1. Loading one OPTEE at address 0x06280000 successfully by following the guidance attached below. 2. In the file <path-to-workspace>/optee_os/core/arch/arm/plat-vexpress/conf.mk change "CFG_TZDRAM_START ?=0x06281000" to "CFG_TZDRAM_START ?= 0x08002000" 3. In the file <path-to-workspace>//trusted-firmware-a/fdts/optee_sp_manifest.dts change "load-address = <0x6280000>" to "load-address = <0x8001000>" 4. Compile OPTEE CROSS_COMPILE64=aarch64-none-elf- PLATFORM=vexpress PLATFORM_FLAVOR=fvp CFG_ARM_GICV3=y CFG_CORE_SEL2_SPMC=y CFG_ARM64_core=y CFG_USER_TA_TARGETS=ta_arm64 CFG_TEE_CORE_DEBUG=y CFG_TEE_CORE_LOG_LEVEL=4 CFG_TEE_BENCHMARK=n CFG_WITH_STATS=y make 5. Compile ATF make CROSS_COMPILE=aarch64-none-elf- SPD=spmd CTX_INCLUDE_EL2_REGS=1 PLAT=fvp BL33=../tf-a-tests/build/fvp/debug/tftf.bin DEBUG=1 BL32=../hafnium/out/reference/secure_aem_v8a_fvp_clang/hafnium.bin ARM_ARCH_MINOR=4 SP_LAYOUT_FILE=sp_layout.json ARM_SPMC_MANIFEST_DTS=plat/arm/board/fvp/fdts/fvp_spmc_optee_sp_manifest.dts all fip 6. Run FVP ../fvp/Base_RevC_AEMv8A_pkg/models/Linux64_GCC-6.4/FVP_Base_RevC-2xAEMv8A -C pctl.startup=0.0.0.0 -C cluster0.NUM_CORES=4 -C cluster1.NUM_CORES=4 -C bp.secure_memory=1 -C bp.secureflashloader.fname=trusted-firmware-a/build/fvp/debug/bl1.bin -C bp.flashloader0.fname=trusted-firmware-a/build/fvp/debug/fip.bin -C cluster0.has_arm_v8-4=1 -C cluster1.has_arm_v8-4=1 -C cache_state_modelled=0 -C bp.pl011_uart0.out_file=fvp-uart0.log -C bp.pl011_uart1.out_file=fvp-uart1.log -C bp.vis.disable_visualisation=1 7. The error message from fvp-uart0.log (fvp-uart1.log is empty) NOTICE: Booting Trusted Firmware NOTICE: BL1: v2.4(debug):v2.4-79-gb4b23c780-dirty NOTICE: BL1: Built : 09:39:24, Feb 25 2021 INFO: BL1: RAM 0x4035000 - 0x403c000 INFO: Loading image id=31 at address 0x4001010 INFO: Image id=31 loaded: 0x4001010 - 0x4001234 INFO: FCONF: Config file with image ID:31 loaded at address = 0x4001010 INFO: Loading image id=24 at address 0x4001300 INFO: Image id=24 loaded: 0x4001300 - 0x4001466 INFO: FCONF: Config file with image ID:24 loaded at address = 0x4001300 INFO: BL1: Loading BL2 INFO: Loading image id=1 at address 0x4022000 INFO: Image id=1 loaded: 0x4022000 - 0x402bb49 NOTICE: BL1: Booting BL2 INFO: Entry point address = 0x4022000 INFO: SPSR = 0x3c5 INFO: FCONF: Reading FW_CONFIG firmware configuration file from: 0x4001010 INFO: FCONF: Reading firmware configuration information for: dyn_cfg INFO: FCONF: Reading TB_FW firmware configuration file from: 0x4001300 INFO: FCONF: Reading firmware configuration information for: arm_sp NOTICE: BL2: v2.4(debug):v2.4-79-gb4b23c780-dirty NOTICE: BL2: Built : 09:39:26, Feb 25 2021 INFO: BL2: Doing platform setup INFO: Configuring TrustZone Controller INFO: Total 4 regions set. INFO: BL2: Loading image id 3 INFO: Loading image id=3 at address 0x4003000 INFO: Image id=3 loaded: 0x4003000 - 0x401722c INFO: BL2: Loading image id 23 INFO: Loading image id=23 at address 0x82000000 INFO: Image id=23 loaded: 0x82000000 - 0x82002348 INFO: BL2: Loading image id 25 INFO: Loading image id=25 at address 0x4001300 INFO: Image id=25 loaded: 0x4001300 - 0x4001348 INFO: BL2: Loading image id 4 INFO: Loading image id=4 at address 0x6000000 INFO: Image id=4 loaded: 0x6000000 - 0x601e250 INFO: BL2: Skip loading image id 21 INFO: BL2: Skip loading image id 22 INFO: BL2: Loading image id 26 INFO: Loading image id=26 at address 0x4001500 INFO: Image id=26 loaded: 0x4001500 - 0x4001acf INFO: BL2: Loading image id 5 INFO: Loading image id=5 at address 0x88000000 INFO: Image id=5 loaded: 0x88000000 - 0x8800b2b0 INFO: BL2: Loading image id 34 INFO: Loading image id=34 at address 0x6280000 INFO: Image id=34 loaded: 0x6280000 - 0x62e2050 NOTICE: BL1: Booting BL31 INFO: Entry point address = 0x4003000 INFO: SPSR = 0x3cd INFO: FCONF: Reading HW_CONFIG firmware configuration file from: 0x82000000 INFO: FCONF: Reading firmware configuration information for: cpu_timer INFO: FCONF: Reading firmware configuration information for: uart_config INFO: FCONF: Reading firmware configuration information for: topology INFO: FCONF: Reading firmware configuration information for: gicv3_config NOTICE: BL31: v2.4(debug):v2.4-79-gb4b23c780-dirty NOTICE: BL31: Built : 09:39:31, Feb 25 2021 INFO: GICv3 with legacy support detected. INFO: ARM GICv3 driver initialized in EL3 INFO: BL31: Initializing runtime services INFO: SPM Core setup done. INFO: BL31: Initializing BL32 NOTICE: Initialising hafnium INFO: text: 0x6000000 - 0x601a000 INFO: rodata: 0x601a000 - 0x601e000 INFO: data: 0x601e000 - 0x60a0000 INFO: Supported bits in physical address: 40 INFO: Stage 2 has 3 page table levels with 2 pages at the root. INFO: SPM: 0x84000069 0x0 0x0 0x0 0x0 0x0 0x0 0x0 INFO: Memory range: 0x6000000 - 0x7ffffff INFO: SPM: 0x8400006f 0xffffffff8000ffff 0x0 0x1 0x0 0x6001340 0x601e000 0x0 INFO: In case FFA_MSG_SEND_DIRECT_REQ_SMC32, branch1 (this message is added by myself) INFO: SPM: 0x8400006f 0xffffffff8000ffff 0x0 0x1 0x10300 0x6001340 0x601e0a8 0x0 INFO: In case FFA_MSG_SEND_DIRECT_REQ_SMC32, branch1 (this message is added by myself) INFO: SPM: 0x8400006f 0xffffffff8000ffff 0x0 0x1 0x10200 0x6001340 0x601e090 0x0 INFO: In case FFA_MSG_SEND_DIRECT_REQ_SMC32, branch1 (this message is added by myself) INFO: SPM: 0x8400006f 0xffffffff8000ffff 0x0 0x1 0x10100 0x6001340 0x601e078 0x0 INFO: In case FFA_MSG_SEND_DIRECT_REQ_SMC32, branch1 (this message is added by myself) INFO: SPM: 0x8400006f 0xffffffff8000ffff 0x0 0x1 0x10000 0x6001340 0x601e060 0x0 INFO: In case FFA_MSG_SEND_DIRECT_REQ_SMC32, branch1 (this message is added by myself) INFO: SPM: 0x8400006f 0xffffffff8000ffff 0x0 0x1 0x300 0x6001340 0x601e048 0x0 INFO: In case FFA_MSG_SEND_DIRECT_REQ_SMC32, branch1 (this message is added by myself) INFO: SPM: 0x8400006f 0xffffffff8000ffff 0x0 0x1 0x200 0x6001340 0x601e030 0x0 INFO: In case FFA_MSG_SEND_DIRECT_REQ_SMC32, branch1 (this message is added by myself) INFO: SPM: 0x8400006f 0xffffffff8000ffff 0x0 0x1 0x100 0x6001340 0x601e018 0x0 INFO: In case FFA_MSG_SEND_DIRECT_REQ_SMC32, branch1 (this message is added by myself) INFO: Loaded primary VM with 8 vCPUs, entry at 0x8001000. INFO: Hafnium initialisation completed WARNING: Stage-2 page fault: pc=0x8002000, vmid=32769, vcpu=0, vaddr=0x8002000, ipaddr=0x0, mode=0x4 NOTICE: Injecting Instruction Abort exception into VM32769. WARNING: Stage-2 page fault: pc=0x200, vmid=32769, vcpu=0, vaddr=0x200, ipaddr=0x200, mode=0x4 NOTICE: Injecting Instruction Abort exception into VM32769. WARNING: Stage-2 page fault: pc=0x200, vmid=32769, vcpu=0, vaddr=0x200, ipaddr=0x200, mode=0x4 NOTICE: Injecting Instruction Abort exception into VM32769. WARNING: Stage-2 page fault: pc=0x200, vmid=32769, vcpu=0, vaddr=0x200, ipaddr=0x200, mode=0x4 NOTICE: Injecting Instruction Abort exception into VM32769. . . . (infinite loop . . .) ============The guidance from Oliver Deprez to load one OPTEE============ # NOTE: make sure gcc-arm-9.2-2019.12-x86_64-aarch64-none-elf/bin is in PATH mkdir workspace; cd workspace # Hafnium # https://review.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/HEAD/d… git clone https://git.trustedfirmware.org/hafnium/hafnium.git; cd hafnium git fetch "https://review.trustedfirmware.org/hafnium/hafnium" refs/changes/11/6011/16 && git checkout FETCH_HEAD git checkout -b spmc git submodule update --init make PROJECT=reference cd .. # OPTEE # https://optee.readthedocs.io/en/latest/building/prerequisites.html#prerequi… git clone https://git.trustedfirmware.org/OP-TEE/optee_os.git -b ffa_rel_proto; cd optee_os # Adjust TEE start address perl -pi -e 's/CFG_TZDRAM_START \?= 0x06280000/CFG_TZDRAM_START \?= 0x06281000/' core/arch/arm/plat-vexpress/conf.mk CROSS_COMPILE64=aarch64-none-elf- PLATFORM=vexpress PLATFORM_FLAVOR=fvp CFG_ARM_GICV3=y CFG_CORE_SEL2_SPMC=y CFG_ARM64_core=y CFG_USER_TA_TARGETS=ta_arm64 CFG_TEE_CORE_DEBUG=y CFG_TEE_CORE_LOG_LEVEL=4 CFG_TEE_BENCHMARK=n CFG_WITH_STATS=y make cd .. # TF-A-tests git clone https://git.trustedfirmware.org/TF-A/tf-a-tests.git; cd tf-a-tests make CROSS_COMPILE=aarch64-none-elf- PLAT=fvp DEBUG=1 TESTS=spm -j4 cd .. # TF-A # git clone https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git; cd trusted-firmware-a git checkout b4b23c780c0763ce01ac21de1a0e79287677405f -b spmc #{ # "op-tee" : { # "image": "../optee_os/out/arm-plat-vexpress/core/tee-pager_v2.bin", # "pm": "fdts/optee_sp_manifest.dts" # } #} echo \ "{ \ \"op-tee\" : { \ \"image\": \"../optee_os/out/arm-plat-vexpress/core/tee-pager_v2.bin\", \ \"pm\": \"fdts/optee_sp_manifest.dts\" \ } }" > sp_layout.json make CROSS_COMPILE=aarch64-none-elf- SPD=spmd CTX_INCLUDE_EL2_REGS=1 PLAT=fvp BL33=../tf-a-tests/build/fvp/debug/tftf.bin DEBUG=1 BL32=../hafnium/out/reference/secure_aem_v8a_fvp_clang/hafnium.bin ARM_ARCH_MINOR=4 SP_LAYOUT_FILE=sp_layout.json ARM_SPMC_MANIFEST_DTS=plat/arm/board/fvp/fdts/fvp_spmc_optee_sp_manifest.dts all fip cd .. # Run FVP ../fvp/Base_RevC_AEMv8A_pkg/models/Linux64_GCC-6.4/FVP_Base_RevC-2xAEMv8A -C pctl.startup=0.0.0.0 -C cluster0.NUM_CORES=4 -C cluster1.NUM_CORES=4 -C bp.secure_memory=1 -C bp.secureflashloader.fname=trusted-firmware-a/build/fvp/debug/bl1.bin -C bp.flashloader0.fname=trusted-firmware-a/build/fvp/debug/fip.bin -C cluster0.has_arm_v8-4=1 -C cluster1.has_arm_v8-4=1 -C cache_state_modelled=0 -C bp.pl011_uart0.out_file=fvp-uart0.log -C bp.pl011_uart1.out_file=fvp-uart1.log -C bp.vis.disable_visualisation=1 ============================= I appreciate for any possible help! Thanks Yinhua

4 years, 2 months

1
0
0 0

Re: [Hafnium] GN build system Question

by Joao Alves

Hi, I've come across the same question when recently working on some patches for the Hafnium CI (https://review.trustedfirmware.org/c/hafnium/hafnium/+/7405). I was trying to setup a standalone SP, trying to reuse most of what was available for a primary VM. I ended up taking the approach of defining a source_set specific to the standalone SP (https://review.trustedfirmware.org/c/hafnium/hafnium/+/7405/22/test/hftest/…), extending only the public configurations. To build the SP, just defined a vm_kernel target referencing the newly defined source_set (https://review.trustedfirmware.org/c/hafnium/hafnium/+/7405/22/test/vmapi/f…) in the target's dependencies. The documentation for the source_set (https://gn.googlesource.com/gn/+/master/docs/reference.md#func_source_set) says: "In most cases, a source set will behave like a static library, except no actual library file will be produced.". Because of this, I thought of the source_set as "non-reconfigurable", therefore the above-described approach. Someone could please comment, but my understanding is that this is the way to do it. I hope this helps. Best regards, João Alves ________________________________ From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of Andrew Walbran via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: Tuesday, February 16, 2021 4:20 PM To: Raghu K <raghu.ncstate(a)icloud.com> Cc: hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org> Subject: Re: [Hafnium] GN build system Question I thought it would work to set the defines directly on the vm_kernel target, but apparently not. The only other way I can think of is to define a new toolchain, but that's probably worse than just making a copy of the source_set with the defines you want added. I'm not really a GN expert though. On Tue, 16 Feb 2021 at 15:36, Raghu Krishnamurthy via Hafnium < hafnium(a)lists.trustedfirmware.org> wrote: > Hi All, > > > > I'm experimenting with a few things with hafnium tests and had a question > of > how(or what is the right way) to achieve the following with the GN build > system. > > I'm using the primary_with_secondaries test, to make a few modifications > for > an experiment. I want to be able to compile this test suite in such a way > that the service_vm1 target(a vm_kernel target) is compiled with a > different > set(or additional set) of defines but not service_vm2 or service_vm3. I'm > looking at the test/vmapi/primary_with_secondaries/services/BUILD.gn file > for these targets. More concretely, I want service_vm1 to be compiled with > -DFOO=1 in addition to existing defines and service_vm2/3 to be compiled > without -DFOO=1. > > I cant seem to find a way to force/push down extra defines on the > source_sets referenced in the deps field at the vm_kernel("service_vm1") > target. I know the other way(source_sets propagating their configs upwards > to targets that depend on it through public_configs) is possible but I'd > effectively like to do the reverse of it. > > > > Should I just create another vm_kernel target, referencing all the source > files directly(not existing source_sets) and having its own config? Or > should I create new source sets with different configs? What is the GN way > to achieve the above? > > > > > > Thanks > > Raghu > > -- > Hafnium mailing list > Hafnium(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/hafnium >

4 years, 2 months

2
1
0 0

Re: [Hafnium] GN build system Question

by Andrew Walbran

I thought it would work to set the defines directly on the vm_kernel target, but apparently not. The only other way I can think of is to define a new toolchain, but that's probably worse than just making a copy of the source_set with the defines you want added. I'm not really a GN expert though. On Tue, 16 Feb 2021 at 15:36, Raghu Krishnamurthy via Hafnium < hafnium(a)lists.trustedfirmware.org> wrote: > Hi All, > > > > I'm experimenting with a few things with hafnium tests and had a question > of > how(or what is the right way) to achieve the following with the GN build > system. > > I'm using the primary_with_secondaries test, to make a few modifications > for > an experiment. I want to be able to compile this test suite in such a way > that the service_vm1 target(a vm_kernel target) is compiled with a > different > set(or additional set) of defines but not service_vm2 or service_vm3. I'm > looking at the test/vmapi/primary_with_secondaries/services/BUILD.gn file > for these targets. More concretely, I want service_vm1 to be compiled with > -DFOO=1 in addition to existing defines and service_vm2/3 to be compiled > without -DFOO=1. > > I cant seem to find a way to force/push down extra defines on the > source_sets referenced in the deps field at the vm_kernel("service_vm1") > target. I know the other way(source_sets propagating their configs upwards > to targets that depend on it through public_configs) is possible but I'd > effectively like to do the reverse of it. > > > > Should I just create another vm_kernel target, referencing all the source > files directly(not existing source_sets) and having its own config? Or > should I create new source sets with different configs? What is the GN way > to achieve the above? > > > > > > Thanks > > Raghu > > -- > Hafnium mailing list > Hafnium(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/hafnium >

4 years, 2 months

2
1
0 0

GN build system Question

by raghu.ncstate＠icloud.com

Hi All, I'm experimenting with a few things with hafnium tests and had a question of how(or what is the right way) to achieve the following with the GN build system. I'm using the primary_with_secondaries test, to make a few modifications for an experiment. I want to be able to compile this test suite in such a way that the service_vm1 target(a vm_kernel target) is compiled with a different set(or additional set) of defines but not service_vm2 or service_vm3. I'm looking at the test/vmapi/primary_with_secondaries/services/BUILD.gn file for these targets. More concretely, I want service_vm1 to be compiled with -DFOO=1 in addition to existing defines and service_vm2/3 to be compiled without -DFOO=1. I cant seem to find a way to force/push down extra defines on the source_sets referenced in the deps field at the vm_kernel("service_vm1") target. I know the other way(source_sets propagating their configs upwards to targets that depend on it through public_configs) is possible but I'd effectively like to do the reverse of it. Should I just create another vm_kernel target, referencing all the source files directly(not existing source_sets) and having its own config? Or should I create new source sets with different configs? What is the GN way to achieve the above? Thanks Raghu

4 years, 2 months

1
0
0 0

Re: [Hafnium] A possible bug in src/ffa_memory.c

by Andrew Walbran

On Fri, 12 Feb 2021 at 10:11, Zongyuan Liu via Hafnium < hafnium(a)lists.trustedfirmware.org> wrote: > Hi, > > I have been trying to understand the Arm’s FFA by reading Hafnium’s > implementation, and recently discovered an inconsistency between the > specification and the implementation regarding the sender’s mode of donated > pages after an invocation of FFA_MEM_DONATE. > > According to item 12.1 of 11.1.1.2 section in > https://developer.arm.com/documentation/den0077/latest, > > 12. If the call executes successfully, the Relayer must: > 1. Ensure that the state of the memory region in the participating FF-A > components is observed as follows: > 1. If the Receiver is a PE endpoint or a SEPID associated with a dependent > peripheral device, then: > • Owner-NA for the Owner. > • !Owner-NA for the Receiver. > > the sender(owner) is supposed to still own the pages, which is not the > case in the implementation( > https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/ffa_memory.c#n… > ). > I don’t know if there is a reason behind this, but I think at least a > consequence of it is that the sender would be not able to invoke > FFA_MEM_RECLAIM successfully before the receiver retrieves those pages, > which implies possible “page leakage” if the receiver refuses to cooperate. > I also wrote a simple test case in which the sender invokes > FFA_MEM_RECLAIM right after FFA_MEM_DONATE. As expected, Hafnium returned > FFA_DENIED( > https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/ffa_memory.c#n… > ). > > If it is indeed a bug, then a simple fix could be removing “| > MM_MODE_UNOWNED” at line 572. > Looks like you might be right, but the fix is not quite so simple. If you only do that then when the receiver retrieves the memory region then you'll end up with both the sender and receiver owning it. So you also need to set the sender state to UNOWNED when the receiver retrieves it, and do so atomically with the update to the receiver page table. That's going to add a bunch of extra complexity unfortunately. Feel free to send a patch though!

4 years, 2 months

1
0
0 0

A possible bug in src/ffa_memory.c

by Zongyuan Liu

Hi, I have been trying to understand the Arm’s FFA by reading Hafnium’s implementation, and recently discovered an inconsistency between the specification and the implementation regarding the sender’s mode of donated pages after an invocation of FFA_MEM_DONATE. According to item 12.1 of 11.1.1.2 section in https://developer.arm.com/documentation/den0077/latest, 12. If the call executes successfully, the Relayer must: 1. Ensure that the state of the memory region in the participating FF-A components is observed as follows: 1. If the Receiver is a PE endpoint or a SEPID associated with a dependent peripheral device, then: • Owner-NA for the Owner. • !Owner-NA for the Receiver. the sender(owner) is supposed to still own the pages, which is not the case in the implementation(https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src… ). I don’t know if there is a reason behind this, but I think at least a consequence of it is that the sender would be not able to invoke FFA_MEM_RECLAIM successfully before the receiver retrieves those pages, which implies possible “page leakage” if the receiver refuses to cooperate. I also wrote a simple test case in which the sender invokes FFA_MEM_RECLAIM right after FFA_MEM_DONATE. As expected, Hafnium returned FFA_DENIED(https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/ffa… ). If it is indeed a bug, then a simple fix could be removing “| MM_MODE_UNOWNED” at line 572. Regards, Zongyuan Liu

4 years, 2 months

1
0
0 0

Re: [Hafnium] Possible bugs with page table management

by Andrew Walbran

On Mon, 4 Jan 2021 at 17:03, Raghu Krishnamurthy via Hafnium < hafnium(a)lists.trustedfirmware.org> wrote: > Hi All, > > I was going through src/mm.c in the hafnium repo and noticed a couple of > things that I think are problem: > > 1. mm_vm_defrag and mm_defrag, which eventually call mm_ptable_defrag > appears to be changing page entries into block entries. Per D5.10.1 of ARM > ARM, this should use break-before-make, but I don't see it being done in > code. Am I missing where this is done in code, or is there some reason > break-before-make is not required during defrag(that is not obvious to me > from code or comments)? > 2. In mm_replace_entry, line 278 > (https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/mm.c#n278) > is > not followed by a DSB + ISB as required by the break-before-make. Without > the DSB, a load/store that uses a VA translated by the PTE being replaced > could be reordered before line 278 and fault. Once again, this looks like a > bug to me but is there some reason that is not obvious due to which it does > not require barriers? > It looks like that code was added in https://hafnium-review.googlesource.com/c/hafnium/+/3260. Maybe Andrew Scull or Wedson can comment, if they can remember?

4 years, 3 months

3
8
0 0

Re: [Hafnium] load TEE systems(like OPTEE) on hafnium

by Olivier Deprez

Hi By Yinhua, Your experiment fails for two main reasons: 1/ you're attempting to load OP-TEE as a normal world VM whereas OP-TEE is a TEE meant to run in TZ secure world. 2/ you're using qemu which is not yet capable of emulating S-EL2. At present, you'd need to use Arm's FVP. Can you confirm you wish to run OP-TEE as TEE on top of Hafnium in the secure world? Clearer instructions on how to run OP-TEE as a Secure Partition shall follow in coming days from Arm's platform team. Regards, Olivier. ________________________________________ From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of 陈胤桦 via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: 15 January 2021 09:48 To: hafnium(a)lists.trustedfirmware.org Subject: [Hafnium] load TEE systems(like OPTEE) on hafnium Hi all : I follow the "Getting Started" instructions and run linux as the primary VM on hafnium successfully. Then, I try to load OP-TEE system as a secondary VM on hafnium but fail. Is there any document which can help me load TEE system on hafnium? If not, could you give me some guidance and tips? The following is the efforts I made : ------ 1. I write the file "manifest.dts" as follows: /dts-v1/; / { hypervisor { compatible = "hafnium,hafnium"; ffa_tee; vm1 { debug_name = "primary VM -chenyinhua"; kernel_filename = "vmlinuz"; ramdisk_filename = "initrd.img"; smc_whitelist = < 0x04000000 0x3200ffff >; }; vm2 { debug_name = "secondary VM 1"; kernel_filename = "kernel0"; vcpu_count = <2>; mem_size = <0x100000>; smc_whitelist_permissive; }; }; }; 1. Run prebuilts/linux-x64/dtc/dtc -I dts -O dtb --out-version 17 -o manifest.dtb manifest.dts 2. Move "manifest.dtb" into "initrd" directory 3. Follow this blog to build OP-TEE: https://blog.csdn.net/dddddttttt/article/details/80793453, now I can run optee_examples successfully. 4. In <opentee-root-dir>/optee_os/out/arm/core, copy the file "tee.bin" into <hafnium-root-dir>/initrd 5. Rename <hafnium-root-dir>/initrd/tee.bin to <hafnium-root-dir>/initrd/kernel0 6. In <hafnium-root-dir>/initrd/ , run the following command (The linux's vmlinuz and initrd.img are already in the directory) find . | cpio -o > ../initrd.img 8. In <hafnium-root-dir>, run qemu-system-aarch64 \ -M virt,gic_version=3 \ -cpu cortex-a57 -nographic -machine virtualization=true \ -kernel out/reference/qemu_aarch64_clang/hafnium.bin \ -initrd initrd.img -append "rdinit=/sbin/init" 9. The result is as follows: NOTICE: Initialising hafnium INFO: text: 0x40001000 - 0x4001b000 INFO: rodata: 0x4001b000 - 0x4001f000 INFO: data: 0x4001f000 - 0x400b7000 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: 0x2 INFO: Memory range: 0x40000000 - 0x47ffffff INFO: Ramdisk range: 0x44000000 - 0x45aa8bff WARNING: Device memory not provided, defaulting to 1 TB. INFO: Loaded primary VM with 8 vCPUs, entry at 0x40280000. INFO: Loading VM id 0x2: secondary VM 1. INFO: Loaded with 2 vCPUs, entry at 0x47f00000. INFO: Loading VM id 0x3: secondary VM 2. INFO: Loaded with 4 vCPUs, entry at 0x47d00000. ./qboot.sh: line 5: 3397 Segmentation fault (core dumped) qemu-system-aarch64 -M virt,gic_version=3 -cpu cortex-a57 -nographic -machine virtualization=true -kernel out/reference/qemu_aarch64_clang/hafnium.bin -initrd initrd.img -append "rdinit=/sbin/init" I appreciate for any possible help! Thanks. ------ By Yinhua -- Hafnium mailing list Hafnium(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/hafnium

4 years, 3 months

2
3
0 0

load TEE systems(like OPTEE) on hafnium

by 陈胤桦

Hi all : I follow the "Getting Started" instructions and run linux as the primary VM on hafnium successfully. Then, I try to load OP-TEE system as a secondary VM on hafnium but fail. Is there any document which can help me load TEE system on hafnium? If not, could you give me some guidance and tips? The following is the efforts I made : ------ 1. I write the file "manifest.dts" as follows: /dts-v1/; / { hypervisor { compatible = "hafnium,hafnium"; ffa_tee; vm1 { debug_name = "primary VM -chenyinhua"; kernel_filename = "vmlinuz"; ramdisk_filename = "initrd.img"; smc_whitelist = < 0x04000000 0x3200ffff >; }; vm2 { debug_name = "secondary VM 1"; kernel_filename = "kernel0"; vcpu_count = <2>; mem_size = <0x100000>; smc_whitelist_permissive; }; }; }; 1. Run prebuilts/linux-x64/dtc/dtc -I dts -O dtb --out-version 17 -o manifest.dtb manifest.dts 2. Move "manifest.dtb" into "initrd" directory 3. Follow this blog to build OP-TEE: https://blog.csdn.net/dddddttttt/article/details/80793453, now I can run optee_examples successfully. 4. In <opentee-root-dir>/optee_os/out/arm/core, copy the file "tee.bin" into <hafnium-root-dir>/initrd 5. Rename <hafnium-root-dir>/initrd/tee.bin to <hafnium-root-dir>/initrd/kernel0 6. In <hafnium-root-dir>/initrd/ , run the following command (The linux's vmlinuz and initrd.img are already in the directory) find . | cpio -o > ../initrd.img 8. In <hafnium-root-dir>, run qemu-system-aarch64 \ -M virt,gic_version=3 \ -cpu cortex-a57 -nographic -machine virtualization=true \ -kernel out/reference/qemu_aarch64_clang/hafnium.bin \ -initrd initrd.img -append "rdinit=/sbin/init" 9. The result is as follows: NOTICE: Initialising hafnium INFO: text: 0x40001000 - 0x4001b000 INFO: rodata: 0x4001b000 - 0x4001f000 INFO: data: 0x4001f000 - 0x400b7000 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: 0x2 INFO: Memory range: 0x40000000 - 0x47ffffff INFO: Ramdisk range: 0x44000000 - 0x45aa8bff WARNING: Device memory not provided, defaulting to 1 TB. INFO: Loaded primary VM with 8 vCPUs, entry at 0x40280000. INFO: Loading VM id 0x2: secondary VM 1. INFO: Loaded with 2 vCPUs, entry at 0x47f00000. INFO: Loading VM id 0x3: secondary VM 2. INFO: Loaded with 4 vCPUs, entry at 0x47d00000. ./qboot.sh: line 5: 3397 Segmentation fault (core dumped) qemu-system-aarch64 -M virt,gic_version=3 -cpu cortex-a57 -nographic -machine virtualization=true -kernel out/reference/qemu_aarch64_clang/hafnium.bin -initrd initrd.img -append "rdinit=/sbin/init" I appreciate for any possible help! Thanks. ------ By Yinhua

4 years, 3 months

1
0
0 0

Possible bugs with page table management

by raghu.ncstate＠icloud.com

Hi All, I was going through src/mm.c in the hafnium repo and noticed a couple of things that I think are problem: 1. mm_vm_defrag and mm_defrag, which eventually call mm_ptable_defrag appears to be changing page entries into block entries. Per D5.10.1 of ARM ARM, this should use break-before-make, but I don't see it being done in code. Am I missing where this is done in code, or is there some reason break-before-make is not required during defrag(that is not obvious to me from code or comments)? 2. In mm_replace_entry, line 278 (https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/mm.c#n278) is not followed by a DSB + ISB as required by the break-before-make. Without the DSB, a load/store that uses a VA translated by the PTE being replaced could be reordered before line 278 and fault. Once again, this looks like a bug to me but is there some reason that is not obvious due to which it does not require barriers? Thanks Raghu

4 years, 4 months

1
0
0 0

Re: [Hafnium] VHE support

by Olivier Deprez

Hi Raghu, one more 5/ maybe answer to 2/3/4 is that it requires an EL1-shim embedded into Hafnium which itself ERETs to a S-EL0 partition? BTW notice my questions are obviously oriented towards the secure implementation. Regards, Olivier. ________________________________________ From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of Olivier Deprez via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: 15 December 2020 09:10 To: hafnium(a)lists.trustedfirmware.org; raghu.ncstate(a)icloud.com Subject: Re: [Hafnium] VHE support Hi Raghu, Thanks for sharing this work. Few thoughts... 1/ I guess it requires an additional change in project/reference to eventually enable the feature for a platform (enable_vhe=1 in the gn build flow)? Sorry if my questions below sound obvious, I may miss bits of the VHE architecture. 2/ The changes are effectively toggling HCR_EL2.E2H=1. Currently when Hafnium ERETs resuming a SP, this happens with the secure EL1&0 translation regime. Though what's the next step forward? Does this require a host OS in secure world? (like linux does when booting under a Hypervisor with VHE enabled?) Would this be a VHE-enabled TOS? 3/ Is the later goal to enable the secure EL2&0 translation regime? 4/ Is there anything to do with HCR_EL2.TGE? Regards, Olivier. ________________________________________ From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of Raghu Krishnamurthy via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: 15 December 2020 04:57 To: hafnium(a)lists.trustedfirmware.org Subject: [Hafnium] VHE support Hi All, I have a series of patches pushed to Gerrit at https://review.trustedfirmware.org/c/hafnium/hafnium/+/7599 with topic "vhe_enable". The goal of this patch series is to enable VM's in both secure and normal world to run with VHE enabled(hcr_el2.e2h=1), without breaking any existing functionality. This is expected to be the first step in the long term goal of enabling S-EL0 partitions(and optionally EL0 partitions), that require VHE support, per the FF-A 1.0 Spec. I'd appreciate feedback on the patches and approach taken to nominally enabling VHE. Note that the FF-A 1.0 spec(AFAIK) does not expect VHE support in the normal world but this patch series enables it anyway due to the wealth of available tests in the hafnium test suite to help with providing confidence in the implementation. The patch series has been tested as follows: Hafnium tests using QEMU(prebuilt in the hafnium repo) - Without VHE, since the prebuilt QEMU does not support VHE. Hafnium tests using QEMU(5.2-RC4, built from source) - With and without VHE, this version of QEMU supports VHE. Hafnium tests using FVP 11.12.28 - With and Without VHE. TFTF tests for secure hafnium using FVP 11.12.28 - With and without VHE. Thanks Raghu -- 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

4 years, 4 months

3
8
0 0

Re: [Hafnium] VHE support

by Olivier Deprez

Hi Achin, > HCR_EL2.{E2H,TGE} = {1,1} reduces the number of translation stages managed by > the SPMC for S-EL0 SPs. It allows them to be managed like apps instead of VMs > which is the case pre-v8.4. I think this is the better configuration for a > system that only deploys S-EL0 SPs. If the system only deploys S-EL0 SPs in this configuration, what's the benefit of using Hafnium in place of a S-EL1 TEE? (appart maybe from product / SW scalability perspective?) Regards, Olivier. ________________________________________ From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of Achin Gupta via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: 19 December 2020 15:24 To: raghu.ncstate(a)icloud.com Cc: hafnium(a)lists.trustedfirmware.org; 'Mayur Gudmeti'; 'Joakim Bech' Subject: Re: [Hafnium] VHE support Hi Raghu, On Fri, Dec 18, 2020 at 02:39:44PM -0800, raghu.ncstate(a)icloud.com wrote: > Thanks Achin. > > >> Now if a S-EL0 SP is run in this configuration, irrespective of how TGE is configured, the SPMC would have to manage both the Stage 1 and 2 translations on behalf of the S-EL0 SP in the Secure EL1&0 translation regime, > [RK] Not sure I understand the statement "irrespective of how TGE is configured". If HCR_EL2.E2H,TGE=1,1, then SPMC would manage Secure EL2&0 translation regime for the S-EL0 SP and crucially, no stage 2 translations. Your statement applies only when HCR_EL2.{E2H,TGE} = {1,1}. The statement right after this contradicts "irrespective of how TGE is configured". Apologies. I meant E2H and not TGE i.e. if HCR_EL2.TGE=0, then the SPMC has to manage both the Stage 1 and 2 translations on behalf of a S-EL0 SP in the Secure EL1&0 translation regime, > > >> Management of a S-EL0 SP in the earlier configuration is expected to be easier. > [RK] Sorry, which configuration? Earlier is vague. HCR_EL2.{E2H,TGE} = {1,1} > > >> Does this seem reasonable? > Yes, this is reasonable. However, what configuration of HCR_EL2.{E2H, TGE} should hafnium use to manage S-EL0 SP's? Should it use {0, 1} (not in spec) or {1, 1}( Section 2.2.1, Bullet 1)? HCR_EL2.{E2H,TGE} = {1,1} reduces the number of translation stages managed by the SPMC for S-EL0 SPs. It allows them to be managed like apps instead of VMs which is the case pre-v8.4. I think this is the better configuration for a system that only deploys S-EL0 SPs. The spec does not specify the values of E2H or TGE. So {0, 1} is not disallowed by the spec either. Looks like that the choices we have for Hafnium are: 1. {1, 1} for S-EL0 SPs and {1, 0} for S-EL1 SPs 2. {0, 1} for S-EL0 SPs and {0, 0} for S-EL1 SPs We would need to understand the impact of these choices on the Hafnium implementation before making a call. The v1.1 spec can recommend the sensible choices to avoid confusion. cheers, Achin > > Thanks > Raghu > > -----Original Message----- > From: Achin Gupta <achin.gupta(a)arm.com> > Sent: Friday, December 18, 2020 1:57 PM > To: François Ozog <francois.ozog(a)linaro.org>; raghu.ncstate(a)icloud.com > Cc: raghu.ncstate(a)icloud.com; hafnium(a)lists.trustedfirmware.org; Mayur Gudmeti <mgudmeti(a)nvidia.com>; Ruchika Gupta <ruchika.gupta(a)linaro.org>; Joakim Bech <joakim.bech(a)linaro.org> > Subject: Re: [Hafnium] VHE support > > Hi Francois and Raghu, > > Some comments inline... > > On Fri, Dec 18, 2020 at 04:12:55PM +0100, François Ozog wrote: > > > > > > On Fri, 18 Dec 2020 at 15:59, <raghu.ncstate(a)icloud.com> wrote: > > > > > > Hi Francois, > > > > > > > > OPTEE should work with and without VHE enabled and be able to communicate > > with normal world. VHE should be entirely transparent to S-EL1 partitions/ > > VM’s. Is there a reason you think VHE may not be transparent? > > > > > > > > that's what I thought when I red "With VHE, the S-EL1 exception level > > disappears." earlier in the thread. > > Raghu is right that the presence or absence of VHE does not matter to OP-TEE or any S-EL1 SP. It is an S-EL2 knob. > > Just to be clear, "With VHE, the S-EL1 exception level disappears" is the configuration when HCR_EL2.{E2H, TGE} == {1, 1}. > > In this configuration, the S-EL0 SPs are controlled by the SPMC just like Host Apps are controlled by the Host OS in the link from Raghu. OP-TEE or any S-EL1 SP cannot run in this setup. > > The key point from the spec's perspective is that the SPMC manages the Secure > EL2&0 translation regime. I will come back to this. > > The configuration in which OP-TEE runs as a VM is when HCR_EL2.{E2H, TGE} == {1, 0} or {0, 0}. The key point is that TGE=0. Whether E2H is set or not is a Hypervisor choice. It does not matter whether VHE is being used or not from the > S-EL1 SP's perspective. > > In this configuration, the SPMC manages the Stage 2 translations on behalf of OP-TEE in the Secure EL1&0 translation regime, > > Now if a S-EL0 SP is run in this configuration, irrespective of how TGE is configured, the SPMC would have to manage both the Stage 1 and 2 translations on behalf of the S-EL0 SP in the Secure EL1&0 translation regime, > > Going back to the key point above, in the earlier configuration (HCR_EL2.{E2H, TGE} == {1, 1}), the SPMC would have to manage only the Stage 1 translations in Secure EL2&0 translation regime. > > The spec is trying to highlight this difference. Management of a S-EL0 SP in the earlier configuration is expected to be easier. Also, this is the closest we get to the FF-A configuration where the SPMC in EL3 manages S-EL0 SPs directly. The SPMC manages the Stage 1 translations in Secure EL1&0 translation regime in this case. > > In short, in Section 2.2.1, > > - In bullet 1, the spec has HCR_EL2.{E2H, TGE} == {1, 1} in mind. > > - In bullet 2, the spec has HCR_EL2.TGE == 0 in mind. > > Does this seem reasonable? > > > > > > > > > The third picture in the link below helped me visualize the system with > > VHE: > > > > https://developer.arm.com/architectures/learn-the-architecture/ > > aarch64-virtualization/virtualization-host-extensions > > > > > > > > Hypervisor/Host OS is Hafnium, Guest OS will be OPTEE, Guest Apps with be > > TA’s. Host App’s with be S-EL0 partitions. > > Completely agree. > > cheers, > Achin > > > > > > > > > Thanks > > > > Raghu > > > > > > > > From: François Ozog <francois.ozog(a)linaro.org> > > Sent: Friday, December 18, 2020 4:03 AM > > To: Achin Gupta <achin.gupta(a)arm.com> > > Cc: raghu.ncstate(a)icloud.com; hafnium(a)lists.trustedfirmware.org; Mayur > > Gudmeti <mgudmeti(a)nvidia.com>; Ruchika Gupta <ruchika.gupta(a)linaro.org>; > > Joakim Bech <joakim.bech(a)linaro.org> > > Subject: Re: [Hafnium] VHE support > > > > > > > > > > > > > > > > On Thu, 17 Dec 2020 at 17:44, Achin Gupta via Hafnium < > > hafnium(a)lists.trustedfirmware.org> wrote: > > > > Hi Raghu, > > > > On Tue, Dec 15, 2020 at 09:41:05AM -0800, raghu.ncstate(a)icloud.com > > wrote: > > > Hi Olivier, > > > > > > > [snip] > > > > > > > > Hi Achin, > > > > > > Question for you. I interpreted the FF-A 1.0 spec as "requiring" VHE > > for > > > S-EL0 partitions, based on options 1 and 2 in section 2.2.1, since > > option 2 > > > does not mention S-EL0 partitions. Can you confirm this is the case? > > As I > > > was thinking through this, it seems like we might be able to pull off > > EL0 > > > partitions without using VHE, i.e by using HCR_EL2.E2H = 0 and > > > HCR_EL2.TGE=1. > > > HCR_EL2.TGE is present even on ARMv8.0 architecture and removes > > dependence > > > on VHE, and effectively removes the necessity for this patch series. > > > However, I'd like to understand your thoughts on why VHE is suggested > > in the > > > spec and if hafnium should use VHE for S-EL0 partitions or if hafnium > > can > > > use the approach suggested above. > > > > The intent in the spec is not to mandate VHE for S-EL0 SPs. We can add > > a > > clarification if that helps. > > > > The intent in the spec is to highlight that VHE is applicable to S-EL0 > > SPs only. > > > > With VHE, the S-EL1 exception level disappears. The SPMC can only have > > awareness > > of S-EL0 SPs. > > > > Without WHE, the S-EL1 exception level is present. As you state above, > > there are > > knobs in the architecture that reduce the role of S-EL1. But based upon > > my > > current understanding, the SPMC will see S-EL1 as the next lower > > exception > > level. > > > > If we want OPTEE to be running a number of Apps in one Secure world VM, we > > wouldn't need WHE right? > > > > Can you confirm that without enabling VHE, an OPTEE VM, and its containing > > apps, is possible and can communicate with normal world VMs? > > > > > > > > A S-EL0 SP can be "wrapped" as a S-EL1 SP such that the role of S-EL1 > > is > > reduced. This could be done in SW (e.g. a shim layer in S-EL1), HW > > (e.g. the TGE > > bit above) or both. But architecturally, the SPMC will still see S-EL1. > > > > I hope this clarifies. That said, I do need to double check the > > original intent > > and impact of TGE. So please do correct me if I have misinterpreted > > anything. > > > > cheers, > > Achin > > > > > > > > > > > Thanks > > > Raghu > > > > > > > > > -----Original Message----- > > > From: Olivier Deprez <Olivier.Deprez(a)arm.com> > > > Sent: Tuesday, December 15, 2020 12:18 AM > > > To: hafnium(a)lists.trustedfirmware.org; raghu.ncstate(a)icloud.com; > > Olivier > > > Deprez <Olivier.Deprez(a)arm.com> > > > Subject: Re: [Hafnium] VHE support > > > > > > Hi Raghu, > > > > > > one more > > > > > > 5/ maybe answer to 2/3/4 is that it requires an EL1-shim embedded > > into > > > Hafnium which itself ERETs to a S-EL0 partition? > > > > > > BTW notice my questions are obviously oriented towards the secure > > > implementation. > > > > > > Regards, > > > Olivier. > > > > > > ________________________________________ > > > From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf > > of > > > Olivier Deprez via Hafnium <hafnium(a)lists.trustedfirmware.org> > > > Sent: 15 December 2020 09:10 > > > To: hafnium(a)lists.trustedfirmware.org; raghu.ncstate(a)icloud.com > > > Subject: Re: [Hafnium] VHE support > > > > > > Hi Raghu, > > > > > > Thanks for sharing this work. > > > > > > Few thoughts... > > > > > > 1/ I guess it requires an additional change in project/reference to > > > eventually enable the feature for a platform (enable_vhe=1 in the gn > > build > > > flow)? > > > > > > Sorry if my questions below sound obvious, I may miss bits of the VHE > > > architecture. > > > > > > 2/ The changes are effectively toggling HCR_EL2.E2H=1. Currently when > > > Hafnium ERETs resuming a SP, this happens with the secure EL1&0 > > translation > > > regime. > > > Though what's the next step forward? > > > Does this require a host OS in secure world? (like linux does when > > booting > > > under a Hypervisor with VHE enabled?) Would this be a VHE-enabled > > TOS? > > > > > > 3/ Is the later goal to enable the secure EL2&0 translation regime? > > > > > > 4/ Is there anything to do with HCR_EL2.TGE? > > > > > > Regards, > > > Olivier. > > > > > > > > > ________________________________________ > > > From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf > > of Raghu > > > Krishnamurthy via Hafnium <hafnium(a)lists.trustedfirmware.org> > > > Sent: 15 December 2020 04:57 > > > To: hafnium(a)lists.trustedfirmware.org > > > Subject: [Hafnium] VHE support > > > > > > Hi All, > > > > > > > > > > > > I have a series of patches pushed to Gerrit at > > > https://review.trustedfirmware.org/c/hafnium/hafnium/+/7599 with > > topic > > > "vhe_enable". The goal of this patch series is to enable VM's in both > > secure > > > and normal world to run with VHE enabled(hcr_el2.e2h=1), without > > breaking > > > any existing functionality. This is expected to be the first step in > > the > > > long term goal of enabling S-EL0 partitions(and optionally EL0 > > partitions), > > > that require VHE support, per the FF-A 1.0 Spec. I'd appreciate > > feedback on > > > the patches and approach taken to nominally enabling VHE. Note that > > the FF-A > > > 1.0 spec(AFAIK) does not expect VHE support in the normal world but > > this > > > patch series enables it anyway due to the wealth of available tests > > in the > > > hafnium test suite to help with providing confidence in the > > implementation. > > > > > > > > > > > > The patch series has been tested as follows: > > > > > > > > > > > > Hafnium tests using QEMU(prebuilt in the hafnium repo) - Without VHE, > > since > > > the prebuilt QEMU does not support VHE. > > > > > > Hafnium tests using QEMU(5.2-RC4, built from source) - With and > > without VHE, > > > this version of QEMU supports VHE. > > > > > > Hafnium tests using FVP 11.12.28 - With and Without VHE. > > > > > > TFTF tests for secure hafnium using FVP 11.12.28 - With and without > > VHE. > > > > > > > > > > > > > > > > > > Thanks > > > > > > Raghu > > > > > > -- > > > 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 > > > > > -- > > Hafnium mailing list > > Hafnium(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/hafnium > > > > > > > > > > -- > > > > [uc] François-Frédéric Ozog | Director Linaro Edge & Fog Computing > > Group > > > > T: +33.67221.6485 > > francois.ozog(a)linaro.org | Skype: ffozog > > > > > > > > > > > > > > -- > > [uc] François-Frédéric Ozog | Director Linaro Edge & Fog Computing Group > > T: +33.67221.6485 > > francois.ozog(a)linaro.org | Skype: ffozog > > > -- Hafnium mailing list Hafnium(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/hafnium

4 years, 4 months

3
2
0 0

Re: [Hafnium] VHE support

by François Ozog

On Thu, 17 Dec 2020 at 17:44, Achin Gupta via Hafnium < hafnium(a)lists.trustedfirmware.org> wrote: > Hi Raghu, > > On Tue, Dec 15, 2020 at 09:41:05AM -0800, raghu.ncstate(a)icloud.com wrote: > > Hi Olivier, > > > > [snip] > > > > > Hi Achin, > > > > Question for you. I interpreted the FF-A 1.0 spec as "requiring" VHE for > > S-EL0 partitions, based on options 1 and 2 in section 2.2.1, since > option 2 > > does not mention S-EL0 partitions. Can you confirm this is the case? As I > > was thinking through this, it seems like we might be able to pull off EL0 > > partitions without using VHE, i.e by using HCR_EL2.E2H = 0 and > > HCR_EL2.TGE=1. > > HCR_EL2.TGE is present even on ARMv8.0 architecture and removes > dependence > > on VHE, and effectively removes the necessity for this patch series. > > However, I'd like to understand your thoughts on why VHE is suggested in > the > > spec and if hafnium should use VHE for S-EL0 partitions or if hafnium can > > use the approach suggested above. > > The intent in the spec is not to mandate VHE for S-EL0 SPs. We can add a > clarification if that helps. > > The intent in the spec is to highlight that VHE is applicable to S-EL0 SPs > only. > > With VHE, the S-EL1 exception level disappears. The SPMC can only have > awareness > of S-EL0 SPs. > > Without WHE, the S-EL1 exception level is present. As you state above, > there are > knobs in the architecture that reduce the role of S-EL1. But based upon my > current understanding, the SPMC will see S-EL1 as the next lower exception > level. > > If we want OPTEE to be running a number of Apps in one Secure world VM, we wouldn't need WHE right? Can you confirm that without enabling VHE, an OPTEE VM, and its containing apps, is possible and can communicate with normal world VMs? A S-EL0 SP can be "wrapped" as a S-EL1 SP such that the role of S-EL1 is > reduced. This could be done in SW (e.g. a shim layer in S-EL1), HW (e.g. > the TGE > bit above) or both. But architecturally, the SPMC will still see S-EL1. > > I hope this clarifies. That said, I do need to double check the original > intent > and impact of TGE. So please do correct me if I have misinterpreted > anything. > > cheers, > Achin > > > > > > > Thanks > > Raghu > > > > > > -----Original Message----- > > From: Olivier Deprez <Olivier.Deprez(a)arm.com> > > Sent: Tuesday, December 15, 2020 12:18 AM > > To: hafnium(a)lists.trustedfirmware.org; raghu.ncstate(a)icloud.com; Olivier > > Deprez <Olivier.Deprez(a)arm.com> > > Subject: Re: [Hafnium] VHE support > > > > Hi Raghu, > > > > one more > > > > 5/ maybe answer to 2/3/4 is that it requires an EL1-shim embedded into > > Hafnium which itself ERETs to a S-EL0 partition? > > > > BTW notice my questions are obviously oriented towards the secure > > implementation. > > > > Regards, > > Olivier. > > > > ________________________________________ > > From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of > > Olivier Deprez via Hafnium <hafnium(a)lists.trustedfirmware.org> > > Sent: 15 December 2020 09:10 > > To: hafnium(a)lists.trustedfirmware.org; raghu.ncstate(a)icloud.com > > Subject: Re: [Hafnium] VHE support > > > > Hi Raghu, > > > > Thanks for sharing this work. > > > > Few thoughts... > > > > 1/ I guess it requires an additional change in project/reference to > > eventually enable the feature for a platform (enable_vhe=1 in the gn > build > > flow)? > > > > Sorry if my questions below sound obvious, I may miss bits of the VHE > > architecture. > > > > 2/ The changes are effectively toggling HCR_EL2.E2H=1. Currently when > > Hafnium ERETs resuming a SP, this happens with the secure EL1&0 > translation > > regime. > > Though what's the next step forward? > > Does this require a host OS in secure world? (like linux does when > booting > > under a Hypervisor with VHE enabled?) Would this be a VHE-enabled TOS? > > > > 3/ Is the later goal to enable the secure EL2&0 translation regime? > > > > 4/ Is there anything to do with HCR_EL2.TGE? > > > > Regards, > > Olivier. > > > > > > ________________________________________ > > From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of > Raghu > > Krishnamurthy via Hafnium <hafnium(a)lists.trustedfirmware.org> > > Sent: 15 December 2020 04:57 > > To: hafnium(a)lists.trustedfirmware.org > > Subject: [Hafnium] VHE support > > > > Hi All, > > > > > > > > I have a series of patches pushed to Gerrit at > > https://review.trustedfirmware.org/c/hafnium/hafnium/+/7599 with topic > > "vhe_enable". The goal of this patch series is to enable VM's in both > secure > > and normal world to run with VHE enabled(hcr_el2.e2h=1), without breaking > > any existing functionality. This is expected to be the first step in the > > long term goal of enabling S-EL0 partitions(and optionally EL0 > partitions), > > that require VHE support, per the FF-A 1.0 Spec. I'd appreciate feedback > on > > the patches and approach taken to nominally enabling VHE. Note that the > FF-A > > 1.0 spec(AFAIK) does not expect VHE support in the normal world but this > > patch series enables it anyway due to the wealth of available tests in > the > > hafnium test suite to help with providing confidence in the > implementation. > > > > > > > > The patch series has been tested as follows: > > > > > > > > Hafnium tests using QEMU(prebuilt in the hafnium repo) - Without VHE, > since > > the prebuilt QEMU does not support VHE. > > > > Hafnium tests using QEMU(5.2-RC4, built from source) - With and without > VHE, > > this version of QEMU supports VHE. > > > > Hafnium tests using FVP 11.12.28 - With and Without VHE. > > > > TFTF tests for secure hafnium using FVP 11.12.28 - With and without VHE. > > > > > > > > > > > > Thanks > > > > Raghu > > > > -- > > 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 > > > -- > Hafnium mailing list > Hafnium(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/hafnium > -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog(a)linaro.org | Skype: ffozog

4 years, 4 months

3
8
0 0

Re: [Hafnium] VHE support

by Olivier Deprez

Hi Raghu, Thanks for sharing this work. Few thoughts... 1/ I guess it requires an additional change in project/reference to eventually enable the feature for a platform (enable_vhe=1 in the gn build flow)? Sorry if my questions below sound obvious, I may miss bits of the VHE architecture. 2/ The changes are effectively toggling HCR_EL2.E2H=1. Currently when Hafnium ERETs resuming a SP, this happens with the secure EL1&0 translation regime. Though what's the next step forward? Does this require a host OS in secure world? (like linux does when booting under a Hypervisor with VHE enabled?) Would this be a VHE-enabled TOS? 3/ Is the later goal to enable the secure EL2&0 translation regime? 4/ Is there anything to do with HCR_EL2.TGE? Regards, Olivier. ________________________________________ From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of Raghu Krishnamurthy via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: 15 December 2020 04:57 To: hafnium(a)lists.trustedfirmware.org Subject: [Hafnium] VHE support Hi All, I have a series of patches pushed to Gerrit at https://review.trustedfirmware.org/c/hafnium/hafnium/+/7599 with topic "vhe_enable". The goal of this patch series is to enable VM's in both secure and normal world to run with VHE enabled(hcr_el2.e2h=1), without breaking any existing functionality. This is expected to be the first step in the long term goal of enabling S-EL0 partitions(and optionally EL0 partitions), that require VHE support, per the FF-A 1.0 Spec. I'd appreciate feedback on the patches and approach taken to nominally enabling VHE. Note that the FF-A 1.0 spec(AFAIK) does not expect VHE support in the normal world but this patch series enables it anyway due to the wealth of available tests in the hafnium test suite to help with providing confidence in the implementation. The patch series has been tested as follows: Hafnium tests using QEMU(prebuilt in the hafnium repo) - Without VHE, since the prebuilt QEMU does not support VHE. Hafnium tests using QEMU(5.2-RC4, built from source) - With and without VHE, this version of QEMU supports VHE. Hafnium tests using FVP 11.12.28 - With and Without VHE. TFTF tests for secure hafnium using FVP 11.12.28 - With and without VHE. Thanks Raghu -- Hafnium mailing list Hafnium(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/hafnium

4 years, 4 months

1
0
0 0

VHE support

by raghu.ncstate＠icloud.com

Hi All, I have a series of patches pushed to Gerrit at https://review.trustedfirmware.org/c/hafnium/hafnium/+/7599 with topic "vhe_enable". The goal of this patch series is to enable VM's in both secure and normal world to run with VHE enabled(hcr_el2.e2h=1), without breaking any existing functionality. This is expected to be the first step in the long term goal of enabling S-EL0 partitions(and optionally EL0 partitions), that require VHE support, per the FF-A 1.0 Spec. I'd appreciate feedback on the patches and approach taken to nominally enabling VHE. Note that the FF-A 1.0 spec(AFAIK) does not expect VHE support in the normal world but this patch series enables it anyway due to the wealth of available tests in the hafnium test suite to help with providing confidence in the implementation. The patch series has been tested as follows: Hafnium tests using QEMU(prebuilt in the hafnium repo) - Without VHE, since the prebuilt QEMU does not support VHE. Hafnium tests using QEMU(5.2-RC4, built from source) - With and without VHE, this version of QEMU supports VHE. Hafnium tests using FVP 11.12.28 - With and Without VHE. TFTF tests for secure hafnium using FVP 11.12.28 - With and without VHE. Thanks Raghu

4 years, 4 months

1
0
0 0

FW: [TF-A] TF-A Tech Forum Agenda @ Thr 17th December 2020 16:00-1700 GMT: Introduction to the Trusted Services project

by Joanna Farley

Fwd to Hafnium mailing list. Joanna From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Joanna Farley via TF-A <tf-a(a)lists.trustedfirmware.org> Reply to: Joanna Farley <Joanna.Farley(a)arm.com> Date: Monday, 14 December 2020 at 10:03 To: "tf-a(a)lists.trustedfirmware.org" <tf-a(a)lists.trustedfirmware.org>, "op-tee(a)lists.trustedfirmware.org" <op-tee(a)lists.trustedfirmware.org> Subject: [TF-A] TF-A Tech Forum Agenda @ Thr 17th December 2020 16:00-1700 GMT: Introduction to the Trusted Services project Hi All, The next TF-A Tech Forum is scheduled for Thu 17th December 2020 16:00 – 17:00 (GMT). As well as being posted to the TF-A mailing list this has been cross posted to OPTEE mailing list. For OPTEE attendees the Zoom call details are included below. Agenda: * An introduction to the Trusted Services project * Presented by Julian Hall * Summary * The Trusted Services project is a new trustedfirmware.org project that provides a home for security related service components that can run in the different isolated processing environments available on Arm Cortex-A. The project attempts to promote reuse and standardization to enable a consistent set of services to be provided by firmware, independent of which isolation technology is used. 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. This is the last TF-A Tech Forum session until January 2021. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…> Meeting ID: 915 970 4974 One tap mobile +16465588656,,9159704974# US (New York) +16699009128,,9159704974# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> Thanks Joanna

4 years, 4 months

1
0
0 0

Re: [Hafnium] Memory sharing test failures with FVP

by Olivier Deprez

Hi Raghu, Are you referring to the gcc build flavor with which FVP is built (Linux64_GCC-6.4)? FVP version should look more like 11.12.38 if you do: ./FVP_Base_RevC-2xAEMv8A --version Thus far Hypervisor has been validated using qemu through the Hafnium builder (using the kokoro/build.sh script): https://ci.trustedfirmware.org/job/hafnium-build-test-review/ Even though the build script offers the capability, there is currently no automation with FVP for the Hypervisor test suite. We've used FVP for the secure-world / SPMC validation, but that's a different test suite within TF-A CI. In other words, it's possible you find problems running FVP on the Hypervisor test suite, and that's worth fixing. Regards, Olivier. ________________________________________ From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of Raghu Krishnamurthy via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: 08 December 2020 17:20 To: hafnium(a)lists.trustedfirmware.org Subject: [Hafnium] Memory sharing test failures with FVP Hi All, I'm seeing test failures when I use FVP and run the memory_share test suite(in primary_with_secondaries_test) on the 6.4 version of AEM FVP(works on qemu, don't know if it works on AEM FVP 4.9). Is anybody else aware of these failures and working on fixing them? Appears to be alignment faults. Test logs for some of the tests show a stage 2 fault at 0x200 but that is really because service_vm3 does not install an exception handler in EL1 and when the data abort is taken in EL1, VBAR_EL1 is not set up, and hafnium gets a stage 2 fault, and injects unknown exception to EL1, which faults again in hafnium again and so on. Easy to repro: Update test/hftest/hftest.py to use the 6.4 version of FVP and run: timeout --foreground 300s ./test/hftest/hftest.py --driver=fvp --out out/reference/aem_v8a_fvp_clang --out_initrd out/reference/aem_v8a_fvp_vm_clang --tfa --log out/reference/kokoro_log hafnium --initrd test/vmapi/primary_with_secondaries/primary_with_secondaries_test --suite memory_sharing Thanks Raghu -- Hafnium mailing list Hafnium(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/hafnium

4 years, 5 months

2
1
0 0

Memory sharing test failures with FVP

by raghu.ncstate＠icloud.com

Hi All, I'm seeing test failures when I use FVP and run the memory_share test suite(in primary_with_secondaries_test) on the 6.4 version of AEM FVP(works on qemu, don't know if it works on AEM FVP 4.9). Is anybody else aware of these failures and working on fixing them? Appears to be alignment faults. Test logs for some of the tests show a stage 2 fault at 0x200 but that is really because service_vm3 does not install an exception handler in EL1 and when the data abort is taken in EL1, VBAR_EL1 is not set up, and hafnium gets a stage 2 fault, and injects unknown exception to EL1, which faults again in hafnium again and so on. Easy to repro: Update test/hftest/hftest.py to use the 6.4 version of FVP and run: timeout --foreground 300s ./test/hftest/hftest.py --driver=fvp --out out/reference/aem_v8a_fvp_clang --out_initrd out/reference/aem_v8a_fvp_vm_clang --tfa --log out/reference/kokoro_log hafnium --initrd test/vmapi/primary_with_secondaries/primary_with_secondaries_test --suite memory_sharing Thanks Raghu

4 years, 5 months

1
0
0 0

SPMC and Arm generic timer / counter

by Olivier Deprez

Hi, I noticed OP-TEE accesses CNTPCT_EL1 aka the physical system counter for different reasons (small delay loops, user session time, debug/trace,...) I wonder how this should be supported when OP-TEE runs as a Secure Partition (and more generally for other TEEs and bare metal SPs) under the SPMC. I guess this is ok as long as SPs are all statically loaded at boot time (that is all SPs use the same t0 reference time), and thus the virtual system time is similar to the physical system time. For a VM running under Hafnium, EL1 physical counter and timer accesses are: -not trapped when accessed from the PVM. -trapped when accessed from secondary VMs. (https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/arch/aarch64/h…) Hafnium (or the SPMC): -does not access the EL1 physical counter (CNTPCT), nor the EL1 physical timer (CNTP) -does not setup the virtual counter offset (CNTVOFF_EL2=0 which leads to CNTVCT=CNTPCT) -emulates the EL1 timer using virtual timer registers (CNTVCT and CNTV), and Hypervisor timer (CNTHP) for the primary VM. Considering OP-TEE currently uses the physical counter (and does not use any architected timer), options are: -do not trap CNTPCT accesses. The problem I see here in the longer term, the virtual time does no longer match physical time (e.g. consider dynamic loading of SPs). -the SPMC traps CNTPCT accesses for all SPs (and maybe emulate like non-VHE KVM does, but this incurs latency in returning the virtual counter value). -OP-TEE replaces its CNTPCT usage by CNTVCT. The latter behaves such that if virtualization is disabled accesses are made with CNTVCT=CNTPCT. I tend to think that's the approach used by linux (needs further check though). Let me know your thoughts (@Achin, @Andrew, @JensW, others ...) Other considerations: -With S-EL2 enabled, the EL3 physical timer cannot be accessed from lower ELs whichever SCR_EL3.ST (the behavior is slightly different when virtualization is disabled). -S-EL2 physical (CNTHPS) and virtual (CNTHVS) timers are unused. -The EL1 virtual timer interrupt can fire only under the condition that the SP is voluntarily scheduled either by a direct message request or ffa_run. In other words such interrupt is never triggered by HW, but because the SPMC injects it to an SP vCPU which explicitly enabled it, when the virtual timer expires. - I noticed CNTPCT/CNTVCT direct reads within OP-TEE and Hafnium code bases. Arm ARM quite clearly mentions that such reads must be preceded by an ISB to forbid re-ordering. I think it's worth doing the change. Regards, Olivier.

4 years, 5 months

2
1
0 0

Hafnium / TF-A v2.4 first tagged release is available

by Olivier Deprez

Hi All, Following the announcement of the Trusted Firmware-A/Trusted Firmware-A-tests v2.4 release: We are pleased to announce the first tagged release of Hafnium [1] implementing the SPMC according to the FF-A v1.0 specification [2]. As a reminder, Hafnium has been transferred to trustedfirmware.org back in May 2020 to become the reference open source S-EL2 firmware, under an Arm/Google co-maintainership. Contributions are open to partners in trustedfirmware.org The Secure Partition Manager documentation is available at [3] Please also refer to the change log at [4] The companion TF-A test suite permits the validation of FF-A ABIs and NWd/SWd communication by the use of bare-metal S-EL1 secure partitions. Thanks to all who contributed to make it happen. Regards, Olivier. [1] https://git.trustedfirmware.org/hafnium/hafnium.git/tag/?h=v2.4 [2] https://developer.arm.com/documentation/den0077/latest [3] https://trustedfirmware-a.readthedocs.io/en/latest/components/secure-partit… [4] https://review.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/HEAD/d… ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Manish Badarkhe via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 18 November 2020 14:35 To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Trusted Firmware-A & Trusted Firmware-A-tests version 2.4 is now available Hi All, Trusted Firmware-A and Trusted Firmware-A-tests version 2.4 is now available and can be found here: Trusted Firmware-A: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tag/?h=v2.4 Trusted Firmware-A-tests: https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tag/?h=v2.4 Please refer to the change log of Trusted Firmware-A and Trusted Firmware-A-tests for further information here: Trusted Firmware-A: https://trustedfirmware-a.readthedocs.io/en/v2.4/change-log.html Trusted Firmware-A-tests: https://trustedfirmware-a-tests.readthedocs.io/en/v2.4/change-log.html Thanks Manish Badarkhe

4 years, 5 months

1
0
0 0

Re: [Hafnium] FFA Memory Management Interfaces

by raghu.ncstate＠icloud.com

Sorry for chiming in late. Whether or not the FF-A spec forbids exchanging executable pages, it would be better as a general rule to limit execute permissions to an SP, unless explicitly requested by the SP. I cant think of a reason why an SP would need to take donated NS memory and map it as an executable page unless it generates code or loads new code at run time. This, in my mind, is just another attack vector and potential "feature" to misuse, in case SP's don't sanitize pages for ex. I would be okay with limiting all memory exchanges between NWd and SWd to only operate on RW and have NX enabled always, unless there is an explicit use case some one comes up with that requires it. Also, shared pages between NWd and SWd should definitely not have execute permissions. Thanks Raghu -----Original Message----- From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrew Walbran via Hafnium Sent: Tuesday, October 20, 2020 9:07 AM To: Olivier Deprez <Olivier.Deprez(a)arm.com> Cc: hafnium(a)lists.trustedfirmware.org Subject: Re: [Hafnium] FFA Memory Management Interfaces On Tue, 20 Oct 2020 at 16:51, Olivier Deprez <Olivier.Deprez(a)arm.com> wrote: > Hi Andrew, > > On the first question it relates to this line > > https://review.trustedfirmware.org/c/hafnium/hafnium/+/6008/8/src/arch > /aarch64/hypervisor/other_world.c#92 > > and whether we should map the "Hypervisor VM" pages as RWX provided a > SP must never execute from an NS memory region. So it should never > happen that a VM grants execute permissions to an NS buffer shared to a SP. > I don't think it can happen if the memory region is shared, but why shouldn't an SP be allowed to retrieve a memory region donated or lent from a normal world VM to map as executable? Is there something in the FF-A spec that forbids that, or some reason we wouldn't want to allow it? > > Or should this be enforced by the Relayer/SPMC on a mem retrieve that > an NS memory region will always be mapped RW / NX? > > Regards, > Olivier. > > ________________________________________ > From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of > Andrew Walbran via Hafnium <hafnium(a)lists.trustedfirmware.org> > Sent: 20 October 2020 17:37 > To: Joao Alves > Cc: hafnium(a)lists.trustedfirmware.org > Subject: Re: [Hafnium] FFA Memory Management Interfaces > > On Tue, 20 Oct 2020 at 11:18, Joao Alves <Joao.Alves(a)arm.com> wrote: > > > Hello All, > > > > We have been working on enabling the use memory management > > interfaces between SWd and NWd, on Hafnium as SPMC. We identified a > > few points that would benefit from a general > > discussion/clarification through the Mailing List for this work to progress on time for the first release. > > > > The whole memory has been mapped to a VM representative of the NWd > > FFA endpoints (in the code can be found as a global variable called > > 'other_world_vm') in this patch > > <https://review.trustedfirmware.org/c/hafnium/hafnium/+/6008>. > > All the memory is configured as RW memory, to be permissive enough > > to > ease > > the validation of the sender's original permissions vs the requested > > sharing permissions. > > This approach seems valid given the following assumptions: the > > 'other_world_vm' is never scheduled, which means that there is no > > risk of memory leakage; the hypervisor should do the necessary > > validation of the permissions that a given NWd FFA endpoint has on a > > given memory region, before forwarding the handling of the operation to the SPMC. > > > > The first point to bring to discussion is regarding the RW configuration. > > > > *Is this really the best configuration we would expect for memory to > > be shared from NWd to the SWd? Or is this excluding any use-case we > > are not aware of (e.g. at this point we are restricting instruction > > permissions > to > > NX)?* > > > Is there any reason we need to restrict it to NX? Usually a VM owning > memory implies that it has full RWX access to it, as it would without > a hypervisor involved. We assume that it should be able to grant any > subset of those permissions when donating or lending the memory, > subject to FF-A or other policy restrictions. > > Whilst testing the memory management interfaces, I noticed that if the > > instruction access on the memory region descriptor (in the spec has > > been described in section 5.12, and in the code defined as 'struct > > ffa_memory_region') is set as 'not specified' for the Lend and > > Donate operations, the receiver would acquire permission to execute > > the memory region. This is due to the implementation of the function ' > > ffa_memory_permissions_to_mode > > < > https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/ffa_memor > y.c#n393 > > > > < > https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/ffa_memor > y.c#n393 > >', > > which sets the memory mode to MM_MODE_X for case instruction access > >FFA_INSTRUCTION_ACCESS_NOT_SPECIFIED. My understanding is that in > >such > case > > MM_MODE_X shouldn't be set. Please check this change > > <https://review.trustedfirmware.org/c/hafnium/hafnium/+/6008>. > > *@Andrew Walbran <qwandor(a)google.com>, is the change I provided correct? > > Or is there a reason for the current implementation of > > 'ffa_memory_permissions_to_mode'?* > > > Again, the assumption is that the owner of a page always has full > access to it. From the FF-A spec, section 5.11.2.2 says "In a > transaction to donate memory... if the receiver is a PE, the owner > must not specify the level of access". Section 5.11.3.2 says the same > thing for the execute permission in the case of donating or lending to > a single borrower. The spec says that the retriever should specify the > permissions it wants, but it is not required. So in these cases the > retriever may specify any permissions, and if it doesn't specify any then we give it full access. > > I also noticed that after a memory reclaim, the sender/owner of a > memory > > region acquires RW and X permissions, even if these were not part of > > the original permissions when sending the memory region. This is due > > to definition of the variable 'memory_to_attributes' in the function ' > > ffa_memory_reclaim > > < > https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/ffa_memor > y.c#n2576 > > > > ': > > uint32_t memory_to_attributes = MM_MODE_R | MM_MODE_W | MM_MODE_X; > > Down the call stack, the value of this variable is used to update > > the variable 'to_mode' in function 'ffa_retrieve_check_transition < > https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/ffa_memor > y.c#n665 > >'. > > The value of variable 'to_mode' is later passed to > >'ffa_region_group_identity_map' > > < > https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/ffa_memor > y.c#n1018 > > > > to update the owner's memory mapping. My understanding is that the > sender's > > memory mode should be reset to the mode it had prior to the original > memory > > send operation, and that this is going to be a problem for memory > > management operations (even between between VMs and between SPs). I > > have seen this behavior on my set, however I would like to validate > > my > analysis. > > *@Andrew Walbran <qwandor(a)google.com> would you be able to provide > > any comments on this?* > > > Our assumption, as above, is that the initial owner of a page starts > with full access to it, and so this is what should be restored when it > is reclaimed. > > Please let me know if anyone has any comments/questions. > > > > Best regards, > > João Alves > > > > > > > > > > > > > > > > > > > > >

4 years, 6 months

1
0
0 0

Re: [Hafnium] FFA Memory Management Interfaces

by Joao Alves

Hello, In the specification, section 5.4, after the definition of access there is a list of all accesses, and the missing combination is RWX. Someone else could comment here, this might have been a decision with security in mind, to avoid a writable section that is also executable. At least according to the spec, the owner could be sharing something else other than an RWX memory region. A partition's manifest may contain memory regions that will be owned by the partition. The memory attributes for that memory is also specified in the manifest. My understanding is that there is nothing preventing that memory from being used for memory management operations, whilst having configuration different than RWX. Am I thinking correctly? Also, currently the configuration of SCR_EL3.SIF (configured when booting TF-A) defines that no SWd component can execute from a NS memory segment. Does it make sense to enforce this at the 2nd stage of translation as well now that we are concerned with memory sharing between NWd and SWd? This is not to be changed now, but could be that SCR_EL3.SIF will need to be updated? I think that making the memory management operations implementation generic (i.e. not tied to any assumption), would prevent the above points to be a problem, even if in practice what you say is the case (i.e. owned memory is always RWX) because that would also be preserved. Best regards, João Alves ________________________________ From: Andrew Walbran Sent: Thursday, October 22, 2020 2:01 PM To: Joao Alves Cc: hafnium(a)lists.trustedfirmware.org Subject: Re: [Hafnium] FFA Memory Management Interfaces Hello, I still don't understand why a VM which owns a memory region and has exclusive access to it shouldn't have full RWX access permissions to it. What purpose does this serve? If the VM wants to restrict its own access it can do so with the permissions in its stage 1 page table. What other component should be controlling the VM's access to its own exclusively owned memory? On Thu, 22 Oct 2020 at 10:31, Joao Alves <Joao.Alves(a)arm.com<mailto:Joao.Alves@arm.com>> wrote: Hello Andrew, Thank you for your addressing our questions on the previous email. The section 5.4 of the spec defines ownership as "... software attribute that determines if a component can grant access to a memory region to anothercomponent." The same section also defines the accesses that a component may have on a memory region. I prepared the following patch: https://review.trustedfirmware.org/c/hafnium/hafnium/+/6521. It explicitly saves the access the sender had prior to the memory send operation, and restores that same value at a memory reclaim. This change makes the code generic, as it complies with all use-cases. Also the patch: https://review.trustedfirmware.org/c/hafnium/hafnium/+/6471. Assuming the use-cases where the owner does not have execute permissions, the receiver's permissions will be set as NX if the Instruction Access is not specified. Would you be able to review the changes? Let us know if you have any concerns regarding those patches. Best regards, João Alves ________________________________ From: Andrew Walbran Sent: Tuesday, October 20, 2020 5:06 PM To: Olivier Deprez Cc: Joao Alves; hafnium(a)lists.trustedfirmware.org<mailto:hafnium@lists.trustedfirmware.org> Subject: Re: [Hafnium] FFA Memory Management Interfaces On Tue, 20 Oct 2020 at 16:51, Olivier Deprez <Olivier.Deprez(a)arm.com<mailto:Olivier.Deprez@arm.com>> wrote: Hi Andrew, On the first question it relates to this line https://review.trustedfirmware.org/c/hafnium/hafnium/+/6008/8/src/arch/aarc… and whether we should map the "Hypervisor VM" pages as RWX provided a SP must never execute from an NS memory region. So it should never happen that a VM grants execute permissions to an NS buffer shared to a SP. I don't think it can happen if the memory region is shared, but why shouldn't an SP be allowed to retrieve a memory region donated or lent from a normal world VM to map as executable? Is there something in the FF-A spec that forbids that, or some reason we wouldn't want to allow it? Or should this be enforced by the Relayer/SPMC on a mem retrieve that an NS memory region will always be mapped RW / NX? Regards, Olivier. ________________________________________ From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org<mailto:hafnium-bounces@lists.trustedfirmware.org>> on behalf of Andrew Walbran via Hafnium <hafnium(a)lists.trustedfirmware.org<mailto:hafnium@lists.trustedfirmware.org>> Sent: 20 October 2020 17:37 To: Joao Alves Cc: hafnium(a)lists.trustedfirmware.org<mailto:hafnium@lists.trustedfirmware.org> Subject: Re: [Hafnium] FFA Memory Management Interfaces On Tue, 20 Oct 2020 at 11:18, Joao Alves <Joao.Alves(a)arm.com<mailto:Joao.Alves@arm.com>> wrote: > Hello All, > > We have been working on enabling the use memory management interfaces > between SWd and NWd, on Hafnium as SPMC. We identified a few points that > would benefit from a general discussion/clarification through the Mailing > List for this work to progress on time for the first release. > > The whole memory has been mapped to a VM representative of the NWd FFA > endpoints (in the code can be found as a global variable called > 'other_world_vm') in this patch > <https://review.trustedfirmware.org/c/hafnium/hafnium/+/6008>. > All the memory is configured as RW memory, to be permissive enough to ease > the validation of the sender's original permissions vs the requested > sharing permissions. > This approach seems valid given the following assumptions: the > 'other_world_vm' is never scheduled, which means that there is no risk of > memory leakage; the hypervisor should do the necessary validation of the > permissions that a given NWd FFA endpoint has on a given memory region, > before forwarding the handling of the operation to the SPMC. > > The first point to bring to discussion is regarding the RW configuration. > > *Is this really the best configuration we would expect for memory to be > shared from NWd to the SWd? Or is this excluding any use-case we are not > aware of (e.g. at this point we are restricting instruction permissions to > NX)?* > Is there any reason we need to restrict it to NX? Usually a VM owning memory implies that it has full RWX access to it, as it would without a hypervisor involved. We assume that it should be able to grant any subset of those permissions when donating or lending the memory, subject to FF-A or other policy restrictions. Whilst testing the memory management interfaces, I noticed that if the > instruction access on the memory region descriptor (in the spec has been > described in section 5.12, and in the code defined as 'struct > ffa_memory_region') is set as 'not specified' for the Lend and Donate > operations, the receiver would acquire permission to execute the memory > region. This is due to the implementation of the function ' > ffa_memory_permissions_to_mode > <https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/ffa_memory.c#n…> > <https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/ffa_memory.c#n…>', > which sets the memory mode to MM_MODE_X for case instruction access > FFA_INSTRUCTION_ACCESS_NOT_SPECIFIED. My understanding is that in such case > MM_MODE_X shouldn't be set. Please check this change > <https://review.trustedfirmware.org/c/hafnium/hafnium/+/6008>. > *@Andrew Walbran <qwandor(a)google.com<mailto:qwandor@google.com>>, is the change I provided correct? > Or is there a reason for the current implementation of > 'ffa_memory_permissions_to_mode'?* > Again, the assumption is that the owner of a page always has full access to it. From the FF-A spec, section 5.11.2.2 says "In a transaction to donate memory... if the receiver is a PE, the owner must not specify the level of access". Section 5.11.3.2 says the same thing for the execute permission in the case of donating or lending to a single borrower. The spec says that the retriever should specify the permissions it wants, but it is not required. So in these cases the retriever may specify any permissions, and if it doesn't specify any then we give it full access. I also noticed that after a memory reclaim, the sender/owner of a memory > region acquires RW and X permissions, even if these were not part of the > original permissions when sending the memory region. This is due to > definition of the variable 'memory_to_attributes' in the function ' > ffa_memory_reclaim > <https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/ffa_memory.c#n…> > ': > uint32_t memory_to_attributes = MM_MODE_R | MM_MODE_W | MM_MODE_X; > Down the call stack, the value of this variable is used to update the > variable 'to_mode' in function 'ffa_retrieve_check_transition > <https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/ffa_memory.c#n…>'. > The value of variable 'to_mode' is later passed to > 'ffa_region_group_identity_map' > <https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/ffa_memory.c#n…> > to update the owner's memory mapping. My understanding is that the sender's > memory mode should be reset to the mode it had prior to the original memory > send operation, and that this is going to be a problem for memory > management operations (even between between VMs and between SPs). I have > seen this behavior on my set, however I would like to validate my analysis. > *@Andrew Walbran <qwandor(a)google.com<mailto:qwandor@google.com>> would you be able to provide any > comments on this?* > Our assumption, as above, is that the initial owner of a page starts with full access to it, and so this is what should be restored when it is reclaimed. Please let me know if anyone has any comments/questions. > > Best regards, > João Alves > > > > > > > > > >

4 years, 6 months

1
0
0 0

Re: [Hafnium] FFA Memory Management Interfaces

by Joao Alves

Hello Andrew, Thank you for your addressing our questions on the previous email. The section 5.4 of the spec defines ownership as "... software attribute that determines if a component can grant access to a memory region to anothercomponent." The same section also defines the accesses that a component may have on a memory region. I prepared the following patch: https://review.trustedfirmware.org/c/hafnium/hafnium/+/6521. It explicitly saves the access the sender had prior to the memory send operation, and restores that same value at a memory reclaim. This change makes the code generic, as it complies with all use-cases. Also the patch: https://review.trustedfirmware.org/c/hafnium/hafnium/+/6471. Assuming the use-cases where the owner does not have execute permissions, the receiver's permissions will be set as NX if the Instruction Access is not specified. Would you be able to review the changes? Let us know if you have any concerns regarding those patches. Best regards, João Alves ________________________________ From: Andrew Walbran Sent: Tuesday, October 20, 2020 5:06 PM To: Olivier Deprez Cc: Joao Alves; hafnium(a)lists.trustedfirmware.org Subject: Re: [Hafnium] FFA Memory Management Interfaces On Tue, 20 Oct 2020 at 16:51, Olivier Deprez <Olivier.Deprez(a)arm.com<mailto:Olivier.Deprez@arm.com>> wrote: Hi Andrew, On the first question it relates to this line https://review.trustedfirmware.org/c/hafnium/hafnium/+/6008/8/src/arch/aarc… and whether we should map the "Hypervisor VM" pages as RWX provided a SP must never execute from an NS memory region. So it should never happen that a VM grants execute permissions to an NS buffer shared to a SP. I don't think it can happen if the memory region is shared, but why shouldn't an SP be allowed to retrieve a memory region donated or lent from a normal world VM to map as executable? Is there something in the FF-A spec that forbids that, or some reason we wouldn't want to allow it? Or should this be enforced by the Relayer/SPMC on a mem retrieve that an NS memory region will always be mapped RW / NX? Regards, Olivier. ________________________________________ From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org<mailto:hafnium-bounces@lists.trustedfirmware.org>> on behalf of Andrew Walbran via Hafnium <hafnium(a)lists.trustedfirmware.org<mailto:hafnium@lists.trustedfirmware.org>> Sent: 20 October 2020 17:37 To: Joao Alves Cc: hafnium(a)lists.trustedfirmware.org<mailto:hafnium@lists.trustedfirmware.org> Subject: Re: [Hafnium] FFA Memory Management Interfaces On Tue, 20 Oct 2020 at 11:18, Joao Alves <Joao.Alves(a)arm.com<mailto:Joao.Alves@arm.com>> wrote: > Hello All, > > We have been working on enabling the use memory management interfaces > between SWd and NWd, on Hafnium as SPMC. We identified a few points that > would benefit from a general discussion/clarification through the Mailing > List for this work to progress on time for the first release. > > The whole memory has been mapped to a VM representative of the NWd FFA > endpoints (in the code can be found as a global variable called > 'other_world_vm') in this patch > <https://review.trustedfirmware.org/c/hafnium/hafnium/+/6008>. > All the memory is configured as RW memory, to be permissive enough to ease > the validation of the sender's original permissions vs the requested > sharing permissions. > This approach seems valid given the following assumptions: the > 'other_world_vm' is never scheduled, which means that there is no risk of > memory leakage; the hypervisor should do the necessary validation of the > permissions that a given NWd FFA endpoint has on a given memory region, > before forwarding the handling of the operation to the SPMC. > > The first point to bring to discussion is regarding the RW configuration. > > *Is this really the best configuration we would expect for memory to be > shared from NWd to the SWd? Or is this excluding any use-case we are not > aware of (e.g. at this point we are restricting instruction permissions to > NX)?* > Is there any reason we need to restrict it to NX? Usually a VM owning memory implies that it has full RWX access to it, as it would without a hypervisor involved. We assume that it should be able to grant any subset of those permissions when donating or lending the memory, subject to FF-A or other policy restrictions. Whilst testing the memory management interfaces, I noticed that if the > instruction access on the memory region descriptor (in the spec has been > described in section 5.12, and in the code defined as 'struct > ffa_memory_region') is set as 'not specified' for the Lend and Donate > operations, the receiver would acquire permission to execute the memory > region. This is due to the implementation of the function ' > ffa_memory_permissions_to_mode > <https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/ffa_memory.c#n…> > <https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/ffa_memory.c#n…>', > which sets the memory mode to MM_MODE_X for case instruction access > FFA_INSTRUCTION_ACCESS_NOT_SPECIFIED. My understanding is that in such case > MM_MODE_X shouldn't be set. Please check this change > <https://review.trustedfirmware.org/c/hafnium/hafnium/+/6008>. > *@Andrew Walbran <qwandor(a)google.com<mailto:qwandor@google.com>>, is the change I provided correct? > Or is there a reason for the current implementation of > 'ffa_memory_permissions_to_mode'?* > Again, the assumption is that the owner of a page always has full access to it. From the FF-A spec, section 5.11.2.2 says "In a transaction to donate memory... if the receiver is a PE, the owner must not specify the level of access". Section 5.11.3.2 says the same thing for the execute permission in the case of donating or lending to a single borrower. The spec says that the retriever should specify the permissions it wants, but it is not required. So in these cases the retriever may specify any permissions, and if it doesn't specify any then we give it full access. I also noticed that after a memory reclaim, the sender/owner of a memory > region acquires RW and X permissions, even if these were not part of the > original permissions when sending the memory region. This is due to > definition of the variable 'memory_to_attributes' in the function ' > ffa_memory_reclaim > <https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/ffa_memory.c#n…> > ': > uint32_t memory_to_attributes = MM_MODE_R | MM_MODE_W | MM_MODE_X; > Down the call stack, the value of this variable is used to update the > variable 'to_mode' in function 'ffa_retrieve_check_transition > <https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/ffa_memory.c#n…>'. > The value of variable 'to_mode' is later passed to > 'ffa_region_group_identity_map' > <https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/ffa_memory.c#n…> > to update the owner's memory mapping. My understanding is that the sender's > memory mode should be reset to the mode it had prior to the original memory > send operation, and that this is going to be a problem for memory > management operations (even between between VMs and between SPs). I have > seen this behavior on my set, however I would like to validate my analysis. > *@Andrew Walbran <qwandor(a)google.com<mailto:qwandor@google.com>> would you be able to provide any > comments on this?* > Our assumption, as above, is that the initial owner of a page starts with full access to it, and so this is what should be restored when it is reclaimed. Please let me know if anyone has any comments/questions. > > Best regards, > João Alves > > > > > > > > > >

4 years, 6 months

2
1
0 0

Re: [Hafnium] FFA Memory Management Interfaces

by Olivier Deprez

Hi Andrew, On the first question it relates to this line https://review.trustedfirmware.org/c/hafnium/hafnium/+/6008/8/src/arch/aarc… and whether we should map the "Hypervisor VM" pages as RWX provided a SP must never execute from an NS memory region. So it should never happen that a VM grants execute permissions to an NS buffer shared to a SP. Or should this be enforced by the Relayer/SPMC on a mem retrieve that an NS memory region will always be mapped RW / NX? Regards, Olivier. ________________________________________ From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of Andrew Walbran via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: 20 October 2020 17:37 To: Joao Alves Cc: hafnium(a)lists.trustedfirmware.org Subject: Re: [Hafnium] FFA Memory Management Interfaces On Tue, 20 Oct 2020 at 11:18, Joao Alves <Joao.Alves(a)arm.com> wrote: > Hello All, > > We have been working on enabling the use memory management interfaces > between SWd and NWd, on Hafnium as SPMC. We identified a few points that > would benefit from a general discussion/clarification through the Mailing > List for this work to progress on time for the first release. > > The whole memory has been mapped to a VM representative of the NWd FFA > endpoints (in the code can be found as a global variable called > 'other_world_vm') in this patch > <https://review.trustedfirmware.org/c/hafnium/hafnium/+/6008>. > All the memory is configured as RW memory, to be permissive enough to ease > the validation of the sender's original permissions vs the requested > sharing permissions. > This approach seems valid given the following assumptions: the > 'other_world_vm' is never scheduled, which means that there is no risk of > memory leakage; the hypervisor should do the necessary validation of the > permissions that a given NWd FFA endpoint has on a given memory region, > before forwarding the handling of the operation to the SPMC. > > The first point to bring to discussion is regarding the RW configuration. > > *Is this really the best configuration we would expect for memory to be > shared from NWd to the SWd? Or is this excluding any use-case we are not > aware of (e.g. at this point we are restricting instruction permissions to > NX)?* > Is there any reason we need to restrict it to NX? Usually a VM owning memory implies that it has full RWX access to it, as it would without a hypervisor involved. We assume that it should be able to grant any subset of those permissions when donating or lending the memory, subject to FF-A or other policy restrictions. Whilst testing the memory management interfaces, I noticed that if the > instruction access on the memory region descriptor (in the spec has been > described in section 5.12, and in the code defined as 'struct > ffa_memory_region') is set as 'not specified' for the Lend and Donate > operations, the receiver would acquire permission to execute the memory > region. This is due to the implementation of the function ' > ffa_memory_permissions_to_mode > <https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/ffa_memory.c#n…> > <https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/ffa_memory.c#n…>', > which sets the memory mode to MM_MODE_X for case instruction access > FFA_INSTRUCTION_ACCESS_NOT_SPECIFIED. My understanding is that in such case > MM_MODE_X shouldn't be set. Please check this change > <https://review.trustedfirmware.org/c/hafnium/hafnium/+/6008>. > *@Andrew Walbran <qwandor(a)google.com>, is the change I provided correct? > Or is there a reason for the current implementation of > 'ffa_memory_permissions_to_mode'?* > Again, the assumption is that the owner of a page always has full access to it. From the FF-A spec, section 5.11.2.2 says "In a transaction to donate memory... if the receiver is a PE, the owner must not specify the level of access". Section 5.11.3.2 says the same thing for the execute permission in the case of donating or lending to a single borrower. The spec says that the retriever should specify the permissions it wants, but it is not required. So in these cases the retriever may specify any permissions, and if it doesn't specify any then we give it full access. I also noticed that after a memory reclaim, the sender/owner of a memory > region acquires RW and X permissions, even if these were not part of the > original permissions when sending the memory region. This is due to > definition of the variable 'memory_to_attributes' in the function ' > ffa_memory_reclaim > <https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/ffa_memory.c#n…> > ': > uint32_t memory_to_attributes = MM_MODE_R | MM_MODE_W | MM_MODE_X; > Down the call stack, the value of this variable is used to update the > variable 'to_mode' in function 'ffa_retrieve_check_transition > <https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/ffa_memory.c#n…>'. > The value of variable 'to_mode' is later passed to > 'ffa_region_group_identity_map' > <https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/ffa_memory.c#n…> > to update the owner's memory mapping. My understanding is that the sender's > memory mode should be reset to the mode it had prior to the original memory > send operation, and that this is going to be a problem for memory > management operations (even between between VMs and between SPs). I have > seen this behavior on my set, however I would like to validate my analysis. > *@Andrew Walbran <qwandor(a)google.com> would you be able to provide any > comments on this?* > Our assumption, as above, is that the initial owner of a page starts with full access to it, and so this is what should be restored when it is reclaimed. Please let me know if anyone has any comments/questions. > > Best regards, > João Alves > > > > > > > > > >

4 years, 6 months

2
1
0 0

FFA Memory Management Interfaces

by Joao Alves

Hello All, We have been working on enabling the use memory management interfaces between SWd and NWd, on Hafnium as SPMC. We identified a few points that would benefit from a general discussion/clarification through the Mailing List for this work to progress on time for the first release. The whole memory has been mapped to a VM representative of the NWd FFA endpoints (in the code can be found as a global variable called 'other_world_vm') in this patch<https://review.trustedfirmware.org/c/hafnium/hafnium/+/6008>. All the memory is configured as RW memory, to be permissive enough to ease the validation of the sender's original permissions vs the requested sharing permissions. This approach seems valid given the following assumptions: the 'other_world_vm' is never scheduled, which means that there is no risk of memory leakage; the hypervisor should do the necessary validation of the permissions that a given NWd FFA endpoint has on a given memory region, before forwarding the handling of the operation to the SPMC. The first point to bring to discussion is regarding the RW configuration. Is this really the best configuration we would expect for memory to be shared from NWd to the SWd? Or is this excluding any use-case we are not aware of (e.g. at this point we are restricting instruction permissions to NX)? Whilst testing the memory management interfaces, I noticed that if the instruction access on the memory region descriptor (in the spec has been described in section 5.12, and in the code defined as 'struct ffa_memory_region') is set as 'not specified' for the Lend and Donate operations, the receiver would acquire permission to execute the memory region. This is due to the implementation of the function 'ffa_memory_permissions_to_mode<https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/ffa_memory.c#n…><https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/ffa_memory.c#n…>', which sets the memory mode to MM_MODE_X for case instruction access FFA_INSTRUCTION_ACCESS_NOT_SPECIFIED. My understanding is that in such case MM_MODE_X shouldn't be set. Please check this change<https://review.trustedfirmware.org/c/hafnium/hafnium/+/6008>. @Andrew Walbran<mailto:qwandor@google.com>, is the change I provided correct? Or is there a reason for the current implementation of 'ffa_memory_permissions_to_mode'? I also noticed that after a memory reclaim, the sender/owner of a memory region acquires RW and X permissions, even if these were not part of the original permissions when sending the memory region. This is due to definition of the variable 'memory_to_attributes' in the function 'ffa_memory_reclaim<https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/ffa_memory.c#n…>': uint32_t memory_to_attributes = MM_MODE_R | MM_MODE_W | MM_MODE_X; Down the call stack, the value of this variable is used to update the variable 'to_mode' in function 'ffa_retrieve_check_transition<https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/ffa_memory.c#n…>'. The value of variable 'to_mode' is later passed to 'ffa_region_group_identity_map'<https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/ffa_memory.c#n…> to update the owner's memory mapping. My understanding is that the sender's memory mode should be reset to the mode it had prior to the original memory send operation, and that this is going to be a problem for memory management operations (even between between VMs and between SPs). I have seen this behavior on my set, however I would like to validate my analysis. @Andrew Walbran<mailto:qwandor@google.com> would you be able to provide any comments on this? Please let me know if anyone has any comments/questions. Best regards, João Alves

4 years, 6 months

2
1
0 0

Forthcoming Trusted Firmware-A 2.4 release

by Manish Badarkhe

Hi, This is to notify that we are planning to target the Trusted Firmware-A 2.4 release during the second week of November 2020 as part of the regular 6 month cadence. The aim is to consolidate all TF-A work since the 2.3 release. As part of this, a release candidate tag will be created and release activities will commence from Friday 30th Oct 2020 (code freeze date). Essentially we will not merge any major enhancements from this date until the release is made. Please ensure any Pull Requests (PR’s) desired to make the 2.4 release are submitted in good time, to be completed by Tuesday 27th Oct 2020. Any major enhancement PR’s still open after that date will not be merged until after the release Please note, there is no guarantee that all patches under review will be merged before the code freeze date. Any patches that don’t make the code freeze date will complete their review and merge post the release date. Thanks Manish Badarkhe

4 years, 7 months

1
0
0 0

Re: [Hafnium] Specify number of CPUs for Hafnium builds

by David Brazdil

Hi Varun, Memory footprint will be a function of three build-time constants: MAX_CPUS, MAX_VMS and HEAP_PAGES. They're defined in the build rule of each target platform, e.g. for RPi4 it is here: https://git.trustedfirmware.org/hafnium/project/reference.git/tree/BUILD.gn… Hope this helps, David On Tue, Sep 15, 2020 at 1:08 AM Varun Wadekar via Hafnium < hafnium(a)lists.trustedfirmware.org> wrote: > Hi, > > We are trying to figure out the memory footprint (.text + .data) for the > Hafnium image. I couldn't find a place where the number of CPUs are > specified for a platform. I assume that the footprint will increase as we > introduce more CPUs in the mix. > > Can someone please help me figure this out? > > Thanks. > -- > Hafnium mailing list > Hafnium(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/hafnium >

4 years, 7 months

1
0
0 0

Specify number of CPUs for Hafnium builds

by Varun Wadekar

Hi, We are trying to figure out the memory footprint (.text + .data) for the Hafnium image. I couldn't find a place where the number of CPUs are specified for a platform. I assume that the footprint will increase as we introduce more CPUs in the mix. Can someone please help me figure this out? Thanks.

4 years, 7 months

1
0
0 0

Re: [Hafnium] [TF-A] Fw: Automate generation of Partition's specific configuration

by Joao Alves

Hi Raghu, Thank you very much for your feedback! It seems like a good idea to automate it and the approach looks fine to me. Is my understanding correct that the generated *dtsi* files will need to be included in the *dts* files once and the hope is if there is a change, the dts files need not change since the dtsi files will be regenerated every time during build? Yes, your understanding is correct. The other way this could be done is that the tool can generate dts files which have nodes that change at build time, which can then be compiled and added as dtb files, added to the FIP. That way fvp_tb_fw_config.dts and fvp_spmc_manifest.dts will remain the same and not have any dependency on a changing dtsi file. I’d prefer that dts files that change frequently like in this case be autogenerated entirely and as separate files. That _seems_ cleaner but may not work out so in practice. I agree with you that the approach you described above would make the whole process a bit cleaner. One way this could be done is by passing the *.pre.dts files (generated after the initial processing from dtc) to the script that are part of the patch. Last time I worked on this, I added the possibility to generate the nodes structure to an already existing dts file. Thus, expanding the previous configuration with the values of the new nodes. However, this work needs further testing. Alternatively, the python package I am using in the script can parse and generate dtb instead of dts. I was thinking to add the option to the dts_gen.py script (maybe rename it as well) to operate over the dtb format. So, making sure that "in-place" changes are working , and adding the option to operate over dtb files should allow for the cleaner approach that you referred. As is and making the referred changes, most of the script's logic should be preserved, so I don't think there will be a lot of changes to the current implementation, which is good. Please let me know if I was not very clear, or if you have any other comments. Also thanks @Gyorgy Szing<mailto:Gyorgy.Szing@arm.com> for the feedback on the current state of the patch, I appreciate it. Let me know if anyone has questions, or any other comments to the scripts and/or current discussion. I will notify once the work progresses. Best regards, João Alves ________________________________ From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of Raghu Krishnamurthy via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: Friday, August 7, 2020 5:54 PM To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>; hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org> Subject: Re: [Hafnium] [TF-A] Fw: Automate generation of Partition's specific configuration Hi, It seems like a good idea to automate it and the approach looks fine to me. Is my understanding correct that the generated *dtsi* files will need to be included in the *dts* files once and the hope is if there is a change, the dts files need not change since the dtsi files will be regenerated every time during build? The other way this could be done is that the tool can generate dts files which have nodes that change at build time, which can then be compiled and added as dtb files, added to the FIP. That way fvp_tb_fw_config.dts and fvp_spmc_manifest.dts will remain the same and not have any dependency on a changing dtsi file. I’d prefer that dts files that change frequently like in this case be autogenerated entirely and as separate files. That _seems_ cleaner but may not work out so in practice. Thanks Raghu From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Joao Alves via TF-A Sent: Monday, August 3, 2020 10:08 AM To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Fw: Automate generation of Partition's specific configuration Hi all, Forwarding email below as the referred work may be useful/relevant for other parts of the TF-A project as well. Best regards, João Alves _____ From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org <mailto:hafnium-bounces@lists.trustedfirmware.org> > on behalf of Joao Alves via Hafnium <hafnium(a)lists.trustedfirmware.org <mailto:hafnium@lists.trustedfirmware.org> > Sent: Monday, August 3, 2020 5:59 PM To: hafnium(a)lists.trustedfirmware.org <mailto:hafnium@lists.trustedfirmware.org> <hafnium(a)lists.trustedfirmware.org <mailto:hafnium@lists.trustedfirmware.org> > Subject: [Hafnium] Automate generation of Partition's specific configuration Hello all, I have been trying to ease the process of adding a Secure Partition to a system using Secure Hafnium. There is no way to automatically generate SP's specific configuration into TF-A's code-base. Considering FVP as the target platform, we need to manually add partition's specific configuration to files "fvp_tb_fw_config.dts" and "fvp_spmc_manifest.dts" (files held in FVP platform specific folder of TF-A codebase). The following snippet shows the hypervisor node from "fvp_spmc_manifest.dts", for the simple case of having in the system two Cactus Secure Partitions: hypervisor { compatible = "hafnium,hafnium"; vm1 { is_ffa_partition; debug_name = "cactus-primary"; load_address = <0x7000000>; }; vm2 { is_ffa_partition; debug_name = "cactus-secondary"; load_address = <0x7100000>; vcpu_count = <2>; mem_size = <1048576>; }; }; Some of the above properties are available in the partition's manifest, for example "debug_name" and "load_address". If changing one of these values in the partition's manifest or adding another SP, we also need to update the referred files. In order to avoid the burden of having to manually update partition's specific configuration and to make whole system more scalable, I started to write a script that is able to generate a specific node structure and fetch any property value from a any dts file. Then, applied it to fetch/generate SPs specific configuration and include it in aforementioned configuration files. Although it is still a Work In Progress, the work can be found in the patch: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5150. The implementation is divided between two scripts: * "dts_gen.py" - This is a generic solution for the problem. It can fetch/generate/alter any configuration using dts files. * "sp_dts_gen.py" - Uses the previous command to solve the specific problem regarding SPs specific configuration. Although is still Work In Progress, I am looking to obtain feedback/reviews from anyone that could be interested in using this implementation. The above files contain a lot of comments on how to use them, and also describing the implementation. If the obtained feedback is good, I can work on integrating this in TF-A's build-system. Let me know if anyone has questions. Best regards, João Alves -- 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

4 years, 8 months

1
0
0 0

Re: [Hafnium] Stage-2 page faults reports to EL1

by Andrew Walbran

On Mon, 3 Aug 2020 at 10:32, Olivier Deprez via Hafnium < hafnium(a)lists.trustedfirmware.org> wrote: > Hi, > > On a Stage-2 page fault, Hafnium does not report FAR_EL2 to FAR_EL1 in > inject_el1_exception . > > As a consequence EL1 is resumed although it cannot determine the faulting > address from FAR_EL1 (which likely holds zero or some other remnant value?). > > Is this intended? > That sounds like a bug. Fuad, did you work on this? Any idea what's going on here? (Note, Fuad is away this week but can hopefully reply next week.)

4 years, 9 months

2
1
0 0

Re: [Hafnium] [TF-A] Fw: Automate generation of Partition's specific configuration

by raghu.ncstate＠icloud.com

Hi, It seems like a good idea to automate it and the approach looks fine to me. Is my understanding correct that the generated *dtsi* files will need to be included in the *dts* files once and the hope is if there is a change, the dts files need not change since the dtsi files will be regenerated every time during build? The other way this could be done is that the tool can generate dts files which have nodes that change at build time, which can then be compiled and added as dtb files, added to the FIP. That way fvp_tb_fw_config.dts and fvp_spmc_manifest.dts will remain the same and not have any dependency on a changing dtsi file. I’d prefer that dts files that change frequently like in this case be autogenerated entirely and as separate files. That _seems_ cleaner but may not work out so in practice. Thanks Raghu From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Joao Alves via TF-A Sent: Monday, August 3, 2020 10:08 AM To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Fw: Automate generation of Partition's specific configuration Hi all, Forwarding email below as the referred work may be useful/relevant for other parts of the TF-A project as well. Best regards, João Alves _____ From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org <mailto:hafnium-bounces@lists.trustedfirmware.org> > on behalf of Joao Alves via Hafnium <hafnium(a)lists.trustedfirmware.org <mailto:hafnium@lists.trustedfirmware.org> > Sent: Monday, August 3, 2020 5:59 PM To: hafnium(a)lists.trustedfirmware.org <mailto:hafnium@lists.trustedfirmware.org> <hafnium(a)lists.trustedfirmware.org <mailto:hafnium@lists.trustedfirmware.org> > Subject: [Hafnium] Automate generation of Partition's specific configuration Hello all, I have been trying to ease the process of adding a Secure Partition to a system using Secure Hafnium. There is no way to automatically generate SP's specific configuration into TF-A's code-base. Considering FVP as the target platform, we need to manually add partition's specific configuration to files "fvp_tb_fw_config.dts" and "fvp_spmc_manifest.dts" (files held in FVP platform specific folder of TF-A codebase). The following snippet shows the hypervisor node from "fvp_spmc_manifest.dts", for the simple case of having in the system two Cactus Secure Partitions: hypervisor { compatible = "hafnium,hafnium"; vm1 { is_ffa_partition; debug_name = "cactus-primary"; load_address = <0x7000000>; }; vm2 { is_ffa_partition; debug_name = "cactus-secondary"; load_address = <0x7100000>; vcpu_count = <2>; mem_size = <1048576>; }; }; Some of the above properties are available in the partition's manifest, for example "debug_name" and "load_address". If changing one of these values in the partition's manifest or adding another SP, we also need to update the referred files. In order to avoid the burden of having to manually update partition's specific configuration and to make whole system more scalable, I started to write a script that is able to generate a specific node structure and fetch any property value from a any dts file. Then, applied it to fetch/generate SPs specific configuration and include it in aforementioned configuration files. Although it is still a Work In Progress, the work can be found in the patch: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5150. The implementation is divided between two scripts: * "dts_gen.py" - This is a generic solution for the problem. It can fetch/generate/alter any configuration using dts files. * "sp_dts_gen.py" - Uses the previous command to solve the specific problem regarding SPs specific configuration. Although is still Work In Progress, I am looking to obtain feedback/reviews from anyone that could be interested in using this implementation. The above files contain a lot of comments on how to use them, and also describing the implementation. If the obtained feedback is good, I can work on integrating this in TF-A's build-system. Let me know if anyone has questions. Best regards, João Alves -- Hafnium mailing list Hafnium(a)lists.trustedfirmware.org <mailto:Hafnium@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/hafnium

4 years, 9 months

1
0
0 0

Re: [Hafnium] FF-A id ranges

by raghu.ncstate＠icloud.com

The static partitioning scheme and option 1 looks fine to me. Option 2 is fine too but not sure I see why a platform would want to or need to customize the ID range. -----Original Message----- From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrew Walbran via Hafnium Sent: Tuesday, August 4, 2020 3:13 AM To: Olivier Deprez <Olivier.Deprez(a)arm.com> Cc: hafnium(a)lists.trustedfirmware.org Subject: Re: [Hafnium] FF-A id ranges On Mon, 3 Aug 2020 at 18:03, Olivier Deprez via Hafnium < hafnium(a)lists.trustedfirmware.org> wrote: > Hi, > > We consider updating the range of FF-A IDs for Secure Partitions > running in SWd on top of Hafnium. > > Bit 15 in FF-A IDs can serve to hint the world type into which the > VM/SP resides. > FF-A id bit 15 clear => id space [1 : 0x7fff] reserved for VMs on top > of NWd Hafnium FF-A id bit 15 set => id space [0x8001 : 0xffff] > reserved for SPs on top of SWd Hafnium > > 0 reserved to the Hypervisor itself. > 0x8000 reserved for the TEE (or later for the SPMC). > > One way to achieve this is to define a static value for the base of > FF-A ids, see: > > https://review.trustedfirmware.org/c/hafnium/hafnium/+/5165/1/inc/vmap > i/hf/types.h#30 > > The intent is to set 0 for the NWd Hypervisor build and 0x8000 for the > SWd SPMC build. > 1/ This can be done through the SECURE_WORLD macro (although this > macro is only available to src/arch/aarch64/* files) 2/ This can be > passed as a platform parameter in the build flow (e.g. same way as > max_vms) > > There are others ways rather than using id ranges, e.g. setting the > bit explicitly in FF-A IDs when doing the SPMC build. > > Any thoughts? > I guess Hafnium will need to know not just what IDs to use for the world it is operating in, but also how to interact with the other world. This seems like an arch-specific concept, so maybe some of the constants currently defined in hf/types should be moved into an aarch64 directory so they can be defined based on the SECURE_WORLD macro? This is essentially your option 1 above.

4 years, 9 months

2
1
0 0

Re: [Hafnium] FF-A id ranges

by Andrew Walbran

On Mon, 3 Aug 2020 at 18:03, Olivier Deprez via Hafnium < hafnium(a)lists.trustedfirmware.org> wrote: > Hi, > > We consider updating the range of FF-A IDs for Secure Partitions running > in SWd on top of Hafnium. > > Bit 15 in FF-A IDs can serve to hint the world type into which the VM/SP > resides. > FF-A id bit 15 clear => id space [1 : 0x7fff] reserved for VMs on top of > NWd Hafnium > FF-A id bit 15 set => id space [0x8001 : 0xffff] reserved for SPs on top > of SWd Hafnium > > 0 reserved to the Hypervisor itself. > 0x8000 reserved for the TEE (or later for the SPMC). > > One way to achieve this is to define a static value for the base of FF-A > ids, see: > > https://review.trustedfirmware.org/c/hafnium/hafnium/+/5165/1/inc/vmapi/hf/… > > The intent is to set 0 for the NWd Hypervisor build and 0x8000 for the SWd > SPMC build. > 1/ This can be done through the SECURE_WORLD macro (although this macro is > only available to src/arch/aarch64/* files) > 2/ This can be passed as a platform parameter in the build flow (e.g. same > way as max_vms) > > There are others ways rather than using id ranges, e.g. setting the bit > explicitly in FF-A IDs when doing the SPMC build. > > Any thoughts? > I guess Hafnium will need to know not just what IDs to use for the world it is operating in, but also how to interact with the other world. This seems like an arch-specific concept, so maybe some of the constants currently defined in hf/types should be moved into an aarch64 directory so they can be defined based on the SECURE_WORLD macro? This is essentially your option 1 above.

4 years, 9 months

1
0
0 0

FF-A id ranges

by Olivier Deprez

Hi, We consider updating the range of FF-A IDs for Secure Partitions running in SWd on top of Hafnium. Bit 15 in FF-A IDs can serve to hint the world type into which the VM/SP resides. FF-A id bit 15 clear => id space [1 : 0x7fff] reserved for VMs on top of NWd Hafnium FF-A id bit 15 set => id space [0x8001 : 0xffff] reserved for SPs on top of SWd Hafnium 0 reserved to the Hypervisor itself. 0x8000 reserved for the TEE (or later for the SPMC). One way to achieve this is to define a static value for the base of FF-A ids, see: https://review.trustedfirmware.org/c/hafnium/hafnium/+/5165/1/inc/vmapi/hf/… The intent is to set 0 for the NWd Hypervisor build and 0x8000 for the SWd SPMC build. 1/ This can be done through the SECURE_WORLD macro (although this macro is only available to src/arch/aarch64/* files) 2/ This can be passed as a platform parameter in the build flow (e.g. same way as max_vms) There are others ways rather than using id ranges, e.g. setting the bit explicitly in FF-A IDs when doing the SPMC build. Any thoughts? Regards, Olivier.

4 years, 9 months

1
0
0 0

Automate generation of Partition's specific configuration

by Joao Alves

Hello all, I have been trying to ease the process of adding a Secure Partition to a system using Secure Hafnium. There is no way to automatically generate SP's specific configuration into TF-A's code-base. Considering FVP as the target platform, we need to manually add partition's specific configuration to files "fvp_tb_fw_config.dts" and "fvp_spmc_manifest.dts" (files held in FVP platform specific folder of TF-A codebase). The following snippet shows the hypervisor node from "fvp_spmc_manifest.dts", for the simple case of having in the system two Cactus Secure Partitions: hypervisor { compatible = "hafnium,hafnium"; vm1 { is_ffa_partition; debug_name = "cactus-primary"; load_address = <0x7000000>; }; vm2 { is_ffa_partition; debug_name = "cactus-secondary"; load_address = <0x7100000>; vcpu_count = <2>; mem_size = <1048576>; }; }; Some of the above properties are available in the partition's manifest, for example "debug_name" and "load_address". If changing one of these values in the partition's manifest or adding another SP, we also need to update the referred files. In order to avoid the burden of having to manually update partition's specific configuration and to make whole system more scalable, I started to write a script that is able to generate a specific node structure and fetch any property value from a any dts file. Then, applied it to fetch/generate SPs specific configuration and include it in aforementioned configuration files. Although it is still a Work In Progress, the work can be found in the patch: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5150. The implementation is divided between two scripts: * "dts_gen.py" - This is a generic solution for the problem. It can fetch/generate/alter any configuration using dts files. * "sp_dts_gen.py" - Uses the previous command to solve the specific problem regarding SPs specific configuration. Although is still Work In Progress, I am looking to obtain feedback/reviews from anyone that could be interested in using this implementation. The above files contain a lot of comments on how to use them, and also describing the implementation. If the obtained feedback is good, I can work on integrating this in TF-A's build-system. Let me know if anyone has questions. Best regards, João Alves

4 years, 9 months

1
0
0 0

Stage-2 page faults reports to EL1

by Olivier Deprez

Hi, On a Stage-2 page fault, Hafnium does not report FAR_EL2 to FAR_EL1 in inject_el1_exception . As a consequence EL1 is resumed although it cannot determine the faulting address from FAR_EL1 (which likely holds zero or some other remnant value?). Is this intended? Regards, Olivier.

4 years, 9 months

1
0
0 0

Re: [Hafnium] FFA_FEATURES and FFA_RXTX_MAP_64

by Achin Gupta

Hi Olivier/Andrew, > On 22 Jul 2020, at 15:08, Andrew Walbran via Hafnium <hafnium(a)lists.trustedfirmware.org> wrote: > > On Wed, 22 Jul 2020 at 15:01, Olivier Deprez via Hafnium < > hafnium(a)lists.trustedfirmware.org> wrote: > >> Hi, >> >> We noticed api_ffa_features returns FFA_SUCCESS_32 for all implemented >> ABIs with the SMC32 convention, but FFA_RXTX_MAP_64: >> https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/api.c#n1430 Did you mean : https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/api.c#n1510 >> >> On the other hand ffa_handler discards the SMC convention bit: >> >> https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/arch/aarch64/h… What is the rationale behind this? As per the SMCCC: -1 must be returned for an SMC64/HVC64 call from AArch32 state or an unknown function ID. In the latter case, if the spec don’t list it then it ain’t there :) >> >> It means one can call FFA_FEATURES(FFA_RXTX_MAP_32) which will fail, >> although this does not prevent effectively calling the same ABI with the >> SMC32 convention. >> >> Is there some fine tuning to do here? >> Should we just discard the SMC convention bit in api_ffa_features? >> > > I don't think FFA_RXTX_MAP_32 will work, because we need 64-bit addresses > for the buffers that it passes. We should probably return an error from > ffa_handler if a VM tries to call FFA_RXTX_MAP_32. Does Hafnium not intend to work with AArch32 SPs? Is this is a requirement that has been spelt out so the community ensures no AArch32 SPs are presented. The SPM design doc catered for this requirement the last time I checked. > > For other functions I guess we could make it support either, by discarding > the SMC convention bit in FFA_FEATURES as you suggest. Are there any other > differences between the SMC32 and SMC64 convention which we need to take > care of? I think we need to make a more informed choice. For example, what if FFA_FEATURES is called with the non-existent 64-bit FID for FFA_ID_GET, FFA_RXTX_UNMAP, FFA_PARTITION_INFO_GET, FFA_MEM_FRAG_RX, FFA_MEM_FRAG_TX etc. Cheers, Achin > -- > Hafnium mailing list > Hafnium(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/hafnium

4 years, 9 months

2
3
0 0

Re: [Hafnium] FFA_FEATURES and FFA_RXTX_MAP_64

by Andrew Walbran

On Wed, 22 Jul 2020 at 15:01, Olivier Deprez via Hafnium < hafnium(a)lists.trustedfirmware.org> wrote: > Hi, > > We noticed api_ffa_features returns FFA_SUCCESS_32 for all implemented > ABIs with the SMC32 convention, but FFA_RXTX_MAP_64: > https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/api.c#n1430 > > On the other hand ffa_handler discards the SMC convention bit: > > https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/arch/aarch64/h… > > It means one can call FFA_FEATURES(FFA_RXTX_MAP_32) which will fail, > although this does not prevent effectively calling the same ABI with the > SMC32 convention. > > Is there some fine tuning to do here? > Should we just discard the SMC convention bit in api_ffa_features? > I don't think FFA_RXTX_MAP_32 will work, because we need 64-bit addresses for the buffers that it passes. We should probably return an error from ffa_handler if a VM tries to call FFA_RXTX_MAP_32. For other functions I guess we could make it support either, by discarding the SMC convention bit in FFA_FEATURES as you suggest. Are there any other differences between the SMC32 and SMC64 convention which we need to take care of?

4 years, 9 months

1
0
0 0

FFA_FEATURES and FFA_RXTX_MAP_64

by Olivier Deprez

Hi, We noticed api_ffa_features returns FFA_SUCCESS_32 for all implemented ABIs with the SMC32 convention, but FFA_RXTX_MAP_64: https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/api.c#n1430 On the other hand ffa_handler discards the SMC convention bit: https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/arch/aarch64/h… It means one can call FFA_FEATURES(FFA_RXTX_MAP_32) which will fail, although this does not prevent effectively calling the same ABI with the SMC32 convention. Is there some fine tuning to do here? Should we just discard the SMC convention bit in api_ffa_features? Regards, Olivier.

4 years, 9 months

1
0
0 0

Re: [Hafnium] Debugging page table creation in Hafnium

by Andrew Walbran

+hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org> On Mon, 20 Jul 2020 at 17:31, Andrew Walbran <qwandor(a)google.com> wrote: > mm_vm_dump is for dumping a VM's stage 2 page table. To dump the > hypervisor's page table (which is what mm_init is initialising), try: > > mm_ptable_dump(&ptable, MM_FLAG_STAGE1); > > If that doesn't work let me know and I'll try to reproduce the problem. > > On Mon, 20 Jul 2020 at 17:20, Madhukar Pappireddy < > Madhukar.Pappireddy(a)arm.com> wrote: > >> Hi Raghu and Andrew, >> >> Thanks for the inputs. I have added the mm_vm_dump() call to the >> mm_init() function but nothing was dumped to uart log. I guess I am missing >> something trivial. It looks like mm_root_table_count() returns 0. Any >> suggestions? >> >> diff --git a/src/mm.c b/src/mm.c >> index 2e352e9..7c56a09 100644 >> --- a/src/mm.c >> +++ b/src/mm.c >> @@ -1041,5 +1041,7 @@ bool mm_init(struct mpool *ppool) >> mm_identity_map(stage1_locked, layout_data_begin(), >> layout_data_end(), >> MM_MODE_R | MM_MODE_W, ppool); >> >> + mm_vm_dump(&ptable); >> + >> return arch_mm_init(ptable.root); >> } >> >> Thanks, >> Madhukar >> >> -----Original Message----- >> From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> On Behalf Of >> Andrew Walbran via Hafnium >> Sent: Friday, July 17, 2020 6:10 AM >> To: Raghu K <raghu.ncstate(a)icloud.com> >> Cc: hafnium(a)lists.trustedfirmware.org >> Subject: Re: [Hafnium] Debugging page table creation in Hafnium >> >> 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 >> > >> >

4 years, 9 months

2
1
0 0

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 >

4 years, 9 months

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 >

4 years, 9 months

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

4 years, 9 months

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

4 years, 10 months

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 >

4 years, 10 months

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

4 years, 10 months

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

4 years, 10 months

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

4 years, 10 months

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.

4 years, 10 months

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

4 years, 10 months

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)

4 years, 10 months

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

4 years, 10 months

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

4 years, 10 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

4 years, 10 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

4 years, 11 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 >

4 years, 11 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

4 years, 11 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 >

4 years, 11 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 >>

4 years, 11 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 >

4 years, 11 months

2
1
0 0