From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E3061ECDE44 for ; Wed, 31 Oct 2018 17:56:56 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6E7AB2080A for ; Wed, 31 Oct 2018 17:56:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6E7AB2080A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 42lbd20xfnzF3Gq for ; Thu, 1 Nov 2018 04:56:54 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: lists.ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=redhat.com (client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=fweimer@redhat.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=redhat.com Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 42lbZn415MzF3GW for ; Thu, 1 Nov 2018 04:54:57 +1100 (AEDT) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id AFEE12027A; Wed, 31 Oct 2018 17:54:55 +0000 (UTC) Received: from oldenburg.str.redhat.com (dhcp-192-212.str.redhat.com [10.33.192.212]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E148B1054FDA; Wed, 31 Oct 2018 17:54:54 +0000 (UTC) From: Florian Weimer To: Michal =?utf-8?Q?Such=C3=A1nek?= Subject: Re: PIE binaries are no longer mapped below 4 GiB on ppc64le References: <87k1lyf2x3.fsf@oldenburg.str.redhat.com> <20181031185032.679e170a@naga.suse.cz> Date: Wed, 31 Oct 2018 18:54:52 +0100 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") Message-ID: <877ehyf1cj.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Wed, 31 Oct 2018 17:54:55 +0000 (UTC) X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" * Michal Such=C3=A1nek: > On Wed, 31 Oct 2018 18:20:56 +0100 > Florian Weimer 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. >>=20 >> With our 4.10-derived kernel, PIE binaries are mapped below 4 GiB, so >> relocations like R_PPC64_ADDR16_HA work: >>=20 > ... > >> There are fewer mappings because the loader detects a relocation >> overflow and aborts (=E2=80=9Cerror while loading shared libraries: >> R_PPC64_ADDR16_HA reloc at 0x0000000120f0983c for symbol `' out of >> range=E2=80=9D), so I had to recover the mappings externally. Disabling= ASLR >> does not help. >>=20 > ... >>=20 >> And it needs to be built with: >>=20 >> go build -ldflags=3D-extldflags=3D-pie extld.go >>=20 >> 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com [209.85.160.199]) by kanga.kvack.org (Postfix) with ESMTP id 21CE36B0007 for ; Wed, 31 Oct 2018 13:54:57 -0400 (EDT) Received: by mail-qt1-f199.google.com with SMTP id x8-v6so17381816qtc.15 for ; Wed, 31 Oct 2018 10:54:57 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com. [209.132.183.28]) by mx.google.com with ESMTPS id j3-v6si13269140qkf.0.2018.10.31.10.54.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 Oct 2018 10:54:56 -0700 (PDT) From: Florian Weimer Subject: Re: PIE binaries are no longer mapped below 4 GiB on ppc64le References: <87k1lyf2x3.fsf@oldenburg.str.redhat.com> <20181031185032.679e170a@naga.suse.cz> Date: Wed, 31 Oct 2018 18:54:52 +0100 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") Message-ID: <877ehyf1cj.fsf@oldenburg.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sender: owner-linux-mm@kvack.org List-ID: To: Michal =?utf-8?Q?Such=C3=A1nek?= Cc: linuxppc-dev@lists.ozlabs.org, linux-mm@kvack.org * Michal Such=C3=A1nek: > On Wed, 31 Oct 2018 18:20:56 +0100 > Florian Weimer 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. >>=20 >> With our 4.10-derived kernel, PIE binaries are mapped below 4 GiB, so >> relocations like R_PPC64_ADDR16_HA work: >>=20 > ... > >> There are fewer mappings because the loader detects a relocation >> overflow and aborts (=E2=80=9Cerror while loading shared libraries: >> R_PPC64_ADDR16_HA reloc at 0x0000000120f0983c for symbol `' out of >> range=E2=80=9D), so I had to recover the mappings externally. Disabling= ASLR >> does not help. >>=20 > ... >>=20 >> And it needs to be built with: >>=20 >> go build -ldflags=3D-extldflags=3D-pie extld.go >>=20 >> 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