This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Add private_function for private functions within glibc [BZ #21598]
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 9 Aug 2017 03:58:41 -0700
- Subject: Re: [PATCH] Add private_function for private functions within glibc [BZ #21598]
- Authentication-results: sourceware.org; auth=none
- References: <20170808182536.GA24765@gmail.com> <email@example.com>
On Wed, Aug 9, 2017 at 3:33 AM, Florian Weimer <firstname.lastname@example.org> wrote:
> On 08/08/2017 08:25 PM, H.J. Lu wrote:
>> which is incompatible with Shadow Stack in Intel Control-flow Enforcement
>> Technology (CET) instructions:
>> since shadow stack doesn't match return stack. We need to use register
>> indirect branch via %ecx. That means only 2 parameters can be passed
>> in registers for external function calls with lazy binding when shadow
>> stack is enabled. However, internal_function, which should be used only
>> with hidden function within libc.so, are also used with private function
>> calls between different shared objects of glibc.
> I think we should work towards removing internal_function instead. It's
> an unnecessary maintenance overhead for those working on other
> architectures besides i386.
Some i386 assembly codes call internal functions directly:
Removing internal_function is too risky for i386.
> In addition, the GCC manual currently says this about %ecx:
> Systems with the GNU C Library version 2.1 or higher and FreeBSD are
> believed to be safe since the loaders there save EAX, EDX and ECX.
> This means that you can recover %ecx for internal ld.so with some form
> of ABI compatibility mark-up only because we pretty much guarantee that
> regparm (3) is compatible with the GNU ABI.