[PATCH] Add private_function for private functions within glibc [BZ #21598]
H.J. Lu
hjl.tools@gmail.com
Wed Aug 9 10:58:00 GMT 2017
On Wed, Aug 9, 2017 at 3:33 AM, Florian Weimer <fweimer@redhat.com> 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:
>>
>> 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.
Some i386 assembly codes call internal functions directly:
https://sourceware.org/ml/libc-alpha/2017-06/msg00764.html
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.
> ”
> <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.
>
I opened:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81780
--
H.J.
More information about the Libc-alpha
mailing list