From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail03.groups.io (mail03.groups.io [45.79.227.220]) by spool.mail.gandi.net (Postfix) with ESMTPS id 1B79BD8086D for ; Fri, 15 Mar 2024 23:45:53 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=i+3Q9Bl1h/s5bahWgsFftkSfLDm5h8+ppQMGmIHtTJw=; c=relaxed/simple; d=groups.io; h=From:Mime-Version:Subject:Date:Message-Id:References:Cc:In-Reply-To:To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Resent-Date:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type:Content-Transfer-Encoding; s=20240206; t=1710546352; v=1; b=txUIJPLqcoMv0q6F1/0Lup/QN/44zKi0aJZam0kP4t0DEiDQ6RSDBuaUCVV/UgZJzOK0fhl3 MnmBasIRZP+vcLy7CEWi2dMlP8Mdo3l0y7SPc1I2Zyll1fdiyWEOsui96REgQYU5U1vjSCJncD9 aBbVF6QBQYJs+olKX1FbaLui+WpAL5NsSbuQttC0vT2noZqqSWynOmlh9urp2m5lED+2Ts2Jvp5 IOcBxb3KOHSe3oX4O6Gf1k/tiuVQig61LMbg6hmgOt4mlH965EkKcRvLxi81YPl/WUeujTWNY1A QJZzk8ret6psHlPrT4FXfLtrYSzEl4ErWMwsBdDixZ6aQ== X-Received: by 127.0.0.2 with SMTP id bejeYY7687511xDjvScWjqaf; Fri, 15 Mar 2024 16:45:52 -0700 X-Received: from mout01.posteo.de (mout01.posteo.de [185.67.36.65]) by mx.groups.io with SMTP id smtpd.web10.7675.1710546345971609987 for ; Fri, 15 Mar 2024 16:45:46 -0700 X-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id D92AE240027 for ; Sat, 16 Mar 2024 00:45:43 +0100 (CET) X-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4TxLTy302Wz6tvw; Sat, 16 Mar 2024 00:45:42 +0100 (CET) From: =?UTF-8?B?TWFydmluIEjDpHVzZXI=?= Mime-Version: 1.0 (1.0) Subject: Re: [edk2-devel][PATCH v1 1/3] MdeModulePkg: ImagePropertiesRecordLib: Use SectionAlignment for CodeSize Date: Fri, 15 Mar 2024 23:45:31 +0000 Message-Id: <92E2E047-C087-4122-9938-D84025F47B7D@posteo.de> References: <58edd77a-1282-4e3a-b2c9-9d5a8dd8b1d2@linux.microsoft.com> Cc: devel@edk2.groups.io, Leif Lindholm , Ard Biesheuvel , Sami Mujawar , Taylor Beebe In-Reply-To: <58edd77a-1282-4e3a-b2c9-9d5a8dd8b1d2@linux.microsoft.com> To: Oliver Smith-Denny 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: Fri, 15 Mar 2024 16:45:46 -0700 Reply-To: devel@edk2.groups.io,mhaeuser@posteo.de List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: SA6hzS5egUnud0YwYskCIITOx7686176AA= Content-Type: multipart/signed; boundary=Apple-Mail-7C6E6A28-4D3E-4479-8464-2CC0E542B190; protocol="application/pkcs7-signature"; micalg=sha-256 Content-Transfer-Encoding: 7bit X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20240206 header.b=txUIJPLq; spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 45.79.227.220 as permitted sender) smtp.mailfrom=bounce@groups.io; dmarc=fail reason="SPF not aligned (strict), DKIM not aligned (strict)" header.from=posteo.de (policy=none) --Apple-Mail-7C6E6A28-4D3E-4479-8464-2CC0E542B190 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On 15. Mar 2024, at 23:57, Oliver Smith-Denny = wrote: >=20 > 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 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=9Cre= al data=E2=80=9D, I assumed you meant strictly the non-0 data from the file= . Same misunderstanding with SizeOfImage, so that=E2=80=99s all fine. Whew.= :) > 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. Well, not rounding to pad is somewhat superior in some scenarios. If you ro= und, 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. > 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. See first comment. > Do you mind adding your RB to v2? And certainly if you have any other > comments that is greatly appreciated. Will try to remember tomorrow. :) > Examples of the differences I see between MSVC and gcc binaries: >=20 > 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. >=20 > I dumped ReportStatusCodeRouterRuntimeDxe.efi from both using dumpbin > (from VS2022) to examine the PE headers. >=20 > MSVC selected header values: >=20 > 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 >=20 > 6 sections: .data, .pdata, .rdata, .reloc, .text, .xdata >=20 > .text section: > 0x30DF virtual size > 0x3200 size of raw data >=20 > .data section: > 0x130 virtual size > 0x200 size of raw data >=20 >=20 > GCC ElfConverted selected header values: >=20 > 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 >=20 > 3 sections: .data, .text, .reloc >=20 > .text section: > 0x4000 virtual size > 0x4000 size of raw data >=20 > .data section: > 0x1000 virtual size > 0x1000 size of raw data >=20 > 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). I don=E2=80=99t think it really matters, but it wouldn=E2=80=99t hurt eithe= r. Both kinds of binaries are in the wild, so you cannot really leverage an= y of the choices=E2=80=99 advantages either way. Adjusting to MSVC=E2=80=99= s behaviour would be right though, as you can at least properly distinguish= between padding and 0-data with new binaries. > In practice this will tend to work as is, since we > are using SizeOfImage to allocate with, but as you > have pointed out there are so many edge cases that > having a difference here makes me worried we would > see something weird with only binaries built by one toolchain. There is plenty of room for that as-is, including that MSVC emits .rdata (a= nd others), but GCC does not, and there is a super awkward heuristic in Dxe= Core to determine section permissions rather than using the PE values at fa= ce value - R-- is literally not respected. Also there had been issues with = NASM sections, because PE needs .rdata, but ELF needs .rodata naming there. > I am curious to hear your thoughts though. This is > very easy to reproduce, build any UEFI binary with > MSVC and GCC and compare the headers. Yes, sorry for the confusion, this all looks as expected. Best regards, Marvin >=20 > 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 (#116820): https://edk2.groups.io/g/devel/message/116820 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- --Apple-Mail-7C6E6A28-4D3E-4479-8464-2CC0E542B190 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCBa8w ggWrMIIDk6ADAgECAhA9P4A/jnLYWuD7Jx/CcP6cMA0GCSqGSIb3DQEBCwUAMIGBMQswCQYDVQQG EwJJVDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRybzEXMBUGA1UE CgwOQWN0YWxpcyBTLnAuQS4xLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1dGhlbnRpY2F0aW9u IENBIEczMB4XDTIzMTExMzE5MDczM1oXDTI0MTExMzE5MDczMlowHTEbMBkGA1UEAwwSbWhhZXVz ZXJAcG9zdGVvLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsPgyylO/hLZ+hUjY e9p5SD7JY/LtVfmjwmirJYi05zfgjRxyjCsrcmELQTz5J/X3I7Jmjz0T5pjIeGqurnKG9ujmOW+E Gba+HmXLG9raJW5ITYoJkulkUcSD/175NPKUa8euwQl0pxzoydsEwG5/c26AejkJWwV7d6JctEUZ TLF8Sn66yKDW2amANdIkq1c2N5tmeqwrnuelqS9TqddhnVwckNi1k9bLRbh2cDsNI1CPuYy5a3PB ACqQp2CO3x0dVgq5MpZlUEGY5ZJq78pEWeDqQxA/ODoZChqVQ8I/8ajlEm0oTZoYQhrSWGSqtbEG FKGnXClARLYPnRVllRb1KQIDAQABo4IBgDCCAXwwDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBS+ l6mqhL+AvxBTfQky+eEuMhvPdzB+BggrBgEFBQcBAQRyMHAwOwYIKwYBBQUHMAKGL2h0dHA6Ly9j YWNlcnQuYWN0YWxpcy5pdC9jZXJ0cy9hY3RhbGlzLWF1dGNsaWczMDEGCCsGAQUFBzABhiVodHRw Oi8vb2NzcDA5LmFjdGFsaXMuaXQvVkEvQVVUSENMLUczMB0GA1UdEQQWMBSBEm1oYWV1c2VyQHBv c3Rlby5kZTAUBgNVHSAEDTALMAkGB2eBDAEFAQEwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF BwMEMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwwOS5hY3RhbGlzLml0L1JlcG9zaXRvcnkv QVVUSENMLUczL2dldExhc3RDUkwwHQYDVR0OBBYEFBFU4hxIknfzPKlxOiVK4CyW+z3YMA4GA1Ud DwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOCAgEAqowroDg2qqNAcUQ1O04P1PMklKGLZi7KjQzt 1sNWAMOXJeGfudilIZVG7hBn5iSO0vcuuqSRolNxC26hWPcBW+SbfNeaN+VZAJWDAOdso5Q+sxki 7+k+QmzZYXHrDrpWFSQcLPUhl20iUtqsJRNHexNbWh8ZVGjMh9HiJM5uoJlsV5wqZlotyC6qK+8w MPWTbWTHg+WRJqDv1pOelmuEK2afJg5qh2NQFfk3O6ewOKyZ3roEkD3xs8S9+xU0y9aAFIO+3dzT gjJJn6koJiN+fxviIn0lkTRSoSyIx74C4yg/gTjW3WJNCIOWUoD4ak5yewxWZKsqGxRleEZq4rCO mqU0HJMyYULde8wjcK7r43K1m/opjlSke6QYwFab/YSdEj83c0eGqDYyD/Bs3uXynw7nQm5kduYn jCNavsgrzXVacVt2KljiPaMUD73l0UNT6HUjWcUs0HDw6s0uKKc+AedWek003wl/O9U/drRzgKZo N3aTgYhidU0ayD8kXafgPfIV6kgzHI0PJ4AEa4vKzNQhaGWqd4p0H0Xd9L1IicCljubqird+GLzQ ruk8WmCZyKXKed2sn8NRjlLIoLgcGcuRu0bm0ADchMdlr9E+VM6V6gmRdlLlQZ+KSLCYBl2Ke/Y+ G4zv6+/Y8mabyDIIzLTg0dpU2ziDlq3kBA+FxMMxggOFMIIDgQIBATCBljCBgTELMAkGA1UEBhMC SVQxEDAOBgNVBAgMB0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0cm8xFzAVBgNVBAoM DkFjdGFsaXMgUy5wLkEuMSwwKgYDVQQDDCNBY3RhbGlzIENsaWVudCBBdXRoZW50aWNhdGlvbiBD QSBHMwIQPT+AP45y2Frg+ycfwnD+nDANBglghkgBZQMEAgEFAKCCAb8wGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjQwMzE1MjM0NTMxWjAvBgkqhkiG9w0BCQQxIgQg 13i04YyMegqpZL1FGH5c6v2rE9twoqgqfC0DGy8xjUEwgacGCSsGAQQBgjcQBDGBmTCBljCBgTEL MAkGA1UEBhMCSVQxEDAOBgNVBAgMB0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0cm8x FzAVBgNVBAoMDkFjdGFsaXMgUy5wLkEuMSwwKgYDVQQDDCNBY3RhbGlzIENsaWVudCBBdXRoZW50 aWNhdGlvbiBDQSBHMwIQPT+AP45y2Frg+ycfwnD+nDCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgYEx CzAJBgNVBAYTAklUMRAwDgYDVQQIDAdCZXJnYW1vMRkwFwYDVQQHDBBQb250ZSBTYW4gUGlldHJv MRcwFQYDVQQKDA5BY3RhbGlzIFMucC5BLjEsMCoGA1UEAwwjQWN0YWxpcyBDbGllbnQgQXV0aGVu dGljYXRpb24gQ0EgRzMCED0/gD+Octha4PsnH8Jw/pwwDQYJKoZIhvcNAQELBQAEggEAQLb27Rxx OWZFmI3CadkJ9FRddLqDTr349mZQGRXWW9sf2sT6y2pmOJym8YubR22XAyuAmAbeRftn9r0pbjBN I2cFs43sT5qPmEX2DVCElbGHyGYIUABoKe7YWBI6ojqJbwebQktvp1+U6oazMX5L5pk36m8LB9Ef z2ahCJK0FIVOWPasyV7emOTum5RmSTRpg4c+wGRwcKFeabD1vUyxuxsTVG8lKAuWzy1ko1FxlLde N7GSK7yPv0TvXzxAbbXUhtLGjv6zI8mqa4d5NGaVDi/VlKy4/r/8XyMPhvHDO2KQq8B+1e9mW1FT fibCMsH0zaSXSQZoLca78rrI3PTmKwAAAAAAAA== --Apple-Mail-7C6E6A28-4D3E-4479-8464-2CC0E542B190--