Re: 2.25 freeze status

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

On Tue, Jan 31, 2017 at 12:45 PM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 01/31/2017 02:02 PM, H.J. Lu wrote:
>> On Tue, Jan 31, 2017 at 10:59 AM, Carlos O'Donell <carlos@redhat.com> wrote:
>>> On 01/31/2017 10:57 AM, H.J. Lu wrote:
>>>> On Mon, Jan 30, 2017 at 1:39 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>> On Mon, Jan 30, 2017 at 12:41 PM, Carlos O'Donell <carlos@redhat.com> wrote:
>>>>>> On 01/30/2017 03:38 PM, H.J. Lu wrote:
>>>>>>> On Mon, Jan 30, 2017 at 12:22 PM, Carlos O'Donell <carlos@redhat.com> wrote:
>>>>>>>> On 01/30/2017 02:39 PM, H.J. Lu wrote:
>>>>>>>>> On Mon, Jan 30, 2017 at 11:17 AM, Carlos O'Donell <carlos@redhat.com> wrote:
>>>>>>>>>> On 01/30/2017 02:04 PM, H.J. Lu wrote:
>>>>>>>>>>>> H.J.,
>>>>>>>>>>>>
>>>>>>>>>>>> Could you please back out the fix for bug 20019?
>>>>>>>>>>>>
>>>>>>>>>>>> We will continue to try and fix this in 2.26 with a solution that moves
>>>>>>>>>>>> IFUNC design towards a better documented set of semantics.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Since calling longjmp will segfault in this case, shouldn't it be
>>>>>>>>>>> fixed first by reverting IFUNC implementation in libpthread?
>>>>>>>>>>
>>>>>>>>>> I believe there is insufficient time to test that such a change and verify
>>>>>>>>>> it does not have other unintended consequences for changing a symbol from
>>>>>>>>>> IFUNC to non-IFUNC.
>>>>>>>>>>
>>>>>>>>>> The minimal fix is to revert the changes for bug 20019, and allow programs
>>>>>>>>>> to startup, and run as expected in the cases they do not call longjmp.
>>>>>>>>>>
>>>>>>>>>> I would like to see the minimum amount of reversion required to get us
>>>>>>>>>> back to a state where applications run again.
>>>>>>>>>>
>>>>>>>>>> We have only a few days until the release deadline and I do not wish
>>>>>>>>>> to extend that date.
>>>>>>>>>>
>>>>>>>>>> I understand your desire to fix this correctly, and we will continue this
>>>>>>>>>> discussion once master reopens, possibly with a reversion of the IFUNC
>>>>>>>>>> change to libpthread.
>>>>>>>>>
>>>>>>>>> I don't think knowingly allow a program to segfault at random without any
>>>>>>>>> warning is appropriate.  Can't we turn the fatal error into a non-fatal warning?
>>>>>>>>
>>>>>>>> What is or is not appropriate right now must be in the context of the upcoming
>>>>>>>> release.
>>>>>>>>
>>>>>>>> The reversal of the patch is the simplist and most conservative move which
>>>>>>>> restores the behaviour that allows programs to start.
>>>>>>>>
>>>>>>>
>>>>>>> I am not against allowing the bad programs to start.  But silently allow the
>>>>>>> bad programs to crash at random isn't a conservative fix to me.
>>>>>>
>>>>>> It isn't a fix at all. We have run out of time to address the issue, and for
>>>>>> the upcoming 2.25 release it would be better that the applications continue
>>>>>> with their existing behaviour, rather than new behaviour that we know we
>>>>>> have to change again.
>>>>>
>>>>> I have a couple questions:
>>>>>
>>>>> 1. Will this change be ever in 2.26?
>>>>> 2. Will this change be backported to 2.24?
>>>>>
>>>>
>>>> I don't think we should change anything for 2.25.  We know that when the
>>>> function is called, the program will crash.  If programmer is confident that
>>>> the function won't be called, he/she can create a private copy which calls
>>>> abort.  The program will start and abort if the function is called.
>>>
>>> I disagree, and consensus appears to be so far to revert your patch until we
>>> can resolve this discussion.
>>>
>>> Is your position an objecting position? Would you object to the reversion of
>>> your patch for 2.25 until we can work out a better solution?
>>>
>>> In favor of reverting:
>>> Carlos O'Donell, Florian Weimer, Phil Blundell.
>>>
>>> Not in favor of reverting:
>>> H.J. Lu (non-objecting?)
>>>
>>
>> I object.
>
> https://sourceware.org/glibc/wiki/Consensus
>
> Let me ask again:
>
> Do you have a sustained (blocks consensus) opposition to the reverting of
> the patch for bug 20019 for the glibc 2.25 release which is scheduled to
> go out in 24 hours?
>
> Consensus need not imply unanimity.
>
> If your objection is non-sustained then it will be noted that you objected,
> but consensus carries that the patch should be reverted. And we continue to
> work on the issue _after_ the release.
>
> If your objection is sustained then we need to work through why you have a
> sustained objection.
>
> Success Criteria:
>
> * Release of glibc 2.25 without the side effect caused by the fix for 20019
>   which prevents potentially valid applications from starting.
>
> Technical Problems:
>
> * Allow certain applications that use libpthread and longjmp to operate
>   correctly.
>
> Solutions:
>
> (a) Revert the changes to libpthread which introduced the longjmp IFUNC.
>
> (b) Revert the fix for bug 20019 which stops the affected applications from
>     starting.

It just silently ignores the potential crash when longjmp is called.  I won't
call it a solution.

> (c) Implement IFUNC relocation ordering such that the applications work
>     correctly in the presence of the libpthread longjmp IFUNC.
>
> Florian Weimer has stated that (c) is not ready for glibc 2.25 release which
> is tomorrow.

d)

Remove IFUNC from libpthread.so.   The requirement for that the symbol
definition at run-time must come from the same shared object at link-time
is questionable.

> I argue that given that examples exist of libpthread and longjmp using programs
> which would now fail to start, when in the past they operated fine, that (b)
> is not sufficiently conservative for a project such as glibc. And so I propose
> we revert (b) and wait for (c) (along with a discussion of our design goals around
> IFUNC and what we do want to support).
>
> I also argue that (a) has unknown risks that we have not evaluated and will not
> easily be evaluated before the release date of 2017-02-01 (24 hours from now).
> I argue we don't have time  to add back the longjmp code to libpthread and audit
> that (yes I'm spending time here arguing this).
>
> H.J., Could you please explain your position and why you object to (b)?
>
> Your present position as I understand it is:
>
> * It is safer that the user application does not start given the IFUNC
>   defect in libpthread relocation handling order.
>
> * If a user really wants their application to start they should preload
>   a DSO which provides a working longjmp.
>
> I find this position not sufficiently conservative for glibc.
>
> While failing safe appears to be a conservative position, you can't know if the
> entire system fails safe because this one application fails to start. We can't
> argue a fail safe position without knowing a broader context.
>
> Therefore I continue to express my opinion that we should revert the fix for bug
> 20019 and continue with the implementation as it is for 2.25, and look for a new fix
> that actually resolves the problem by (1) refining the IFUNC design and
> (2) implementing the required relocation ordering to support #1.
>
> Given this explanation do you still have a sustained objection to (b) above?
>
> --
> Cheers,
> Carlos.



-- 
H.J.