From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 1EEFD385DC04 for ; Tue, 3 May 2022 12:56:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1EEFD385DC04 Received: from pps.filterd (m0098393.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 243CmLGN016912; Tue, 3 May 2022 12:56:26 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3fu1ajbt51-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 03 May 2022 12:56:25 +0000 Received: from m0098393.ppops.net (m0098393.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 243CnG5v010206; Tue, 3 May 2022 12:56:25 GMT Received: from ppma01fra.de.ibm.com (46.49.7a9f.ip4.static.sl-reverse.com [159.122.73.70]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3fu1ajbt47-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 03 May 2022 12:56:25 +0000 Received: from pps.filterd (ppma01fra.de.ibm.com [127.0.0.1]) by ppma01fra.de.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 243CqVoV030537; Tue, 3 May 2022 12:56:22 GMT Received: from b06cxnps4075.portsmouth.uk.ibm.com (d06relay12.portsmouth.uk.ibm.com [9.149.109.197]) by ppma01fra.de.ibm.com with ESMTP id 3frvr8ubtu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 03 May 2022 12:56:22 +0000 Received: from d06av23.portsmouth.uk.ibm.com (d06av23.portsmouth.uk.ibm.com [9.149.105.59]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 243CuKgH46858542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 3 May 2022 12:56:20 GMT Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7D62AA404D; Tue, 3 May 2022 12:56:20 +0000 (GMT) Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 293F0A4040; Tue, 3 May 2022 12:56:20 +0000 (GMT) Received: from [9.145.13.52] (unknown [9.145.13.52]) by d06av23.portsmouth.uk.ibm.com (Postfix) with ESMTP; Tue, 3 May 2022 12:56:20 +0000 (GMT) Message-ID: Date: Tue, 3 May 2022 14:56:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: [PATCH] S390: Enable static PIE Content-Language: en-US To: Florian Weimer , Adhemerval Zanella Cc: Stefan Liebler via Libc-alpha References: <20220428141530.567838-1-stli@linux.ibm.com> <87y1zk70vk.fsf@oldenburg.str.redhat.com> <760241d4-2f3e-7078-ad98-a4d8ed3fdc69@linaro.org> <87r15b4ubx.fsf@oldenburg.str.redhat.com> From: Stefan Liebler In-Reply-To: <87r15b4ubx.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8 X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: Cisu9DQBT__2AbcAdy8yh_k3clV5D5l9 X-Proofpoint-GUID: -P0NQ-Ld0l-D9dGhQH9FunOUSdUg0Y5S Content-Transfer-Encoding: 7bit X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.858,Hydra:6.0.486,FMLib:17.11.64.514 definitions=2022-05-03_03,2022-05-02_03,2022-02-23_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 adultscore=0 clxscore=1011 lowpriorityscore=0 phishscore=0 bulkscore=0 malwarescore=0 mlxlogscore=999 mlxscore=0 priorityscore=1501 spamscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2205030092 X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, 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: Tue, 03 May 2022 12:56:29 -0000 On 02/05/2022 21:18, Florian Weimer wrote: > * 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 > Hi Florian and Adhemerval, I've just build glibc-HEAD and run the testsuite with /proc/sys/kernel/randomize_va_space = 0. => Recognized fails as srbk failed. Then I've build with Florian's patch series on top. I don't see any testsuite fails. Furthermore I've debbugged a static testcase into _dl_early_allocate => mmap was used as result and previous was equal. With Florian's patch series also applied, static PIE binaries also run on an unchanged kernel. Thanks, Stefan