[SOLVED] AT (Address Translation) instruction's privilege level in ARMv8

AT (Address Translation) instruction's privilege level in ARMv8

Executing AT instruction (Address Translation) from user-space (a.k.a EL0) gives SIGILL, so I tried executing it from kernel-space (EL1), this way it didn't fail.

I also found that AT is alias for SYS instruction, so I guess it cannot be executed from EL0, but I cannot find any document that says it, nor says that this is implementation defined, so my question is at which privilege level AT instruction can be executed?

Solution

You can just look at the pseudocode for the AT instruction. There's separate listings for all the different flavours of the instruction, but if you look at AT S1E0R, for example:

if PSTATE.EL == EL0 then
    UNDEFINED;
elsif PSTATE.EL == EL1 then
    if EL2Enabled() && HCR_EL2.AT == '1' then
        AArch64.SystemAccessTrap(EL2, 0x18);
    elsif EL2Enabled() && (!HaveEL(EL3) || SCR_EL3.FGTEn == '1') && HFGITR_EL2.ATS1E0R == '1' then
        AArch64.SystemAccessTrap(EL2, 0x18);
    else
        AT_S1E0R(X[t]);
elsif PSTATE.EL == EL2 then
    AT_S1E0R(X[t]);
elsif PSTATE.EL == EL3 then
    AT_S1E0R(X[t]);

Every flavour of AT is UNDEFINED at EL0. Other than that, it behaves more or less like you'd expect, e.g. lower exception levels can't access translation of higher levels, EL2 translation faults from EL3 if EL2 is disabled, EL2 translation is redirected to perform EL1 translation instead if run from EL1 in nested virtualization, etc.