All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: "Michal Suchánek" <msuchanek@suse.de>
Cc: linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org
Subject: Re: PIE binaries are no longer mapped below 4 GiB on ppc64le
Date: Wed, 31 Oct 2018 18:54:52 +0100	[thread overview]
Message-ID: <877ehyf1cj.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <20181031185032.679e170a@naga.suse.cz> ("Michal \=\?utf-8\?Q\?Suc\?\= \=\?utf-8\?Q\?h\=C3\=A1nek\=22's\?\= message of "Wed, 31 Oct 2018 18:50:32 +0100")

* Michal Suchánek:

> On Wed, 31 Oct 2018 18:20:56 +0100
> Florian Weimer <fweimer@redhat.com> wrote:
>
>> We tried to use Go to build PIE binaries, and while the Go toolchain
>> is definitely not ready (it produces text relocations and problematic
>> relocations in general), it exposed what could be an accidental
>> userspace ABI change.
>> 
>> With our 4.10-derived kernel, PIE binaries are mapped below 4 GiB, so
>> relocations like R_PPC64_ADDR16_HA work:
>> 
> ...
>
>> There are fewer mappings because the loader detects a relocation
>> overflow and aborts (“error while loading shared libraries:
>> R_PPC64_ADDR16_HA reloc at 0x0000000120f0983c for symbol `' out of
>> range”), so I had to recover the mappings externally.  Disabling ASLR
>> does not help.
>> 
> ...
>> 
>> And it needs to be built with:
>> 
>>   go build -ldflags=-extldflags=-pie extld.go
>> 
>> I'm not entirely sure what to make of this, but I'm worried that this
>> could be a regression that matters to userspace.
>
> I encountered the same when trying to build go on ppc64le. I am not
> familiar with the internals so I just let it be.
>
> It does not seem to matter to any other userspace.

It would matter to C code which returns the address of a global variable
in the main program through and (implicit) int return value.

The old behavior hid some pointer truncation issues.

> Maybe it would be good idea to generate 64bit relocations on 64bit
> targets?

Yes, the Go toolchain definitely needs fixing for PIE.  I don't dispute
that.

Thanks,
Florian

WARNING: multiple messages have this Message-ID (diff)
From: Florian Weimer <fweimer@redhat.com>
To: "Michal Suchánek" <msuchanek@suse.de>
Cc: linuxppc-dev@lists.ozlabs.org, linux-mm@kvack.org
Subject: Re: PIE binaries are no longer mapped below 4 GiB on ppc64le
Date: Wed, 31 Oct 2018 18:54:52 +0100	[thread overview]
Message-ID: <877ehyf1cj.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <20181031185032.679e170a@naga.suse.cz> ("Michal \=\?utf-8\?Q\?Suc\?\= \=\?utf-8\?Q\?h\=C3\=A1nek\=22's\?\= message of "Wed, 31 Oct 2018 18:50:32 +0100")

* Michal Suchánek:

> On Wed, 31 Oct 2018 18:20:56 +0100
> Florian Weimer <fweimer@redhat.com> wrote:
>
>> We tried to use Go to build PIE binaries, and while the Go toolchain
>> is definitely not ready (it produces text relocations and problematic
>> relocations in general), it exposed what could be an accidental
>> userspace ABI change.
>> 
>> With our 4.10-derived kernel, PIE binaries are mapped below 4 GiB, so
>> relocations like R_PPC64_ADDR16_HA work:
>> 
> ...
>
>> There are fewer mappings because the loader detects a relocation
>> overflow and aborts (“error while loading shared libraries:
>> R_PPC64_ADDR16_HA reloc at 0x0000000120f0983c for symbol `' out of
>> range”), so I had to recover the mappings externally.  Disabling ASLR
>> does not help.
>> 
> ...
>> 
>> And it needs to be built with:
>> 
>>   go build -ldflags=-extldflags=-pie extld.go
>> 
>> I'm not entirely sure what to make of this, but I'm worried that this
>> could be a regression that matters to userspace.
>
> I encountered the same when trying to build go on ppc64le. I am not
> familiar with the internals so I just let it be.
>
> It does not seem to matter to any other userspace.

It would matter to C code which returns the address of a global variable
in the main program through and (implicit) int return value.

The old behavior hid some pointer truncation issues.

> Maybe it would be good idea to generate 64bit relocations on 64bit
> targets?

Yes, the Go toolchain definitely needs fixing for PIE.  I don't dispute
that.

Thanks,
Florian

  reply	other threads:[~2018-10-31 17:56 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-31 17:20 PIE binaries are no longer mapped below 4 GiB on ppc64le Florian Weimer
2018-10-31 17:50 ` Michal Suchánek
2018-10-31 17:50   ` Michal Suchánek
2018-10-31 17:54   ` Florian Weimer [this message]
2018-10-31 17:54     ` Florian Weimer
2018-10-31 21:23     ` Tulio Magno Quites Machado Filho
2018-10-31 21:23       ` Tulio Magno Quites Machado Filho
2018-10-31 21:28       ` Florian Weimer
2018-10-31 21:28         ` Florian Weimer
2018-10-31 22:04         ` Tulio Magno Quites Machado Filho
2018-10-31 22:04           ` Tulio Magno Quites Machado Filho
2018-10-31 22:41           ` Michal Suchánek
2018-10-31 22:41             ` Michal Suchánek
2018-10-31 22:24     ` Benjamin Herrenschmidt
2018-10-31 22:24       ` Benjamin Herrenschmidt
2018-11-02  4:38       ` Nick Piggin
2018-11-01  3:55 ` Michael Ellerman
2018-11-01  6:49   ` Alan Modra
2018-11-01  6:49     ` Alan Modra
2018-11-02  9:41     ` Michael Ellerman
2018-11-02  9:41       ` Michael Ellerman
2018-11-01 11:20   ` Florian Weimer
2018-11-01 11:20     ` Florian Weimer
2018-11-02  9:37     ` Michael Ellerman
2018-11-02  9:37       ` Michael Ellerman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=877ehyf1cj.fsf@oldenburg.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=msuchanek@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.