[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8735m2ftmu.fsf@oldenburg.str.redhat.com>
Date: Wed, 05 Jan 2022 09:56:25 +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:
> 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 …
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.
