1. 23 May, 2018 5 commits
    • Antonio Nino Diaz's avatar
      context_mgmt: Make cm_init_context_common public · 1634cae8
      Antonio Nino Diaz authored
      
      
      This function can be currently accessed through the wrappers
      cm_init_context_by_index() and cm_init_my_context(). However, they only
      work on contexts that are associated to a CPU.
      
      By making this function public, it is possible to set up a context that
      isn't associated to any CPU. For consistency, it has been renamed to
      cm_setup_context().
      
      Change-Id: Ib2146105abc8137bab08745a8adb30ca2c4cedf4
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      1634cae8
    • Dimitris Papastamos's avatar
      Add support for dynamic mitigation for CVE-2018-3639 · fe007b2e
      Dimitris Papastamos authored
      
      
      Some CPUS may benefit from using a dynamic mitigation approach for
      CVE-2018-3639.  A new SMC interface is defined to allow software
      executing in lower ELs to enable or disable the mitigation for their
      execution context.
      
      It should be noted that regardless of the state of the mitigation for
      lower ELs, code executing in EL3 is always mitigated against
      CVE-2018-3639.
      
      NOTE: This change is a compatibility break for any platform using
      the declare_cpu_ops_workaround_cve_2017_5715 macro.  Migrate to
      the declare_cpu_ops_wa macro instead.
      
      Change-Id: I3509a9337ad217bbd96de9f380c4ff8bf7917013
      Signed-off-by: default avatarDimitris Papastamos <dimitris.papastamos@arm.com>
      fe007b2e
    • Dimitris Papastamos's avatar
      aarch32: Implement static workaround for CVE-2018-3639 · e0865708
      Dimitris Papastamos authored
      
      
      Implement static mitigation for CVE-2018-3639 on
      Cortex A57 and A72.
      
      Change-Id: I83409a16238729b84142b19e258c23737cc1ddc3
      Signed-off-by: default avatarDimitris Papastamos <dimitris.papastamos@arm.com>
      e0865708
    • Dimitris Papastamos's avatar
      Implement static workaround for CVE-2018-3639 · b8a25bbb
      Dimitris Papastamos authored
      For affected CPUs, this approach enables the mitigation during EL3
      initialization, following every PE reset. No mechanism is provided to
      disable the mitigation at runtime.
      
      This approach permanently mitigates the entire software stack and no
      additional mitigation code is required in other software components.
      
      TF-A implements this approach for the following affected CPUs:
      
      *   Cortex-A57 and Cortex-A72, by setting bit 55 (Disable load pass store) of
          `CPUACTLR_EL1` (`S3_1_C15_C2_0`).
      
      *   Cortex-A73, by setting bit 3 of `S3_0_C15_C0_0` (not documented in the
          Technical Reference Manual (TRM)).
      
      *   Cortex-A75, by setting bit 35 (reserved in TRM) of `CPUACTLR_EL1`
          (`S3_0_C15_C1_0`).
      
      Additionally, a new SMC interface is implemented to allow software
      executing in lower ELs to discover whether the system is mitigated
      against CVE-2018-3639.
      
      Refer to "Firmware interfaces for mitigating cache speculation
      vulnerabilities System Software on Arm Systems"[0] for more
      information.
      
      [0] https://developer.arm.com/cache-speculation-vulnerability-firmware-specification
      
      
      
      Change-Id: I084aa7c3bc7c26bf2df2248301270f77bed22ceb
      Signed-off-by: default avatarDimitris Papastamos <dimitris.papastamos@arm.com>
      b8a25bbb
    • Dimitris Papastamos's avatar
      Rename symbols and files relating to CVE-2017-5715 · 2c3a1078
      Dimitris Papastamos authored
      
      
      This patch renames symbols and files relating to CVE-2017-5715 to make
      it easier to introduce new symbols and files for new CVE mitigations.
      
      Change-Id: I24c23822862ca73648c772885f1690bed043dbc7
      Signed-off-by: default avatarDimitris Papastamos <dimitris.papastamos@arm.com>
      2c3a1078
  2. 09 May, 2018 1 commit
  3. 04 May, 2018 6 commits
    • Jeenu Viswambharan's avatar
      RAS: Add fault injection support · 1a7c1cfe
      Jeenu Viswambharan authored
      
      
      The ARMv8.4 RAS extensions introduce architectural support for software
      to inject faults into the system in order to test fault-handling
      software. This patch introduces the build option FAULT_HANDLING_SUPPORT
      to allow for lower ELs to use registers in the Standard Error Record to
      inject fault. The build option RAS_EXTENSIONS must also be enabled along
      with fault injection.
      
      This feature is intended for testing purposes only, and is advisable to
      keep disabled for production images.
      
      Change-Id: I6f7a4454b15aec098f9505a10eb188c2f928f7ea
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      1a7c1cfe
    • Jeenu Viswambharan's avatar
      RAS: Allow individual interrupt registration · ca6d9185
      Jeenu Viswambharan authored
      
      
      EHF currently allows for registering interrupt handlers for a defined
      priority ranges. This is primarily targeted at various EL3 dispatchers
      to own ranges of secure interrupt priorities in order to delegate
      execution to lower ELs.
      
      The RAS support added by earlier patches necessitates registering
      handlers based on interrupt number so that error handling agents shall
      receive and handle specific Error Recovery or Fault Handling interrupts
      at EL3.
      
      This patch introduces a macro, RAS_INTERRUPTS() to declare an array of
      interrupt numbers and handlers. Error handling agents can use this macro
      to register handlers for individual RAS interrupts. The array is
      expected to be sorted in the increasing order of interrupt numbers.
      
      As part of RAS initialisation, the list of all RAS interrupts are sorted
      based on their ID so that, given an interrupt, its handler can be looked
      up with a simple binary search.
      
      For an error handling agent that wants to handle a RAS interrupt,
      platform must:
      
        - Define PLAT_RAS_PRI to be the priority of all RAS exceptions.
      
        - Enumerate interrupts to have the GIC driver program individual EL3
          interrupts to the required priority range. This is required by EHF
          even before this patch.
      
      Documentation to follow.
      
      Change-Id: I9471e4887ff541f8a7a63309e9cd8f771f76aeda
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      ca6d9185
    • Jeenu Viswambharan's avatar
      RAS: Add support for node registration · 362599ec
      Jeenu Viswambharan authored
      
      
      Previous patches added frameworks for handling RAS errors. This patch
      introduces features that the platform can use to enumerate and iterate
      RAS nodes:
      
        - The REGISTER_RAS_NODES() can be used to expose an array of
          ras_node_info_t structures. Each ras_node_info_t describes a RAS
          node, along with handlers for probing the node for error, and if
          did record an error, another handler to handle it.
      
        - The macro for_each_ras_node() can be used to iterate over the
          registered RAS nodes, probe for, and handle any errors.
      
      The common platform EA handler has been amended using error handling
      primitives introduced by both this and previous patches.
      
      Change-Id: I2e13f65a88357bc48cd97d608db6c541fad73853
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      362599ec
    • Jeenu Viswambharan's avatar
      RAS: Add helpers to access Standard Error Records · 30d81c36
      Jeenu Viswambharan authored
      
      
      The ARMv8 RAS Extensions introduced Standard Error Records which are a
      set of standard registers through which:
      
        - Platform can configure RAS node policy; e.g., notification
          mechanism;
      
        - RAS nodes can record and expose error information for error handling
          agents.
      
      Standard Error Records can either be accessed via. memory-mapped
      or System registers. This patch adds helper functions to access
      registers and fields within an error record.
      
      Change-Id: I6594ba799f4a1789d7b1e45b3e17fd40e7e0ba5c
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      30d81c36
    • Jeenu Viswambharan's avatar
      AArch64: Introduce RAS handling · 14c6016a
      Jeenu Viswambharan authored
      
      
      RAS extensions are mandatory for ARMv8.2 CPUs, but are also optional
      extensions to base ARMv8.0 architecture.
      
      This patch adds build system support to enable RAS features in ARM
      Trusted Firmware. A boolean build option RAS_EXTENSION is introduced for
      this.
      
      With RAS_EXTENSION, an Exception Synchronization Barrier (ESB) is
      inserted at all EL3 vector entry and exit. ESBs will synchronize pending
      external aborts before entering EL3, and therefore will contain and
      attribute errors to lower EL execution. Any errors thus synchronized are
      detected via. DISR_EL1 register.
      
      When RAS_EXTENSION is set to 1, HANDLE_EL3_EA_FIRST must also be set to 1.
      
      Change-Id: I38a19d84014d4d8af688bd81d61ba582c039383a
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      14c6016a
    • 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
  4. 02 May, 2018 1 commit
  5. 01 May, 2018 1 commit
    • Roberto Vargas's avatar
      ARM platforms: Demonstrate mem_protect from el3_runtime · 638b034c
      Roberto Vargas authored
      
      
      Previously mem_protect used to be only supported from BL2. This is not
      helpful in the case when ARM TF-A BL2 is not used. This patch demonstrates
      mem_protect from el3_runtime firmware on ARM Platforms specifically
      when RESET_TO_BL31 or RESET_TO_SP_MIN flag is set as BL2 may be absent
      in these cases. The Non secure DRAM is dynamically mapped into EL3 mmap
      tables temporarily and then the protected regions are then cleared. This
      avoids the need to map the non secure DRAM permanently to BL31/sp_min.
      
      The stack size is also increased, because DYNAMIC_XLAT_TABLES require
      a bigger stack.
      
      Change-Id: Ia44c594192ed5c5adc596c0cff2c7cc18c001fde
      Signed-off-by: default avatarRoberto Vargas <roberto.vargas@arm.com>
      638b034c
  6. 27 Apr, 2018 2 commits
    • Masahiro Yamada's avatar
      types: use int-ll64 for both aarch32 and aarch64 · 0a2d5b43
      Masahiro Yamada authored
      Since commit 031dbb12
      
       ("AArch32: Add essential Arch helpers"),
      it is difficult to use consistent format strings for printf() family
      between aarch32 and aarch64.
      
      For example, uint64_t is defined as 'unsigned long long' for aarch32
      and as 'unsigned long' for aarch64.  Likewise, uintptr_t is defined
      as 'unsigned int' for aarch32, and as 'unsigned long' for aarch64.
      
      A problem typically arises when you use printf() in common code.
      
      One solution could be, to cast the arguments to a type long enough
      for both architectures.  For example, if 'val' is uint64_t type,
      like this:
      
        printf("val = %llx\n", (unsigned long long)val);
      
      Or, somebody may suggest to use a macro provided by <inttypes.h>,
      like this:
      
        printf("val = %" PRIx64 "\n", val);
      
      But, both would make the code ugly.
      
      The solution adopted in Linux kernel is to use the same typedefs for
      all architectures.  The fixed integer types in the kernel-space have
      been unified into int-ll64, like follows:
      
          typedef signed char           int8_t;
          typedef unsigned char         uint8_t;
      
          typedef signed short          int16_t;
          typedef unsigned short        uint16_t;
      
          typedef signed int            int32_t;
          typedef unsigned int          uint32_t;
      
          typedef signed long long      int64_t;
          typedef unsigned long long    uint64_t;
      
      [ Linux commit: 0c79a8e29b5fcbcbfd611daf9d500cfad8370fcf ]
      
      This gets along with the codebase shared between 32 bit and 64 bit,
      with the data model called ILP32, LP64, respectively.
      
      The width for primitive types is defined as follows:
      
                         ILP32           LP64
          int            32              32
          long           32              64
          long long      64              64
          pointer        32              64
      
      'long long' is 64 bit for both, so it is used for defining uint64_t.
      'long' has the same width as pointer, so for uintptr_t.
      
      We still need an ifdef conditional for (s)size_t.
      
      All 64 bit architectures use "unsigned long" size_t, and most 32 bit
      architectures use "unsigned int" size_t.  H8/300, S/390 are known as
      exceptions; they use "unsigned long" size_t despite their architecture
      is 32 bit.
      
      One idea for simplification might be to define size_t as 'unsigned long'
      across architectures, then forbid the use of "%z" string format.
      However, this would cause a distortion between size_t and sizeof()
      operator.  We have unknowledge about the native type of sizeof(), so
      we need a guess of it anyway.  I want the following formula to always
      return 1:
      
        __builtin_types_compatible_p(size_t, typeof(sizeof(int)))
      
      Fortunately, ARM is probably a majority case.  As far as I know, all
      32 bit ARM compilers use "unsigned int" size_t.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      0a2d5b43
    • Masahiro Yamada's avatar
      arch_helpers: use u_register_t for register read/write · 8f4dbaab
      Masahiro Yamada authored
      
      
      u_register_t is preferred rather than uint64_t.  This is more
      consistent with the aarch32 implementation.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      8f4dbaab
  7. 26 Apr, 2018 1 commit
    • Antonio Nino Diaz's avatar
      xlat: Set AP[1] to 1 when it is RES1 · 01c0a38e
      Antonio Nino Diaz authored
      
      
      According to the ARMv8 ARM issue C.a:
      
          AP[1] is valid only for stage 1 of a translation regime that can
          support two VA ranges. It is RES 1 when stage 1 translations can
          support only one VA range.
      
      This means that, even though this bit is ignored, it should be set to 1
      in the EL3 and EL2 translation regimes.
      
      For translation regimes consisting on EL0 and a higher regime this bit
      selects between control at EL0 or at the higher Exception level. The
      regimes that support two VA ranges are EL1&0 and EL2&0 (the later one
      is only available since ARMv8.1).
      
      This fix has to be applied to both versions of the translation tables
      library.
      
      Change-Id: If19aaf588551bac7aeb6e9a686cf0c2068e7c181
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      01c0a38e
  8. 23 Apr, 2018 1 commit
    • Antonio Nino Diaz's avatar
      Add support for the SMC Calling Convention 2.0 · 2f370465
      Antonio Nino Diaz authored
      
      
      Due to differences in the bitfields of the SMC IDs, it is not possible
      to support SMCCC 1.X and 2.0 at the same time.
      
      The behaviour of `SMCCC_MAJOR_VERSION` has changed. Now, it is a build
      option that specifies the major version of the SMCCC that the Trusted
      Firmware supports. The only two allowed values are 1 and 2, and it
      defaults to 1. The value of `SMCCC_MINOR_VERSION` is derived from it.
      
      Note: Support for SMCCC v2.0 is an experimental feature to enable
      prototyping of secure partition specifications. Support for this
      convention is disabled by default and could be removed without notice.
      
      Change-Id: I88abf9ccf08e9c66a13ce55c890edea54d9f16a7
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      2f370465
  9. 17 Apr, 2018 1 commit
  10. 12 Apr, 2018 1 commit
  11. 27 Mar, 2018 1 commit
    • Joel Hutton's avatar
      Clean usage of void pointers to access symbols · 9f85f9e3
      Joel Hutton authored
      
      
      Void pointers have been used to access linker symbols, by declaring an
      extern pointer, then taking the address of it. This limits symbols
      values to aligned pointer values. To remove this restriction an
      IMPORT_SYM macro has been introduced, which declares it as a char
      pointer and casts it to the required type.
      
      Change-Id: I89877fc3b13ed311817bb8ba79d4872b89bfd3b0
      Signed-off-by: default avatarJoel Hutton <Joel.Hutton@Arm.com>
      9f85f9e3
  12. 26 Mar, 2018 1 commit
  13. 21 Mar, 2018 1 commit
    • Antonio Nino Diaz's avatar
      Rename 'smcc' to 'smccc' · 085e80ec
      Antonio Nino Diaz authored
      
      
      When the source code says 'SMCC' it is talking about the SMC Calling
      Convention. The correct acronym is SMCCC. This affects a few definitions
      and file names.
      
      Some files have been renamed (smcc.h, smcc_helpers.h and smcc_macros.S)
      but the old files have been kept for compatibility, they include the
      new ones with an ERROR_DEPRECATED guard.
      
      Change-Id: I78f94052a502436fdd97ca32c0fe86bd58173f2f
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      085e80ec
  14. 14 Mar, 2018 2 commits
  15. 28 Feb, 2018 3 commits
  16. 27 Feb, 2018 6 commits
  17. 15 Feb, 2018 1 commit
    • Antonio Nino Diaz's avatar
      Redefine SMC_UNK as -1 instead of 0xFFFFFFFF · 4abd7fa7
      Antonio Nino Diaz authored
      
      
      According to the SMC Calling Convention (ARM DEN0028B):
      
          The Unknown SMC Function Identifier is a sign-extended value of
          (-1) that is returned in R0, W0 or X0 register.
      
      The value wasn't sign-extended because it was defined as a 32-bit
      unsigned value (0xFFFFFFFF).
      
      SMC_PREEMPT has been redefined as -2 for the same reason.
      
      NOTE: This might be a compatibility break for some AArch64 platforms
      that don't follow the previous version of the SMCCC (ARM DEN0028A)
      correctly. That document specifies that only the bottom 32 bits of the
      returned value must be checked. If a platform relies on the top 32 bits
      of the result being 0 (so that SMC_UNK is 0x00000000FFFFFFFF), it will
      have to fix its code to comply with the SMCCC.
      
      Change-Id: I7f7b109f6b30c114fe570aa0ead3c335383cb54d
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      4abd7fa7
  18. 01 Feb, 2018 1 commit
    • Masahiro Yamada's avatar
      zlib: add gunzip() support · c43d6851
      Masahiro Yamada authored
      
      
      This commit adds some more files to use zlib from TF.
      
      To use zlib, ->zalloc and ->zfree hooks are needed.  The implementation
      depends on the system.  For user-space, the libc provides malloc() and
      friends.  Unfortunately, ARM Trusted Firmware does not provide malloc()
      or any concept of dynamic memory allocation.
      
      I implemented very simple calloc() and free() for this.  Stupidly,
      zfree() never frees memory, but it works enough for this.
      
      The purpose of using zlib is to implement gunzip() - this function
      takes compressed data from in_buf, then dumps the decompressed data
      to oub_buf.  The work_buf is used for memory allocation during the
      decompress.  Upon exit, it updates in_buf and out_buf.  If successful,
      in_buf points to the end of input data, out_buf to the end of the
      decompressed data.
      
      To use this feature, you need to do:
      
       - include lib/zlib/zlib.mk from your platform.mk
      
       - add $(ZLIB_SOURCES) to your BL*_SOURCES
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      c43d6851
  19. 31 Jan, 2018 2 commits
  20. 29 Jan, 2018 2 commits