Glibc 2.31 - time64 with 64-bit kernel and 32-bit userland

[Adhemerval Zanella]

On 18/01/2021 17:35, Florian Weimer wrote:
> * Adhemerval Zanella:
> 
>>> Should we just undefined __NR_clock_gettime64 for 64-bit AArch64?
>>
>> No, this is armhf default binaries.  This situation is similar to
>> i686 running on x86_64 kernels.
> 
> It sure looks like it.  I wasn't aware that it's possible to run armhfp
> userspace on an AArch64 kernel.
> 
> What kind of hardware is needed for that?
> 
> (For some reason, Fedora builds its armhfp distribution in a virtualized
> environment.)

You need a hardware that supports ARMv8 on EL0, was described by 
Armv8-A architecture profile (page D13-3255):

EL3, bits [15:12]
          EL3 Exception level handling. Defined values are:

          0b0000      EL3 is not implemented.
          0b0001      EL3 can be executed in AArch64 state only.
          0b0010      EL3 can be executed in either AArch64 or AArch32 state.

          All other values are reserved.

EL2, bits [11:8]
          EL2 Exception level handling. Defined values are:

          0b0000      EL2 is not implemented.
          0b0001      EL2 can be executed in AArch64 state only.
          0b0010      EL2 can be executed in either AArch64 or AArch32 state.

          All other values are reserved.

EL1, bits [7:4]
          EL1 Exception level handling. Defined values are:

          0b0001      EL1 can be executed in AArch64 state only.
          0b0010      EL1 can be executed in either AArch64 or AArch32 state.

          All other values are reserved.

EL0, bits [3:0]
          EL0 Exception level handling. Defined values are:

          0b0001      EL0 can be executed in AArch64 state only.
          0b0010      EL0 can be executed in either AArch64 or AArch32 state.

          All other values are reserved.

And unfortunately there is no way to access this special register without
kernel support [2] even with 'cpuid' support (HWCAP_CPUID from hwcap) [3]
this information is masked away due security issues.

I don't know a easy way to find out without actually issuing a arm32 binary 
to find out if the chip does support A32 and T32 state.

The kernel also limits the compat syscall mechanism (A32 state running on
arm64 chip):

arch/arm64/Kconfig

1213 menuconfig COMPAT
1214         bool "Kernel support for 32-bit EL0"
1215         depends on ARM64_4K_PAGES || EXPERT
1216         select COMPAT_BINFMT_ELF if BINFMT_ELF
1217         select HAVE_UID16
1218         select OLD_SIGSUSPEND3
1219         select COMPAT_OLD_SIGACTION
1220         help
1221           This option enables support for a 32-bit EL0 running under a 64-bit
1222           kernel at EL1. AArch32-specific components such as system calls,
1223           the user helper functions, VFP support and the ptrace interface are
1224           handled appropriately by the kernel.
1225 
1226           If you use a page size other than 4KB (i.e, 16KB or 64KB), please be aware
1227           that you will only be able to execute AArch32 binaries that were compiled
1228           with page size aligned segments.

[1] https://developer.arm.com/documentation/ddi0487/latest/ 
[2] https://stackoverflow.com/questions/60071590/reading-armv8-a-registers-with-devmem-from-gnu-linux-shell
[3] https://www.kernel.org/doc/html/latest/arm64/cpu-feature-registers.html