From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id CEB7F3858430 for ; Mon, 2 May 2022 19:18:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CEB7F3858430 Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-436-Y3W6BDkvPge0C6dsxJ3TAg-1; Mon, 02 May 2022 15:18:13 -0400 X-MC-Unique: Y3W6BDkvPge0C6dsxJ3TAg-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 060DF101AA45; Mon, 2 May 2022 19:18:13 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.59]) by smtp.corp.redhat.com (Postfix) with ESMTPS id EDE7A150DDF6; Mon, 2 May 2022 19:18:11 +0000 (UTC) From: Florian Weimer To: Adhemerval Zanella Cc: Stefan Liebler via Libc-alpha , Stefan Liebler Subject: Re: [PATCH] S390: Enable static PIE References: <20220428141530.567838-1-stli@linux.ibm.com> <87y1zk70vk.fsf@oldenburg.str.redhat.com> <760241d4-2f3e-7078-ad98-a4d8ed3fdc69@linaro.org> Date: Mon, 02 May 2022 21:18:10 +0200 In-Reply-To: <760241d4-2f3e-7078-ad98-a4d8ed3fdc69@linaro.org> (Adhemerval Zanella's message of "Mon, 2 May 2022 12:38:35 -0300") Message-ID: <87r15b4ubx.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.85 on 10.11.54.7 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2022 19:18:18 -0000 * Adhemerval Zanella: > On 02/05/2022 06:13, Florian Weimer via Libc-alpha wrote: >> * Stefan Liebler via Libc-alpha: >> >>> This commit enables static PIE on 64bit. On 31bit, static PIE is >>> not supported. >>> >>> - kernel (the mentioned links to the commits belong to 5.19 merge window): >>> - "s390/mmap: increase stack/mmap gap to 128MB" >>> https://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git/commit/?h=features&id=f2f47d0ef72c30622e62471903ea19446ea79ee2 >>> - "s390/vdso: move vdso mapping to its own function" >>> https://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git/commit/?h=features&id=57761da4dc5cd60bed2c81ba0edb7495c3c740b8 >>> - "s390/vdso: map vdso above stack" >>> https://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git/commit/?h=features&id=9e37a2e8546f9e48ea76c839116fa5174d14e033 >>> - "s390/vdso: add vdso randomization" >>> https://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git/commit/?h=features&id=41cd81abafdc4e58a93fcb677712a76885e3ca25 >>> (We can't test the kernel of the target system) >>> Otherwise if /proc/sys/kernel/randomize_va_space is turned off (0), >>> static PIE executables like ldconfig will crash. While startup sbrk is >>> used to enlarge the HEAP. Unfortunately the underlying brk syscall fails >>> as there is not enough space after the HEAP. Then the address of the TLS >>> image is invalid and the following memcpy in __libc_setup_tls() leads >>> to a segfault. >>> If /proc/sys/kernel/randomize_va_space is activated (default: 2), there >>> is enough space after HEAP. >> >> I'll work an early allocator that does not use the TCB and which should >> avoid the sbrk crash. Will that be sufficient to enable static PIE >> binaries to run on unchanged kernels? >> >> Otherwise I fear that we end up in a world of pain if we turn ldconfig >> into a static PIE binary. 8-( > > > I agree that ideally it should not rely a patched kernel to overcome the > glibc issue of handling sbrk call failures and having a working loader > allocator that work regardless of kernel version is the best approach. > > As I put on weekly call, I would prefer to make it only use mmap as > for simplicity. Getting mmap to work is actually the hard part due to six-argument system call. Trying sbrk first does not add much complexity. I posted my series: Linux: Fall back to mmap if early sbrk fails Stefan, I would appreciate if you could check that the kernel fixes are not strictly required anymore with these changes. Thanks, Florian