- Hafnium - lists.trustedfirmware.org

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, 3 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, 3 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, 3 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, 3 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, 3 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, 3 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, 3 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, 4 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, 4 months

1
0
0 0

2025

2024

2023

2022

2021

2020

Hafnium