Re: PR 18167, Relax PR 15228 protected visibility restriction

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

On Fri, Mar 27, 2015 at 10:39 AM, Pedro Alves <palves@redhat.com> wrote:
> On 03/27/2015 05:25 PM, H.J. Lu wrote:
>> On Fri, Mar 27, 2015 at 10:09 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>> On Fri, Mar 27, 2015 at 10:06 AM, Pedro Alves <palves@redhat.com> wrote:
>>>> On 03/27/2015 04:54 PM, H.J. Lu wrote:
>>>>> On Fri, Mar 27, 2015 at 9:43 AM, Pedro Alves <palves@redhat.com> wrote:
>>>>>> On 03/27/2015 04:40 PM, H.J. Lu wrote:
>>>>>>> On Fri, Mar 27, 2015 at 9:38 AM, Pedro Alves <palves@redhat.com> wrote:
>>>>>>
>>>>>>>> Urgh.  The glibc issue sounds the most alarming.  If we can't keep
>>>>>>>> back compatibility, isn't there a new bit/attribute we can put
>>>>>>>> somewhere to tag new binaries with protected symbols in a
>>>>>>>> way that existing systems just error out when loading them?
>>>>>>>
>>>>>>>
>>>>>>> There is no backward compatibility to speak with since protected
>>>>>>> data symbol never worked before.
>>>>>>
>>>>>> OK, but when it's all fixed, programs and libraries will start
>>>>>> using the feature.  It'd be best if such programs/libraries just
>>>>>> failed to load in older systems, than crash or corrupt data at random.
>>>>>>
>>>>>
>>>>> If one of gcc, glibc or binutils isn't fixed, the program may misbehave.
>>>>> I don't know how it be avoided at run-time with fixing all 3.
>>>>
>>>> I'm not really worried about gcc or binutils.  Those are easy to
>>>> update.  The issue is picking a binary that was built against fixed
>>>> gcc and binutils, and then running it on an system that happens to
>>>> not have glibc fixed.  That just seems like ABI breakage.
>>>>
>>>> How about emitting a reference to a symbol that only fixed glibc
>>>> provides?
>>>
>>> It is easy to verify.  Stay tuned.
>>>
>>
>> Please try the testcase in:
>>
>> https://sourceware.org/bugzilla/show_bug.cgi?id=17711
>>
>> If the run-time glibc isn't fixed, the program will crash.  It doesn't matter
>> which glibc you link against.  If your old binary with protected symbol
>> behaves, it will work with the fixed run-time glibc.
>
> It aborts here, here:
>
> (gdb) r
> Starting program: /tmp/bug/x
>
> Program received signal SIGABRT, Aborted.
> 0x0000003615e35877 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
> 56        return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
> (gdb) bt
> #0  0x0000003615e35877 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
> #1  0x0000003615e36f68 in __GI_abort () at abort.c:89
> #2  0x00000000004006e8 in main () at x.c:13
> (gdb)
>
> 7       int main()
> 8       {
> 9         if (bar_p () != &bar)
> 10          __builtin_abort();
> 11
> 12        if (a_p () != &a)
> 13          __builtin_abort();   <<<<<<<<<<<
> 14
> 15        bar ();
> 16        if (a != 30)
> 17          __builtin_abort();
> 18        return 0;
> 19      }
>
> That is, that isn't the loader crashing the program, but
> just the program itself detecting that protected symbols
> don't work.  Is that what you wanted me to verify?

Yes, the program will misbehave if the run-time glibc isn't
fixed.


-- 
H.J.