1. 04 Aug, 2020 1 commit
    • Grant Likely's avatar
      Use abspath to dereference $BUILD_BASE · 29214e95
      Grant Likely authored
      
      
      If the user tries to change BUILD_BASE to put the build products outside
      the build tree the compile will fail due to hard coded assumptions that
      $BUILD_BASE is a relative path. Fix by using $(abspath $(BUILD_BASE))
      to rationalize to an absolute path every time and remove the relative
      path assumptions.
      
      This patch also adds documentation that BUILD_BASE can be specified by
      the user.
      Signed-off-by: default avatarGrant Likely <grant.likely@arm.com>
      Signed-off-by: default avatarManish Pandey <manish.pandey2@arm.com>
      Change-Id: Ib1af874de658484aaffc672f30029b852d2489c8
      29214e95
  2. 30 Jul, 2020 2 commits
  3. 09 Jul, 2020 1 commit
  4. 29 Jun, 2020 1 commit
    • Sami Mujawar's avatar
      Fix makefile to build on a Windows host PC · 4a565bd8
      Sami Mujawar authored
      
      
      The TF-A firmware build system is capable of building on both Unix like
      and Windows host PCs. The commit ID 7ff088 "Enable MTE support" updated
      the Makefile to conditionally enable the MTE support if the AArch64
      architecture revision was greater than 8.5. However, the Makefile changes
      were dependent on shell commands that are only available on unix shells,
      resulting in build failures on a Windows host PC.
      
      This patch fixes the Makefile by using a more portable approach for
      comparing the architecture revision.
      
      Change-Id: Icb56cbecd8af5b0b9056d105970ff4a6edd1755a
      Signed-off-by: default avatarSami Mujawar <sami.mujawar@arm.com>
      4a565bd8
  5. 19 Jun, 2020 1 commit
  6. 12 Jun, 2020 1 commit
  7. 09 Jun, 2020 1 commit
  8. 08 Jun, 2020 1 commit
  9. 15 May, 2020 1 commit
  10. 14 May, 2020 1 commit
    • Manish V Badarkhe's avatar
      Implement workaround for AT speculative behaviour · 45aecff0
      Manish V Badarkhe authored
      During context switching from higher EL (EL2 or higher)
      to lower EL can cause incorrect translation in TLB due to
      speculative execution of AT instruction using out-of-context
      translation regime.
      
      Workaround is implemented as below during EL's (EL1 or EL2)
      "context_restore" operation:
      1. Disable page table walk using SCTLR.M and TCR.EPD0 & EPD1
         bits for EL1 or EL2 (stage1 and stage2 disabled)
      2. Save all system registers except TCR and SCTLR (for EL1 and EL2)
      3. Do memory barrier operation (isb) to ensure all
         system register writes are done.
      4. Restore TCR and SCTLR registers (for EL1 and EL2)
      
      Errata details are available for various CPUs as below:
      Cortex-A76: 1165522
      Cortex-A72: 1319367
      Cortex-A57: 1319537
      Cortex-A55: 1530923
      Cortex-A53: 1530924
      
      More details can be found in mail-chain:
      https://lists.trustedfirmware.org/pipermail/tf-a/2020-April/000445.html
      
      
      
      Currently, Workaround is implemented as build option which is default
      disabled.
      Signed-off-by: default avatarManish V Badarkhe <Manish.Badarkhe@arm.com>
      Change-Id: If8545e61f782cb0c2dda7ffbaf50681c825bd2f0
      45aecff0
  11. 25 Apr, 2020 1 commit
  12. 20 Apr, 2020 1 commit
  13. 02 Apr, 2020 1 commit
    • Masahiro Yamada's avatar
      Pass more -D options to BL*_CPPFLAGS instead of BL*_CFLAGS · 9cefb4b1
      Masahiro Yamada authored
      Commit d5e97a1d ("Build: define IMAGE_AT_EL1 or IMAGE_AT_EL3
      globally for C files") does not have commit 848a7e8c ("Build:
      introduce per-BL CPPFLAGS and ASFLAGS") as an ancestor because
      they were pulled almost at the same time.
      
      This is a follow-up conversion to be consistent with commit
      11a3c5ee
      
       ("plat: pass -D option to BL*_CPPFLAGS instead of
      BL*_CFLAGS").
      
      With this change, the command line option, IMAGE_AT_EL3, will be
      passed to .S files as well.
      
      I remove the definition in include/lib/cpus/aarch64/cpu_macros.S
      
      Otherwise, the following error would happen.
      
        include/lib/cpus/aarch64/cpu_macros.S:29:0: error: "IMAGE_AT_EL3" redefined [-Werror]
      
      Change-Id: I943c8f22356483c2ae3c57b515c69243a8fa6889
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      9cefb4b1
  14. 01 Apr, 2020 2 commits
    • Gilad Ben-Yossef's avatar
      cryptocell: add support for Cryptocell 713 · 4501843f
      Gilad Ben-Yossef authored
      
      
      Add Crypto 713 support as crypto module and NVM counter provider.
      
      As files under include/drivers/arm/cryptocell/713/ are copied verbatim
      from the CryptoCell SBROM lib project they are filtered from checkpatch
      coding style check.
      Signed-off-by: default avatarGilad Ben-Yossef <gilad@benyossef.com>
      Change-Id: I7c361772f00ca7d96481f81ac6cbb2704467e52c
      4501843f
    • Manish V Badarkhe's avatar
      Enable MTE support · 7ff088d1
      Manish V Badarkhe authored
      
      
      Enable MTE support by adding memory tag option in Makefile
      This option is available only when ARMv8.5-MemTag is implemented
      
      MTE options are added in latest clang and armclang compiler which
      support below options:
      for clang <version 11.0.0>
      1. -march=arm8.5-a+memtag
      2. -fsanitize=memtag
      
      for armclang <version 6.12>
      1. -march=arm8.5-a+memtag
      2. -mmemtag-stack
      
      Set the option SUPPORT_STACK_MEMTAG=yes to enable memory stack tagging.
      Signed-off-by: default avatarManish V Badarkhe <Manish.Badarkhe@arm.com>
      Change-Id: I4e0bbde4e9769ce03ead6f550158e22f32c1c413
      7ff088d1
  15. 31 Mar, 2020 2 commits
    • Ahmad Fatoum's avatar
      Makefile: don't use $(CC) before value is explicit set · 32b209bf
      Ahmad Fatoum authored
      Unless specified in the environment, $(CC) expands to some generic
      host C compiler like cc or c99. We set our own value for $(CC), but
      only few lines later.
      
      Move the first use of the $(CC) variable behind the definition to
      correct this.
      
      Change-Id: I45344e063d21ddfe22b7ad77954e85c1c46087bd
      Fixes: 1684b873
      
       ("Use clang assembler when clang compiler is used")
      Signed-off-by: default avatarAhmad Fatoum <a.fatoum@pengutronix.de>
      32b209bf
    • Masahiro Yamada's avatar
      Build: define IMAGE_AT_EL1 or IMAGE_AT_EL3 globally for C files · d5e97a1d
      Masahiro Yamada authored
      
      
      The build system defines the IMAGE_BL* macro when compiling each image.
      This is useful to distinguish which image the current file is being
      built for by using #if defined(IMAGE_BL2) or #if defined(IMAGE_BL31),
      or whatever.
      
      There are some cases where we are more interested in which exception
      level the current file is being built for.
      
      include/lib/cpus/{aarch32,aarch64}/cpu_macros.S defines IMAGE_AT_EL3,
      but we do not have it globally.
      
      Pass IMAGE_AT_EL1 or IMAGE_AT_EL3 to BL*_CFLAGS so that it is available
      from all C code.
      
      The library code (libc.a, libmbedtls.a, etc.) is exceptional cases,
      where the code can be shared between BL images.
      
      Other than that, we know the exception level at the build time, and
      this macro will be useful in the shared code.
      
      Change-Id: I7c8a1da10726906adfba981cfe8464dff111d6b0
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      d5e97a1d
  16. 25 Mar, 2020 1 commit
  17. 23 Mar, 2020 1 commit
  18. 16 Mar, 2020 1 commit
    • Louis Mayencourt's avatar
      fconf: Clean Arm IO · a6de824f
      Louis Mayencourt authored
      
      
      Merge the previously introduced arm_fconf_io_storage into arm_io_storage. This
      removes the duplicate io_policies and functions definition.
      
      This patch:
      - replace arm_io_storage.c with the content of arm_fconf_io_storage.c
      - rename the USE_FCONF_BASED_IO option into ARM_IO_IN_DTB.
      - use the ARM_IO_IN_DTB option to compile out io_policies moved in dtb.
      - propagate DEFINES when parsing dts.
      - use ARM_IO_IN_DTB to include or not uuid nodes in fw_config dtb.
      - set the ARM_IO_IN_DTB to 0 by default for fvp. This ensure that the behavior
        of fvp stays the same as it was before the introduction of fconf.
      
      Change-Id: Ia774a96d1d3a2bccad29f7ce2e2b4c21b26c080e
      Signed-off-by: default avatarLouis Mayencourt <louis.mayencourt@arm.com>
      a6de824f
  19. 11 Mar, 2020 1 commit
    • Madhukar Pappireddy's avatar
      fconf: necessary modifications to support fconf in BL31 & SP_MIN · 26d1e0c3
      Madhukar Pappireddy authored
      
      
      Necessary infrastructure added to integrate fconf framework in BL31 & SP_MIN.
      Created few populator() functions which parse HW_CONFIG device tree
      and registered them with fconf framework. Many of the changes are
      only applicable for fvp platform.
      
      This patch:
      1. Adds necessary symbols and sections in BL31, SP_MIN linker script
      2. Adds necessary memory map entry for translation in BL31, SP_MIN
      3. Creates an abstraction layer for hardware configuration based on
         fconf framework
      4. Adds necessary changes to build flow (makefiles)
      5. Minimal callback to read hw_config dtb for capturing properties
         related to GIC(interrupt-controller node)
      6. updates the fconf documentation
      
      Change-Id: Ib6292071f674ef093962b9e8ba0d322b7bf919af
      Signed-off-by: default avatarMadhukar Pappireddy <madhukar.pappireddy@arm.com>
      26d1e0c3
  20. 06 Mar, 2020 3 commits
    • Sumit Garg's avatar
      Makefile: Add support to optionally encrypt BL31 and BL32 · c6ba9b45
      Sumit Garg authored
      
      
      Following build flags have been added to support optional firmware
      encryption:
      
      - FW_ENC_STATUS: Top level firmware's encryption numeric flag, values:
          0: Encryption is done with Secret Symmetric Key (SSK) which is
             common for a class of devices.
          1: Encryption is done with Binding Secret Symmetric Key (BSSK) which
             is unique per device.
      
      - ENC_KEY: A 32-byte (256-bit) symmetric key in hex string format. It
          could be SSK or BSSK depending on FW_ENC_STATUS flag.
      
      - ENC_NONCE: A 12-byte (96-bit) encryption nonce or Initialization Vector
          (IV) in hex string format.
      
      - ENCRYPT_BL31: Binary flag to enable encryption of BL31 firmware.
      
      - ENCRYPT_BL32: Binary flag to enable encryption of Secure BL32 payload.
      
      Similar flags can be added to encrypt other firmwares as well depending
      on use-cases.
      Signed-off-by: default avatarSumit Garg <sumit.garg@linaro.org>
      Change-Id: I94374d6830ad5908df557f63823e58383d8ad670
      c6ba9b45
    • Sumit Garg's avatar
      tools: Add firmware authenticated encryption tool · 90aa901f
      Sumit Garg authored
      
      
      Add firmware authenticated encryption tool which utilizes OpenSSL
      library to encrypt firmwares using a key provided via cmdline. Currently
      this tool supports AES-GCM as an authenticated encryption algorithm.
      Signed-off-by: default avatarSumit Garg <sumit.garg@linaro.org>
      Change-Id: I60e296af1b98f1912a19d5f91066be7ea85836e4
      90aa901f
    • Sumit Garg's avatar
      drivers: crypto: Add authenticated decryption framework · 7cda17bb
      Sumit Garg authored
      
      
      Add framework for autheticated decryption of data. Currently this
      patch optionally imports mbedtls library as a backend if build option
      "DECRYPTION_SUPPORT = aes_gcm" is set to perform authenticated decryption
      using AES-GCM algorithm.
      Signed-off-by: default avatarSumit Garg <sumit.garg@linaro.org>
      Change-Id: I2966f0e79033151012bf4ffc66f484cd949e7271
      7cda17bb
  21. 03 Mar, 2020 1 commit
  22. 02 Mar, 2020 1 commit
  23. 24 Feb, 2020 1 commit
    • Petre-Ionut Tudor's avatar
      Read-only xlat tables for BL31 memory · 60e8f3cf
      Petre-Ionut Tudor authored
      
      
      This patch introduces a build flag which allows the xlat tables
      to be mapped in a read-only region within BL31 memory. It makes it
      much harder for someone who has acquired the ability to write to
      arbitrary secure memory addresses to gain control of the
      translation tables.
      
      The memory attributes of the descriptors describing the tables
      themselves are changed to read-only secure data. This change
      happens at the end of BL31 runtime setup. Until this point, the
      tables have read-write permissions. This gives a window of
      opportunity for changes to be made to the tables with the MMU on
      (e.g. reclaiming init code). No changes can be made to the tables
      with the MMU turned on from this point onwards. This change is also
      enabled for sp_min and tspd.
      
      To make all this possible, the base table was moved to .rodata. The
      penalty we pay is that now .rodata must be aligned to the size of
      the base table (512B alignment). Still, this is better than putting
      the base table with the higher level tables in the xlat_table
      section, as that would cost us a full 4KB page.
      
      Changing the tables from read-write to read-only cannot be done with
      the MMU on, as the break-before-make sequence would invalidate the
      descriptor which resolves the level 3 page table where that very
      descriptor is located. This would make the translation required for
      writing the changes impossible, generating an MMU fault.
      
      The caches are also flushed.
      Signed-off-by: default avatarPetre-Ionut Tudor <petre-ionut.tudor@arm.com>
      Change-Id: Ibe5de307e6dc94c67d6186139ac3973516430466
      60e8f3cf
  24. 20 Feb, 2020 1 commit
    • Manish Pandey's avatar
      SPMD: generate and add Secure Partition blobs into FIP · ce2b1ec6
      Manish Pandey authored
      
      
      Till now TF-A allows limited number of external images to be made part
      of FIP. With SPM coming along, there may exist multiple SP packages
      which need to be inserted into FIP. To achieve this we need a more
      scalable approach to feed SP packages to FIP.
      
      This patch introduces changes in build system to generate and add SP
      packages into FIP based on information provided by platform.
      Platform provides information in form of JSON which contains layout
      description of available Secure Partitions.
      JSON parser script is invoked by build system early on and generates
      a makefile which updates FIP, SPTOOL and FDT arguments which will be
      used by build system later on for final packaging.
      
      "SP_LAYOUT_FILE" passed as a build argument and can be outside of TF-A
      tree. This option will be used only when SPD=spmd.
      
      For each SP, generated makefile will have following entries
           - FDT_SOURCES	+=	sp1.dts
           - SPTOOL_ARGS	+= 	-i sp1.img:sp1.dtb -o sp1.pkg
           - FIP_ARGS		+=	--blob uuid=XXXX-XXX...,file=SP1.pkg
      Signed-off-by: default avatarManish Pandey <manish.pandey2@arm.com>
      Change-Id: Ib6a9c064400caa3cd825d9886008a3af67741af7
      ce2b1ec6
  25. 14 Feb, 2020 1 commit
  26. 12 Feb, 2020 1 commit
  27. 10 Feb, 2020 1 commit
  28. 07 Feb, 2020 1 commit
    • Louis Mayencourt's avatar
      fconf: Move platform io policies into fconf · 0a6e7e3b
      Louis Mayencourt authored
      
      
      Use the firmware configuration framework to store the io_policies
      information inside the configuration device tree instead of the static
      structure in the code base.
      
      The io_policies required by BL1 can't be inside the dtb, as this one is
      loaded by BL1, and only available at BL2.
      
      This change currently only applies to FVP platform.
      
      Change-Id: Ic9c1ac3931a4a136aa36f7f58f66d3764c1bfca1
      Signed-off-by: default avatarLouis Mayencourt <louis.mayencourt@arm.com>
      0a6e7e3b
  29. 29 Jan, 2020 2 commits
  30. 28 Jan, 2020 2 commits
    • Madhukar Pappireddy's avatar
      Enable -Wredundant-decls warning check · ca661a00
      Madhukar Pappireddy authored
      
      
      This flag warns if anything is declared more than once in the same
      scope, even in cases where multiple declaration is valid and changes
      nothing.
      
      Consequently, this patch also fixes the issues reported by this
      flag. Consider the following two lines of code from two different source
      files(bl_common.h and bl31_plat_setup.c):
      
      IMPORT_SYM(uintptr_t, __RO_START__, BL_CODE_BASE);
      IMPORT_SYM(unsigned long, __RO_START__, BL2_RO_BASE);
      
      The IMPORT_SYM macro which actually imports a linker symbol as a C expression.
      The macro defines the __RO_START__ as an extern variable twice, one for each
      instance. __RO_START__ symbol is defined by the linker script to mark the start
      of the Read-Only area of the memory map.
      
      Essentially, the platform code redefines the linker symbol with a different
      (relevant) name rather than using the standard symbol. A simple solution to
      fix this issue in the platform code for redundant declarations warning is
      to remove the second IMPORT_SYM and replace it with following assignment
      
      static const unsigned long BL2_RO_BASE = BL_CODE_BASE;
      
      Change-Id: If4835d1ee462d52b75e5afd2a59b64828707c5aa
      Signed-off-by: default avatarMadhukar Pappireddy <madhukar.pappireddy@arm.com>
      ca661a00
    • Alexei Fedorov's avatar
      Measured Boot: add function for hash calculation · 8c105290
      Alexei Fedorov authored
      
      
      This patch adds 'calc_hash' function using Mbed TLS library
      required for Measured Boot support.
      
      Change-Id: Ifc5aee0162d04db58ec6391e0726a526f29a52bb
      Signed-off-by: default avatarAlexei Fedorov <Alexei.Fedorov@arm.com>
      8c105290
  31. 24 Jan, 2020 3 commits
    • Masahiro Yamada's avatar
      TSP: add PIE support · d974301d
      Masahiro Yamada authored
      
      
      This implementation simply mimics that of BL31.
      
      Change-Id: Ibbaa4ca012d38ac211c52b0b3e97449947160e07
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      d974301d
    • Masahiro Yamada's avatar
      BL2_AT_EL3: add PIE support · 69af7fcf
      Masahiro Yamada authored
      
      
      This implementation simply mimics that of BL31.
      
      I did not implement the ENABLE_PIE support for BL2_IN_XIP_MEM=1 case.
      It would make the linker script a bit uglier.
      
      Change-Id: If3215abd99f2758dfb232e44b50320d04eba808b
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      69af7fcf
    • Masahiro Yamada's avatar
      PIE: pass PIE options only to BL31 · 320920c1
      Masahiro Yamada authored
      
      
      docs/getting_started/build-options.rst clearly says ENABLE_PIE is
      currently only supported in BL31, but in fact, it has a stronger
      limitation:
      
        Defining ENABLE_PIE may corrupt BL1 and BL2. So, ENABLE_PIE is
        supported only for platforms where BL31 is the only image built
        in the TF-A tree.
      
      Currently, ENABLE_PIE is enabled by two platforms,
      plat/arm/common/arm_common.mk and ti/k3/common/plat_common.mk,
      both of which enable ENABLE_PIE together with RESET_TO_BL31.
      
      For platforms with the full boot sequence, ENABLE_PIE may break earlier
      BL stages. For example, if I build PLAT=qemu with ENABLE_PIE=1, it
      fails in BL1.
      
      When ENABLE_PIE is enabled, PIE options are added to TF_CFLAGS and
      TF_LDFLAGS, so all BL images are affected. It is problematic because
      currently only the BL31 linker script handles it. Even if BL1/BL2
      works, the image size would increase needlessly, at least.
      
      Pass the PIE options only to BL images that support it.
      
      Change-Id: I550e95148aa3c63571c8ad2081082c554a848f57
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      320920c1