mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Ahmad Fatoum <a.fatoum@pengutronix.de>
To: barebox@lists.infradead.org
Cc: Ahmad Fatoum <a.fatoum@pengutronix.de>
Subject: [PATCH master] ARM: stm32mp: much enlarge very early stack size
Date: Fri, 17 Feb 2023 18:51:24 +0100	[thread overview]
Message-ID: <20230217175124.1897402-1-a.fatoum@pengutronix.de> (raw)

The barebox stack is always located at a fixed offset from the end of
SDRAM. To determine end of SDRAM, barebox may need a stack setup, so
at that early time, either stack pointer set up by BootROM is reused
or we set up a temporary stack on some on-chip SRAM .

On STM32MP1, TF-A runs after BootROM, so barebox runs in normal world
without prepared stack and TF-A is located on on-chip SRAM.

So what we did so far was have a small stack of 64 bytes starting behind
end of barebox image to cover the first function call to determine
actual memory size. This may have been chosen that small with the thought
that an overflow would give an error message anyway, because of failed
decompression. An overflow of exactly 4 bytes overwrites just the barebox
proper image size though located at the end of the barebox image, thereby
overflowing the size and leading to out-of-bounds access during decompression
in 1 of 4 cases depending on barebox size, because we align barebox
proper size to 16 bytes...

Let's just use a fully sized stack even in the early state. That's
usually 32K and we expect a barebox loaded into DRAM to always have
that much bytes following it. Another way would've been to use
some of the other SRAMs, but I decided to leave those alone, as not
to clobber data used by the coprocessor, when reloading barebox.

Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
 arch/arm/mach-stm32mp/include/mach/entry.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-stm32mp/include/mach/entry.h b/arch/arm/mach-stm32mp/include/mach/entry.h
index f8d981cca7cd..8d3adb4bdaf9 100644
--- a/arch/arm/mach-stm32mp/include/mach/entry.h
+++ b/arch/arm/mach-stm32mp/include/mach/entry.h
@@ -11,7 +11,7 @@ static __always_inline void stm32mp_cpu_lowlevel_init(void)
 	unsigned long stack_top;
 	arm_cpu_lowlevel_init();
 
-	stack_top = (unsigned long)__image_end + get_runtime_offset() + 64;
+	stack_top = (unsigned long)__image_end + get_runtime_offset() + CONFIG_STACK_SIZE;
 	stack_top = ALIGN(stack_top, 16);
 	arm_setup_stack(stack_top);
 }
-- 
2.30.2




             reply	other threads:[~2023-02-17 17:52 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-17 17:51 Ahmad Fatoum [this message]
2023-02-21 10:16 ` 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=20230217175124.1897402-1-a.fatoum@pengutronix.de \
    --to=a.fatoum@pengutronix.de \
    --cc=barebox@lists.infradead.org \
    /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