diff mbox

2.25 freeze status

Message ID CAMe9rOoS=DhUp7qiMS=Haz3x2jHBO7+t2eJxQGYvd+pKm_SnNA@mail.gmail.com
State New
Headers show

Commit Message

H.J. Lu Feb. 2, 2017, 6:07 p.m. UTC 
On Thu, Feb 2, 2017 at 5:02 AM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 02/01/2017 12:04 PM, H.J. Lu wrote:
>> On Tue, Jan 31, 2017 at 12:45 PM, Carlos O'Donell <carlos@redhat.com> wrote:
>>> 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.
>
> Which of (b) or (d) do you interpret to be less risk given the upcoming release?
>
> Keeping in mind the success criteria defined earlier for this consensus discussion:
>
> * Release of glibc 2.25 without the side effect caused by the fix for 20019
>   which prevents potentially valid applications from starting.
>
> This is a time-boxed release. We can delay a fix. Incremental progress is OK.
>

This is what I propose for 2.25.

Comments

Carlos O'Donell Feb. 2, 2017, 9:04 p.m. UTC | #1 
On 02/02/2017 01:07 PM, H.J. Lu wrote:
> On Thu, Feb 2, 2017 at 5:02 AM, Carlos O'Donell <carlos@redhat.com> wrote:
>> On 02/01/2017 12:04 PM, H.J. Lu wrote:
>>> On Tue, Jan 31, 2017 at 12:45 PM, Carlos O'Donell <carlos@redhat.com> wrote:
>>>> 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.
>>
>> Which of (b) or (d) do you interpret to be less risk given the upcoming release?
>>
>> Keeping in mind the success criteria defined earlier for this consensus discussion:
>>
>> * Release of glibc 2.25 without the side effect caused by the fix for 20019
>>   which prevents potentially valid applications from starting.
>>
>> This is a time-boxed release. We can delay a fix. Incremental progress is OK.
>>
> 
> This is what I propose for 2.25.
 
I agree with your proposal. It meets the success criteria.

Issuing an error but allowing the program to start is an excellent compromise.

We currently print errors for failing to preload objects, and many of the machine
backends print errors for relocation problems encountered during dynamic linking
(x86_64: overflows and copy relocs where the size has changed).

I agree that this situation is very similar to those and so the use of _dl_error_printf
instead of _dl_fatal_printf is a good idea.

Please commit your change and we'll mark this issue complete for 2.25.

As you noted bug 21041 will remain open to handle the real problem in the 2.26 timeframe.
H.J. Lu Feb. 2, 2017, 9:15 p.m. UTC | #2 
On Thu, Feb 2, 2017 at 1:04 PM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 02/02/2017 01:07 PM, H.J. Lu wrote:
>> On Thu, Feb 2, 2017 at 5:02 AM, Carlos O'Donell <carlos@redhat.com> wrote:
>>> On 02/01/2017 12:04 PM, H.J. Lu wrote:
>>>> On Tue, Jan 31, 2017 at 12:45 PM, Carlos O'Donell <carlos@redhat.com> wrote:
>>>>> 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.
>>>
>>> Which of (b) or (d) do you interpret to be less risk given the upcoming release?
>>>
>>> Keeping in mind the success criteria defined earlier for this consensus discussion:
>>>
>>> * Release of glibc 2.25 without the side effect caused by the fix for 20019
>>>   which prevents potentially valid applications from starting.
>>>
>>> This is a time-boxed release. We can delay a fix. Incremental progress is OK.
>>>
>>
>> This is what I propose for 2.25.
>
> I agree with your proposal. It meets the success criteria.
>
> Issuing an error but allowing the program to start is an excellent compromise.
>
> We currently print errors for failing to preload objects, and many of the machine
> backends print errors for relocation problems encountered during dynamic linking
> (x86_64: overflows and copy relocs where the size has changed).
>
> I agree that this situation is very similar to those and so the use of _dl_error_printf
> instead of _dl_fatal_printf is a good idea.
>
> Please commit your change and we'll mark this issue complete for 2.25.

Done.  Thanks.

> As you noted bug 21041 will remain open to handle the real problem in the 2.26 timeframe.
>
> --
> Cheers,
> Carlos.
diff mbox

Patch

From 53ebca73097fff387c4263370b9676dbbd6ccaea Mon Sep 17 00:00:00 2001
From: "H.J. Lu" <hjl.tools@gmail.com>
Date: Thu, 2 Feb 2017 09:59:21 -0800
Subject: [PATCH] Allow IFUNC relocation against unrelocated shared library

IFUNC relocation against definition in unrelocated shared library
will lead to segfault when the IFUNC function is called.  This
patch allows such IFUNC relocations with a warning.  This isn't
a real fix for

https://sourceware.org/bugzilla/show_bug.cgi?id=21041

It simply allows the program to load.  The program will segfault
when longjmp is called.

	* sysdeps/i386/dl-machine.h (elf_machine_rel): Replace
	_dl_fatal_printf with _dl_error_printf for IFUNC relocation
	against unrelocated shared library.
	* sysdeps/x86_64/dl-machine.h (elf_machine_rela): Likewise.
---
 sysdeps/i386/dl-machine.h   | 2 +-
 sysdeps/x86_64/dl-machine.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/sysdeps/i386/dl-machine.h b/sysdeps/i386/dl-machine.h
index 6eca69d..99a72f6 100644
--- a/sysdeps/i386/dl-machine.h
+++ b/sysdeps/i386/dl-machine.h
@@ -329,7 +329,7 @@  elf_machine_rel (struct link_map *map, const Elf32_Rel *reloc,
 	    {
 	      const char *strtab
 		= (const char *) D_PTR (map, l_info[DT_STRTAB]);
-	      _dl_fatal_printf ("\
+	      _dl_error_printf ("\
 %s: Relink `%s' with `%s' for IFUNC symbol `%s'\n",
 				RTLD_PROGNAME, map->l_name,
 				sym_map->l_name,
diff --git a/sysdeps/x86_64/dl-machine.h b/sysdeps/x86_64/dl-machine.h
index 3e7ae22..daf4d8c 100644
--- a/sysdeps/x86_64/dl-machine.h
+++ b/sysdeps/x86_64/dl-machine.h
@@ -339,7 +339,7 @@  elf_machine_rela (struct link_map *map, const ElfW(Rela) *reloc,
 	    {
 	      const char *strtab
 		= (const char *) D_PTR (map, l_info[DT_STRTAB]);
-	      _dl_fatal_printf ("\
+	      _dl_error_printf ("\
 %s: Relink `%s' with `%s' for IFUNC symbol `%s'\n",
 				RTLD_PROGNAME, map->l_name,
 				sym_map->l_name,
-- 
2.9.3