Fantastic! When we hit this in GCC 12.3 toolchain, the ADR was indeed at a 0xffc page offset. So, that connects.
This also explains why the issue seemed to be specific to stack protection: Because it's comparing values right away. If we hit this with other loads, we might not notice until later or at all. I have one more dot to connect: When I built crosstool-ng, I was using "--enable-fix-cortex-a53-843419". However, I'm guessing I wasn't lucky enough to end up with an ADRP at the end of a page. I'll try to manufacture that situation as further confirmation. Thanks, Jake ________________________________ From: Pedro Falcato <pedro.falc...@gmail.com> Sent: Wednesday, December 13, 2023 1:01 PM To: Ard Biesheuvel <a...@kernel.org> Cc: Jake Garver <j...@nvidia.com>; devel@edk2.groups.io <devel@edk2.groups.io>; rebe...@bsdio.com <rebe...@bsdio.com>; gaolim...@byosoft.com.cn <gaolim...@byosoft.com.cn>; bob.c.f...@intel.com <bob.c.f...@intel.com>; yuwei.c...@intel.com <yuwei.c...@intel.com> Subject: Re: [edk2-devel] [PATCH] BaseTools/GenFw: Change opcode when converting ADR to ADRP External email: Use caution opening links or attachments On Wed, Dec 13, 2023 at 5:31 PM Ard Biesheuvel <a...@kernel.org> wrote: > > On Wed, 13 Dec 2023 at 15:58, Jake Garver <j...@nvidia.com> wrote: > > > > Totally understand and agree, Ard. > > > > In the meantime, I've now experienced the issue with Ubuntu22's GCC 12.3. > > Originally, we didn't see the issue on this toolchain, but a developer ran > > into when preparing a change. Even more concerning, when I instrumented > > that change, it went away. So, it seems to be very sensitive to the input, > > which will make it hard to reproduce. > > > > Specifically, like the Ubuntu20 10.5 toolchain, the Ubuntu 12.3 toolchain > > generated an R_AARCH64_ADR_GOT_PAGE relocation against an ADR instruction. > > Further, it was when loading the value of __stack_chk_guard. > > > > I was again unable to reproduce this using a crosstool-ng build of GCC > > 12.3, even when matching the ./configure arguments. > > > > Since it's now reproducible in a toolchain we're actively using, I'll > > continue looking at it. I'll let you know what I find. > > OK, mystery solved. > > # Load to set the stack canary > 2ffc: 10000480 adr x0, 0x308c > 3008: 912ec000 add x0, x0, #0xbb0 > > The location of the ADRP instruction is at the end of a 4k page > (0xffc), which could trigger erratum #843419 on Cortex-A53, and is > therefore converted into ADR. Ha! Great deduction! And because GCC builds don't turn on the a53 ADRP errata by default, the toolchains Jake built weren't catching this issue. -- Pedro -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#112490): https://edk2.groups.io/g/devel/message/112490 Mute This Topic: https://groups.io/mt/102202314/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
