From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 24999 invoked from network); 5 Jan 2022 08:56:48 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 5 Jan 2022 08:56:48 -0000 Received: (qmail 32129 invoked by uid 550); 5 Jan 2022 08:56:45 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 32109 invoked from network); 5 Jan 2022 08:56:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1641372993; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=9pXJMWEq8jPUElcfzyWxBzzCtAt0UfLSqJPE4JA7xmU=; b=BPdsyW54KtLDd09Ad+PHFE2M8z6dFGcF9SXEt63OX3JwN/ZoDBKJRURgaDxkqR+zc7MtAg TAXAwTZnWle+7pUIsImPG7S8RucWbed+ErQ9rWF55aSloHiPOm8G99WF1SM0ZvlbxD+Lq3 y5o1vALFG/YbRbciKpaiUe4eKbwvV+E= X-MC-Unique: QrywjV7JMmqgB6M2P4VtSw-1 From: Florian Weimer To: Rich Felker Cc: Nihal Jere , musl@lists.openwall.com References: <20220104214211.GC7074@brightrain.aerifal.cx> Date: Wed, 05 Jan 2022 09:56:25 +0100 In-Reply-To: <20220104214211.GC7074@brightrain.aerifal.cx> (Rich Felker's message of "Tue, 4 Jan 2022 16:42:12 -0500") Message-ID: <8735m2ftmu.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.79 on 10.5.11.12 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=fweimer@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] Dynamic linker segfault * Rich Felker: > This is a malformed program file not compatible with the machine page > size (4k). Arguably it should be detected as p_align < PAGESIZE -- in > a sense, p_align for LOAD segments is the maximum supported page size > for the program file, and machines not capable of providing a page > size that small can't map/run it. In theory the loader could allow > this if all the differences between segments satisfy the right > congruences and have matching permissions where the maps would > overlap, but I'm not sure that's useful. We've been looking at this on the glibc side recently. The use case is supporting large data alignments (greater than the kernel page size) while not pessimizing multi-page-size targets such as POWER and AArch64. With a p_align < PAGESIZE check, binaries need to specify p_align as the largest support kernel page size (64K on those targets). On a 64K page kernel, this alignment happens naturally, but on a 4K (or 16K) kernel, the loader needs to carve out a larger memory area and align it manually to achieve 64K alignment (because that's what p_align says). So far this didn't happen because we only checked p_align against the kernel size, we did not actually use it for aligning the mappings =E2=80=A6 Thanks, Florian