From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-119.freemail.mail.aliyun.com (out30-119.freemail.mail.aliyun.com [115.124.30.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 05F442E3705 for ; Mon, 4 Aug 2025 07:39:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.119 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754293152; cv=none; b=Hib8b2ASehgYN4J0C54gUh2pr1VS7QSWo21p+xxYQk0PUX/0oBrAPTH+/+18mTwi5Ggq3Ao3RBrg3AJtt/IZ5pms85Sfk1vQLI3zK/dYcwhVECtdjK3xI/yLHFe7E9yxZxVH7slHeL4qOXV1RCyVEk+U/+yJD8BfJ9BqTXkyVwQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754293152; c=relaxed/simple; bh=raGA8lnbIPGmvURhE76kqB4Q7juXLPvbjYFbs0DAzjQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=c5xWEncm41z0BykSfhquHxoCyPMnrDDyyqEIzni72qUUierhhsio28SPv0m6GL+nQpwD8BhJsiq57J/iQH+S70hQAulJ7qPn0LObQ32LTdSedAe6CojK2iNVwU539LmAaZ1jiEnjmMNf9gM7MN4SwqJOWwwI3xYNeKAtdGXEOzY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=jyBXwr88; arc=none smtp.client-ip=115.124.30.119 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="jyBXwr88" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1754293141; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=VLUQ2YmpOeF4iBTFxFURlyjSpp1p8WA2sdCUCNZyHcw=; b=jyBXwr884ScuBitJHxzRlF7WeFLpW3erzhp9OSR/urs0Al506uJuOajo0hM8fPa1knHTU2u4tJmpVF8vEeVyOMdhuvT8ewsX48zW4ZbJWw0SaSB00jfOGuGxGQRqXC2MHws6LbmuC8xF/chLFAXBq/nc7ixT61lkhwQlGqGXDLw= Received: from 30.21.176.60(mailfrom:fengwei_yin@linux.alibaba.com fp:SMTPD_---0Wkwpm7d_1754293140 cluster:ay36) by smtp.aliyun-inc.com; Mon, 04 Aug 2025 15:39:00 +0800 Message-ID: <4c035c88-c268-40fc-9930-b5cc73fd49fb@linux.alibaba.com> Date: Mon, 4 Aug 2025 15:38:59 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] binfmt_elf: remove the 4k limitation of program header size To: Ismael Luceno Cc: Kees Cook , linux-kernel@vger.kernel.org, linux-mm@kvack.org, zhourundong.zrd@linux.alibaba.com References: <202508021029.7CC8B334@keescook> <6653242a-5b08-48ff-a126-9e9367633420@linux.alibaba.com> From: Yin Fengwei In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 在 2025/8/4 15:19, Ismael Luceno 写道: > 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. OK. > > I'm not aware of any system with an MMU doing that but, I think on > RISC-V it's implementation-defined. But resitriction of 4K can NOT prevent cross-page multi-byte reads as well. Say if the phdrs is on 2K offset, the size of entries is larger than 2K. Right? Regards Yin, Fengwei