From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from iodev.co.uk (iodev.co.uk [46.30.189.100]) by smtp.subspace.kernel.org (Postfix) with ESMTP id ECEF6161302 for ; Mon, 4 Aug 2025 07:19:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=46.30.189.100 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754291991; cv=none; b=NjUMA8AKGJxikOleANMoNdg9tZQ3+qifDYp8IIle7jZ+B5ALqihGO05vskfVNJEcoOvfwir0yHCndyheldlq0gcJppw7pOcH1B22uZ96Z8ajvYzk0A+vp83vYbn2xXCuk7Oe9dKqjAXSmQFrCIhRjDB4ozT98zJ1toFAz9NGQPQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754291991; c=relaxed/simple; bh=Hv+TXMwiLSMUx4WsbCJF+px7zqZ1LYB90rHsL92Htlc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Ep7UFaPzgFrDS9fEGbFHx5qVtWt6htqiGzWa7kScE2pRkD4VJq11voDIqxJQqFxT42xKYFUSnziLtYyQzlljyeZ7lkEwM5fzrL49NzhFA0lzAwfKFyyFXv1kvVrMWA2edByubyJzydUutD9+fa7MGzSHjE1O7fWJY/DkgG7vN28= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=iodev.co.uk; spf=pass smtp.mailfrom=iodev.co.uk; arc=none smtp.client-ip=46.30.189.100 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=iodev.co.uk Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=iodev.co.uk Received: from pirotess (112.red-83-45-208.dynamicip.rima-tde.net [83.45.208.112]) by iodev.co.uk (Postfix) with ESMTPSA id C8D7F4552BC; Mon, 04 Aug 2025 09:19:41 +0200 (CEST) Date: Mon, 4 Aug 2025 09:19:40 +0200 From: Ismael Luceno To: Yin Fengwei Cc: Kees Cook , linux-kernel@vger.kernel.org, linux-mm@kvack.org, zhourundong.zrd@linux.alibaba.com Subject: Re: [PATCH] binfmt_elf: remove the 4k limitation of program header size Message-ID: References: <202508021029.7CC8B334@keescook> <6653242a-5b08-48ff-a126-9e9367633420@linux.alibaba.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6653242a-5b08-48ff-a126-9e9367633420@linux.alibaba.com> On 04/Aug/2025 10:12, Yin Fengwei wrote: > > > 在 2025/8/3 13:28, Ismael Luceno 写道: > > On 02/Aug/2025 10:29, Kees Cook wrote: > > > On Sat, Aug 02, 2025 at 05:47:13AM +0200, Ismael Luceno wrote: > > > > On Sat, Jul 19, 2025 at 17:17:09 +0800, YinFengwei wrote: > > > > > On Thu, Jul 17, 2025 at 04:31:50PM +0800, Kees Cook wrote: > > > > > > On Thu, 17 Jul 2025 19:01:08 +0800, fengwei_yin@linux.alibaba.com wrote: > > > > > > > We have assembly code generated by a script. GCC successfully compiles > > > > > > > it. However, the kernel cannot load it on an ARM64 platform with a 4K > > > > > > > page size. In contrast, the same ELF file loads correctly on the same > > > > > > > platform with a 64K page size. > > > > > > > > > > > > > > The root cause is the Linux kernel's ELF_MIN_ALIGN limitation on the > > > > > > > program headers of ELF files. The ELF file contains 78 program headers > > > > > > > (the script inserts many holes when generating the assembly code). On > > > > > > > ARM64 with a 4K page size, the ELF_MIN_ALLIGN enforces a maximum of 74 > > > > > > > program headers, causing the ELF file to fail. However, with a 64K page > > > > > > > size, the ELF_MIN_ALIGN is relaxed to over 1,184 program headers, allowing > > > > > > > the file to run correctly. > > > > > > > > > > > > > > [...] > > > > > > > > > > > > Applied to for-next/execve, thanks! > > > > > Cook, thanks a lot. > > > > > > > > > > Regards > > > > > Yin, Fengwei > > > > > > > > > > > > > > > > > [1/1] binfmt_elf: remove the 4k limitation of program header size > > > > > > https://git.kernel.org/kees/c/8030790477e8 > > > > > > > > > > > > Take care, > > > > > > > > Hi, > > > > > > > > I noticed this removal and wonder whether it could be a problem on > > > > smaller platforms. > > > > > > > > IIRC that code has been there since ELF support was added in one > > > > form or another; and the idea behind it was to simplify the code > > > > by ensuring no cross-page reads could happen, as these could cause > > > > undefined behaviours or read abort exceptions. > > > > > > I didn't see a place where that would happen -- the reads aren't done on > > > a single page. If you see something that I missed, please let me know! > > > > The offset to the phdrs can point anywhere and the entries are > > arbitrarily sized, thus it can be unaligned, so we can be potentially > > reading at an entry right between two pages. > > The read buffer are managed in kernel. Why cross-page read can cause > undefined behaviors or read abort? > > Does smaller platforms have special behavior in this situation? Like > can't do cross-page read against the buffer allocated by kmalloc? Pretty much anything MMU-less will fault at cross-page multi-byte reads. I'm not aware of any system with an MMU doing that but, I think on RISC-V it's implementation-defined.