From: Ahmad Fatoum <a.fatoum@pengutronix.de>
To: barebox@lists.infradead.org
Cc: ejo@pengutronix.de, Ahmad Fatoum <a.fatoum@pengutronix.de>
Subject: [PATCH 2/5] ARM64: board-dt-2nd: grow stack down from start of binary
Date: Wed, 9 Oct 2024 08:05:08 +0200 [thread overview]
Message-ID: <20241009060511.4121157-3-a.fatoum@pengutronix.de> (raw)
In-Reply-To: <20241009060511.4121157-1-a.fatoum@pengutronix.de>
When first added, the ARM64 generic DT image started with `adr x1, 0'.
With the addition of the optional EFI entry point, a nop with an
optional MZ magic needed to be added at the start of the binary and so
`adr x1, 0' moved further down.
This 0 however is interpreted relative to the program counter and thus
the stack was now setup not from the start of the image down, but from
the location at which the adr instruction is located.
This happens to be 0x48, which not only overwrites the header during
execution, but also is not aligned to 16 bytes.
This issue went unnoticed so far, because the stack is only used to
find out the available memory (either from FDT or EFI boot service)
after which the stack is set up at a properly aligned fixed location
for the remainder of barebox' execution.
Under KVM however, this quickly crashes on the first stack access:
ldr x0, =0x4007fff8
mov sp, x0
stp x0, x1, [sp] // <-- data abort
Thus fix the code to grow the stack down from the first address.
Fixes: 742e78976dd4 ("ARM64: add optional EFI stub")
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
arch/arm/cpu/board-dt-2nd-aarch64.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/board-dt-2nd-aarch64.S b/arch/arm/cpu/board-dt-2nd-aarch64.S
index 030366c1cbf5..2ea13d20b450 100644
--- a/arch/arm/cpu/board-dt-2nd-aarch64.S
+++ b/arch/arm/cpu/board-dt-2nd-aarch64.S
@@ -22,7 +22,7 @@ ENTRY("start_dt_2nd")
.int .Lpe_header_offset /* reserved (PE-COFF offset) */
.asciz "barebox" /* unused for now */
2:
- adr x1, 0
+ adr x1, _text - .
mov sp, x1
/* Stack now grows into the 0x80000 image load offset specified
* above. This is more than enough until FDT /memory is decoded.
--
2.39.5
next prev parent reply other threads:[~2024-10-09 6:08 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-09 6:05 [PATCH 0/5] ARM64: make barebox compatible with KVM Ahmad Fatoum
2024-10-09 6:05 ` [PATCH 1/5] ARM64: io: implement I/O accessors in assembly Ahmad Fatoum
2024-10-09 6:05 ` Ahmad Fatoum [this message]
2024-10-09 6:05 ` [PATCH 3/5] mtd: cfi-flash: use I/O accessors for reads/writes of MMIO regions Ahmad Fatoum
2024-10-09 6:05 ` [PATCH 4/5] ARM64: mmu: flush cacheable regions prior to remapping Ahmad Fatoum
2024-10-09 6:05 ` [PATCH 5/5] virtio: don't use DMA API unless required Ahmad Fatoum
2024-10-14 12:48 ` Sascha Hauer
2024-10-14 13:05 ` Ahmad Fatoum
2024-10-14 13:06 ` [PATCH] fixup! " Ahmad Fatoum
2024-10-15 6:54 ` [PATCH 0/5] ARM64: make barebox compatible with KVM Sascha Hauer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241009060511.4121157-3-a.fatoum@pengutronix.de \
--to=a.fatoum@pengutronix.de \
--cc=barebox@lists.infradead.org \
--cc=ejo@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox