public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Tom Rini <trini@konsulko.com>
To: Simon Glass <sjg@google.com>
Cc: David Virag <virag.david003@gmail.com>, u-boot@lists.denx.de
Subject: Re: [BUG] fdt_pack_reg in common/fdt_support.c can cause crash from unaligned access
Date: Mon, 10 Jul 2023 16:13:39 -0400	[thread overview]
Message-ID: <20230710201339.GZ148062@bill-the-cat> (raw)
In-Reply-To: <CAPnjgZ3xUzbs0MGJybA2xg_AQ=nshQjD+rCL=gVAj81UMetgzg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1557 bytes --]

On Mon, Jul 10, 2023 at 01:45:46PM -0600, Simon Glass wrote:
> Hi David,
> 
> On Sun, 9 Jul 2023 at 19:11, David Virag <virag.david003@gmail.com> wrote:
> >
> > Hi,
> >
> > I'm trying to port U-Boot to a new board (Samsung JACKPOTLTE, ARMv8,
> > Exynos7885) but when CONFIG_ARCH_FIXUP_FDT_MEMORY is enabled, the bootm
> > command leads to an unaligned memory access, which results in a
> > synchronous abort.
> >
> > After a long debugging session, I concluded that fdt_pack_reg in
> > common/fdt_support.c writes to unaligned addresses in its for loop.
> > In the case of address_cells being 2, and size_cells being 1, the
> > buffer pointer gets incremented by 12 in each loop, making the second
> > iteration (i=1) write a 64bit value to a non 64bit aligned address.
> >
> > Turning the alignment check enable bit (A) off in SCTLR makes the
> > function work as intended. I couldn't find code that touches this bit,
> > but I may have missed something. I don't think writing in two parts
> > should be the fix, but something should be done about this. As far as I
> > understand, any arm64 board that has this bit turned on, either from
> > previous code or just the initial status of the bit after power on,
> > could crash here.
> >
> > This is on top of the latest commit as of now
> > (0beb649053b86b2cfd5cf55a0fc68bc2fe91a430)
> >
> > What should be done here?
> 
> +Tom Rini

... I was hoping you had an idea Simon. Is this part of the code we
share with libfdt itself, or one of the helpers we made?

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

  reply	other threads:[~2023-07-10 20:13 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-09 21:42 [BUG] fdt_pack_reg in common/fdt_support.c can cause crash from unaligned access David Virag
2023-07-10 19:45 ` Simon Glass
2023-07-10 20:13   ` Tom Rini [this message]
2023-07-10 21:38     ` Simon Glass
2023-07-11 10:34       ` David Virag
2023-07-11 19:13         ` Simon Glass
2024-03-27  6:18           ` Sam Protsenko

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=20230710201339.GZ148062@bill-the-cat \
    --to=trini@konsulko.com \
    --cc=sjg@google.com \
    --cc=u-boot@lists.denx.de \
    --cc=virag.david003@gmail.com \
    /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