1. 03 Jan, 2018 1 commit
  2. 21 Nov, 2017 1 commit
  3. 17 Oct, 2017 1 commit
    • Evan Lloyd's avatar
      fiptool: Enable Visual Studio build · a1ee3836
      Evan Lloyd authored
      
      
      Updates are required to enable the fiptool utility to be built on a
      Windows platform.  This change modifies the source files to enable
      building with Visual Studio (detected via preprocessor settings).
      The primary changes are:
        1.  Provide an implementation of the getopt_long function.  This does
            not exist in the Visual Studio CRT libraries because Windows
            commands normally use '/' not '-' as an option indicator.
        2.  Redirect some function names to match those supported by the
            Visual Studio libraries (when building with Visual Studio).
        2.  Modify a structure name (stat) to match that provided
            by the Visual Studio libraries (_stat).
      
      Note - this change does not provide makefile updates.  It only modifies
             the sources to enable the fiptool to be built from a Visual
             Studio project.  In normal use the presence of FIPTOOL.EXE is
             enough to satisfy the make requirements.  A makefile change may
             be derived from the Visual Studio command line information at
             some point in the future.
      
      Change-Id: I3ade77ea140246af3c030920b3f97c070087f111
      Signed-off-by: default avatarEvan Lloyd <evan.lloyd@arm.com>
      a1ee3836
  4. 11 Oct, 2017 1 commit
    • Evan Lloyd's avatar
      fiptool: Precursor changes for Visual Studio · 96851114
      Evan Lloyd authored
      
      
      In order to compile the source of Fiptool using Visual Studio a number
      of adjustments are required to the source.  This commit modifies the
      source with changes that will be required, but makes no functional
      modification.  The intent is to allow confirmation that the GCC build
      is unaffected.
      
      Change-Id: I4055bd941c646dd0a1aa2e24b940a1db3bf629ce
      Signed-off-by: default avatarEvan Lloyd <evan.lloyd@arm.com>
      96851114
  5. 09 Oct, 2017 1 commit
    • Qixiang Xu's avatar
      cert_tool: Fix ECDSA certificates create failure · 1727de0e
      Qixiang Xu authored
      Commit a8eb286a
      
       introduced the
      following error when creating ECDSA certificates.
          ERROR:   Error creating key 'Trusted World key'
          Makefile:634: recipe for target 'certificates' failed
          make: *** [certificates] Error 1
      
      this patch adds the function to create PKCS#1 v1.5.
      
      Change-Id: Ief96d55969d5e9877aeb528c6bb503b560563537
      Signed-off-by: default avatarQixiang Xu <qixiang.xu@arm.com>
      1727de0e
  6. 08 Oct, 2017 1 commit
  7. 11 Sep, 2017 1 commit
    • Soby Mathew's avatar
      Set default value of USE_TBBR_DEFS · 4a2bf951
      Soby Mathew authored
      
      
      Using the OIDs defined in tbbr_oids.h is the recommended way to build
      the cert_create tool. This patch hence sets default value of the build
      flag USE_TBBR_DEFS to 1 in the Makefile in `tools/cert_create` folder
      when cert_create is built from this folder.
      
      Fixes ARM-software/tf-issues#482
      
      Change-Id: Id1d224826b3417770bccbefa1b68d9bdb3b567f0
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      4a2bf951
  8. 31 Aug, 2017 1 commit
    • Soby Mathew's avatar
      cert_tool: Support for legacy RSA PKCS#1 v1.5 · a8eb286a
      Soby Mathew authored
      
      
      This patch enables choice of RSA version at run time to be used for
      generating signatures by the cert_tool. The RSA PSS as defined in
      PKCS#1 v2.1 becomes the default version and this patch enables to specify
      the RSA PKCS#1 v1.5 algorithm to `cert_create` through the command line
      -a option. Also, the build option `KEY_ALG` can be used to pass this
      option from the build system. Please note that RSA PSS is mandated
      by Trusted Board Boot requirements (TBBR) and legacy RSA support is
      being added for compatibility reasons.
      
      Fixes ARM-Software/tf-issues#499
      Change-Id: Ifaa3f2f7c9b43f3d7b3effe2cde76bf6745a5d73
      Co-Authored-By: default avatarEleanor Bonnici <Eleanor.bonnici@arm.com>
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      a8eb286a
  9. 30 Aug, 2017 1 commit
  10. 09 Aug, 2017 1 commit
  11. 31 Jul, 2017 1 commit
  12. 26 Jul, 2017 1 commit
  13. 12 Jul, 2017 1 commit
    • Isla Mitchell's avatar
      Fix order of #includes · 2a4b4b71
      Isla Mitchell authored
      
      
      This fix modifies the order of system includes to meet the ARM TF coding
      standard. There are some exceptions in order to retain header groupings,
      minimise changes to imported headers, and where there are headers within
      the #if and #ifndef statements.
      
      Change-Id: I65085a142ba6a83792b26efb47df1329153f1624
      Signed-off-by: default avatarIsla Mitchell <isla.mitchell@arm.com>
      2a4b4b71
  14. 12 Jun, 2017 1 commit
  15. 05 Jun, 2017 1 commit
    • Soby Mathew's avatar
      cert_create: Use RSASSA-PSS signature scheme for certificates · 1f33ad4e
      Soby Mathew authored
      
      
      This patch modifies the `cert_create` tool to use RSASSA-PSS scheme for
      signing the certificates. This is compliant with RSA PKCS_2_1 standard as
      mandated by TBBR.
      
      Note that the certificates generated by using cert_create tool after this
      patch can be authenticated during TBB only if the corresponding mbedtls
      driver in ARM Trusted Firmware has the corresponding support.
      
      Change-Id: If224f41c76b3c4765ae2af5259e67f73602818a4
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      1f33ad4e
  16. 24 May, 2017 1 commit
  17. 23 May, 2017 2 commits
    • Masahiro Yamada's avatar
      cert: move platform_oid.h to include/tools_share for all platforms · bb41eb7a
      Masahiro Yamada authored
      
      
      Platforms aligned with TBBR are supposed to use their own OIDs, but
      defining the same macros with different OIDs does not provide any
      value (at least technically).
      
      For easier use of TBBR, this commit allows platforms to reuse the OIDs
      obtained by ARM Ltd.  This will be useful for non-ARM vendors that
      do not need their own extension fields in their certificate files.
      
      The OIDs of ARM Ltd. have been moved to include/tools_share/tbbr_oid.h
      
      Platforms can include <tbbr_oid.h> instead of <platform_oid.h> by
      defining USE_TBBR_DEFS as 1.  USE_TBBR_DEFS is 0 by default to keep the
      backward compatibility.
      
      For clarification, I inserted a blank line between headers from the
      include/ directory (#include <...>) and ones from a local directory
      (#include "..." ).
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      bb41eb7a
    • Masahiro Yamada's avatar
      fip: move headers shared between TF and fiptool to include/tools_share · 2a6c1a8f
      Masahiro Yamada authored
      
      
      Some header files need to be shared between TF and host programs.
      For fiptool, two headers are copied to the tools/fiptool directory,
      but it looks clumsy.
      
      This commit introduces a new directory, include/tools_share, which
      collects headers that should be shared between TF and host programs.
      
      This will clarify the interface exposed to host tools.  We should
      add new headers to this directory only when we really need to do so.
      
      For clarification, I inserted a blank line between headers from the
      include/ directory (#include <...>) and ones from a local directory
      (#include "..." ).
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      2a6c1a8f
  18. 03 May, 2017 1 commit
  19. 24 Apr, 2017 1 commit
  20. 27 Feb, 2017 1 commit
    • dp-arm's avatar
      fiptool: Embed a pointer to an image within the image descriptor · b9589fe5
      dp-arm authored
      
      
      Currently, fiptool uses two linked lists.  One to chain together all
      the images and one for all the image descriptors.  Initially this was
      done because not all images had a corresponding image descriptor.
      This was the case for unknown images which existed in the FIP but
      there was no descriptor in the builtin table for them.  When support
      for the --blob option came in, we started building descriptors for the
      unknown images on the fly.  As a result every image now has a
      corresponding image descriptor and therefore it is no longer necessary
      to keep track of them separately.
      
      To simplify the design, maintain only a single linked list of image
      descriptors.  An image descriptor contains a pointer to the
      corresponding image.  If the pointer is NULL, then the descriptor is
      skipped in all the operations.  This approach simplifies the traversal
      code and avoids redundant lookups.
      
      The linked list of image descriptors is populated based on the
      `toc_entries` array.  This means that the order of the images in the
      FIP file remains the same across add/remove or create/update
      operations.  This is true for all standard images (those specified in
      `toc_entries`) but not for those specified via the --blob option.
      
      Change-Id: Ic29a263c86c8f1efdad322b430368c7623782e2d
      Signed-off-by: default avatardp-arm <dimitris.papastamos@arm.com>
      b9589fe5
  21. 14 Feb, 2017 1 commit
  22. 11 Feb, 2017 6 commits
  23. 28 Jan, 2017 2 commits
    • Masahiro Yamada's avatar
      fiptool: support --align option to add desired alignment to image offset · 1c75d5df
      Masahiro Yamada authored
      
      
      The current fiptool packs all the images without any padding between
      them.  So, the offset to each image has no alignment.  This is not
      efficient, for example, when the FIP is read from a block-oriented
      device.
      
      For example, (e)MMC is accessed by block-addressing.  The block size
      is 512 byte.  So, the best case is each image is aligned by 512 byte
      since the DMA engine can transfer the whole of the image to its load
      address directly.  The worst case is the offset does not have even
      DMA-capable alignment (this is where we stand now).  In this case,
      we need to transfer every block to a bounce buffer, then do memcpy()
      from the bounce buffer to our final destination.  At least, this
      should work with the abstraction by the block I/O layer, but the
      CPU-intervention for the whole data transfer makes it really slow.
      
      This commit adds a new option --align to the fiptool.  This option,
      if given, requests the tool to align each component in the FIP file
      by the specified byte.  Also, add a new Make option FIP_ALIGN for
      easier access to this feature; users can give something like
      FIP_ALIGN=512 from the command line, or add "FIP_ALIGN := 512" to
      their platform.mk file.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      1c75d5df
    • Masahiro Yamada's avatar
      fiptool: embed fip_toc_entry in struct image · 65caa3d0
      Masahiro Yamada authored
      
      
      The struct image has "uuid" and "size" to memorize the field values
      they had in the TOC entry.  So, parse_fip() copies them from struct
      fip_toc_entry to struct image, then pack_images() copies them back
      to struct fip_toc_entry.
      
      The next commit (support --align option) will require to save the
      "offset" field as well.  This makes me realize that struct image
      can embed struct fip_toc_entry.
      
      This commit will allow the "flags" field to persevere the "update"
      command.  At this moment, the "flags" is not used in a useful way.
      (Yet, platforms can save their own parameters in the flags field.)
      It makes sense to save it unless users explicitly replace the image.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      65caa3d0
  24. 27 Jan, 2017 8 commits
  25. 14 Jan, 2017 2 commits
    • Masahiro Yamada's avatar
      fiptool: fix add_image() and add_image_desc() implementation · 11c0a4ff
      Masahiro Yamada authored
      The "make fip" shows the content of the generated FIP at the end of
      the build.  (This is shown by "fiptool info" command.)
      
      Prior to commit e0f083a0 ("fiptool: Prepare ground for expanding
      the set of images at runtime"), the last part of the build log of
       make CROSS_COMPILE=aarch64-linux-gnu- BL33=../u-boot/u-boot.bin fip
      was like follows:
      
       Trusted Boot Firmware BL2: offset=0xB0, size=0x4188, cmdline="--tb-fw"
       EL3 Runtime Firmware BL31: offset=0x4238, size=0x6090, cmdline="--soc-fw"
       Non-Trusted Firmware BL33: offset=0xA2C8, size=0x58B51, cmdline="--nt-fw"
      
      With that commit, now it is displayed like follows:
      
       Non-Trusted Firmware BL33: offset=0xB0, size=0x58B51, cmdline="--nt-fw"
       EL3 Runtime Firmware BL31: offset=0x58C01, size=0x6090, cmdline="--soc-fw"
       Trusted Boot Firmware BL2: offset=0x5EC91, size=0x4188, cmdline="--tb-fw"
      
      You will notice two differences:
        - the contents are displayed in BL33, BL31, BL2 order
        - the offset values are wrong
      
      The latter is more serious, and means "fiptool info" is broken.
      
      Another interesting change is "fiptool update" every time reverses
      the image order.  For example, if you input FIP with BL2, BL31, BL33
      in this order, the command will pack BL33, BL31, BL2 into FIP, in
      this order.  Of course, the order of components is not a big deal
      except that users will have poor impression about this.
      
      The root cause is in the implementation of add_image(); the
      image_head points to the last added image.  For example, if you call
      add_image() for BL2, BL31, BL33 in this order, the resulted image
      chain is:
      
        image_head -> BL33 -> BL31 -> BL2
      
      Then, they are processed from the image_head in "for" loops:
      
        for (image = image_head; image != NULL; image = image->next) {
      
      This means images are handled in Last-In First-Out manner.
      
      Interestingly, "fiptool create" is still correct because
      add_image_desc() also reverses the descriptor order and the command
      works as before due to the double reverse.
      
      The implementation of add_image() is efficient, but it made the
      situation too complicated.
      
      Let's make image_head point to the first added image.  This will
      add_image() inefficient because every call of add_image() follows
      the ->next chain to get the tail.  We can solve it by adopting a
      nicer linked list structure, but I am not doing as far as that
      because we handle only limited number of images anyway.
      
      Do likewise for add_image_desc().
      
      Fixes: e0f083a0
      
       ("fiptool: Prepare ground for expanding the set of images at runtime")
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      11c0a4ff
    • Masahiro Yamada's avatar
      fiptool: introduce xzalloc() helper function · 696ccba6
      Masahiro Yamada authored
      
      
      We often want to zero out allocated memory.
      
      My main motivation for this commit is to set image::next and
      image_desc::next to NULL automatically in the next commit.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      696ccba6