This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] powerpc: New feature - HWCAP/HWCAP2 bits in the TCB
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: OndÅej BÃlka <neleai at seznam dot cz>
- Cc: Carlos Eduardo Seo <cseo at linux dot vnet dot ibm dot com>, GLIBC Devel <libc-alpha at sourceware dot org>, Steve Munroe <sjmunroe at us dot ibm dot com>, Richard Henderson <rth at redhat dot com>
- Date: Fri, 03 Jul 2015 13:31:04 -0400
- Subject: Re: [PATCH] powerpc: New feature - HWCAP/HWCAP2 bits in the TCB
- Authentication-results: sourceware.org; auth=none
- References: <55760314 dot 6070601 at linux dot vnet dot ibm dot com> <559617FF dot 8010100 at redhat dot com> <20150703085542 dot GE32307 at domone> <55968AF8 dot 8060104 at redhat dot com> <20150703171121 dot GA23898 at domone>
On 07/03/2015 01:11 PM, OndÅej BÃlka wrote:
> On Fri, Jul 03, 2015 at 09:15:36AM -0400, Carlos O'Donell wrote:
>> Lastly, the symbol address hack is an incomplete solution because Florian
>> has not provided an implementation. Depending on the implementation it
>> may require a new relocation, and that is potentially more costly to the
>> program startup than the present process for filling in HWCAP/HWCAP2.
>
> Thats valid concern. My idea was checking if hwcap_hack relocation exist.
> I didn't realize that it scales with number of libraries.
Exactly. Usually a GOT entry with a reloc, but this one is special since
it's computed by another function. Actually, can't the IFUNC infrastructure
doing this already? If you take the address of an STT_GNU_IFUNC symbol
you should get back the address of the resolved to function? Can the
resolver return `(void *)HWCAP`? It's an abuse of IFUNC to use the resolver
to return a custom function address that can't be executed but means
something dynamic?
> One of reasons why I didn't like this proposal is that it harms linux
> ecosystem as it increases startup cost of a bit everything while its
> unlikely that cross-platform projects will use this.
That could be fixed by removing the initialization from glibc and forcing
the developer to call __builtin_cpu_init() to do the initialization?
Then there is no dependency on glibc other than to provide scratch space
in TP+offset? Someone should ask IBM if this is feasible? Then instead
of having to say:
"For old glibc you must have a constructor which calls __builtin_cpu_init()
and old glibc varies depending on your distro like this..."
You just say:
"Always call __builtin_cpu_init(). Period."
Note that while we continue to add things to TP+offset it becomes a target
for security attacks too. The TCB is read-write and now impacts program
control flow with these new bits, and it's easy to find ROP widgets that
store to TP+offset. You would need a program to use these bits and an
attack vector though.
Cheers,
Carlos.