public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Leif Lindholm <leif.lindholm@linaro.org>
Cc: "edk2-devel@lists.01.org" <edk2-devel@lists.01.org>
Subject: Re: [PATCH edk2-platforms 1/2] Silicon/SynQuacerPlatformFlashAccessLib: relax FV address check
Date: Wed, 13 Jun 2018 14:06:00 +0200	[thread overview]
Message-ID: <CAKv+Gu94h6L9uwOONN1Y8p3irrVXWqqS5KgNUW7jNSL1Cw=hFA@mail.gmail.com> (raw)
In-Reply-To: <20180612230325.vkcjj4iuvpq2vbuk@bivouac.eciton.net>

On 13 June 2018 at 01:03, Leif Lindholm <leif.lindholm@linaro.org> wrote:
> On Thu, Jun 07, 2018 at 05:08:17PM +0200, Ard Biesheuvel wrote:
>> In commit 913fdda9f4b9 ("Silicon/SynQuacerPlatformFlashAccessLib: don't
>> dereference FVB header fields"), we dropped all accesses to FVB header
>> field, which was necessary because the flash partition may not in fact
>> contain such a header. Instead, only an exact match on the base address
>> of the FV compared to the base address of the capsule payload would
>> result in a match, making it difficult to create capsules that only
>> update a subset of the flash contents.
>>
>> Given that the FVB protocol provides a GetBlockSize() method that also
>> returns the number of consecutive blocks of that size, and does not rely
>> on the FVB header contents, we can actually infer the size of the flash
>> partition, and use it to decide whether a capsule payload targets an
>> area that is covered by this partition entirely.
>>
>> This optimization allows us to extend the FV description to include the
>> SCP firmware partition without requiring us to actually provide a
>> payload for that partition immediately, which is useful as a preparatory
>> step.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> ---
>>  Silicon/Socionext/SynQuacer/Library/SynQuacerPlatformFlashAccessLib/SynQuacerPlatformFlashAccessLib.c | 53 +++++++++-----------
>>  1 file changed, 25 insertions(+), 28 deletions(-)
>>
>> diff --git a/Silicon/Socionext/SynQuacer/Library/SynQuacerPlatformFlashAccessLib/SynQuacerPlatformFlashAccessLib.c b/Silicon/Socionext/SynQuacer/Library/SynQuacerPlatformFlashAccessLib/SynQuacerPlatformFlashAccessLib.c
>> index ebb6ce189aa5..a6843c949a28 100644
>> --- a/Silicon/Socionext/SynQuacer/Library/SynQuacerPlatformFlashAccessLib/SynQuacerPlatformFlashAccessLib.c
>> +++ b/Silicon/Socionext/SynQuacer/Library/SynQuacerPlatformFlashAccessLib/SynQuacerPlatformFlashAccessLib.c
>> @@ -44,8 +44,10 @@ STATIC
>>  EFI_STATUS
>>  GetFvbByAddress (
>>    IN  EFI_PHYSICAL_ADDRESS                Address,
>> +  IN  UINTN                               Length,
>>    OUT EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL  **OutFvb,
>> -  OUT EFI_PHYSICAL_ADDRESS                *FvbBaseAddress
>> +  OUT EFI_LBA                             *Lba,
>> +  OUT UINTN                               *BlockSize
>>    )
>>  {
>>    EFI_STATUS                          Status;
>> @@ -54,6 +56,8 @@ GetFvbByAddress (
>>    UINTN                               Index;
>>    EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL  *Fvb;
>>    EFI_FVB_ATTRIBUTES_2                Attributes;
>> +  EFI_PHYSICAL_ADDRESS                FvbBaseAddress;
>> +  UINTN                               NumberOfBlocks;
>>
>>    //
>>    // Locate all handles with Firmware Volume Block protocol
>> @@ -84,7 +88,7 @@ GetFvbByAddress (
>>      //
>>      // Checks if the address range of this handle contains parameter Address
>>      //
>> -    Status = Fvb->GetPhysicalAddress (Fvb, FvbBaseAddress);
>> +    Status = Fvb->GetPhysicalAddress (Fvb, &FvbBaseAddress);
>>      if (EFI_ERROR (Status)) {
>>        continue;
>>      }
>> @@ -102,8 +106,25 @@ GetFvbByAddress (
>>        continue;
>>      }
>>
>> -    if (Address == *FvbBaseAddress) {
>> +    Status = Fvb->GetBlockSize (Fvb, 0, BlockSize, &NumberOfBlocks);
>> +    if (EFI_ERROR (Status)) {
>> +      DEBUG ((DEBUG_INFO, "%a: failed to get FVB blocksize - %r, ignoring\n",
>> +        __FUNCTION__, Status));
>> +      continue;
>> +    }
>> +
>> +    if ((Length % *BlockSize) != 0) {
>> +      DEBUG ((DEBUG_INFO,
>> +        "%a: Length 0x%lx is not a multiple of the blocksize 0x%lx, ignoring\n",
>> +        __FUNCTION__, Length, *BlockSize));
>> +      Status = EFI_INVALID_PARAMETER;
>> +      continue;
>> +    }
>> +
>> +    if (Address >= FvbBaseAddress &&
>> +        (Address + Length) <= (FvbBaseAddress + *BlockSize * NumberOfBlocks)) {
>
> As I've already been giving Marcin a hard time about this today, could you add
> parentheses around "Address >= FvbBaseAddress" and "*BlockSize * NumberOfBlocks"?
>

Sure. But to be consistent, shouldn't I also add parens around the
entire term after the && then?

I.e.,

+    if ((Address >= FvbBaseAddress) &&
+        ((Address + Length) <= (FvbBaseAddress + (*BlockSize *
NumberOfBlocks)))) {

I'm not sure why we like redundant parentheses so much in Tianocore,
but I don't particularly mind either.



>>        *OutFvb  = Fvb;
>> +      *Lba = (Address - FvbBaseAddress) / *BlockSize;
>>        Status   = EFI_SUCCESS;
>>        break;
>>      }
>> @@ -190,9 +211,7 @@ PerformFlashWriteWithProgress (
>>    EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL  *Fvb;
>>    EFI_STATUS                          Status;
>>    UINTN                               BlockSize;
>> -  UINTN                               NumberOfBlocks;
>>    EFI_LBA                             Lba;
>> -  EFI_PHYSICAL_ADDRESS                FvbBaseAddress;
>>    UINTN                               NumBytes;
>>    UINTN                               Remaining;
>>
>> @@ -216,7 +235,7 @@ PerformFlashWriteWithProgress (
>>    // that covers the system firmware
>>    //
>>    Fvb = NULL;
>> -  Status = GetFvbByAddress (FlashAddress, &Fvb, &FvbBaseAddress);
>> +  Status = GetFvbByAddress (FlashAddress, Length, &Fvb, &Lba, &BlockSize);
>>    if (EFI_ERROR (Status)) {
>>      DEBUG ((DEBUG_ERROR,
>>        "%a: failed to locate FVB handle for address 0x%llx - %r\n",
>> @@ -224,28 +243,6 @@ PerformFlashWriteWithProgress (
>>      return Status;
>>    }
>>
>> -  Status = Fvb->GetBlockSize(Fvb, 0, &BlockSize, &NumberOfBlocks);
>> -  if (EFI_ERROR (Status)) {
>> -    DEBUG ((DEBUG_ERROR, "%a: failed to get FVB blocksize - %r\n",
>> -      __FUNCTION__, Status));
>> -    return Status;
>> -  }
>> -
>> -  if ((Length % BlockSize) != 0) {
>> -    DEBUG ((DEBUG_ERROR,
>> -      "%a: Length 0x%lx is not a multiple of the blocksize 0x%lx\n",
>> -      __FUNCTION__, Length, BlockSize));
>> -    return EFI_INVALID_PARAMETER;
>> -  }
>> -
>> -  Lba = (FlashAddress - FvbBaseAddress) / BlockSize;
>> -  if (Lba > NumberOfBlocks - 1) {
>> -    DEBUG ((DEBUG_ERROR,
>> -      "%a: flash device with non-uniform blocksize not supported\n",
>> -      __FUNCTION__));
>> -    return EFI_UNSUPPORTED;
>> -  }
>> -
>>    //
>>    // Remap the region as device rather than uncached.
>>    //
>> --
>> 2.17.0
>>


  reply	other threads:[~2018-06-13 12:06 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-07 15:08 [PATCH edk2-platforms 0/2] DeveloperBox: prepare for expanding the capsule payload Ard Biesheuvel
2018-06-07 15:08 ` [PATCH edk2-platforms 1/2] Silicon/SynQuacerPlatformFlashAccessLib: relax FV address check Ard Biesheuvel
2018-06-12 23:03   ` Leif Lindholm
2018-06-13 12:06     ` Ard Biesheuvel [this message]
2018-06-13 13:17       ` Leif Lindholm
2018-06-07 15:08 ` [PATCH edk2-platforms 2/2] Silicon/NorFlashSynQuacerLib: describe entire firmware region as FV Ard Biesheuvel
2018-06-12 22:59   ` Leif Lindholm
2018-06-13  7:19     ` Ard Biesheuvel
2018-06-13 10:00       ` Leif Lindholm
2018-06-13 12:00         ` Ard Biesheuvel
2018-06-13 12:28           ` Leif Lindholm
2018-06-07 16:06 ` [PATCH edk2-platforms 0/2] DeveloperBox: prepare for expanding the capsule payload Ard Biesheuvel

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-list 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='CAKv+Gu94h6L9uwOONN1Y8p3irrVXWqqS5KgNUW7jNSL1Cw=hFA@mail.gmail.com' \
    --to=devel@edk2.groups.io \
    /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