From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) by mx.groups.io with SMTP id smtpd.web10.87244.1680562583327094269 for ; Mon, 03 Apr 2023 15:56:23 -0700 Authentication-Results: mx.groups.io; dkim=fail reason="signature has expired" header.i=@bsdio.com header.s=fm3 header.b=H422mFuV; spf=pass (domain: bsdio.com, ip: 64.147.123.24, mailfrom: rebecca@bsdio.com) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 3AE413200990; Mon, 3 Apr 2023 18:56:22 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Mon, 03 Apr 2023 18:56:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdio.com; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm3; t= 1680562581; x=1680648981; bh=t1K75S1fnNXVOs2apiGbjBpquNd5s4NZBn6 98szwbJ0=; b=H422mFuV1v6iJqTZaOr4WXZZCIfMZIVXVoXHJk9QzokCq47zboF WEUlx3t9uaa5XbZlXsH+4pCfD3PS4iMx09l6D/+4DwQMAmNbQorkIvlYButg0rlp KMInx55CWJflDloCkXbuKWA6NdccKPO07JuGJ7tTc6GHjtLOep3M3v78wim9pkQf fNCcpKLL5eLWo5tMcEhCbaKjNie17OSGLX66CrNMd5kM+izNBZKxxlVBOHOUIboW uj/B8qqTHd7M4yNAcahhfDcbCoWXNl61wXRlarGSpvRih3Ni1Xq3A7gOJi1ND2GZ tYJHrOz88pbDpkrZjaXIom5JZ3G7Uu9ZWyg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1680562581; x=1680648981; bh=t1K75S1fnNXVOs2apiGbjBpquNd5s4NZBn6 98szwbJ0=; b=QEBNrW3NEbP4Zo/cF1yRCQMzBCu0OppQ6+w3yrlvwc5JqE5wrez +dt0J2oukjmEvgAtNOcs18yk4s1bu/nUct3pWn+15nIy2ihWzBslE8KSc6aOSpz6 hpbxIauNgwaf7aMW2Mv4rQbuaSKCfIjG3U5EYUPne8Q81ddbu7LQ6smb+Ay+ba04 xLjkrGqBCSEqMPCgDriJwq8Yt4tNu5TQCG4ElnVSPqFGubZ7t4HZf7AHTJ2FB29u JbA+15fNwCBVlb2BWbyCuv8MA5RDrcaiVN7wL3B9OPNE0ibaGs/OKPfSCrrPzO4G dQWZXrtL/ACH0MiqDosef3Jhau8fRNj/bIw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdeijedgudektdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthekredttdefjeenucfhrhhomheptfgv sggvtggtrgcuvehrrghnuceorhgvsggvtggtrgessghsughiohdrtghomheqnecuggftrf grthhtvghrnhepveeufffhveejtedvkeefkeeihffhuddtgedtueehleeludekleeuveeh ffeugfdunecuffhomhgrihhnpehsfhdrnhgvthenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpehrvggsvggttggrsegsshguihhordgtohhm X-ME-Proxy: Feedback-ID: i5b994698:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 3 Apr 2023 18:56:19 -0400 (EDT) Message-ID: <6b49d3f9-d58b-a8d4-3695-7a0c8f673d67@bsdio.com> Date: Mon, 3 Apr 2023 16:56:18 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Subject: Re: Linker scripts use of "-z common-page-size=0x20" etc. To: =?UTF-8?Q?Marvin_H=c3=a4user?= Cc: Pedro Falcato , Liming Gao , Ard Biesheuvel , devel@edk2.groups.io References: <9befc3e1-02b6-c0c4-7eba-cccd84dedd3d@bsdio.com> <668CD723-746F-4A04-B5E8-7DD55AECD55F@posteo.de> From: "Rebecca Cran" In-Reply-To: <668CD723-746F-4A04-B5E8-7DD55AECD55F@posteo.de> Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 4/3/23 2:58 PM, Marvin Häuser wrote: > That last part is actually not ignoring the use-case, that *is* our use-case. The terminology again is very OS-oriented, it’s important to know that generally OSes will fail to load binaries that are aligned less than the platform page size, as they cannot apply permissions (and probably also some implementation details of mmap / VM / whatever). That’s why the maximum page size you’re realistic to encounter is exactly the image segment alignment (by hardware convention, this is a power of two, thus a strict alignment satisfies all less strict alignment constraints). > > The common page size on the other hand appears to be an optimization, for which you specify the most common page size (e.g., you may target AARCH64 which may require 16 KB alignment, but most of your targets will have only 4 KB pages), which the compiler will use to optimize the binary for the common targets. I have no idea why this is even used. There also were discussions on LLVM platforms that it should be avoided. > > The naive approach would be to just use max-page-size, drop all references to common-page-size, and align all ELF sections that will be converted to PE sections by max-page-size. But I’m sure there’s some ancient workaround / compiler bug / edge use case / portability or whatever reason why common-page-size was used. :) > (CC Leif for related experience.) > > edk2 generally sets this to a low value to save SPI (and possibly RAM) space, as nothing in the stack enforces memory protection ( :( ). I’m not sure why there’s both 32 and 64 Bytes, but I could imagine it’s some GNU ABI thing where some type of some arch actually requires this alignment, or maybe there’s different rules for global variables. A text segment must at least satisfy the maximum instruction alignment constraint (this may be a thing with, e.g., normalised instruction lengths), while data segments must satisfy at least the maximum data alignment constraint (which might usually be some large float? Not sure). 4 KB is used when memory protection is needed (usually RT drivers, as they’re mapped into the OS environment), but AARCH64 may actually require 16 KB (e.g. Apple A chips didn’t even support less for a while). Thanks. One problem with using max page size appears to be that there are some modules that set the common page size to 4KB in order to enable memory protection. e.g.: commit ddd89cd50dd3a989e58a75ed38011168e3ec0954 Author: Ard Biesheuvel Date:   Wed Sep 30 08:53:00 2015 +0000     OvmfPkg: set 4 KB section alignment for DXE_RUNTIME_DRIVER modules     Increase the section alignment to 4 KB for DXE_RUNTIME_DRIVER modules.     This allows the OS to map them with tightened permissions (i.e., R-X for     .text and RW- for .data). This is a prerequisite for enabling the EFI_PROPERTIES_RUNTIME_MEMORY_PROTECTION_NON_EXECUTABLE_PE_DATA (sic)     feature that was introduced in UEFIv2.5.     Contributed-under: TianoCore Contribution Agreement 1.0     Signed-off-by: Ard Biesheuvel     Reviewed-by: Laszlo Ersek     Reviewed-by: Jordan Justen     Tested-by: Laszlo Ersek     git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18564 6f19259b-4bc3-4df7-8a09-765794883524