1. 27 Jan, 2021 2 commits
    • Jimmy Brisson's avatar
      cert-tool: avoid duplicates in extension stack · 1ed941c0
      Jimmy Brisson authored
      
      
      This bug manifests itself as a segfault triggered by a double-free.
      
      I noticed that right before the double-free, the sk list contained 2
      elements with the same address.
      
          (gdb) p sk_X509_EXTENSION_value(sk, 1)
          $34 = (X509_EXTENSION *) 0x431ad0
          (gdb) p sk_X509_EXTENSION_value(sk, 0)
          $35 = (X509_EXTENSION *) 0x431ad0
          (gdb) p sk_X509_EXTENSION_num(sk)
          $36 = 2
      
      This caused confusion; this should never happen.
      
      I figured that this was caused by a ext_new_xxxx function freeing
      something before it is added to the list, so I put a breakpoint on
      each of them to step through. I was suprised to find that none of my
      breakpoints triggered for the second element of the iteration through
      the outer loop just before the double-free.
      
      Looking through the code, I noticed that it's possible to avoid doing
      a ext_new_xxxx, when either:
         * ext->type == NVCOUNTER and ext->arg == NULL
         * ext->type == HASH and ext->arg == NULL and ext->optional == false
      So I put a breakpoint on both.
      
      It turns out that it was the HASH version, but I added a fix for both.
      The fix for the Hash case is simple, as it was a mistake. The fix for
      the NVCOUNTER case, however, is a bit more subtle. The NVCOUNTER may
      be optional, and when it's optional we can skip it. The other case,
      when the NVCOUNTER is required (not optinal), the `check_cmd_params`
      function has already verified that the `ext->arg` must be non-NULL.
      We assert that before processing it to covert any possible segfaults
      into more descriptive errors.
      
      This should no longer cause double-frees by adding the same ext twice.
      
      Change-Id: Idae2a24ecd964b0a3929e6193c7f85ec769f6470
      Signed-off-by: default avatarJimmy Brisson <jimmy.brisson@arm.com>
      1ed941c0
    • Manish V Badarkhe's avatar
      tools: cert_create: Create only requested certificates · 294e2656
      Manish V Badarkhe authored
      
      
      The certification tool creates all the certificates mentioned
      statically in the code rather than taking explicit certificate
      requests from the command line parameters.
      
      Code is optimized to avoid unnecessary attempts to create
      non-requested certificates.
      Signed-off-by: default avatarManish V Badarkhe <Manish.Badarkhe@arm.com>
      Change-Id: I78feac25bc701bf8f08c6aa5a2e1590bec92d0f2
      294e2656
  2. 20 Oct, 2020 4 commits
  3. 12 Aug, 2020 1 commit
    • Manish Pandey's avatar
      cert_create: add Platform owned secure partitions support · 23d5f03a
      Manish Pandey authored
      
      
      Add support to generate a certificate named "plat-sp-cert" for Secure
      Partitions(SP) owned by Platform.
      Earlier a single certificate file "sip-sp-cert" was generated which
      contained hash of all 8 SPs, with this change SPs are divided into
      two categories viz "SiP owned" and "Plat owned" containing 4 SPs each.
      
      Platform RoT key pair is used for signing.
      Signed-off-by: default avatarManish Pandey <manish.pandey2@arm.com>
      Change-Id: I5bd493cfce4cf3fc14b87c8ed1045f633d0c92b6
      23d5f03a
  4. 24 Jun, 2020 1 commit
  5. 11 Jun, 2020 1 commit
  6. 08 Jun, 2020 1 commit
    • Manish Pandey's avatar
      cert_create: add SiP owned secure partitions support · 0792dd7d
      Manish Pandey authored
      
      
      Add support to generate certificate "sip-sp-cert" for Secure
      Partitions(SP) owned by Silicon provider(SiP).
      To avoid deviation from TBBR specification the support is only added for
      dualroot CoT and not for TBBR CoT.
      
      A single certificate file is generated containing hash of individual
      packages. Maximum 8 secure partitions are supported.
      
      Following new options added to cert_tool:
       --sip-sp-cert --> SiP owned Secure Partition Content Certificate
       --sp-pkg1 --> Secure Partition Package1 file
       --sp-pkg2
       .....
       --sp-pkg8
      
      Trusted world key pair is used for signing.
      
      Going forward, this feature can be extended for Platfrom owned
      Partitions, if required.
      Signed-off-by: default avatarManish Pandey <manish.pandey2@arm.com>
      Change-Id: Ia6dfbc1447cfb41b1fcbd12cf2bf7b88f409bd8d
      0792dd7d
  7. 24 Feb, 2020 1 commit
  8. 29 Jan, 2020 2 commits
  9. 14 Jan, 2020 1 commit
  10. 12 Sep, 2019 2 commits
    • Justin Chadwell's avatar
      Remove RSA PKCS#1 v1.5 support from cert_tool · 6a415a50
      Justin Chadwell authored
      Support for PKCS#1 v1.5 was deprecated in SHA 1001202d and fully removed
      in SHA fe199e3b
      
      , however, cert_tool is still able to generate
      certificates in that form. This patch fully removes the ability for
      cert_tool to generate these certificates.
      
      Additionally, this patch also fixes a bug where the issuing certificate
      was a RSA and the issued certificate was EcDSA. In this case, the issued
      certificate would be signed using PKCS#1 v1.5 instead of RSAPSS per
      PKCS#1 v2.1, preventing TF-A from verifying the image signatures. Now
      that PKCS#1 v1.5 support is removed, all certificates that are signed
      with RSA now use the more modern padding scheme.
      
      Change-Id: Id87d7d915be594a1876a73080528d968e65c4e9a
      Signed-off-by: default avatarJustin Chadwell <justin.chadwell@arm.com>
      6a415a50
    • Justin Chadwell's avatar
      Add cert_create tool support for RSA key sizes · dfe0f4c2
      Justin Chadwell authored
      
      
      cert_tool is now able to accept a command line option for specifying the
      key size. It now supports the following options: 1024, 2048 (default),
      3072 and 4096. This is also modifiable by TFA using the build flag
      KEY_SIZE.
      
      Change-Id: Ifadecf84ade3763249ee8cc7123a8178f606f0e5
      Signed-off-by: default avatarJustin Chadwell <justin.chadwell@arm.com>
      dfe0f4c2
  11. 16 Aug, 2019 1 commit
  12. 12 Mar, 2019 1 commit
  13. 27 Jun, 2018 1 commit
  14. 18 May, 2018 1 commit
  15. 26 Feb, 2018 1 commit
    • Soby Mathew's avatar
      Dynamic cfg: Update the tools · e24659df
      Soby Mathew authored
      
      
      This patch updates the `fiptool` and `cert_create` for the
      `hw_config` and `tb_fw_config` dynamic configuration files.
      The necessary UUIDs and OIDs are assigned to these files and
      the `cert_create` is updated to generate appropriate hashes
      and include them in the "Trusted Boot FW Certificate". The
      `fiptool` is updated to allow the configs to be specified
      via cmdline and included in the generated FIP.
      
      Change-Id: I940e751a49621ae681d14e162aa1f5697eb0cb15
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      e24659df
  16. 21 Nov, 2017 1 commit
  17. 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
  18. 08 Oct, 2017 1 commit
  19. 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
  20. 09 Aug, 2017 1 commit
  21. 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
  22. 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
  23. 23 May, 2017 1 commit
    • 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
  24. 03 May, 2017 1 commit
  25. 14 Feb, 2017 1 commit
  26. 11 Feb, 2017 3 commits
  27. 05 Jul, 2016 1 commit
    • Yatharth Kochar's avatar
      Fix `cert_create` tool for Segmentation fault · f16db56a
      Yatharth Kochar authored
      With the introduction of commit `96103d5a`, the Certificate
      Generation tool is not able to generate FWU certificate and
      while doing so it does segmentation fault.
      
      This happens because it is now required to pass non-volatile
      counter values to the `cert_create` tool from the command line
      for creating the trusted firmware certificates.
      
      But in case of creating FWU certificate these counter values are not
      being passed to the tool and as a consequence the `cert_create` tool
      try to use the NULL argument and errors out with Segmentation fault.
      
      This patch fixes this issue by providing a check before using the
      command line argument passed in the case of `EXT_TYPE_NVCOUNTER`
      certificate extension.
      
      Change-Id: Ie17d0c1502b52aaa8500f3659c2da2448ab0347a
      f16db56a
  28. 30 Mar, 2016 1 commit
    • Juan Castillo's avatar
      cert_create: add non-volatile counter support · 96103d5a
      Juan Castillo authored
      This patch adds non-volatile counter support to the Certificate
      Generation tool. The TBBR Chain of Trust definition in the tool
      has been extended to include the counters as certificate extensions.
      The counter values can be specified in the command line.
      
      The following default counter values are specified in the build
      system:
      
        * Trusted FW Non-Volatile counter = 0
        * Non-Trusted FW Non-Volatile counter = 0
      
      These values can be overridden by the platform at build time.
      
      Change-Id: I7ea10ee78d72748d181df4ee78a7169b3ef2720c
      96103d5a
  29. 07 Jan, 2016 1 commit
    • Juan Castillo's avatar
      cert_create: update help message · 159807e2
      Juan Castillo authored
      The help message printed by the cert_create tool using the command
      line option -h (or --help) does not correctly list all the available
      command line options.
      
      This patch reworks the print_help() function to print the help
      messages in a data driven approach. For each command line option
      registered, an optional help message can be specified, which will
      be printed by print_help().
      
      Help messages for the TBBR options (certificates, keys and images)
      are also provided.
      
      Fix a small bug in the short options string passed to getopt_long:
      the ':' was missing in the '-a' option (this option must take an
      argument).
      
      Fixes ARM-software/tf-issues#337
      
      Change-Id: I9d08c2dfd349022808fcc884724f677eefdc1452
      159807e2
  30. 14 Dec, 2015 2 commits
    • Juan Castillo's avatar
      Replace all SCP FW (BL0, BL3-0) references · f59821d5
      Juan Castillo authored
      This patch replaces all references to the SCP Firmware (BL0, BL30,
      BL3-0, bl30) with the image terminology detailed in the TF wiki
      (https://github.com/ARM-software/arm-trusted-firmware/wiki):
      
          BL0          -->  SCP_BL1
          BL30, BL3-0  -->  SCP_BL2
          bl30         -->  scp_bl2
      
      This change affects code, documentation, build system, tools and
      platform ports that load SCP firmware. ARM plaforms have been
      updated to the new porting API.
      
      IMPORTANT: build option to specify the SCP FW image has changed:
      
          BL30 --> SCP_BL2
      
      IMPORTANT: This patch breaks compatibility for platforms that use BL2
      to load SCP firmware. Affected platforms must be updated as follows:
      
          BL30_IMAGE_ID --> SCP_BL2_IMAGE_ID
          BL30_BASE --> SCP_BL2_BASE
          bl2_plat_get_bl30_meminfo() --> bl2_plat_get_scp_bl2_meminfo()
          bl2_plat_handle_bl30() --> bl2_plat_handle_scp_bl2()
      
      Change-Id: I24c4c1a4f0e4b9f17c9e4929da815c4069549e58
      f59821d5
    • Juan Castillo's avatar
      TBB: apply TBBR naming convention to certificates and extensions · 516beb58
      Juan Castillo authored
      This patch applies the TBBR naming convention to the certificates
      and the corresponding extensions defined by the CoT:
      
          * Certificate UUID names
          * Certificate identifier names
          * OID names
      
      Changes apply to:
      
          * Generic code (variables and defines)
          * The default certificate identifiers provided in the generic
            code
          * Build system
          * ARM platforms port
          * cert_create tool internal definitions
          * fip_create and cert_create tools command line options
          * Documentation
      
      IMPORTANT: this change breaks the compatibility with platforms
      that use TBBR. The platform will need to adapt the identifiers
      and OIDs to the TBBR naming convention introduced by this patch:
      
      Certificate UUIDs:
      
          UUID_TRUSTED_BOOT_FIRMWARE_BL2_CERT --> UUID_TRUSTED_BOOT_FW_CERT
          UUID_SCP_FIRMWARE_BL30_KEY_CERT --> UUID_SCP_FW_KEY_CERT
          UUID_SCP_FIRMWARE_BL30_CERT --> UUID_SCP_FW_CONTENT_CERT
          UUID_EL3_RUNTIME_FIRMWARE_BL31_KEY_CERT --> UUID_SOC_FW_KEY_CERT
          UUID_EL3_RUNTIME_FIRMWARE_BL31_CERT --> UUID_SOC_FW_CONTENT_CERT
          UUID_SECURE_PAYLOAD_BL32_KEY_CERT --> UUID_TRUSTED_OS_FW_KEY_CERT
          UUID_SECURE_PAYLOAD_BL32_CERT --> UUID_TRUSTED_OS_FW_CONTENT_CERT
          UUID_NON_TRUSTED_FIRMWARE_BL33_KEY_CERT --> UUID_NON_TRUSTED_FW_KEY_CERT
          UUID_NON_TRUSTED_FIRMWARE_BL33_CERT --> UUID_NON_TRUSTED_FW_CONTENT_CERT
      
      Certificate identifiers:
      
          BL2_CERT_ID --> TRUSTED_BOOT_FW_CERT_ID
          BL30_KEY_CERT_ID --> SCP_FW_KEY_CERT_ID
          BL30_CERT_ID --> SCP_FW_CONTENT_CERT_ID
          BL31_KEY_CERT_ID --> SOC_FW_KEY_CERT_ID
          BL31_CERT_ID --> SOC_FW_CONTENT_CERT_ID
          BL32_KEY_CERT_ID --> TRUSTED_OS_FW_KEY_CERT_ID
          BL32_CERT_ID --> TRUSTED_OS_FW_CONTENT_CERT_ID
          BL33_KEY_CERT_ID --> NON_TRUSTED_FW_KEY_CERT_ID
          BL33_CERT_ID --> NON_TRUSTED_FW_CONTENT_CERT_ID
      
      OIDs:
      
          TZ_FW_NVCOUNTER_OID --> TRUSTED_FW_NVCOUNTER_OID
          NTZ_FW_NVCOUNTER_OID --> NON_TRUSTED_FW_NVCOUNTER_OID
          BL2_HASH_OID --> TRUSTED_BOOT_FW_HASH_OID
          TZ_WORLD_PK_OID --> TRUSTED_WORLD_PK_OID
          NTZ_WORLD_PK_OID --> NON_TRUSTED_WORLD_PK_OID
          BL30_CONTENT_CERT_PK_OID --> SCP_FW_CONTENT_CERT_PK_OID
          BL30_HASH_OID --> SCP_FW_HASH_OID
          BL31_CONTENT_CERT_PK_OID --> SOC_FW_CONTENT_CERT_PK_OID
          BL31_HASH_OID --> SOC_AP_FW_HASH_OID
          BL32_CONTENT_CERT_PK_OID --> TRUSTED_OS_FW_CONTENT_CERT_PK_OID
          BL32_HASH_OID --> TRUSTED_OS_FW_HASH_OID
          BL33_CONTENT_CERT_PK_OID --> NON_TRUSTED_FW_CONTENT_CERT_PK_OID
          BL33_HASH_OID --> NON_TRUSTED_WORLD_BOOTLOADER_HASH_OID
          BL2U_HASH_OID --> AP_FWU_CFG_HASH_OID
          SCP_BL2U_HASH_OID --> SCP_FWU_CFG_HASH_OID
          NS_BL2U_HASH_OID --> FWU_HASH_OID
      
      Change-Id: I1e047ae046299ca913911c39ac3a6e123bd41079
      516beb58
  31. 09 Dec, 2015 1 commit
    • Yatharth Kochar's avatar
      FWU: Add FWU support to `cert_create` tool · cebe1f23
      Yatharth Kochar authored
      Firmware Update requires an X509v3 certificate which contains
      hashes for SCP_BL2U, BL2U and NS_BL2U images as extensions.
      
      This patch extends the Chain of Trust definition in the
      'cert_create' tool to include the Firmware Update certificate
      and the required extensions (including command line options).
      A new field in the extension structure will be used to indicate
      that the extension is optional. In the case of an image hash
      extension, this field will tell the tool that the hash should
      be included in the certificate, but filled with zeros.
      
      Change-Id: I1f77a66b018826b71745910771f38d9cf6050388
      cebe1f23