1. 11 Dec, 2018 1 commit
  2. 10 Dec, 2018 1 commit
  3. 28 Sep, 2018 5 commits
  4. 04 Sep, 2018 1 commit
    • John Tsichritzis's avatar
      Prepare Mbed TLS drivers for shared heap · 6d01a463
      John Tsichritzis authored
      
      
      The Mbed TLS drivers, in order to work, need a heap for internal usage.
      This heap, instead of being directly referenced by the drivers, now it
      is being accessed indirectly through a pointer. Also, the heap, instead
      of being part of the drivers, now it is being received through the
      plat_get_mbedtls_heap() function. This function requests a heap from the
      current BL image which utilises the Mbed TLS drivers.
      
      Those changes create the opportunity for the Mbed TLS heap to be shared
      among different images, thus saving memory. A default heap
      implementation is provided but it can be overridden by a platform
      specific, optimised implemenetation.
      
      Change-Id: I286a1f10097a9cdcbcd312201eea576c18d157fa
      Signed-off-by: default avatarJohn Tsichritzis <john.tsichritzis@arm.com>
      6d01a463
  5. 22 Aug, 2018 1 commit
  6. 24 Jul, 2018 1 commit
  7. 04 May, 2018 1 commit
    • Jeenu Viswambharan's avatar
      AArch64: Introduce External Abort handling · 76454abf
      Jeenu Viswambharan authored
      
      
      At present, any External Abort routed to EL3 is reported as an unhandled
      exception and cause a panic. This patch enables ARM Trusted Firmware to
      handle External Aborts routed to EL3.
      
      With this patch, when an External Abort is received at EL3, its handling
      is delegated to plat_ea_handler() function. Platforms can provide their
      own implementation of this function. This patch adds a weak definition
      of the said function that prints out a message and just panics.
      
      In order to support handling External Aborts at EL3, the build option
      HANDLE_EA_EL3_FIRST must be set to 1.
      
      Before this patch, HANDLE_EA_EL3_FIRST wasn't passed down to
      compilation; this patch fixes that too.
      
      Change-Id: I4d07b7e65eb191ff72d63b909ae9512478cd01a1
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      76454abf
  8. 28 Feb, 2018 2 commits
  9. 26 Feb, 2018 3 commits
    • Soby Mathew's avatar
      BL1: Deprecate the `bl1_init_bl2_mem_layout()` API · 101d01e2
      Soby Mathew authored
      
      
      The `bl1_init_bl2_mem_layout()` API is now deprecated. The default weak
      implementation of `bl1_plat_handle_post_image_load()` calculates the
      BL2 memory layout and populates the same in x1(r1). This ensures
      compatibility for the deprecated API.
      
      Change-Id: Id44bdc1f572dc42ee6ceef4036b3a46803689315
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      101d01e2
    • Soby Mathew's avatar
      Introduce the new BL handover interface · a6f340fe
      Soby Mathew authored
      
      
      This patch introduces a new BL handover interface. It essentially allows
      passing 4 arguments between the different BL stages. Effort has been made
      so as to be compatible with the previous handover interface. The previous
      blx_early_platform_setup() platform API is now deprecated and the new
      blx_early_platform_setup2() variant is introduced. The weak compatiblity
      implementation for the new API is done in the `plat_bl_common.c` file.
      Some of the new arguments in the new API will be reserved for generic
      code use when dynamic configuration support is implemented. Otherwise
      the other registers are available for platform use.
      
      Change-Id: Ifddfe2ea8e32497fe1beb565cac155ad9d50d404
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      a6f340fe
    • Soby Mathew's avatar
      Add image_id to bl1_plat_handle_post/pre_image_load() · 566034fc
      Soby Mathew authored
      
      
      This patch adds an argument to bl1_plat_post/pre_image_load() APIs
      to make it more future proof. The default implementation of
      these are moved to `plat_bl1_common.c` file.
      
      These APIs are now invoked appropriately in the FWU code path prior
      to or post image loading by BL1 and are not restricted
      to LOAD_IMAGE_V2.
      
      The patch also reorganizes some common platform files. The previous
      `plat_bl2_el3_common.c` and `platform_helpers_default.c` files are
      merged into a new `plat_bl_common.c` file.
      
      NOTE: The addition of an argument to the above mentioned platform APIs
      is not expected to have a great impact because these APIs were only
      recently added and are unlikely to be used.
      
      Change-Id: I0519caaee0f774dd33638ff63a2e597ea178c453
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      566034fc
  10. 01 Feb, 2018 2 commits
  11. 18 Jan, 2018 1 commit
    • Roberto Vargas's avatar
      bl2-el3: Add BL2_EL3 image · b1d27b48
      Roberto Vargas authored
      
      
      This patch enables BL2 to execute at the highest exception level
      without any dependancy on TF BL1. This enables platforms which already
      have a non-TF Boot ROM to directly load and execute BL2 and subsequent BL
      stages without need for BL1.  This is not currently possible because
      BL2 executes at S-EL1 and cannot jump straight to EL3.
      
      Change-Id: Ief1efca4598560b1b8c8e61fbe26d1f44e929d69
      Signed-off-by: default avatarRoberto Vargas <roberto.vargas@arm.com>
      b1d27b48
  12. 13 Nov, 2017 2 commits
  13. 08 Nov, 2017 1 commit
    • Antonio Nino Diaz's avatar
      SPM: Introduce Secure Partition Manager · 2fccb228
      Antonio Nino Diaz authored
      
      
      A Secure Partition is a software execution environment instantiated in
      S-EL0 that can be used to implement simple management and security
      services. Since S-EL0 is an unprivileged exception level, a Secure
      Partition relies on privileged firmware e.g. ARM Trusted Firmware to be
      granted access to system and processor resources. Essentially, it is a
      software sandbox that runs under the control of privileged software in
      the Secure World and accesses the following system resources:
      
      - Memory and device regions in the system address map.
      - PE system registers.
      - A range of asynchronous exceptions e.g. interrupts.
      - A range of synchronous exceptions e.g. SMC function identifiers.
      
      A Secure Partition enables privileged firmware to implement only the
      absolutely essential secure services in EL3 and instantiate the rest in
      a partition. Since the partition executes in S-EL0, its implementation
      cannot be overly complex.
      
      The component in ARM Trusted Firmware responsible for managing a Secure
      Partition is called the Secure Partition Manager (SPM). The SPM is
      responsible for the following:
      
      - Validating and allocating resources requested by a Secure Partition.
      - Implementing a well defined interface that is used for initialising a
        Secure Partition.
      - Implementing a well defined interface that is used by the normal world
        and other secure services for accessing the services exported by a
        Secure Partition.
      - Implementing a well defined interface that is used by a Secure
        Partition to fulfil service requests.
      - Instantiating the software execution environment required by a Secure
        Partition to fulfil a service request.
      
      Change-Id: I6f7862d6bba8732db5b73f54e789d717a35e802f
      Co-authored-by: default avatarDouglas Raillard <douglas.raillard@arm.com>
      Co-authored-by: default avatarSandrine Bailleux <sandrine.bailleux@arm.com>
      Co-authored-by: default avatarAchin Gupta <achin.gupta@arm.com>
      Co-authored-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      2fccb228
  14. 24 Oct, 2017 1 commit
  15. 16 Oct, 2017 10 commits
  16. 11 Sep, 2017 1 commit
    • Soby Mathew's avatar
      Implement log framework · 7f56e9a3
      Soby Mathew authored
      
      
      This patch gives users control over logging messages printed from the C
      code using the LOG macros defined in debug.h Users now have the ability
      to reduce the log_level at run time using the tf_log_set_max_level()
      function. The default prefix string can be defined by platform by
      overriding the `plat_log_get_prefix()` platform API which is also
      introduced in this patch.
      
      The new log framework results in saving of some RO data. For example,
      when BL1 is built for FVP with LOG_LEVEL=LOG_LEVEL_VERBOSE, resulted
      in saving 384 bytes of RO data and increase of 8 bytes of RW data. The
      framework also adds about 108 bytes of code to the release build of FVP.
      
      Fixes ARM-software/tf-issues#462
      
      Change-Id: I476013d9c3deedfdd4c8b0b0f125665ba6250554
      Co-authored-by: default avatarEleanor Bonnici <Eleanor.bonnici@arm.com>
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      7f56e9a3
  17. 03 May, 2017 1 commit
  18. 31 Mar, 2017 2 commits
    • Douglas Raillard's avatar
      Add support for GCC stack protection · 51faada7
      Douglas Raillard authored
      
      
      Introduce new build option ENABLE_STACK_PROTECTOR. It enables
      compilation of all BL images with one of the GCC -fstack-protector-*
      options.
      
      A new platform function plat_get_stack_protector_canary() is introduced.
      It returns a value that is used to initialize the canary for stack
      corruption detection. Returning a random value will prevent an attacker
      from predicting the value and greatly increase the effectiveness of the
      protection.
      
      A message is printed at the ERROR level when a stack corruption is
      detected.
      
      To be effective, the global data must be stored at an address
      lower than the base of the stacks. Failure to do so would allow an
      attacker to overwrite the canary as part of an attack which would void
      the protection.
      
      FVP implementation of plat_get_stack_protector_canary is weak as
      there is no real source of entropy on the FVP. It therefore relies on a
      timer's value, which could be predictable.
      
      Change-Id: Icaaee96392733b721fa7c86a81d03660d3c1bc06
      Signed-off-by: default avatarDouglas Raillard <douglas.raillard@arm.com>
      51faada7
    • Antonio Nino Diaz's avatar
      Add and use plat_crash_console_flush() API · 801cf93c
      Antonio Nino Diaz authored
      
      
      This API makes sure that all the characters sent to the crash console
      are output before returning from it.
      
      Porting guide updated.
      
      Change-Id: I1785f970a40f6aacfbe592b6a911b1f249bb2735
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      801cf93c
  19. 13 Feb, 2017 1 commit
    • dp-arm's avatar
      PSCI: Decouple PSCI stat residency calculation from PMF · 04c1db1e
      dp-arm authored
      
      
      This patch introduces the following three platform interfaces:
      
      * void plat_psci_stat_accounting_start(const psci_power_state_t *state_info)
      
        This is an optional hook that platforms can implement in order
        to perform accounting before entering a low power state.  This
        typically involves capturing a timestamp.
      
      * void plat_psci_stat_accounting_stop(const psci_power_state_t *state_info)
      
        This is an optional hook that platforms can implement in order
        to perform accounting after exiting from a low power state.  This
        typically involves capturing a timestamp.
      
      * u_register_t plat_psci_stat_get_residency(unsigned int lvl,
      	const psci_power_state_t *state_info,
      	unsigned int last_cpu_index)
      
        This is an optional hook that platforms can implement in order
        to calculate the PSCI stat residency.
      
      If any of these interfaces are overridden by the platform, it is
      recommended that all of them are.
      
      By default `ENABLE_PSCI_STAT` is disabled.  If `ENABLE_PSCI_STAT`
      is set but `ENABLE_PMF` is not set then an alternative PSCI stat
      collection backend must be provided.  If both are set, then default
      weak definitions of these functions are provided, using PMF to
      calculate the residency.
      
      NOTE: Previously, platforms did not have to explicitly set
      `ENABLE_PMF` since this was automatically done by the top-level
      Makefile.
      
      Change-Id: I17b47804dea68c77bc284df15ee1ccd66bc4b79b
      Signed-off-by: default avatardp-arm <dimitris.papastamos@arm.com>
      04c1db1e
  20. 15 Dec, 2016 1 commit
    • dp-arm's avatar
      tbbr: Fix updating of Non-Trusted NV counter · d35dee23
      dp-arm authored
      
      
      The previous code required that a certificate be signed with the ROT
      key before the platform's NV counter could be updated with the value
      in the certificate.  This implies that the Non-Trusted NV counter was
      not being updated for Non-Trusted content certificates, as they cannot
      be signed with the ROT key in the TBBR CoT scheme.
      
      The code is reworked to only allow updating the platform's Trusted NV
      counter when a certificate protected by the Trusted NV counter is
      signed with the ROT key.
      
      Content certificates protected by the Non-Trusted NV counter are
      allowed to update the platform's Non-Trusted NV counter, assuming
      that the certificate value is higher than the platform's value.
      
      A new optional platform API has been introduced, named
      plat_set_nv_ctr2().  Platforms may choose to implement it and perform
      additional checks based on the authentication image descriptor before
      modifying the NV counters.  A default weak implementation is available
      that just calls into plat_set_nv_ctr().
      
      Fixes ARM-software/tf-issues#426
      
      Change-Id: I4fc978fd28a3007bc0cef972ff1f69ad0413b79c
      Signed-off-by: default avatardp-arm <dimitris.papastamos@arm.com>
      d35dee23
  21. 21 Sep, 2016 1 commit
    • Yatharth Kochar's avatar
      AArch32: Common changes needed for BL1/BL2 · 1a0a3f06
      Yatharth Kochar authored
      This patch adds common changes to support AArch32 state in
      BL1 and BL2. Following are the changes:
      
      * Added functions for disabling MMU from Secure state.
      * Added AArch32 specific SMC function.
      * Added semihosting support.
      * Added reporting of unhandled exceptions.
      * Added uniprocessor stack support.
      * Added `el3_entrypoint_common` macro that can be
        shared by BL1 and BL32 (SP_MIN) BL stages. The
        `el3_entrypoint_common` is similar to the AArch64
        counterpart with the main difference in the assembly
        instructions and the registers that are relevant to
        AArch32 execution state.
      * Enabled `LOAD_IMAGE_V2` flag in Makefile for
        `ARCH=aarch32` and added check to make sure that
        platform has not overridden to disable it.
      
      Change-Id: I33c6d8dfefb2e5d142fdfd06a0f4a7332962e1a3
      1a0a3f06