On Wed, Apr 19, 2023 at 10:55 PM Ard Biesheuvel <a...@kernel.org> wrote:
>
> On Wed, 19 Apr 2023 at 22:10, Marvin Häuser <mhaeu...@posteo.de> wrote:
> >
> >
> > > On 19. Apr 2023, at 21:48, Ard Biesheuvel <a...@kernel.org> 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?
>
> It would, but you only appear to be setting that for ASLD_DLINK_FLAGS,
> right? So that seems unrelated.
>
> The only thing I am observing is that the store to memory in
> ArmMmuBaseLibConstructor()
>
>   Hob = GetFirstGuidHob (&gArmMmuReplaceLiveTranslationEntryFuncGuid);
>   if (Hob != NULL) {
>     mReplaceLiveEntryFunc = *(VOID **)GET_GUID_HOB_DATA (Hob);
>
> is writing to the emulated NOR flash, and this switches it into NOR
> programming mode, causing the firmware to crash immediately as it can
> no longer fetch instructions.
>
> FYI I am using GDB to step through the code, i.e.,
>
> - run gdb (or 'gdb-multiarch' if you are cross-compiling)
> - start qemu with -s -S
> - connect using 'target remote :1234'
> - paste the 'add-symbol-file' line, e.g.,
> add-symbol-file
> /home/ard/build/edk2-workspace/Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/AARCH64/MdeModulePkg/Core/DxeIplPeim/DxeIpl/DEBUG/DxeIpl.dll
> 0x30000
> - set breakpoint
> "hb _ModuleEntryPoint"
> - start executing
> "c"
> - use 'ni' to advance to the 'str' instruction that sets mReplaceLiveEntryFunc
>
> > 0x3553c <_ModuleEntryPoint+96>  str     x1, [x0, #224]
>
> Now, as soon as I step over that instruction (using 's'), the entire
> view of memory changes into
>
> │  > 0x35540 <_ModuleEntryPoint+100> .inst   0x00800080 ; undefined
> │    0x35544 <_ModuleEntryPoint+104> .inst   0x00800080 ; undefined
>
> etc, and the next step generates an exception, but this cannot be
> handled either. This is all related to the NOR flash emulation code in
> QEMU, that stops working as a ROM and switches into programming mode.
>
> I cannot explain why this only happens in this case, and why some
> writes seem to be ignored. But it does explain why this particular
> firmware build is misbehaving
>
> Now, if you apply the following patches:
>
> ArmPkg/Mmu: Remove handling of NONSECURE memory regions
> ArmPkg/ArmMmuLib: Introduce region types for RO/XP WB cached memory
> ArmVirtPkg/ArmVirtQemu: Use read-only memory region type for code flash
>
> (from the edk2-devel list), your build still crashes, but it prints
> one additional line
>
> Synchronous Exception at 0x3553C
>
> which is the exception caused by the write to NOR flash, which is now
> mapped read-only in the page tables, and so it is caught by the
> firmware itself.
>
> If you subsequently apply
>
> ArmVirtPkg/ArmVirtQemu: Use PEI flavor of ArmMmuLib for all PEIMs
>
> things work as expected.
>
> https://github.com/ardbiesheuvel/edk2/tree/arm_corruption-latest-ardb

<random bystander approaches>

Hi Ard,

Marvin's emails keep getting caught on your spam filter, please see
https://edk2.groups.io/g/devel/message/103259

<random bystander leaves>
-- 
Pedro


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#103260): https://edk2.groups.io/g/devel/message/103260
Mute This Topic: https://groups.io/mt/98325898/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Reply via email to