include/asm-powerpc/elf.h:289
Why we need the second AT_IGNOREPPC entry here?
There is a mm_struct->saved_auxv overflow on PPC64 with AT_VECTOR_SIZE
== 44 (may be on PPC32 too, not checked) when adding all entries to
it. I've removed the second AT_IGNOREPCC from ARCH_DLINFO to prevent
overflowing, checked it on IBM OpenPower 720 and a system (Fedora 7) is
going on as well. Have I missed some tricky thing?
Vitaly Mayatskikh writes:
> include/asm-powerpc/elf.h:289
>
> Why we need the second AT_IGNOREPPC entry here?
>
> There is a mm_struct->saved_auxv overflow on PPC64 with AT_VECTOR_SIZE
> == 44 (may be on PPC32 too, not checked) when adding all entries to
> it. I've removed the second AT_IGNOREPCC from ARCH_DLINFO to prevent
> overflowing, checked it on IBM OpenPower 720 and a system (Fedora 7) is
> going on as well. Have I missed some tricky thing?
In the past, ppc32 kernels used to round up the address of the end of
the environment pointers to a multiple of 16 before writing the aux
vector, which meant that that was where userspace looked for it. When
the rounding was removed in the kernel, we arranged to put in the two
AT_IGNOREPPC entries so that old binaries would still be able to find
the aux vector.
I'll have to check when that change was done and decide whether we can
now take out the AT_IGNOREPPC entries. If not it sounds like we need
to expand AT_VECTOR_SIZE.
Paul.
Paul Mackerras <[email protected]> writes:
> I'll have to check when that change was done and decide whether we can
> now take out the AT_IGNOREPPC entries. If not it sounds like we need
> to expand AT_VECTOR_SIZE.
I've looked over glibc-2.3 sources (is it old enough? :) and didn't
notice any specialities for AT_IGNOREPPC.
--
Vitaly Mayatskikh <[email protected]>
Kernel development
Red Hat Czech, Brno
Phone: +420 532 294 111
IRC: vitaly on #kernel, #brno
GPG: 0x4BA2E8FB