Re: [PATCH] x86: Add a GNU_PROPERTY_X86_ISA_1_USED note if needed

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

On Fri, Jul 20, 2018 at 8:44 AM, Rich Felker <dalias@libc.org> wrote:
> On Fri, Jul 20, 2018 at 08:36:48AM -0700, H.J. Lu wrote:
>> On Fri, Jul 20, 2018 at 8:06 AM, Rich Felker <dalias@libc.org> wrote:
>> > On Fri, Jul 20, 2018 at 06:38:52AM -0700, H.J. Lu wrote:
>> >> On Fri, Jul 20, 2018 at 6:31 AM, Rich Felker <dalias@libc.org> wrote:
>> >> > On Fri, Jul 20, 2018 at 05:24:08AM -0700, H.J. Lu wrote:
>> >> >> On Fri, Jul 20, 2018 at 2:30 AM, Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
>> >> >> > On 19/07/18 22:33, H.J. Lu wrote:
>> >> >> >>
>> >> >> >> Here is the updated patch.  Any comments?
>> >> >> >>
>> >> >> >>
>> >> >> >> H.J.
>> >> >> >> --
>> >> >> >> When -z separate-code, which is enabled by default for Linux/x86, is
>> >> >> >> used to create executable, ld won't place any data in the code-only
>> >> >> >> PT_LOAD segment.  If there are no data sections placed before the
>> >> >> >> code-only PT_LOAD segment, the program headers won't be mapped into
>> >> >> >> any PT_LOAD segment.  When the executable tries to access it (based
>> >> >> >> on the program header address passed in AT_PHDR), it will lead to
>> >> >> >> segfault.  This patch inserts a GNU_PROPERTY_X86_ISA_1_USED note if
>> >> >> >> there may be no data sections before the text section so that the
>> >> >> >> first PT_LOAD segment won't be code-only and will contain the program
>> >> >> >> header.
>> >> >> >
>> >> >> >
>> >> >> > i agree with Rich's comment on the bugzilla ticket:
>> >> >> > simply always adding a .phdrs section that covers
>> >> >> > the program headers would ensure that this kind of
>> >> >> > bug is not introduced on other targets and seems
>> >> >> > less hackish than adding a note.
>> >> >>
>> >> >> We can explore it.
>> >> >>
>> >> >> > i don't know why there is no such section already,
>> >> >> > or if there is any drawback adding such a section,
>> >> >> > is the requirement to access program headers in a
>> >> >> > static linked executable a linux only thing?
>> >> >>
>> >> >> The program headers aren't required to be mapped into
>> >> >> process image.  It may not be correct for Linux kermel
>> >> >> to set AT_PHDR to an unmapped address.  But I'd like
>> >> >> to support the existing kernel.  I am going to check in
>> >> >> my change ASIS and backport it to 2.31 branch.
>> >> >
>> >> > They are required to be mapped, for at least these reasons:
>> >> >
>> >> > 1. PT_TLS is the only way the runtime can find the program's TLS
>> >> >    image.
>> >> >
>> >> > 2. They're exposed as a public interface via dl_iterate_phdr, and the
>> >> >    AT_PHDR auxv entry.
>> >>
>> >> Only this one is relevant here.   The others don't need program headers
>> >> mapped into process image.
>> >
>> > Sure they do. Perhaps you're forgetting static linking. In the
>> > dynamic-linked case, except for the main program, the dynamic linker
>> > has access to the file and could load them and store them somewhere
>> > other than mapped as part of a load segment. But for a static linked
>> > program there is no access to the file available.
>> >
>>
>> Can you show that AT_PHDR isn't used in this case?
>
> Maybe I'm misunderstanding you then. AT_PHDR is the vector by which
> the program headers are found at runtime, but I consider it being part
> of a public interface for applications (#2 in my list) to be a
> separate issue from it being necessary to runtime implementation
> internals (all the other points).
>

It is a problem only when AT_PHDR points to an unmapped address.

-- 
H.J.