Re: [PATCH rsa/hwcap2_v3] Implement AT_HWCAP2 version 3

[Roland McGrath <roland at hack dot frob dot com>]

> The AT_HWCAP[2] entries are always read from the env as (ElfW(auxv_t) *)
> so this would only be a concern on 64-bit platforms.

Indeed.

> In this case the kernel may continue to use bits in AT_HWCAP (and use
> 64-bit masks) and then ignore AT_HWCAP2. Or the kernel can use 32-bit
> masks and use AT_HWCAP2. (As of now none of these systems actually need
> to use the higher 32-bits)

I understand the kernel has these options.  In fact, that's what concerns
me.  That is, the code you've written unconditionally uses all the bits of
AT_HWCAP, and the low 32 bits of AT_HWCAP2.  So if what the kernel actually
did on some 64-bit machine were to use high bits of AT_HWCAP and then also
use bits in AT_HWCAP2, libc would muddle together the high bits of AT_HWCAP
and the low bits of AT_HWCAP2.

The code needs at the very least some comments about this stuff.  But I'd
also like to see some sanity enforcement of some kind.  It could just mask
off the high bits of AT_HWCAP, which is safe in the sense of not muddling
the bits together but perhaps poor future-proofing in the sense that
callers of getauxval would never see those high bits (i.e. a caller that
knows about some new high bits on a kernel that sets them, but using a libc
that doesn't preserve them).  Or it could barf on either AT_HWCAP or
AT_HWCAP2 having any high bits set, which is safe in the sense of never
silently eating bits the kernel supplies but poor future-proofing in that
an innocuous-seeming kernel change could make every program on the system
start crashing.

I think we need to get the kernel folks to state and document an intent
about the possible future uses of these before we decide exactly what to
do.

> It'd be nice if such systems had 64-bits for both AT_HWCAP and
> AT_HWCAP2, but ultimately our dl_hwcap is only 64-bits anyway so we
> couldn't store all of the bits without adding another _dl_hwcap entry

If the kernel people intend to (or reserve the right to) set any high bits
in AT_HWCAP ever in the future on any 64-bit machine, then we need to do
something different in libc than what you've proposed so far.  Given the
32/64 pairs we have like sparc32/sparc64, ppc32/ppc64, s390/s390x, and
x32/x86_64 (it's essentially incidental that ix86 uses common bits with
x86_64 since their ABIs are sole wholly different, but x86_64 vs x32 is
much more like sparc64 vs sparc32 et al), it seems likely that the right
answer is that AT_HWCAP only ever get 32 bits and more bits go to AT_HWCAP2
just so things are consistent across each 32/64 pair.  If that's the plan,
then libc asserting the the high bits are clear seems right.

> The reason WORD can't be uint64_t (which I was going to do originally)
> is because this code is called out of _dl_show_auxv which parses the
> preserved dl_auxv directly and processes each entry as it is found,
> which means that one part or the other of the 64-bit hwcap might not yet
> have been encountered thus far.

I didn't mean that it would be the merged value.  I just meant that it
would be a type at least as wide as ElfW(auxv_t).a_type so that if there
are high bits set, they get printed.  That would be a great boon to
debugging if there ever were a kernel that set some high bits.  Using
'unsigned long int' should be sufficient to ensure that.


Thanks,
Roland