Re: [edk2-devel] [PATCH v2 1/3] MdeModulePkg: ImagePropertiesRecordLib: Use SectionAlignment for CodeSize

Reviewed-by: Marvin Häuser On Mon, Mar 11, 2024 at 02:29 PM, Oliver Smith-Denny wrote: > > When an ImageRecord is stored by ImagePropertiesRecordLib, it reports the > CodeSegmentSize as the SizeOfRawData from the image. However, the image > as loaded into memor

Re: [edk2-devel][PATCH v1 1/3] MdeModulePkg: ImagePropertiesRecordLib: Use SectionAlignment for CodeSize

> 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

Re: [edk2-devel][PATCH v1 1/3] MdeModulePkg: ImagePropertiesRecordLib: Use SectionAlignment for CodeSize

> On 14. Mar 2024, at 15:45, Oliver Smith-Denny > wrote: > > This does not appear to be the case with MSVC built binaries. I am > seeing that VirtualSize is the size of the data-initialized part of the > section. What? :( So you are saying modern MSVC generates PEs that either have

Re: [edk2-devel][PATCH v1 1/3] MdeModulePkg: ImagePropertiesRecordLib: Use SectionAlignment for CodeSize

Good day everyone, Sorry for interjecting, but I’d like to avoid premature changes to PE code that would only make the current mess even worse. > On 4. Mar 2024, at 20:24, Oliver Smith-Denny wrote: > > I relooked at the spec, you are correct, SizeOfRawData is aligned to > the FileAlignment.

Re: [edk2-devel] [PATCH] Ext4Pkg: Fix CRC16 checksumming on block groups

Reviewed-by: Marvin Häuser > On Dec 3, 2023, at 23:41, Pedro Falcato wrote: > > Old filesystems (around 2008 and older) do not use CRC32c > but rather CRC16-ANSI. Previously, the CalculateCrc16Ansi function was > broken and gave us wrong checksums. Adapt to the new interface.

Re: [edk2-devel] efi and ext4 and case sensitive file names

> On Sep 29, 2023, at 12:58, Michael Brown wrote: > > On 29/09/2023 10:47, Marvin Häuser wrote: >> Maybe when Linux starts adhering the spec for file names (the spec clearly >> defines e.g. BOOTx64.EFI, while at least some distros/images use >> bootx64.efi), this

Re: [edk2-devel] efi and ext4 and case sensitive file names

> On Sep 28, 2023, at 19:57, Pedro Falcato wrote: > > On Wed, Sep 27, 2023 at 1:09 PM Gerd Hoffmann wrote: >> >> Hi, >> >> I've noticed that the edk2 ext4 driver does case-insensitive filename >> matching. I know the fat filesystem is case-insensitive, and the uefi >> spec describing the

Re: [edk2-devel] [RFC PATCH 08/11] MdeModulePkg/DxeIpl: Relocate and remap XIP capable DXE drivers

  From: devel@edk2.groups.io On Behalf Of Marvin Häuser Sent: Tuesday, May 30, 2023 6:25 PM To: Ard Biesheuvel Cc: edk2-devel-groups-io ; Ni, Ray Subject: Re: [edk2-devel] [RFC PATCH 08/11] MdeModulePkg/DxeIpl: Relocate and remap XIP capable DXE drivers     On 30. May 2023, at 12:02, Ard

Re: [edk2-devel] [RFC PATCH 08/11] MdeModulePkg/DxeIpl: Relocate and remap XIP capable DXE drivers

> On 30. May 2023, at 12:02, Ard Biesheuvel wrote: > > On Tue, 30 May 2023 at 11:53, Marvin Häuser <mailto:mhaeu...@posteo.de>> wrote: >> >> >> >> On 30. May 2023, at 11:48, Ard Biesheuvel wrote: >> >> On Tue, 30 May 2023 at 11:47,

Re: [edk2-devel] [RFC PATCH 08/11] MdeModulePkg/DxeIpl: Relocate and remap XIP capable DXE drivers

> On 30. May 2023, at 11:48, Ard Biesheuvel wrote: > > On Tue, 30 May 2023 at 11:47, Ard Biesheuvel <mailto:a...@kernel.org>> wrote: >> >> On Tue, 30 May 2023 at 11:42, Marvin Häuser wrote: >>> >>> >>>> On 30. May 2023, at 11:38,

Re: [edk2-devel] [RFC PATCH 08/11] MdeModulePkg/DxeIpl: Relocate and remap XIP capable DXE drivers

> On 30. May 2023, at 11:38, Ard Biesheuvel wrote: > > On Tue, 30 May 2023 at 11:07, Marvin Häuser wrote: >> >> Hi Ard, >> >> Native PE toolchains *generally* also generate XIP images (/ALIGN = >> /FILEALIGN, but with 32 Byte rather than

Re: [edk2-devel] [RFC PATCH 08/11] MdeModulePkg/DxeIpl: Relocate and remap XIP capable DXE drivers

> On 30. May 2023, at 11:06, Marvin Häuser wrote: > > Hi Ard, > > Native PE toolchains *generally* also generate XIP images (/ALIGN = > /FILEALIGN, but with 32 Byte rather than 64 Byte alignment compared to GCC49+ > / CLANGDWARF) [1]. However, because they are underali

Re: [edk2-devel] [RFC PATCH 08/11] MdeModulePkg/DxeIpl: Relocate and remap XIP capable DXE drivers

Hi Ard, Native PE toolchains *generally* also generate XIP images (/ALIGN = /FILEALIGN, but with 32 Byte rather than 64 Byte alignment compared to GCC49+ / CLANGDWARF) [1]. However, because they are underaligned by default (even for RT images that run in an OS context and MM drivers...

Re: [edk2-devel] [PATCH v2 1/1] MdePkg/Base.h: Simply alignment expressions

> On 16. May 2023, at 09:18, Marvin Häuser wrote: > > > >> On 16. May 2023, at 04:22, Pedro Falcato wrote: >> >> On Tue, May 16, 2023 at 2:46 AM gaoliming via groups.io >> wrote: >>> >>> Pedro: >>> >>>> -邮件

Re: [edk2-devel] [PATCH v3 1/1] MdePkg/Base.h: Simplify alignment expressions

and > clang compilers were already able to see through things and optimize > them into optimal instruction sequences, in the ALIGN_VALUE_ADDEND case. > > Cc: Michael D Kinney > Cc: Liming Gao > Cc: Zhiguang Liu > Cc: Marvin Häuser > Signed-off-by: Pedro Falcato > --- &g

Re: [edk2-devel] [PATCH v2 1/1] MdePkg/Base.h: Simply alignment expressions

23:15 >>> 收件人: devel@edk2.groups.io >>> 抄送: Pedro Falcato ; Michael D Kinney >>> ; Liming Gao ; >>> Zhiguang Liu ; Marvin Häuser >>> >>> 主题: [edk2-devel] [PATCH v2 1/1] MdePkg/Base.h: Simply alignment >>> expressions >>> >>>

Re: [edk2-devel] [PATCH 1/1] MdePkg/Base.h: Simply alignment expressions

Well, I explicitly added this macro as a prerequisite to code used in our new PE library (remember this patch was initially sent in 2021). We still require it downstream, but obviously upstream is not interested in the related contributions that were to follow at the time. Gerd picked it up

Re: [edk2-devel] [PATCH v3 1/2] Ext4Pkg: Improve extent node validation on the number of entries

Reviewed-by: Marvin Häuser > On 9. May 2023, at 17:49, Pedro Falcato wrote: > > Improve the extent tree node validation by validating the number of > entries the node advertises against the theoretical max (derived from > the size of on-disk structs and the block size (or i_

Re: [edk2-devel] [PATCH v2 1/2] Ext4Pkg: Improve extent node validation on the number of entries

data, if inline > extents). > > Previously, we did not validate the number of entries. This could be > exploited for out-of-bounds reads and crashes. > > Cc: Marvin Häuser > Fixes: d9ceedca6c8f ("Ext4Pkg: Add Ext4Dxe driver.") > Reported-by: Savva Mitrofanov > Sign

Re: [edk2-devel] [PATCH 2/2] Ext4Pkg: Advertise CSUM_SEED as supported

Reviewed-by: Marvin Häuser > On 9. May 2023, at 02:42, Pedro Falcato wrote: > > We had added support for CSUM_SEED but accidentally forgot to advertise > it in gSupportedIncompatFeat. This made it (erroneously) impossible to > mount CSUM_SEED filesystems. > > Detected b

Re: [edk2-devel] [PATCH 1/2] Ext4Pkg: Improve extent node validation on the number of entries

). > > Previously, we did not validate the number of entries. This could be > exploited for out-of-bounds reads and crashes. > > Cc: Marvin Häuser > Fixes: d9ceedca6c8f ("Ext4Pkg: Add Ext4Dxe driver.") > Reported-by: Savva Mitrofanov > Signed-off-by: Pedro Falc

Re: [edk2-devel] [PATCH v5 02/10] MdePkg: don't set visibility to hidden

> On 21. Apr 2023, at 09:21, Ard Biesheuvel wrote: > > On Fri, 21 Apr 2023 at 08:49, Gerd Hoffmann wrote: >> >>> On Fri, Apr 21, 2023 at 06:01:11AM +, Marvin Häuser wrote: >>> >>>> On 21. Apr 2023, at 06:45, Gerd Hoffmann wrote: >>

Re: [edk2-devel] [PATCH v5 02/10] MdePkg: don't set visibility to hidden

> On 21. Apr 2023, at 08:49, Gerd Hoffmann wrote: > > On Fri, Apr 21, 2023 at 06:01:11AM +0000, Marvin Häuser wrote: >> >>>> On 21. Apr 2023, at 06:45, Gerd Hoffmann wrote: >>> >>> Not needed any more on modern toolchains, they are better

Re: [edk2-devel] [PATCH v5 02/10] MdePkg: don't set visibility to hidden

> On 21. Apr 2023, at 06:45, Gerd Hoffmann wrote: > > Not needed any more on modern toolchains, they are better > in not creating a GOT without this trick. Hi Gerd, Thanks! Just out of interest, how did you test this and what were the results? Best regards, Marvin > > Signed-off-by: Gerd

[edk2-devel] [PATCH v3 1/2] ArmPkg/AsmMacroIoLibV8: Introduce ASM_FUNC_ALIGN()

constraint right before the function label. Signed-off-by: Marvin Häuser Cc: Leif Lindholm Cc: Ard Biesheuvel Cc: Sami Mujawar Cc: Vitaly Cheptsov --- ArmPkg/Include/AsmMacroIoLibV8.h | 11 +++ 1 file changed, 11 insertions(+) diff --git a/ArmPkg/Include/AsmMacroIoLibV8.h b/ArmPkg

[edk2-devel] [PATCH v3 2/2] ArmPkg/ArmMmuLib: Fix ArmReplaceLiveTranslationEntry() alignment

a compilation error. Reviewed-by: Leif Lindholm Signed-off-by: Marvin Häuser Cc: Leif Lindholm Cc: Ard Biesheuvel Cc: Sami Mujawar Cc: Vitaly Cheptsov --- .../ArmMmuLib/AArch64/ArmMmuLibReplaceEntry.S | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git

Re: [edk2-devel] [PATCH 1/2] ArmPkg/AsmMacroIoLibV8: Introduce ASM_FUNC_ALIGN()

On 19. Apr 2023, at 23:55, Ard Biesheuvel wrote:On Wed, 19 Apr 2023 at 22:10, Marvin Häuser wrote:On 19. Apr 2023, at 21:48, Ard Biesheuvel wrote:The issue is likely caused by-Wl,--defsym=PECOFF_HEADER_SIZE=0Why are you setting that? It breaks the ELF to PE conversion.Where?It would, but you

Re: [edk2-devel] [PATCH 1/2] ArmPkg/AsmMacroIoLibV8: Introduce ASM_FUNC_ALIGN()

> On 19. Apr 2023, at 22:10, Marvin Häuser wrote: > >  >> On 19. Apr 2023, at 21:48, Ard Biesheuvel wrote: >> >> The issue is likely caused by >> >> -Wl,--defsym=PECOFF_HEADER_SIZE=0 >> >> Why are you setting that? It breaks the

Re: [edk2-devel] [PATCH 1/2] ArmPkg/AsmMacroIoLibV8: Introduce ASM_FUNC_ALIGN()

> On 19. Apr 2023, at 21:48, Ard Biesheuvel wrote: > > The issue is likely caused by > > -Wl,--defsym=PECOFF_HEADER_SIZE=0 > > Why are you setting that? It breaks the ELF to PE conversion. Where? -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group.

Re: [edk2-devel] [PATCH 1/2] ArmPkg/AsmMacroIoLibV8: Introduce ASM_FUNC_ALIGN()

> On 19. Apr 2023, at 20:26, Ard Biesheuvel wrote: > > On Wed, 19 Apr 2023 at 20:25, Marvin Häuser wrote: >> >> >> On 19. Apr 2023, at 20:03, Ard Biesheuvel wrote: >> >> Your branch seems to be missing 16e0969ef775b898ac700f3261d76030b8ab9ef0 >>

Re: [edk2-devel] [PATCH 1/2] ArmPkg/AsmMacroIoLibV8: Introduce ASM_FUNC_ALIGN()

> On 19. Apr 2023, at 20:03, Ard Biesheuvel wrote: > > Your branch seems to be missing 16e0969ef775b898ac700f3261d76030b8ab9ef0 > > "ArmVirtPkg/ArmVirtQemu: Use PEI flavor of ArmMmuLib for all PEIMs" That's correct (because that commit is after the last commit I managed to reproduce the

Re: [edk2-devel] [PATCH 1/2] ArmPkg/AsmMacroIoLibV8: Introduce ASM_FUNC_ALIGN()

> On 19. Apr 2023, at 19:40, Ard Biesheuvel wrote: > > On Wed, 19 Apr 2023 at 19:14, Marvin Häuser <mailto:mhaeu...@posteo.de>> wrote: >> >> Hi all, >> >> While testing Ard's suggestion for V3, I noticed I got a broken FD where >> ArmRepla

Re: [edk2-devel] [PATCH v4 01/10] BaseTools: add BASETOOLS define

> On 18. Apr 2023, at 15:20, Gerd Hoffmann wrote: > > On Tue, Apr 18, 2023 at 01:59:43PM +0200, Ard Biesheuvel wrote: >> On Tue, 18 Apr 2023 at 13:52, Gerd Hoffmann wrote: >>> >>> Seems to work fine on fedora 37, even without adding --relax, maybe this >>> is enabled by default (there is a

Re: [edk2-devel] [PATCH 1/2] ArmPkg/AsmMacroIoLibV8: Introduce ASM_FUNC_ALIGN()

> On 18. Apr 2023, at 10:10, Ard Biesheuvel wrote: > > On Tue, 18 Apr 2023 at 08:40, Marvin Häuser wrote: >> >> >>> On 17. Apr 2023, at 23:18, Ard Biesheuvel wrote: >>> >>> Agree with all of this. >>> >>> And thanks for

Re: [edk2-devel] [PATCH 1/2] ArmPkg/AsmMacroIoLibV8: Introduce ASM_FUNC_ALIGN()

> On 17. Apr 2023, at 23:18, Ard Biesheuvel wrote: > > Agree with all of this. > > And thanks for tracking this down - must not have been fun :-) No worries - it wasn’t. :) It was mere luck Vitaly discovered early it was an issue that triggered based on the binary layout rather than a bug

[edk2-devel] [PATCH v2 1/2] ArmPkg/AsmMacroIoLibV8: Introduce ASM_FUNC_ALIGN()

constraint right before the function label. Signed-off-by: Marvin Häuser Cc: Leif Lindholm Cc: Ard Biesheuvel Cc: Sami Mujawar Cc: Vitaly Cheptsov --- ArmPkg/Include/AsmMacroIoLibV8.h | 11 +++ 1 file changed, 11 insertions(+) diff --git a/ArmPkg/Include/AsmMacroIoLibV8.h b/ArmPkg

[edk2-devel] [PATCH v2 2/2] ArmPkg/ArmMmuLib: Fix ArmReplaceLiveTranslationEntry() alignment

invocation of .balign with the ASM_FUNC_ALIGN() macro, which guarantees the alignment constraint is applied correctly. Reviewed-by: Leif Lindholm Signed-off-by: Marvin Häuser Cc: Leif Lindholm Cc: Ard Biesheuvel Cc: Sami Mujawar Cc: Vitaly Cheptsov --- ArmPkg/Library/ArmMmuLib/AArch64

[edk2-devel] [PATCH 2/2] ArmPkg/ArmMmuLib: Fix ArmReplaceLiveTranslationEntry() alignment

invocation of .balign with the ASM_FUNC_ALIGN() macro, which guarantees the alignment constraint is applied correctly. Signed-off-by: Marvin Häuser Cc: Leif Lindholm Cc: Ard Biesheuvel Cc: Sami Mujawar Cc: Vitaly Cheptsov --- ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibReplaceEntry.S | 9

[edk2-devel] [PATCH 1/2] ArmPkg/AsmMacroIoLibV8: Introduce ASM_FUNC_ALIGN()

constraint right before the function label. Signed-off-by: Marvin Häuser Cc: Leif Lindholm Cc: Ard Biesheuvel Cc: Sami Mujawar Cc: Vitaly Cheptsov --- ArmPkg/Include/AsmMacroIoLibV8.h | 22 ++ 1 file changed, 18 insertions(+), 4 deletions(-) diff --git a/ArmPkg/Include

Re: [edk2-devel] Role of DLINK2_FLAGS and link-time option consistency

> On 7. Apr 2023, at 14:00, Ard Biesheuvel wrote: > > (cc Ray) > > On Fri, 7 Apr 2023 at 13:05, Marvin Häuser wrote: >> >> >> On 7. Apr 2023, at 13:02, Ard Biesheuvel wrote: >> >> IIRC DLINK2_FLAGS is mainly being used (in the GCC case) f

Re: [edk2-devel] [PATCH v4 01/10] BaseTools: add BASETOOLS define

> On 14. Apr 2023, at 16:57, Ard Biesheuvel wrote: > > On Fri, 14 Apr 2023 at 16:37, Gerd Hoffmann wrote: >> >>> On Fri, Apr 14, 2023 at 12:29:21PM +, Marvin Häuser wrote: >>> Hi Gerd, >>> >>> Thanks for your effort! >>>

Re: [edk2-devel] [PATCH v4 01/10] BaseTools: add BASETOOLS define

> On 14. Apr 2023, at 16:37, Gerd Hoffmann wrote: > > On Fri, Apr 14, 2023 at 12:29:21PM +0000, Marvin Häuser wrote: >> Hi Gerd, >> >> Thanks for your effort! >> >> Sorry, but I *really* dislike this “BASETOOLS” notion. There might be >> ex

Re: [edk2-devel] [PATCH v4 01/10] BaseTools: add BASETOOLS define

Hi Gerd, Thanks for your effort! Sorry, but I *really* dislike this “BASETOOLS” notion. There might be external tools that also want to use the header (like we do with AUDK) and also edk2 supports host-based unit tests. Imo the macro name should be generic, like “HOST_OS” or “USERLAND” or

[edk2-devel] [RFC PATCH] Fix ArmReplaceLiveTranslationEntry alignment

Good day everyone, Sorry, but due to time constraints, I cannot immediately provide a proper patch. Would you mind checking this commit and commenting on whether it looks about right, so I can submit a proper patch for review some time this or next week?

Re: [edk2-devel] Role of DLINK2_FLAGS and link-time option consistency

> On 7. Apr 2023, at 13:02, Ard Biesheuvel wrote: > > IIRC DLINK2_FLAGS is mainly being used (in the GCC case) for passing > options that need to come after previous occurrences of the same > option with a different value, in order for the DLINK2 one to take > precedence. Thanks for the quick

[edk2-devel] Role of DLINK2_FLAGS and link-time option consistency

Good day everyone, I've been asked to check the following patch: https://edk2.groups.io/g/devel/message/102168 One thing I noticed was that -no-pie is added to DLINK2_FLAGS, not DLINK_FLAGS. For MSVC toolchains, DLINK2_FLAGS is used for a separate linker step [1] introduced by [2], which

Re: [edk2-devel] [PATCH v3 0/4] Enable BTI support in memory attributes table

> On 4. Apr 2023, at 18:29, Ard Biesheuvel wrote: > On Tue, 4 Apr 2023 at 18:19, Marvin Häuser wrote: >> >> FWIW, Reviewed-by: Marvin Häuser >> >> An off-topic remark, but I find it ominous that when adding a hack like the >> DllCharacteristicsEx debu

Re: [edk2-devel] [PATCH v3 0/4] Enable BTI support in memory attributes table

FWIW, Reviewed-by: Marvin Häuser An off-topic remark, but I find it ominous that when adding a hack like the DllCharacteristicsEx debug entry, the opportunity is not used to turn it into something that can be expanded in the future without introducing yet another hack like this (I know 31

Re: [edk2-devel] Linker scripts use of "-z common-page-size=0x20" etc.

> On 4. Apr 2023, at 16:03, Ard Biesheuvel wrote: > > On Tue, 4 Apr 2023 at 13:10, Rebecca Cran > wrote: >> >> On 4/4/23 1:22 AM, Ard Biesheuvel wrote: >>> On Mon, 3 Apr 2023 at 22:33, Rebecca Cran >> > wrote: As part of my work on the

Re: [edk2-devel] [PATCH v4 0/6] UefiCpuPkg, OvmfPkg: Simplify CpuExceptionHandlerLib

FWIW, Reviewed-by: Marvin Häuser > On 3. Apr 2023, at 16:29, Ard Biesheuvel wrote: > > We have a special version of CpuExceptionHandlerLib for XCODE5, whose > linker (LLD) does not permit absolute symbol references in read-only > sections. > > Instead of fixing this

Re: [edk2-devel] Linker scripts use of "-z common-page-size=0x20" etc.

On 4. Apr 2023, at 09:23, Ard Biesheuvel wrote:On Mon, 3 Apr 2023 at 22:33, Rebecca Cran wrote:As part of my work on the toolchain definitions, I've come across asituation where ld.lld fails to align sections correctly, due to itbeing invoked via clang with the '-n' option, which causes GenFw

Re: [edk2-devel] Linker scripts use of "-z common-page-size=0x20" etc.

> On 3. Apr 2023, at 22:33, Rebecca Cran wrote: > > As part of my work on the toolchain definitions, I've come across a > situation where ld.lld fails to align sections correctly, due to it being > invoked via clang with the '-n' option, which causes GenFw to fail with > "Section address

Re: [edk2-devel] [RFT PATCH v2 1/6] BaseTools/tools_def XCODE: Link X64 with -read_only_relocs suppress

> On 31. Mar 2023, at 16:58, Rebecca Cran wrote: > > On 3/31/23 2:29 AM, Marvin Häuser wrote: >> I agree if there’s an actual plan on doing that. We depend on XCODE5 >> downstream, but I think it would literally be easier for us if the upstream >> version was dr

Re: [edk2-devel] [PATCH 2/3] BaseTools/Conf/tools_def: Fix CLANGDWARF_IA32_X64

> On 31. Mar 2023, at 16:41, Ni, Ray wrote: > > Why ELF header overflows into .text section? That's a good question, isn't it? :) >From what I can see, these binaries don't pass post-processing like GenFw or >such. GCC (and I think thus CLANGDWARF?) gets an extra objcopy step as part of

Re: [edk2-devel] [RFT PATCH v3 0/5] UefiCpuPkg, OvmfPkg: Simplify CpuExceptionHandlerLib

> On 31. Mar 2023, at 16:39, Ni, Ray wrote: > > > >> -Original Message- >> From: devel@edk2.groups.io On Behalf Of Marvin >> Häuser >> Sent: Friday, March 31, 2023 7:10 PM >> To: Ard Biesheuvel >> Cc: Ni, Ray ; devel@edk2.gro

Re: [edk2-devel] [RFT PATCH v3 0/5] UefiCpuPkg, OvmfPkg: Simplify CpuExceptionHandlerLib

> On 31. Mar 2023, at 13:03, Ard Biesheuvel wrote: > > On Fri, 31 Mar 2023 at 12:41, Marvin Häuser wrote: >> >> Hi Ray, >> >>>> On 31. Mar 2023, at 12:09, Ni, Ray wrote: >>> >>> Ard, >>> What does "-read_only_reloc

Re: [edk2-devel] [RFT PATCH v2 1/6] BaseTools/tools_def XCODE: Link X64 with -read_only_relocs suppress

Hi Gerd, > On 31. Mar 2023, at 12:53, Gerd Hoffmann wrote: > >  Hi, > >>> However, those issues might have been fixed and it’s not impossible >>> Vitaly will give it another try eventually. In any case, I think our >>> downstream variant of XCODE5 doesn’t require any level of special >>>

Re: [edk2-devel] [PATCH 2/3] BaseTools/Conf/tools_def: Fix CLANGDWARF_IA32_X64

Liming, Platform maintainers can decide whether or not they want to combat *binary corruption*? Excuse me, but what the bloody hell? This needs a root cause analysis for which part of the stack silently borks us and not an “oh, if something fails, well, copy and paste this workaround… maybe”.

Re: [edk2-devel] [RFT PATCH v3 0/5] UefiCpuPkg, OvmfPkg: Simplify CpuExceptionHandlerLib

; >> -Original Message- >> From: devel@edk2.groups.io On Behalf Of Ard >> Biesheuvel >> Sent: Friday, March 31, 2023 5:15 PM >> To: devel@edk2.groups.io >> Cc: Ard Biesheuvel ; Ni, Ray ; Andrew >> Fish ; Kinney, Michael D ; >> Liu, Zhiguang ; R

Re: [edk2-devel] [RFT PATCH v2 1/6] BaseTools/tools_def XCODE: Link X64 with -read_only_relocs suppress

> On 31. Mar 2023, at 11:36, Ard Biesheuvel wrote: > > On Fri, 31 Mar 2023 at 11:27, Marvin Häuser wrote: >> >> >>>> On 31. Mar 2023, at 10:59, Ard Biesheuvel wrote: >>> >>> On Fri, 31 Mar 2023 at 10:29, Marvin Häuser wrote: >>&

Re: [edk2-devel] [RFT PATCH v2 1/6] BaseTools/tools_def XCODE: Link X64 with -read_only_relocs suppress

> On 31. Mar 2023, at 10:59, Ard Biesheuvel wrote: > > On Fri, 31 Mar 2023 at 10:29, Marvin Häuser wrote: >> >> >>>> On 31. Mar 2023, at 09:39, Ard Biesheuvel wrote: >>> Hi Marvin, >>> >>> Thanks for the context. >

Re: [edk2-devel] [RFT PATCH v2 1/6] BaseTools/tools_def XCODE: Link X64 with -read_only_relocs suppress

> On 31. Mar 2023, at 09:39, Ard Biesheuvel wrote: > Hi Marvin, > > Thanks for the context. > > > On Thu, 30 Mar 2023 at 23:54, Marvin Häuser wrote: >> >> Hi Ard, >> >> Sorry, I cannot preserve the CC list as the groups.io interface doesn

Re: [edk2-devel] [RFT PATCH v2 4/6] UefiCpuPkg/CpuExceptionHandlerLib: Remove needless runtime fixups

Hi Ray, Definitely - this is just an optimisation “while we’re at it“, nothing urgent. Best regards, Marvin > On 31. Mar 2023, at 07:09, Ni, Ray wrote: > >  > > diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/Xcode5ExceptionH= > andlerAsm.nasm

Re: [edk2-devel] [RFT PATCH v2 4/6] UefiCpuPkg/CpuExceptionHandlerLib: Remove needless runtime fixups

Hi Ard, Thanks for these important updates! On Thu, Mar 30, 2023 at 02:21 PM, Ard Biesheuvel wrote: > > Recent versions of the XCODE linker can be instructed to permit text > relocations, so we no longer have to work around this, which is > especially nice as our workaround assumes that the

Re: [edk2-devel] [RFT PATCH v2 1/6] BaseTools/tools_def XCODE: Link X64 with -read_only_relocs suppress

Hi Ard, Sorry, I cannot preserve the CC list as the groups.io interface doesn't seem to allow it. Can you please CC me on future revisions? This patch will badly corrupt binaries. I cannot cite a source right now (if you want me to, please remind me in your response, so I can look it up

Re: [edk2-devel] [PATCH 1/3] BaseTools/Conf/tools_def: Fix linking using CLANGDWARF_IA32

Hi Lean,I don’t think individual patches from a series are merged generally. Your 2/3 has open concerns from both Liming and myself.Best regards,MarvinOn 30. Mar 2023, at 09:31, Lean Sheng Tan wrote:HI Liming,If no further concern, would you mind to help get this patch merged?Thanks!Best

Re: [edk2-devel] [PATCH 2/3] BaseTools/Conf/tools_def: Fix CLANGDWARF_IA32_X64

Hi all, > On 28. Mar 2023, at 07:38, gaoliming wrote: > Patrick: > I prefer to override this option in DSC instead of the change in > tools_def.txt. A DSC override to fix *binary corruption* of an unknown cause? It is ridiculous this can even happen silently, even though it’s unclear which

Re: [edk2-devel] [PATCH v2 14/17] BaseTools/GenFw: Add DllCharacteristicsEx field to debug data

Hi Ard, > On 27. Mar 2023, at 13:01, Ard Biesheuvel wrote: > > The PE/COFF spec describes an additional DllCharacteristics field > implemented as a debug directory entry, which carries flags related to > which control flow integrity (CFI) features are supported by the binary. Out of mere

Re: [edk2-devel] [PATCH 3/5] MdePkg/Base.h: Introduce various alignment-related macros

the current description.They do not, the current description explicitly says “*next* alignment boundary”.Best regards,Marvin   Mike   From: Marvin Häuser Sent: Tuesday, March 21, 2023 3:00 PM To: Kinney, Michael D Cc: Gerd Hoffmann ; devel@edk2.groups.io; Ard Biesheuvel ; Wang, Jian J ; Yao

Re: [edk2-devel] [PATCH 3/5] MdePkg/Base.h: Introduce various alignment-related macros

rsday, March 2, 2023 10:51 PM >> To: devel@edk2.groups.io <mailto:devel@edk2.groups.io> >> Cc: Ard Biesheuvel > <mailto:ardb+tianoc...@kernel.org>>; Gerd Hoffmann > <mailto:kra...@redhat.com>>; Wang, Jian J > <mailto:jian.j.w...@intel.com>>

Re: [edk2-devel] [PATCH v2] IntelFsp2Pkg: Fix NASM X64 build warnings.

register renaming optimisations: https://stackoverflow.com/a/45660140 Best regards, Marvin > On 19. Mar 2023, at 10:07, S, Ashraf Ali wrote: >  > Hi., > > Nope, it will not clear the upper 32bit right. > > > From: Marvin Häuser > Sent: Sunday, March 19, 2023

Re: [edk2-devel] [PATCH v2] IntelFsp2Pkg: Fix NASM X64 build warnings.

Hi Ashraf, ”mov eax, eax” does clear the high 32 Bits of rax. Best regards, Marvin -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#101366): https://edk2.groups.io/g/devel/message/101366 Mute This Topic:

Re: [edk2-devel] [PATCH v2] IntelFsp2Pkg: Fix NASM X64 build warnings.

Hi Chasel, If you want to improve the ASM further, maybe opt for “test reg, reg” over “cmp reg, 0”? Best regards, Marvin -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#101365): https://edk2.groups.io/g/devel/message/101365 Mute This

Re: [edk2-devel] [PATCH 1/3] BaseTools/Conf/tools_def: Fix linking using CLANGDWARF_IA32

Which error precisely? X64 PIE *must not* be disabled, as it’s used to enforce RIP-relative addressing where possible and has been for many years. Meanwhile the issues with IA32 is PIE was disabled by default for most toolchains, but some enable it nowadays (and thus it must be disabled

Re: [edk2-devel] [edk2-platforms] Enable GitHub PR, protected branches, and 'push' label

> On 17. Mar 2023, at 14:44, Gerd Hoffmann wrote: > > On Fri, Mar 17, 2023 at 12:32:15PM +0000, Marvin Häuser wrote: >> Hi Rebecca and Gerd, >> >> Replying to 2 mails at once... >> >>>> On 17. Mar 2023, at 11:36, Rebecca Cran wrote: >>

Re: [edk2-devel] [edk2-platforms] Enable GitHub PR, protected branches, and 'push' label

Hi Rebecca and Gerd, Replying to 2 mails at once... > On 17. Mar 2023, at 11:36, Rebecca Cran wrote: > > I like that proposed workflow. > > I've also been wondering if we could consider choosing a different product > for patch reviews that supports our desired workflow better, such as

Re: [edk2-devel] [edk2-platforms] Enable GitHub PR, protected branches, and 'push' label

Well, in this form, it complicates our workflow and adds no value. NACK from Pedro and me till there at least is CI. Best regards, Marvin -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#101283):

Re: [edk2-devel] [PATCH 1/3] BaseTools/Conf/tools_def: Fix linking using CLANGDWARF_IA32_X64

> On 15. Mar 2023, at 23:51, Ard Biesheuvel wrote: > > On Wed, 15 Mar 2023 at 23:16, Marvin Häuser wrote: >> >> Hi, >> >> Why does the title mention X64? From what I can see, PIE is unaffected for >> X64 (and we really want it to be). >> >

Re: [edk2-devel] [edk2-platforms] Enable GitHub PR, protected branches, and 'push' label

Hi Mike, Could this be extended to allow for a full PR workflow, if the package maintainers would prefer so? We would like to utilise this for Ext4Pkg. It could be considered a trial. :) Best regards, Marvin -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this

Re: [edk2-devel] [PATCH 1/3] BaseTools/Conf/tools_def: Fix linking using CLANGDWARF_IA32_X64

Hi, Why does the title mention X64? From what I can see, PIE is unaffected for X64 (and we really want it to be). Best regards, Marvin -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#101249):

Re: [edk2-devel] [PATCH 1/1] SecurityPkg/DxeImageVerificationLib: Check result of GetEfiGlobalVariable2

> On 28. Feb 2023, at 07:12, Gerd Hoffmann wrote: > >  Hi, > >>> (a) the SecureBoot variable is not present (EFI_NOT_FOUND) according to >>>the return value, or >> >> @Maintainers Would there be any objection to drop this and skip the SB >> checks only when explicitly disabled? >>

Re: [edk2-devel] [PATCH 1/1] SecurityPkg/DxeImageVerificationLib: Check result of GetEfiGlobalVariable2

*Thanks*, Gerd! Two comments inline. > On 27. Feb 2023, at 13:55, Gerd Hoffmann wrote: > > Call gRT->GetVariable() directly to read the SecureBoot variable. It is > one byte in size so we can easily place it on the stack instead of > having GetEfiGlobalVariable2() allocate it for us, which

Re: [edk2-devel] [PATCH 1/1] Ext4Pkg: Move unicode collation initialization to Start()

> On 21. Feb 2023, at 20:25, Pedro Falcato wrote: > > Marvin, > > Do you want me to spin up a quick v2 without the > Ext4IsCollationInitialized? Just doing the check internally in > Ext4InitialiseUnicodeCollation. It'd be my preferred solution, but it's just a detail.

Re: [edk2-devel] [PATCH 1/1] Ext4Pkg: Move unicode collation initialization to Start()

]: https://edk2.groups.io/g/devel/message/100312 >> >> Cc: Ard Biesheuvel >> Cc: Marvin Häuser >> Fixes: d9ceedca6c8f ("Ext4Pkg: Add Ext4Dxe driver.") >> Signed-off-by: Pedro Falcato >> --- >> RFC-ish patch that implements one of the possibi

Re: [edk2-devel] [PATCH 1/1] Ext4Pkg: Move unicode collation initialization to Start()

> On 18. Feb 2023, at 16:14, Pedro Falcato wrote: > > Proper collation (and proper unicode handling in general) is AIUI > pretty hard and involves a lot of tables, etc. > So it makes total sense to me why one wants to "dynamically link" this > in using protocols instead of statically linking it

Re: [edk2-devel] [PATCH 1/1] Ext4Pkg: Move unicode collation initialization to Start()

> On 17. Feb 2023, at 21:14, Pedro Falcato wrote: > > @@ -169,5 +170,20 @@ Ext4StrCmpInsensitive ( > IN CHAR16 *Str2 > ) > { > + ASSERT (gUnicodeCollationInterface != NULL); > return gUnicodeCollationInterface->StriColl (gUnicodeCollationInterface, > Str1, Str2); > } Off-topic

Re: [edk2-devel] [PATCH edk2-platforms 1/4] Ext4Pkg: Use depex for unicode collation protocols

> On 17. Feb 2023, at 16:17, Ard Biesheuvel wrote: > > So the FAT driver will happily load, but then fail in an obscure > manner when being started on a controller handle, in a way that is > indistinguishable (afict) from a partition that has not FAT file > system in the first place. > > So

Re: [edk2-devel] [PATCH edk2-platforms 1/4] Ext4Pkg: Use depex for unicode collation protocols

> On 17. Feb 2023, at 15:29, Ard Biesheuvel wrote: > > On Fri, 17 Feb 2023 at 15:05, Marvin Häuser wrote: >> >> Hi Ard, >> >> Thank you! Is "1/4" a mistake or did I miss the other 3? :) > > Oops. > > It was part of s

Re: [edk2-devel] [PATCH edk2-platforms 1/4] Ext4Pkg: Use depex for unicode collation protocols

Hi Ard, Thank you! Is "1/4" a mistake or did I miss the other 3? :) Comments inline. > On 17. Feb 2023, at 12:12, Ard Biesheuvel wrote: > > The Unicode collation protocols, however, are different: loading the > driver will fail if neither of those are present. So they are not > TO_START

Re: [edk2-devel] [edk2-platforms][PATCH v4 1/1] Ext4Pkg: Fixes double-free in Ext4ReadSymlink

Reviewed-by: Marvin Häuser > On 17. Feb 2023, at 09:56, Savva Mitrofanov wrote: > > The SymlinkTmp was deallocated unconditionally, so we shouldn't free it > again on EFI_ERROR > > Cc: Marvin Häuser > Cc: Pedro Falcato > Cc: Vitaly Cheptsov > Fixes: e81432fba

Re: [edk2-devel] [RFC 07/13] MdeModulePkg/DxeCore: Permit preliminary CPU arch fallback

Sounds good to me, thanks! Best regards, Marvin > On 13. Feb 2023, at 23:07, Ard Biesheuvel wrote: > > On Mon, 13 Feb 2023 at 22:32, Marvin Häuser wrote: >> >> Without wanting to blow up your RFC with another one - I discussed this with >> various people, inclu

Re: [edk2-devel] [RFC 13/13] ArmVirtPkg/ArmVirtQemu: Enable hardware enforced W^X memory permissions

> On 13. Feb 2023, at 22:59, Ard Biesheuvel wrote: > > No, the only reason for adding -fpie here is to ensure that statically > initialized CONST pointers are emitted into .data.rel.ro and not into > .rodata, as this is under the control of the compiler. Although, > thinking about this, I

Re: [edk2-devel] [RFC 07/13] MdeModulePkg/DxeCore: Permit preliminary CPU arch fallback

Without wanting to blow up your RFC with another one - I discussed this with various people, including Bret when he was still at Project Mu, and there was a consensus among them that integrating the whole CPU arch code right into DxeCore would be a good idea. This would especially remove the

Re: [edk2-devel] [RFC 13/13] ArmVirtPkg/ArmVirtQemu: Enable hardware enforced W^X memory permissions

Hey Ard, *Praise* to you for this series. Comments inline. On Mon, Feb 13, 2023 at 07:19 AM, Ard Biesheuvel wrote: > > Enable the WXN system control bit straight out of reset when running in > EL1 with the initial ID map from flash. This setting will be inherited > by the page table code after

Re: [edk2-devel] [PATCH v4 3/5] UefiCpuPkg/PiSmmCpuDxeSmm: Consume SMM Base Hob for SmBase info

Hi Jiaxin, 1) mSmmInitialized *must* be volatile. Your current code may cause anything, from skipping waiting entirely (the loop is optimized away as the compiler considers it free from side effects) to stalling (the memory access is optimized away as the compiler considers it

Re: [edk2-devel] [PATCH v4 2/5] UefiCpuPkg/SmmBaseHob.h: Add SMM Base HOB Data

Hi Ray and Jiaxin, Quick reminder that [1] invokes undefined behaviour and [0] is not legal C, but a compiler extension. The canonical way is a flexible array member using []. Off-topic and nitpicking, but I started wondering why so many structures are packed. For UEFI, packing would only help

Re: [edk2-devel] [PATCH 3/3] MdeModulePkg/DxeCore: Unconditionally set memory protections

> On 8. Feb 2023, at 19:49, Ard Biesheuvel wrote: > > This is all copy-pasted from MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c :( > > The ordering here is a bit tricky. As soon as the CPU arch protocol is > exposed, every allocation will be remapped individually, resulting in > page table

Re: [edk2-devel] [PATCH 2/3] ArmPkg/CpuDxe: Perform preliminary NX remap of free memory

Thanks!! :) Comments inline. > On 8. Feb 2023, at 18:58, Ard Biesheuvel wrote: > > The DXE core implementation of PcdDxeNxMemoryProtectionPolicy already > contains an assertion that EfiConventionalMemory and EfiBootServicesData > are subjected to the same policy when it comes to the use of NX >

Re: [edk2-devel] [PATCH 4/4] ArmPkg/CpuDxe: Implement EFI memory attributes protocol

> On 7. Feb 2023, at 19:19, Taylor Beebe wrote: > > If I understand Marvin correctly, he means that there either needs to be a > requirement that if you change the attributes of an allocated buffer you must > change them back before freeing, or the memory management logic should handle >

Re: [edk2-devel] [PATCH 4/4] ArmPkg/CpuDxe: Implement EFI memory attributes protocol

> On 7. Feb 2023, at 18:56, Ard Biesheuvel wrote: > > On Tue, 7 Feb 2023 at 11:13, Marvin Häuser wrote: >> >> >> On 7. Feb 2023, at 11:01, Ard Biesheuvel wrote: >> >> Actually, it seems UnprotectUefiImage () is corrent under the >> assump

  1   2   3   4   5   >