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