From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>,
trini@konsulko.com, u-boot@lists.denx.de
Subject: Re: [PATCH v2] efi_loader: Fix warnings for unaligned accesses
Date: Fri, 12 May 2023 09:05:05 +0900 [thread overview]
Message-ID: <20230512000505.GA8438@laputa> (raw)
In-Reply-To: <CAC_iWjJki2iMZ9BZ1W6q837Zz552weMSEYn4oZTs9Vq+6Sw7ww@mail.gmail.com>
Hi Ilias,
On Thu, May 11, 2023 at 08:00:32PM +0300, Ilias Apalodimas wrote:
> Hi Heinrich,
>
> On Thu, 11 May 2023 at 19:56, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> >
> > On 5/11/23 18:40, Ilias Apalodimas wrote:
> > > Tom reports that when building with clang we see this warning:
> > > field guid within 'struct efi_hii_keyboard_layout' is less aligned than 'efi_guid_t' and is usually due to 'struct efi_hii_keyboard_layout' being packed, which can lead to unaligned accesses [-Wunaligned-access]
> > >
> > > This happens because 'struct efi_hii_keyboard_layout' is defined as
> > > packed and thus has 1-byte alignment but efi_guid_t is a type that
> > > requires greater alignment than that.
> > >
> > > However the EFI spec describes the EFI_GUID as
> > > "128-bit buffer containing a unique identifier value.
> > > Unless otherwise specified"
> > >
> > > So convert the efi_guid_t -> u8 b[16] here and skip the alignment
> > > requirements. Since the struct is packed to begin with, it makes no
> > > difference on the final memory layout.
> > >
> > > Suggested-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
> > > Reported-by: Tom Rini <trini@konsulko.com>
> > > Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> > > ---
> > > Changes since v1:
> > > - Adjust the commit message and add a comment on why this happens
> > >
> > > include/efi_api.h | 28 +++++++++++++++++++++++++++-
> > > 1 file changed, 27 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/include/efi_api.h b/include/efi_api.h
> > > index 2fd0221c1c77..55a4c989fc7c 100644
> > > --- a/include/efi_api.h
> > > +++ b/include/efi_api.h
> > > @@ -1170,7 +1170,33 @@ struct efi_key_descriptor {
> > >
> > > struct efi_hii_keyboard_layout {
> > > u16 layout_length;
> > > - efi_guid_t guid;
> > > + /*
> > > + * The EFI spec defines this as efi_guid_t.
> > > + * clang and gcc both report alignment problems here.
> > > + * clang with -Wunaligned-access
> > > + * warning: field guid within 'struct efi_hii_keyboard_layout' is less
> > > + * aligned than 'efi_guid_t' and is usually due to
> > > + * 'struct efi_hii_keyboard_layout' being packed, which can lead to
> > > + * unaligned accesses
> > > + *
> > > + * GCC with -Wpacked-not-aligned -Waddress-of-packed-member
> > > + * 'efi_guid_t' offset 2 in 'struct efi_hii_keyboard_layout'
> > > + * isn't aligned to 4
> > > + *
> > > + * Removing the alignment from efi_guid_t is not an option, since
> > > + * it is also used in non-packed structs and that would break
> > > + * calculations with offsetof
> > > + *
> > > + * This is the only place we get a report for. That happens because
> > > + * all other declarations of efi_guid_t within a packed struct happens
> > > + * to be 4-byte aligned. i.e a u32, a u64 a 2 * u16 or any combination
> > > + * that ends up landing efi_guid_t on a 4byte boundary precedes.
> > > + *
> > > + * Replace this with a 1-byte aligned counterpart of b[16]. This is a
> > > + * packed struct so the memory placement of efi_guid_t should not change
> > > + *
> > > + */
> > > + u8 guid[16];
I thought that you have agreed with my comment, saying keep "efi_guid_t" here.
https://lists.denx.de/pipermail/u-boot/2023-April/515831.html
-Takahiro Akashi
> > > u32 layout_descriptor_string_offset;
> > > u8 descriptor_count;
> > > /* struct efi_key_descriptor descriptors[]; follows here */
> > > --
> > > 2.39.2
> > >
> >
> > Thank you for investigating this in depth.
>
> yw :)
>
> >
> > Commit messages should preferably limited to 75 characters per line, see
> > scripts/checkpatch.pl. No need to resubmit.
>
> Yea I know, I just prefered to keep the clang warning intact in the
> commit message
>
> Thanks
> /Ilias
> >
> > Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
next prev parent reply other threads:[~2023-05-12 0:05 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-11 16:40 [PATCH v2] efi_loader: Fix warnings for unaligned accesses Ilias Apalodimas
2023-05-11 16:55 ` Heinrich Schuchardt
2023-05-11 17:00 ` Ilias Apalodimas
2023-05-12 0:05 ` AKASHI Takahiro [this message]
2023-05-12 5:28 ` Ilias Apalodimas
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=20230512000505.GA8438@laputa \
--to=takahiro.akashi@linaro.org \
--cc=ilias.apalodimas@linaro.org \
--cc=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
--cc=xypron.glpk@gmx.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.