[PATCH 0/6] Miscellaneous FWU fixes
Michal Simek
michal.simek at amd.com
Thu Sep 5 09:39:21 CEST 2024
On 9/5/24 09:38, Sughosh Ganu wrote:
> On Thu, 5 Sept 2024 at 13:03, Michal Simek <michal.simek at amd.com> wrote:
>>
>>
>>
>> On 9/5/24 08:24, Sughosh Ganu wrote:
>>> On Wed, 4 Sept 2024 at 17:30, Michal Simek <michal.simek at amd.com> wrote:
>>>>
>>>>
>>>>
>>>> On 8/30/24 13:40, Sughosh Ganu wrote:
>>>>>
>>>>> The following set of patches are miscellaneous fixes and some
>>>>> hardening of the FWU update logic.
>>>>>
>>>>> Sughosh Ganu (6):
>>>>> fwu: v2: perform some checks before reading metadata
>>>>> fwu: v2: try reading both copies of metadata
>>>>> fwu: v1: do a version check for the metadata
>>>>> fwu: check all images for transitioning out of Trial State
>>>>> fwu: add dependency checks for selecting FWU metadata version
>>>>> fwu: do not allow capsule processing on exceeding Trial Counter
>>>>> threshold
>>>>>
>>>>> include/fwu.h | 11 ++++++
>>>>> lib/fwu_updates/Kconfig | 1 +
>>>>> lib/fwu_updates/fwu.c | 31 +++++++++++++++-
>>>>> lib/fwu_updates/fwu_v1.c | 18 +++++++--
>>>>> lib/fwu_updates/fwu_v2.c | 80 ++++++++++++++++++++++------------------
>>>>> 5 files changed, 99 insertions(+), 42 deletions(-)
>>>>>
>>>>
>>>> I found one more thing.
>>>>
>>>> I did this change
>>>>
>>>> diff --git a/tools/mkfwumdata.c b/tools/mkfwumdata.c
>>>> index fbc2067bc12d..dab9530e499c 100644
>>>> --- a/tools/mkfwumdata.c
>>>> +++ b/tools/mkfwumdata.c
>>>> @@ -293,7 +293,7 @@ static void fwu_fill_version_specific_mdata(struct
>>>> fwu_mdata_object *mobj)
>>>> struct fwu_mdata *mdata = mobj->mdata;
>>>>
>>>> mdata->metadata_size = mobj->size;
>>>> - mdata->desc_offset = sizeof(struct fwu_mdata);
>>>> + mdata->desc_offset = 0x21; sizeof(struct fwu_mdata);
>>>>
>>>> for (i = 0; i < MAX_BANKS_V2; i++)
>>>> mdata->bank_state[i] = i < mobj->banks ?
>>>>
>>>>
>>>> to break desc_offset location. I generated mdata structure and write it to
>>>> primary mdata partition.
>>>>
>>>> This has been spotted by (my debug) which is the reason why I did it.
>>>>
>>>> if (g_mdata.desc_offset != FWU_IMG_DESC_OFFSET) {
>>>> printf("mdata offset is not 0x20\n");
>>>> return false;
>>>> }
>>>>
>>>> But I got one more message below which
>>>>
>>>> mdata offset is not 0x20
>>>> Both FWU metadata copies are valid but do not match. Restoring the secondary
>>>> partition from the primary
>>>
>>> The reason why this logic is in place is to handle the scenario
>>> whereby, during the metadata update, the primary copy gets updated
>>> correctly, but due to some reason (like a power cut), the secondary
>>> copy does not -- this is because the primary copy gets updated first.
>>> In such a scenario, the secondary copy of metadata can be then
>>> restored from the primary copy. In the scenario where the primary copy
>>> is corrupted, it will show up in the crc check, and will get restored
>>> from the secondary copy.
>>
>> But in this case - CRC of primary is correct but data inside is wrong because
>> offset is at 0x21 not at 0x20.
>
> How will this event play out ? Am I missing something ? When the
> metadata is getting updated, the offset will be written as 0x20, and
> not 0x21. And in case the metadata gets corrupted, the CRC check would
> fail and the primary partition would get restored from the secondary
> (assuming that the secondary copy is correct).
It is not after update. It is initial state with incorrect mdata structure.
M
More information about the U-Boot
mailing list