public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Rui Miguel Silva <rui.silva@linaro.org>
To: Heinrich Schuchardt <xypron.glpk@gmx.de>,
	Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: u-boot@lists.denx.de, Simon Glass <sjg@chromium.org>,
	Tom Rini <trini@konsulko.com>
Subject: Re: [PATCH 1/6] fwu_metadata: make sure structures are packed
Date: Mon, 29 May 2023 14:12:38 +0100	[thread overview]
Message-ID: <m3wn0r8ent.fsf@gmail.com> (raw)
In-Reply-To: <a92cb16d-5afb-e1e5-d22a-e0333b86cfa9@gmx.de>

Hi Heinrich,
thanks for the review,
Heinrich Schuchardt <xypron.glpk@gmx.de> writes:

> On 5/3/23 10:06, Ilias Apalodimas wrote:
>> On Tue, 2 May 2023 at 16:12, Rui Miguel Silva <rui.silva@linaro.org> wrote:
>>
>> Hi Rui,
>>>
>>> The fwu metadata in the metadata partitions
>>> should/are packed to guarantee that the info is
>>> correct in all platforms. Also the size of them
>>> are used to calculate the crc32 and that is important
>>> to get it right.
>>>
>>> Signed-off-by: Rui Miguel Silva <rui.silva@linaro.org>
>>> ---
>>>   include/fwu_mdata.h | 6 +++---
>>>   1 file changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/include/fwu_mdata.h b/include/fwu_mdata.h
>>> index 8fda4f4ac225..c61221a91735 100644
>>> --- a/include/fwu_mdata.h
>>> +++ b/include/fwu_mdata.h
>>> @@ -22,7 +22,7 @@ struct fwu_image_bank_info {
>>>          efi_guid_t  image_uuid;
>>>          uint32_t accepted;
>>>          uint32_t reserved;
>>> -};
>>> +} __packed;
>
> This structure is naturally packed. Why should adding a __packed
> attribute make a difference?

Agree.

>
>>>
>>>   /**
>>>    * struct fwu_image_entry - information for a particular type of image
>>> @@ -38,7 +38,7 @@ struct fwu_image_entry {
>>>          efi_guid_t image_type_uuid;
>>>          efi_guid_t location_uuid;
>>>          struct fwu_image_bank_info img_bank_info[CONFIG_FWU_NUM_BANKS];
>>> -};
>>> +} __packed;
>
> ditto

Agree.

>
>>>
>>>   /**
>>>    * struct fwu_mdata - FWU metadata structure for multi-bank updates
>>> @@ -62,6 +62,6 @@ struct fwu_mdata {
>>>          uint32_t previous_active_index;
>>>
>>>          struct fwu_image_entry img_entry[CONFIG_FWU_NUM_IMAGES_PER_BANK];
>>> -};
>>> +} __packed;
>
> Depending on the alignment of efi_guid_t __packed might make a
> difference here. But as efi_guid_t is defined as 4 aligned I can't see
> an impact here either.

but efi_guid_t is defined as 8 aligned, right?
Even though, I think that this type of data written to disk/flash
without guaranteeing (trusting natural picketing) packed and endianness
is never a good idea.

Cheers,
   Rui

>
> Best regards
>
> Heinrich
>
>>>
>>>   #endif /* _FWU_MDATA_H_ */
>>> --
>>> 2.40.0
>>>
>>
>> Yep, that's a good catch.  The spec defines 'just' the offsets and not
>> the C representation, so those should be indeed packed.
>>
>> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

  reply	other threads:[~2023-05-29 13:12 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-02 13:11 [PATCH 0/6] corstone1000: fwu metadata and GPT Rui Miguel Silva
2023-05-02 13:11 ` [PATCH 1/6] fwu_metadata: make sure structures are packed Rui Miguel Silva
2023-05-03  8:06   ` Ilias Apalodimas
2023-05-29  8:48     ` Heinrich Schuchardt
2023-05-29 13:12       ` Rui Miguel Silva [this message]
2023-05-29 13:18         ` Ilias Apalodimas
2023-05-29 13:47           ` Rui Miguel Silva
2023-05-02 13:11 ` [PATCH 2/6] nvmxip: move header to include Rui Miguel Silva
2023-05-29  8:51   ` Heinrich Schuchardt
2023-05-29 13:13     ` Rui Miguel Silva
2023-05-02 13:11 ` [PATCH 3/6] corstone1000: add fwu-metadata store info Rui Miguel Silva
2023-05-02 13:11 ` [PATCH 4/6] corstone1000: add boot index Rui Miguel Silva
2023-05-02 13:11 ` [PATCH 5/6] corstone1000: set kernel_addr based on boot_idx Rui Miguel Silva
2023-05-02 13:12 ` [PATCH 6/6] corstone1000: add nvmxip, fwu-mdata and gpt options Rui Miguel Silva
2023-05-15 13:27 ` [PATCH 0/6] corstone1000: fwu metadata and GPT Rui Miguel Silva
2023-05-29  8:39   ` Rui Miguel Silva

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=m3wn0r8ent.fsf@gmail.com \
    --to=rui.silva@linaro.org \
    --cc=ilias.apalodimas@linaro.org \
    --cc=sjg@chromium.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox