From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id 28A1C7803CE for ; Sat, 16 Mar 2024 15:47:52 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=k78zgvlMV9TBUAP5r7TwPNa4PAqUoHCEwPEwCH38+8o=; c=relaxed/simple; d=groups.io; h=DKIM-Filter:Message-ID:Date:MIME-Version:User-Agent:Subject:To:Cc:References:From:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Resent-Date:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Language:Content-Type:Content-Transfer-Encoding; s=20240206; t=1710604070; v=1; b=KJB5HFiYk0f/sREltZ3ZhtsZXjdnA2PqxXsFeLy/QZemNdEeZ3H//CMUClQO5J+Lw3/cjYwG LjxqlKuoQpMNc3et3Il/bRVBb+/2zQlpEG1PguOirf1hf24zHdEaV+dvWer/jyta95zMuyDZWkE skvdAfeAZDeyKVXE5M665CdPGhl2+Rndyx5iwZdahwZhfJSW95nuI3itlpIAI+gknj+O62WASGC /wLHp5lTmu1Yme5XqwOeDqjGFPI7++Kn10etodmvvKqGYd6M3A7d/CDqbUou8vUHrWDBV4hOigb cQh/9JrM4oAWZXp21Nr+sVH9rDtHsHefD4DNaj6D91jlw== X-Received: by 127.0.0.2 with SMTP id IapuYY7687511x5RGwAKMKRw; Sat, 16 Mar 2024 08:47:50 -0700 X-Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mx.groups.io with SMTP id smtpd.web10.9432.1710604070020660298 for ; Sat, 16 Mar 2024 08:47:50 -0700 X-Received: from [10.137.194.171] (unknown [131.107.159.43]) by linux.microsoft.com (Postfix) with ESMTPSA id 7E32020B74C0; Sat, 16 Mar 2024 08:47:49 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 7E32020B74C0 Message-ID: <730ed058-eacb-43e0-b20e-e2a399218c70@linux.microsoft.com> Date: Sat, 16 Mar 2024 08:47:49 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [edk2-devel][PATCH v1 1/3] MdeModulePkg: ImagePropertiesRecordLib: Use SectionAlignment for CodeSize To: devel@edk2.groups.io, mhaeuser@posteo.de Cc: Leif Lindholm , Ard Biesheuvel , Sami Mujawar , Taylor Beebe References: <58edd77a-1282-4e3a-b2c9-9d5a8dd8b1d2@linux.microsoft.com> <92E2E047-C087-4122-9938-D84025F47B7D@posteo.de> From: "Oliver Smith-Denny" In-Reply-To: <92E2E047-C087-4122-9938-D84025F47B7D@posteo.de> Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Resent-Date: Sat, 16 Mar 2024 08:47:50 -0700 Reply-To: devel@edk2.groups.io,osde@linux.microsoft.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: idVs9pv4z2xNXIjLROuivT4ux7686176AA= Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20240206 header.b=KJB5HFiY; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=linux.microsoft.com (policy=none); spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io On 3/15/2024 4:45 PM, Marvin H=C3=A4user wrote: >=20 >> On 15. Mar 2024, at 23:57, Oliver Smith-Denny = wrote: >> >> I don't think this is what I'm saying. What I am trying to say is that >> on MSVC, I see PE images getting created that have VirtualSize set to >> the actual number of initialized bytes in that section (not padded to >> the section alignment). On ElfConverted binaries, I see the VirtualSize >> is padded to the section alignment. I've dropped an example below >=20 > Ah, mismatched terminology. Zero-initialized as Ard and I used it refers = to implicitly or explicitly 0-initialized global variables and such, which = is not stored in the file, not the padding. So when you mentioned =E2=80=9C= real data=E2=80=9D, I assumed you meant strictly the non-0 data from the fi= le. Same misunderstanding with SizeOfImage, so that=E2=80=99s all fine. Whe= w. :) Ah gotcha, thanks I was figuring I was using the wrong terminology :). What you said makes sense and I see your concern based on what I said. >=20 >> No, the specific case where I was researching this was explicitly >> setting /ALIGN:0x10000 and /FILEALIGN:0x1000 for DXE_RUNTIME_DRIVERs >> on ARM64 (a UEFI spec requirement). So I would see the SizeOfRawData >> is aligned to the file alignment, as expected, but VirtualSize would >> be the actual size of the data. Again, the troubling thing here for >> me is that the same binary built with gcc has the VirtualSize aligned >> to the section alignment. And I have seen other code that loads PE >> images that relies on VirtualSize not including the padding. The spec >> is vague here, it says VirtualSize is the size of the section as >> loaded in memory (which would lead me to believe this should include >> padding) but it does not explicitly say it should be a multiple of >> the section alignment (as other fields do). But at a minimum I think >> we should have different toolchains doing the same behavior here. >=20 > Well, not rounding to pad is somewhat superior in some scenarios. If you = round, you lose the information on what is section data and what is padding= , so you might end up treating padding as data for some reason (because it = is indistinguishable from mentioned 0-initialized data). This shouldn=E2=80= =99t matter too much for executables and libraries, but MSVC/PE have a lot = less of a distinction between object file and executable/library concepts (= e.g. no distinction between sections and segments). That might be why they = do it this way. >=20 I agree, I've seen other environments that will use VirtualSize to set attributes for that section and then set stricter attributes, like RP on the padded section (if greater than a page). Point being that there are use cases and at least some folks relying on that definition of VirtualSize. >> See below for the VirtualSize examples, I'm confused on your comment on >> SizeOfImage. I agree that SizeOfImage covers everything as loaded into >> memory and I have not seen any issues there. >=20 > See first comment. >=20 >> Do you mind adding your RB to v2? And certainly if you have any other >> comments that is greatly appreciated. >=20 > Will try to remember tomorrow. :) >=20 Thanks! >> Examples of the differences I see between MSVC and gcc binaries: >> >> I originally noticed this on ARM64 on edk2, but wanted to make sure I >> saw it on x64 too, so this is with binaries from Project Mu's QemuQ35Pkg >> (edk2 doesn't have VS2022 support and I didn't feel like adding it >> or reverting back to VS2019). For reference, this is building the >> current top of tree at a4dd5d9785f48302c95fec852338d6bd26dd961a. >> >> I dumped ReportStatusCodeRouterRuntimeDxe.efi from both using dumpbin >> (from VS2022) to examine the PE headers. >> >> MSVC selected header values: >> >> Main header: >> 0x3200 size of code >> 0x2400 size of initialized data >> 0x0 size of uninitialized data >> 0x1000 section alignment >> 0x200 file alignment >> 0xB000 size of image >> >> 6 sections: .data, .pdata, .rdata, .reloc, .text, .xdata >> >> .text section: >> 0x30DF virtual size >> 0x3200 size of raw data >> >> .data section: >> 0x130 virtual size >> 0x200 size of raw data >> >> >> GCC ElfConverted selected header values: >> >> Main header: >> 0x4000 size of code >> 0x1000 size of initialized data >> 0x0 size of uninitialized data >> 0x1000 section alignment >> 0x1000 file alignment >> 0x7000 size of image >> >> 3 sections: .data, .text, .reloc >> >> .text section: >> 0x4000 virtual size >> 0x4000 size of raw data >> >> .data section: >> 0x1000 virtual size >> 0x1000 size of raw data >> >> So my concern here is that ElfConvert takes a >> different view of VirtualSize, that is should be >> section aligned, whereas MSVC binaries take >> VirtualSize to be the actual size without padding. >> I think the correct thing to do would be change >> ElfConvert to do what MSVC does (although the spec >> is vague and so I can understand the confusion). >=20 > I don=E2=80=99t think it really matters, but it wouldn=E2=80=99t hurt eit= her. Both kinds of binaries are in the wild, so you cannot really leverage = any of the choices=E2=80=99 advantages either way. Adjusting to MSVC=E2=80= =99s behaviour would be right though, as you can at least properly distingu= ish between padding and 0-data with new binaries. Yeah, I agree. I may take a look at this, but to your point from an earlier email, it may be safer to leave it as is, considering we have all these binaries in the wild already and changes in a broken environment are risky. Thanks, Oliver -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#116823): https://edk2.groups.io/g/devel/message/116823 Mute This Topic: https://groups.io/mt/104610770/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-