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=-3.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 24634 invoked from network); 7 Jan 2022 13:59:17 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 7 Jan 2022 13:59:17 -0000 Received: (qmail 5728 invoked by uid 550); 7 Jan 2022 13:59:14 -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 5708 invoked from network); 7 Jan 2022 13:59:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1641563941; 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: in-reply-to:in-reply-to:references:references; bh=r+jaBB65HlVaYuXQIXNxv9pBwdmVZJaMELyeydsZlo8=; b=DP4iR1nUe92zjErK3FiQ7KD6dU125xYqlkxUuYEmnvo7LP02LFWBgq5fJ2+rgz7V/u2m/A /MmzlYXA2bIXLDwoSU533QsDRLbSujQJLps7iVqT3O3j6LDoNwgqiHiwmMTb3BUHuyKZEt gt0O+3gRK+ZH4BEB4ELS2CC0ppUnNQA= X-MC-Unique: 3OSOnGYSNJGfFIMdQTVVpQ-1 From: Florian Weimer To: Rich Felker Cc: Nihal Jere , musl@lists.openwall.com References: <20220104214211.GC7074@brightrain.aerifal.cx> <8735m2ftmu.fsf@oldenburg.str.redhat.com> <20220105134957.GF7074@brightrain.aerifal.cx> <87pmp6e0yy.fsf@oldenburg.str.redhat.com> <20220105150035.GG7074@brightrain.aerifal.cx> Date: Fri, 07 Jan 2022 14:58:54 +0100 In-Reply-To: <20220105150035.GG7074@brightrain.aerifal.cx> (Rich Felker's message of "Wed, 5 Jan 2022 10:00:35 -0500") Message-ID: <87v8yv3aw1.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.84 on 10.5.11.23 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 Subject: Re: [musl] Dynamic linker segfault * Rich Felker: >> With a p_align < PAGESIZE check in place, portable binaries need to use >> the value 65536. When running with page size 4096, the loader cannot >> know whether p_align was set to this value merely to satisfy the p_align >> < PAGESIZE check, or because there is actually some section alignment >> that requires 65536 byte alignment. There is no kernel interface to >> request 65536 byte alignment, so the loader has to do extra work to >> satisfy this request. And in the first case (no actual 65536 byte >> alignment requirement), that work is unnecessary. > > Unfortunately it's impossible to distinguish between such an alignment > requirement and __attribute__((__aligned__(65536))) appearing in > section contents that went into the segment, so disregarding it is a > bug (one musl also has) I think. Agreed. >> > In any case, do you know if this test file is somehow related to that >> > work, or is it just a guess? It doesn't seem to be related to me since >> > it's essentially a "pageless" mapping setup. >> >> The glibc test seems to be just buggy: First we verify p_align against >> the page size, then we use that p_align value to check the alignment of >> the PT_LOAD segment (mainly file offset congruency). The p_align check >> against the page size looks completely optional to me if we check file >> offset congruency directly against the run-time page size. >> >> The ELF specification explicitly describes the p_align values 0 and 1 as >> valid, indicating no alignment constraint. So a p_align < PAGESIZE >> check is buggy in that regard as well. This also conflicts with your >> interpretation as p_align as the maximum supported page size. > > The ELF specification describes syntax not semantic requirements on > the platform to support anything the syntax can represent. That's not entirely accurate, there are exceptions. p_align seems to be one such exception: p_align As ``Program Loading'' describes in this chapter of the processor supplement, loadable process segments must have congruent values for p_vaddr and p_offset, modulo the page size. This member gives the value to which the segments are aligned in memory and in the file. Values 0 and 1 mean no alignment is required. Otherwise, p_align should be a positive, integral power of 2, and p_vaddr should equal p_offset, modulo p_align. Most processor supplements do not discuss p_align unfortunately? > The semantics of the above can't be honored (without memcpy instead of > mmap, which is really something you don't want to support) if they > produce congruences incompatible with the layout, and they can't be > honored at all if they're incompatible with the permissions > requirements. Even when they don't conflict with the permissions > requirements, they may expose unintended mapped data (which for users > wanting separate-code is problematic, since it introduces gadgets). So > I'm not convinced it should be supported even when it "can". The congruency compatibility is a property of the file layout, not the p_align value. If the file layout is incompatible, changing p_align doesn't make the object loadable. As far as I can tell, p_align is not at all useful, except for (e.g.) __attribute__((__aligned__(65536))) for global. But even that wasn't implemented widely. Thanks, Florian