1. 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
  2. 16 Oct, 2017 1 commit
    • Jeenu Viswambharan's avatar
      GIC: Add APIs to set interrupt type and query support · 74dce7fa
      Jeenu Viswambharan authored
      
      
      The back end GIC driver converts and assigns the interrupt type to
      suitable group.
      
      For GICv2, a build option GICV2_G0_FOR_EL3 is introduced, which
      determines to which type Group 0 interrupts maps to.
      
       - When the build option is set 0 (the default), Group 0 interrupts are
         meant for Secure EL1. This is presently the case.
      
       - Otherwise, Group 0 interrupts are meant for EL3. This means the SPD
         will have to synchronously hand over the interrupt to Secure EL1.
      
      The query API allows the platform to query whether the platform supports
      interrupts of a given type.
      
      API documentation updated.
      
      Change-Id: I60fdb4053ffe0bd006b3b20914914ebd311fc858
      Co-authored-by: default avatarYousuf A <yousuf.sait@arm.com>
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      74dce7fa
  3. 31 Aug, 2017 1 commit
    • Soby Mathew's avatar
      Export KEY_ALG as a user build option · 2091755c
      Soby Mathew authored
      
      
      The `KEY_ALG` variable is used to select the algorithm for key
      generation by `cert_create` tool for signing the certificates. This
      variable was previously undocumented and did not have a global default
      value. This patch corrects this and also adds changes to derive the
      value of `TF_MBEDTLS_KEY_ALG` based on `KEY_ALG` if it not set by the
      platform. The corresponding assignment of these variables are also now
      removed from the `arm_common.mk` makefile.
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      Change-Id: I78e2d6f4fc04ed5ad35ce2266118afb63127a5a4
      2091755c
  4. 01 Aug, 2017 1 commit
    • Jeenu Viswambharan's avatar
      CCI: Adapt for specific product at run time · e33fd445
      Jeenu Viswambharan authored
      
      
      The current build system and driver requires the CCI product to be
      specified at build time. The device constraints can be determined at run
      time from its ID registers, obviating the need for specifying them
      ahead.
      
      This patch adds changes to identify and validate CCI at run time. Some
      global variables are renamed to be in line with the rest of the code
      base.
      
      The build option ARM_CCI_PRODUCT_ID is now removed, and user guide is
      updated.
      
      Change-Id: Ibb765e349d3bc95ff3eb9a64bde1207ab710a93d
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      e33fd445
  5. 22 Jun, 2017 1 commit
    • dp-arm's avatar
      aarch64: Enable Statistical Profiling Extensions for lower ELs · d832aee9
      dp-arm authored
      
      
      SPE is only supported in non-secure state.  Accesses to SPE specific
      registers from SEL1 will trap to EL3.  During a world switch, before
      `TTBR` is modified the SPE profiling buffers are drained.  This is to
      avoid a potential invalid memory access in SEL1.
      
      SPE is architecturally specified only for AArch64.
      
      Change-Id: I04a96427d9f9d586c331913d815fdc726855f6b0
      Signed-off-by: default avatardp-arm <dimitris.papastamos@arm.com>
      d832aee9
  6. 01 Jun, 2017 1 commit
  7. 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
  8. 03 May, 2017 1 commit
  9. 19 Apr, 2017 1 commit
    • Soby Mathew's avatar
      PSCI: Build option to enable D-Caches early in warmboot · bcc3c49c
      Soby Mathew authored
      
      
      This patch introduces a build option to enable D-cache early on the CPU
      after warm boot. This is applicable for platforms which do not require
      interconnect programming to enable cache coherency (eg: single cluster
      platforms). If this option is enabled, then warm boot path enables
      D-caches immediately after enabling MMU.
      
      Fixes ARM-Software/tf-issues#456
      
      Change-Id: I44c8787d116d7217837ced3bcf0b1d3441c8d80e
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      bcc3c49c
  10. 31 Mar, 2017 1 commit
    • 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
  11. 02 Mar, 2017 1 commit
  12. 14 Feb, 2017 1 commit
    • Jeenu Viswambharan's avatar
      Introduce locking primitives using CAS instruction · c877b414
      Jeenu Viswambharan authored
      
      
      The ARMv8v.1 architecture extension has introduced support for far
      atomics, which includes compare-and-swap. Compare and Swap instruction
      is only available for AArch64.
      
      Introduce build options to choose the architecture versions to target
      ARM Trusted Firmware:
      
        - ARM_ARCH_MAJOR: selects the major version of target ARM
          Architecture. Default value is 8.
      
        - ARM_ARCH_MINOR: selects the minor version of target ARM
          Architecture. Default value is 0.
      
      When:
      
        (ARM_ARCH_MAJOR > 8) || ((ARM_ARCH_MAJOR == 8) && (ARM_ARCH_MINOR >= 1)),
      
      for AArch64, Compare and Swap instruction is used to implement spin
      locks. Otherwise, the implementation falls back to using
      load-/store-exclusive instructions.
      
      Update user guide, and introduce a section in Firmware Design guide to
      summarize support for features introduced in ARMv8 Architecture
      Extensions.
      
      Change-Id: I73096a0039502f7aef9ec6ab3ae36680da033f16
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      c877b414
  13. 28 Jan, 2017 1 commit
    • 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
  14. 08 Nov, 2016 1 commit