This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Add private_function for private functions within glibc [BZ #21598]
- From: Florian Weimer <fweimer at redhat dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 9 Aug 2017 12:33:48 +0200
- Subject: Re: [PATCH] Add private_function for private functions within glibc [BZ #21598]
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=fweimer at redhat dot com
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 54A9F72FE1
- References: <20170808182536.GA24765@gmail.com>
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:
>
> https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf
>
> 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.
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.
”
<https://gcc.gnu.org/onlinedocs/gcc/x86-Function-Attributes.html>
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.
Thanks,
Florian