FEAT_PAuth trapping behaviour incorrectly emulated on Secure-EL0/1 with Secure-EL2 disabled
QEMU currently checks for trapped to EL2 PAuth instructions in pauth_check_trap
by getting the value of the API bit in HCR_EL2 using arm_hcr_el2_eff
which returns 0 when the current EL is EL0/1 secure and EL2 secure is disabled, (based on the following line in the armarm: The bits in this register behave as if they are 0 for all purposes other than direct reads of the register if EL2 is not enabled in the current Security state.
) which results in PAC instructions always trapping in this configuration.
This does not match the specification, as the armarm then goes on to specify that the API bit is handled as if it's 1 when EL2 secure is disabled: If FEAT_PAuth is implemented but EL2 is not implemented or disabled in the current Security state, the system behaves as if this bit is 1.
I have not investigated it further, but this could possibly be a security issue for emulated arm guests, as this lets EL0/1 code trigger execution of EL2 secure when it has been explicitly disabled by EL3, but it doesn't seem like that could be abused to do anything.