We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi there,
I want to verify whether FVP Base RecV (version 1125) supports the ARMv8.9-A Permission Indirection Extension (PIE) and Permission Overlay Extension (POE).
For the quick verification, I decided to run edk2 (UEFI) on FVP only.
The FVP options that I use:
$ Base_RevC_AEMvA_pkg/models/Linux64_GCC-9.3/FVP_Base_RevC-2xAEMvA \ -C pctl.startup=0.0.0.0 \ -C bp.secure_memory=0 \ -C cluster0.NUM_CORES=1 \ -C cluster1.NUM_CORES=1 \ -C cluster0.has_permission_indirection_s1=2 \ -C cluster0.has_permission_indirection_s2=2 \ -C cluster0.has_permission_overlay_s1=2 \ -C cluster0.has_permission_overlay_s2=2 \ -C cluster1.has_permission_indirection_s1=2 \ -C cluster1.has_permission_indirection_s2=2 \ -C cluster1.has_permission_overlay_s1=2 \ -C cluster1.has_permission_overlay_s2=2 \ -C cache_state_modelled=0 \ -C bp.pl011_uart0.untimed_fifos=1 \ -C bp.pl011_uart0.unbuffered_output=1 \ -C bp.pl011_uart0.out_file=uart/uart0.log \ -C bp.pl011_uart1.out_file=uart/uart1.log \ -C bp.secureflashloader.fname=bl1.bin \ -C bp.flashloader0.fname=fip.bin \ -C bp.ve_sysregs.mmbSiteDefault=0 \ -C bp.ve_sysregs.exit_on_shutdown=1
To this end, I added code to the edk2/ShellPkg/Application/Shell/Shell.c to read PIE-POE related system registers and print their value, as illustrated bellow:
edk2/ShellPkg/Application/Shell/Shell.c
EFI_STATUS EFIAPI UefiMain ( IN EFI_HANDLE ImageHandle, IN EFI_SYSTEM_TABLE *SystemTable ) { EFI_STATUS Status; CHAR16 *TempString; UINTN Size; EFI_HANDLE ConInHandle; EFI_SIMPLE_TEXT_INPUT_PROTOCOL *OldConIn; SPLIT_LIST *Split; UINT64 REG_ID_AA64MMFR3_EL1 = 0; UINT64 REG_PIR_EL1 = 0; UINT64 REG_POR_EL1 = 0; if (PcdGet8 (PcdShellSupportLevel) > 3) { return (EFI_UNSUPPORTED); } __asm__ volatile ("mrs %0, ID_AA64MMFR3_EL1" : "=r" (REG_ID_AA64MMFR3_EL1)); Print(L"ID_AA64MMFR3_EL1: 0x%016x\n", REG_ID_AA64MMFR3_EL1); ​ __asm__ volatile ("mrs %0, PIR_EL1" : "=r" (REG_PIR_EL1)); Print(L"PIR_EL1: 0x%016x\n", REG_PIR_EL1); ​ __asm__ volatile ("mrs %0, POR_EL1" : "=r" (REG_POR_EL1)); Print(L"POR_EL1: 0x%016x\n", REG_POR_EL1); }
Results:
ID_AA64MMFR3_EL1: 0x0000000000111101
According to ID_AA64MMFR3_EL1, AArch64 Memory Model Feature Register 3, the value of ID_AA64MMFAR3_EL1 indicates that FVP_Base_RecV supports both PIE and POE.
ID_AA64MMFAR3_EL1
However, the program gets stuck when it further reads PIR_EL1 and POR_EL1. If I remove related code of reading these two registers, the program executes normally.
PIR_EL1
POR_EL1
My questions are:
Does FVP Base RecV (version 1125) really support PIE-POE?
If so, how can we read and write PIE-POE related system registers?
Hi Toshihisa,
Thanks for your suggestion. I add two additional options to run FVP_Base_RecV:
-C cluster0.has_arm_v8-9=1 \ -C cluster1.has_arm_v8-9=1 \
However, the FVP still gets stuck when the program tried to read PIR_EL1 and POR_EL1.
And I cannot set has_arm_v8-9 to 2 because the FVP_Base_RecV warns that it's invalid.
has_arm_v8-9
Thank you for the updates. I've created a small test case and run the FVP (v11.25.15) with the TarmacTrace plugin, and got below. I've noticed that even without has_arm_v8-9=1, I can access PIR_EL1.
$ .../FVP_Base_RevC-2xAEMvA/FVP_Base_RevC-2xAEMvA \ -a dhrystone_v8.axf \ -a test1.dat \ -C pctl.startup=0.0.0.0 \ -C bp.secure_memory=0 \ -C bp.vis.disable_visualisation=1 \ -C cluster0.NUM_CORES=1 \ -C cluster1.NUM_CORES=1 \ -C cluster0.has_permission_indirection_s1=2 \ -C cluster0.has_permission_indirection_s2=2 \ -C cluster0.has_permission_overlay_s1=2 \ -C cluster0.has_permission_overlay_s2=2 \ -C cluster1.has_permission_indirection_s1=2 \ -C cluster1.has_permission_indirection_s2=2 \ -C cluster1.has_permission_overlay_s1=2 \ -C cluster1.has_permission_overlay_s2=2 \ -C cache_state_modelled=0 \ -C bp.pl011_uart0.untimed_fifos=1 \ -C bp.pl011_uart0.unbuffered_output=1 \ -C bp.pl011_uart0.out_file=uart/uart0.log \ -C bp.pl011_uart1.out_file=uart/uart1.log \ -C bp.secureflashloader.fname=bl1.bin \ -C bp.flashloader0.fname=fip.bin \ -C bp.ve_sysregs.mmbSiteDefault=0 \ -C bp.ve_sysregs.exit_on_shutdown=1 \ --plugin .../FVP_Base_RevC-2xAEMvA/plugins/Linux64_GCC-9.3/TarmacTrace.so \ --cyclelimit 5 ... 10000 ps cluster0.cpu0 IT (1) 80001098 d51e115f O EL3h_s : MSR CPTR_EL3,xzr 10000 ps cluster0.cpu0 R CPTR_EL3 00000000:00000000 20000 ps cluster0.cpu0 IT (2) 8000109c d538a260 O EL3h_s : MRS x0,PIR_EL1 20000 ps cluster0.cpu0 R X0 0000000000000000 ...
> However, the FVP still gets stuck when the program tried to read PIR_EL1 and POR_EL1.
Can you please enable the TarmacTrace plugin (see below) so that I can check what you actually encounter when accessing PIR_EL1 and POR_EL1?
developer.arm.com/.../TarmacTrace
Kind regards,
Toshi
Hi Toshi,
I use the FVP_Base_RecV to run a linux 6.7, which has a driver reading permission indirection and overlay related system registers (ID_AA64MMFR3_EL1, PIR_EL0, PIR_EL1, POR_EL0, POR_EL1, and S2POR_EL1).
REG_ID_AA64MMFR3_EL1: 0x0010010000111111 REG_PIRE0_EL1: 0xc0800000e0a20000 REG_PIR_EL1: 0xcc880e0ac0800000 REG_POR_ELO: 0x0000000000000000 REG_POR_EL1: 0x0000000000000000 REG_S2POR_EL1: 0x0000000000000000
The results show that I can read those registers normally without a crash. So I think the FVP_Base_RecV supports permission indirection and overlay extensions.
For the UEFI, maybe there is something wrong with the compilation process.
Best regards,
Rusty
Hi RustyCohle,
Thank you for the updates. I am glad that you could access the PIE/POE registers.