From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mx.groups.io with SMTP id smtpd.web11.51997.1681941326976074628 for ; Wed, 19 Apr 2023 14:55:27 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=XSOrKrIZ; spf=pass (domain: kernel.org, ip: 139.178.84.217, mailfrom: ardb@kernel.org) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 73B4163A05 for ; Wed, 19 Apr 2023 21:55:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DC2EFC433D2 for ; Wed, 19 Apr 2023 21:55:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1681941325; bh=qEIB/pSUa/oagdRx/rL06+PDQQF6HRQfLXMs5+l3N/0=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=XSOrKrIZ1wHus8hCWOdyiaKBG+pAYzWIqivum/Kls2/BkKipJsAiPVR4UVNCLPhaI 4WtsDRauL2PPdYzWxys8iqrPBkuDujsSLp/laEg+WT1Pv/Hg51TLP06z4yQlBZ6gem Or+6fXa51SLUAvjxyYgto6KQ+drkuQQY3c8/KOv+pEYbzV2TGqaN+yiK6O5V2QcoEI 9g62qtDR4xTE/fjIdwdV5kSkuty5Di6LcfrYBYt+11DHK2oDlmvArAWVwyiKfj/AOb zv3qrpgAavEJdOBiRwnqQoX5A0vSAFYZo/hHR34IGWkbFOxMHKdCARjG9w7zz4+7Ah OEytwun0+jvzQ== Received: by mail-lj1-f172.google.com with SMTP id r9so556749ljp.9 for ; Wed, 19 Apr 2023 14:55:25 -0700 (PDT) X-Gm-Message-State: AAQBX9dgjaJFMrmLm9xpxaiLQHNz2yyD24TPLZSgFLFqC5WT1afgnHH5 cMxCEQL8r2NG403CfRUk7ufDShbkHUuHeSouT+Y= X-Google-Smtp-Source: AKy350Yflet9pxrMGoDrdwbC8OKoDFq4QramdlBeq/Fu7CHGBiCJCkiTPc0QVECwVNtWvbyU7XxDzqCMjMlqW1+ATUw= X-Received: by 2002:a2e:b009:0:b0:2a7:7730:9ed with SMTP id y9-20020a2eb009000000b002a7773009edmr2383245ljk.12.1681941323843; Wed, 19 Apr 2023 14:55:23 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Ard Biesheuvel" Date: Wed, 19 Apr 2023 23:55:12 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [PATCH 1/2] ArmPkg/AsmMacroIoLibV8: Introduce ASM_FUNC_ALIGN() To: =?UTF-8?Q?Marvin_H=C3=A4user?= Cc: edk2-devel-groups-io , Leif Lindholm , Ard Biesheuvel , Sami Mujawar , Vitaly Cheptsov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 19 Apr 2023 at 22:10, Marvin H=C3=A4user wrote= : > > > > On 19. Apr 2023, at 21:48, Ard Biesheuvel wrote: > > > > The issue is likely caused by > > > > -Wl,--defsym=3DPECOFF_HEADER_SIZE=3D0 > > > > 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 =3D GetFirstGuidHob (&gArmMmuReplaceLiveTranslationEntryFuncGuid); if (Hob !=3D NULL) { mReplaceLiveEntryFunc =3D *(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 mReplaceLiveEntryF= unc > 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 =E2=94=82 > 0x35540 <_ModuleEntryPoint+100> .inst 0x00800080 ; undefined =E2=94=82 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