This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] powerpc: New feature - HWCAP/HWCAP2 bits in the TCB


On Fri, Jul 03, 2015 at 01:31:04PM -0400, Carlos O'Donell wrote:
> 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?
>
Yes we could, but it needs a LD_BIND_NOW=1, otherwise its lazily
resolved and you would need to initialize it for each dso.

There should be way to force early binding on per-symbol basis as gcc
could easily determine which functions will be called at least once.

Now lot of libc ifunc share that problem, memcpy is resolved for each
dso we load.

 
> > 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?

It couldn't. We need to copy these for each thread, or user application
would need to interpose pthread_create.

> 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..."
>
This part isn't problem at all if only access is __builtin_cpu_support.
When compiling linker would check if __builtin_cpu_support was present
and automatically add constructor if it does.
 
> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]