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?
If you want to use Armv8.9 features in the FVP_Base_RevC, you must enable the has_arm_v8-9 parameter for AEMvACT (which is the core model used in the FVP).
developer.arm.com/.../AEMvACT
has_arm_v8-9 Implement the ARMv8.9 Extension. This feature is incomplete and under development. Type: bool. Default value: 0x0.
Can you please give it a try?
Kind regards,
Toshi
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
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.