Re: Detecting AArch32 support from a AArch64 process in user space

[Stefan Agner <stefan@agner.ch>]

On 2019-08-08 11:04, Marc Zyngier wrote:
> Hi Stefan,
> 
> On 08/08/2019 08:36, Stefan Agner wrote:
>> [resend this time with the correct mailing list address]
>>
>> Hello,
>>
>> I am trying to detect whether an ARMv8 system running in AArch64 state
>> supports AArch32 state from a user space process. The arm64_features[]
>> in
>> arch/arm64/kernel/cpufeature.c lists a CPU feature "32-bit EL0 Support".
>> However, afaik this CPU feature is not directly exposed to user-space.
>> The features do get printed in the kernel log, but that requires
>> privileges and only works directly after boot. There is
>> system_supports_32bit_el0() which is used in various places in the arm64
>> architecture code. One of the instances where I can make sense of from
>> user space is through the personality system call. One idea is to call
>> personality(PER_LINUX32). It would then return error code 22 in case
>> 32-bit is not supported in user space. However, if successful this
>> changes the personality of the current process which might have side
>> effects which I do not want...?
> 
> You should be able to revert the effects of PER_LINUX_32 by feeding back
> the return value of the initial call to personality() to a second
> personality() call.
> 

Oh, of course, that makes sense.

>> I started to ask myself what PER_LINUX32 actually changes. From what I
>> can tell it only changes the behavior of /proc/cpuinfo? The personality
>> seems not to be applied automatically to 32-bit processes, so this is a
>> opt-in backward compatibility feature?
> 
> It's all about giving the illusion that the process runs in a "real"
> 32bit environment, with all its warts. It doesn't change the CPU mode
> you're running in (that'd be a bit harsh). It's only once you exec
> something that requires AArch32 that we engage the COMPAT mode.
> 
> Provided that your kernel contains 00377277166b or a backport of it (or
> that it predates 4378a7d4be30), the following program should do the
> right thing:
> 
> #include <sys/personality.h>
> #include <stdio.h>
> 
> int main(int argc, char *argv[])
> {
>         int old, new;
> 
>         old = personality(PER_LINUX32);
>         if (old < 0) {
>                 perror("No 32bit for you");
>                 return 1;
>         }
> 
>         new = personality(0xffffffff);
>         printf("Running with personality %d\n", new);
> 
>         personality(old);
>         new = personality(0xffffffff);
> 
>         printf("Running with personality %d\n", new);
> 
>         return 0;
> }
> 

Thanks for the example. I had something similar already, just not with
the revert part.

>> To be on the safe side, I was thinking about executing the system call
>> in a separate process. However, at that point I could also just execute
>> a statically linked AArch32 binary and see whether I get a "exec format
>> error". I guess this could then be either due to missing AArch32 CPU
>> support or the kernel not being compiled with 32-bit compatibility.
> 
> Overkill ;-). The above should be enough.
> 
>> At last I was considering reading directly from the CPU. But from what I
>> understand the register used in the kernel to determine 32-bit
>> compatibility (ID_AA64PFR0_EL1) is not accessible by user space (due to
>> the suffix _EL1).
> 
> Hey, you could create a VM, a vcpu and dump the ID registers by issuing
> a set of KVM_GET_ONE_REG ioctls. Not necessarily recommended... ;-)

I see, no no, I think I leave that exercise for somebody else to try :)

--
Stefan


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel