Re: [PATCH] Add private_function for private functions within glibc [BZ #21598]

["H.J. Lu" <hjl dot tools at gmail dot com>]

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.