Date: Fri, 07 Jan 2022 14:58:54 +0100 From: Florian Weimer <fweimer@...hat.com> To: Rich Felker <dalias@...c.org> Cc: Nihal Jere <nihal@...aljere.xyz>, musl@...ts.openwall.com Subject: Re: 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.