diff options
author | Jessica Clarke <jrtc27@jrtc27.com> | 2024-11-06 16:38:17 +0000 |
---|---|---|
committer | mergify[bot] <37929162+mergify[bot]@users.noreply.github.com> | 2024-11-14 06:25:27 +0000 |
commit | cb87aada970c68c1a210ed68a4a1ce238623e3c3 (patch) | |
tree | 205f8615ddfee647a53dcc398def32292be3d4fe /SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c | |
parent | 1bd09ad1936c51fcbfbec2ed4df59a2fbc182a62 (diff) | |
download | edk2-master.tar.gz edk2-master.tar.bz2 edk2-master.zip |
Unlike CPACR_EL1 whose reserved bits are solely RES0, CPTR_EL2 has some
RES1 bits, and so we should not clear them unless we know what they
mean. For example, when SVE was introduced, CPACR_EL1.ZEN occupied a
RES0 field and thus 0 means trap (which is what we get at EL1), but
CPTR_EL2.TZ occupied a RES1 field and thus 1 means trap, but we set it
to 0, so the environment is inconsistent between EDK2 and EL1 and EL2.
Another concrete case is for Morello, where the CEN/TC fields similarly
gate access to capability register state, but also alter exception
delivery and return, such that VBAR_ELx and ELR_ELx become capabilities.
So long as software adheres to RES0/1 this is backwards-compatible, but
since EDK2 does not do so here it inadvertently enables capability-based
exception delivery and return and thus, when run at EL2, gets stuck in a
trap loop when taking its first interrupt, but works just fine at EL1.
Fix this by setting all the RES1 fields in CPTR_EL2, following the
pattern for CPACR_EL1's non-zero initial value (due to setting FPEN so
as to not trap on SIMD/FP use), tested by running ArmVirtQemu-AARCH64
(DEBUG) on Morello QEMU with EL2 enabled.
Signed-off-by: Jessica Clarke <jrtc27@jrtc27.com>
Diffstat (limited to 'SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c')
0 files changed, 0 insertions, 0 deletions