From: David Gibson <david@gibson.dropbear.id.au>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Philippe Mathieu-Daudé" <f4bug@amsat.org>,
"Paul Burton" <paul.burton@mips.com>,
"Marc-André Lureau" <marcandre.lureau@redhat.com>,
"QEMU Developers" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH] loader: Fix misaligned member access
Date: Mon, 23 Apr 2018 13:16:39 +1000 [thread overview]
Message-ID: <20180423031639.GB19804@umbus.fritz.box> (raw)
In-Reply-To: <CAFEAcA_mSu00gEHgmfdpcvtaqfn7X0wbkUX54TCUW_FG+iURWQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3326 bytes --]
On Sun, Apr 22, 2018 at 11:41:20AM +0100, Peter Maydell wrote:
> On 21 April 2018 at 22:16, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
> > This fixes the following ASan warning:
> >
> > $ mips64el-softmmu/qemu-system-mips64el -M boston -kernel vmlinux.gz.itb -nographic
> > hw/core/loader-fit.c:108:17: runtime error: load of misaligned address 0x7f95cd7e4264 for type 'fdt64_t', which requires 8 byte alignment
> > 0x7f95cd7e4264: note: pointer points here
> > 00 00 00 3e ff ff ff ff 80 7d 2a c0 00 00 00 01 68 61 73 68 40 30 00 00 00 00 00 03 00 00 00 14
> > ^
> >
> > Reported-by: AddressSanitizer
> > Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> > ---
> > hw/core/loader-fit.c | 8 ++++++--
> > 1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/hw/core/loader-fit.c b/hw/core/loader-fit.c
> > index 0c4a7207f4..1a69697f89 100644
> > --- a/hw/core/loader-fit.c
> > +++ b/hw/core/loader-fit.c
> > @@ -93,6 +93,8 @@ static int fit_image_addr(const void *itb, int img, const char *name,
> > hwaddr *addr)
> > {
> > const void *prop;
> > + fdt32_t v32;
> > + fdt64_t v64;
> > int len;
> >
> > prop = fdt_getprop(itb, img, name, &len);
> > @@ -102,10 +104,12 @@ static int fit_image_addr(const void *itb, int img, const char *name,
> >
> > switch (len) {
> > case 4:
> > - *addr = fdt32_to_cpu(*(fdt32_t *)prop);
> > + memcpy(&v32, prop, sizeof(v32));
> > + *addr = fdt32_to_cpu(v32);
So, assuming the base of the fdt is aligned (which I'd expect), then
properties should also be 32-bit aligned, so this shouldn't be
necessary. They may not be 64-bit aligned, so the equivalent for
length 8 *is* required.
(Really old fdt versions did attempt to 64-bit align larger
properties, but it caused a bunch of other complications)
> If we need to do an unaligned load, then ldl_p() is the
> right way to do it. (We could also just do
> *addr = ldl_be_p(prop) but we maybe don't want to
> bake in knowledge that FDT is big-endian).
>
> This does make me suspicious that maybe we're not using
> the fdt APIs right here though. Since 'prop' is the return
> value of fdt_getprop(), shouldn't libfdt be providing
> APIs for "give me the fdt32 here" that don't require
> the libfdt user to either implement its own unaligned
> access helpers or invoke C undefined behaviour? David,
> any suggestions?
It's pretty much correct usage. Properties in fdt - as in Open
Firmware - are defined to be bytestrings. libfdt is concerned with
extracting those bytestrings from the tree encoding, and parsing
what's inside the bytestring is mostly out of scope for it.
Mostly.. because we do have some helpers for common cases -
e.g. fdt_setprop_u32(). We don't currently have an fdt_getprop_u32()
or fdt_getprop_u64(). I'm not in principle opposed to adding them,
but the right interface isn't immediately obvious to me: we can't just
return a u32/u64, because then we have no way of reporting errors
(like "no such property").
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2018-04-23 3:16 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-21 21:16 [Qemu-devel] [PATCH] loader: Fix misaligned member access Philippe Mathieu-Daudé
2018-04-22 10:41 ` Peter Maydell
2018-04-23 3:16 ` David Gibson [this message]
2018-04-23 13:57 ` Philippe Mathieu-Daudé
2018-04-23 14:04 ` Peter Maydell
2018-04-23 14:15 ` Philippe Mathieu-Daudé
2018-04-23 14:26 ` Philippe Mathieu-Daudé
2018-04-23 15:32 ` Peter Maydell
2018-04-23 15:49 ` Philippe Mathieu-Daudé
2018-04-23 15:55 ` Peter Maydell
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=20180423031639.GB19804@umbus.fritz.box \
--to=david@gibson.dropbear.id.au \
--cc=f4bug@amsat.org \
--cc=marcandre.lureau@redhat.com \
--cc=paul.burton@mips.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.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;
as well as URLs for NNTP newsgroup(s).