1. 18 Feb, 2020 1 commit
    • Zelalem's avatar
      coverity: fix MISRA violations · 2fe75a2d
      Zelalem authored
      
      
      Fixes for the following MISRA violations:
      - Missing explicit parentheses on sub-expression
      - An identifier or macro name beginning with an
        underscore, shall not be declared
      - Type mismatch in BL1 SMC handlers and tspd_main.c
      
      Change-Id: I7a92abf260da95acb0846b27c2997b59b059efc4
      Signed-off-by: default avatarZelalem <zelalem.aweke@arm.com>
      2fe75a2d
  2. 29 Jan, 2020 1 commit
  3. 10 Jan, 2020 1 commit
    • Deepika Bhavnani's avatar
      Unify type of "cpu_idx" across PSCI module. · 5b33ad17
      Deepika Bhavnani authored
      
      
      NOTE for platform integrators:
         API `plat_psci_stat_get_residency()` third argument
         `last_cpu_idx` is changed from "signed int" to the
         "unsigned int" type.
      
      Issue / Trouble points
      1. cpu_idx is used as mix of `unsigned int` and `signed int` in code
      with typecasting at some places leading to coverity issues.
      
      2. Underlying platform API's return cpu_idx as `unsigned int`
      and comparison is performed with platform specific defines
      `PLAFORM_xxx` which is not consistent
      
      Misra Rule 10.4:
      The value of a complex expression of integer type may only be cast to
      a type that is narrower and of the same signedness as the underlying
      type of the expression.
      
      Based on above points, cpu_idx is kept as `unsigned int` to match
      the API's and low-level functions and platform defines are updated
      where ever required
      Signed-off-by: default avatarDeepika Bhavnani <deepika.bhavnani@arm.com>
      Change-Id: Ib26fd16e420c35527204b126b9b91e8babcc3a5c
      5b33ad17
  4. 26 Nov, 2019 1 commit
    • Pankaj Gupta's avatar
      adding support to enable different personality of the same soc. · ab4df50c
      Pankaj Gupta authored
      
      
      Same SoC has different personality by creating different number of:
      - cores
      - clusters.
      
      As a result, the platform specific power domain tree will be created
      after identify the personality of the SoC.
      Hence, platform specific power domain tree may not be same for all the
      personality of the soc.
      
      Thus, psci library code will deduce the 'plat_core_count', while
      populating the power domain tree topology and return the number of
      cores.
      
      PLATFORM_CORE_COUNT will still be valid for a SoC, such that
      psci_plat_core_count <= PLATFORM_CORE_COUNT.
      
      PLATFORM_CORE_COUNT will continued to be defined by platform to create
      the data structures.
      Signed-off-by: default avatarPankaj Gupta <pankaj.gupta@nxp.com>
      Change-Id: I1f5c47647631cae2dcdad540d64cf09757db7185
      ab4df50c
  5. 26 Sep, 2019 1 commit
  6. 13 Sep, 2019 1 commit
    • Alexei Fedorov's avatar
      Refactor ARMv8.3 Pointer Authentication support code · ed108b56
      Alexei Fedorov authored
      
      
      This patch provides the following features and makes modifications
      listed below:
      - Individual APIAKey key generation for each CPU.
      - New key generation on every BL31 warm boot and TSP CPU On event.
      - Per-CPU storage of APIAKey added in percpu_data[]
        of cpu_data structure.
      - `plat_init_apiakey()` function replaced with `plat_init_apkey()`
        which returns 128-bit value and uses Generic timer physical counter
        value to increase the randomness of the generated key.
        The new function can be used for generation of all ARMv8.3-PAuth keys
      - ARMv8.3-PAuth specific code placed in `lib\extensions\pauth`.
      - New `pauth_init_enable_el1()` and `pauth_init_enable_el3()` functions
        generate, program and enable APIAKey_EL1 for EL1 and EL3 respectively;
        pauth_disable_el1()` and `pauth_disable_el3()` functions disable
        PAuth for EL1 and EL3 respectively;
        `pauth_load_bl31_apiakey()` loads saved per-CPU APIAKey_EL1 from
        cpu-data structure.
      - Combined `save_gp_pauth_registers()` function replaces calls to
        `save_gp_registers()` and `pauth_context_save()`;
        `restore_gp_pauth_registers()` replaces `pauth_context_restore()`
        and `restore_gp_registers()` calls.
      - `restore_gp_registers_eret()` function removed with corresponding
        code placed in `el3_exit()`.
      - Fixed the issue when `pauth_t pauth_ctx` structure allocated space
        for 12 uint64_t PAuth registers instead of 10 by removal of macro
        CTX_PACGAKEY_END from `include/lib/el3_runtime/aarch64/context.h`
        and assigning its value to CTX_PAUTH_REGS_END.
      - Use of MODE_SP_ELX and MODE_SP_EL0 macro definitions
        in `msr	spsel`  instruction instead of hard-coded values.
      - Changes in documentation related to ARMv8.3-PAuth and ARMv8.5-BTI.
      
      Change-Id: Id18b81cc46f52a783a7e6a09b9f149b6ce803211
      Signed-off-by: default avatarAlexei Fedorov <Alexei.Fedorov@arm.com>
      ed108b56
  7. 12 Sep, 2019 1 commit
  8. 09 Sep, 2019 1 commit
  9. 16 Aug, 2019 1 commit
  10. 01 Aug, 2019 1 commit
    • Julius Werner's avatar
      Switch AARCH32/AARCH64 to __aarch64__ · 402b3cf8
      Julius Werner authored
      
      
      NOTE: AARCH32/AARCH64 macros are now deprecated in favor of __aarch64__.
      
      All common C compilers pre-define the same macros to signal which
      architecture the code is being compiled for: __arm__ for AArch32 (or
      earlier versions) and __aarch64__ for AArch64. There's no need for TF-A
      to define its own custom macros for this. In order to unify code with
      the export headers (which use __aarch64__ to avoid another dependency),
      let's deprecate the AARCH32 and AARCH64 macros and switch the code base
      over to the pre-defined standard macro. (Since it is somewhat
      unintuitive that __arm__ only means AArch32, let's standardize on only
      using __aarch64__.)
      
      Change-Id: Ic77de4b052297d77f38fc95f95f65a8ee70cf200
      Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      402b3cf8
  11. 06 Jun, 2019 1 commit
    • Andrew F. Davis's avatar
      PSCI: Lookup list of parent nodes to lock only once · 74d27d00
      Andrew F. Davis authored
      
      
      When acquiring or releasing the power domain locks for a given CPU the
      parent nodes are looked up by walking the up the PD tree list on both the
      acquire and release path, only one set of lookups is needed. Fetch the
      parent nodes first and pass this list into both the acquire and release
      functions to avoid the double lookup.
      
      This also allows us to not have to do this lookup after coherency has
      been exited during the core power down sequence. The shared struct
      psci_cpu_pd_nodes is not placed in coherent memory like is done
      for psci_non_cpu_pd_nodes and doing so would negatively affect
      performance. With this patch we remove the need to have it in coherent
      memory by moving the access out of psci_release_pwr_domain_locks().
      Signed-off-by: default avatarAndrew F. Davis <afd@ti.com>
      Change-Id: I7b9cfa9d31148dea0f5e21091c8b45ef7fe4c4ab
      74d27d00
  12. 04 Jan, 2019 1 commit
    • Antonio Nino Diaz's avatar
      Sanitise includes across codebase · 09d40e0e
      Antonio Nino Diaz authored
      Enforce full include path for includes. Deprecate old paths.
      
      The following folders inside include/lib have been left unchanged:
      
      - include/lib/cpus/${ARCH}
      - include/lib/el3_runtime/${ARCH}
      
      The reason for this change is that having a global namespace for
      includes isn't a good idea. It defeats one of the advantages of having
      folders and it introduces problems that are sometimes subtle (because
      you may not know the header you are actually including if there are two
      of them).
      
      For example, this patch had to be created because two headers were
      called the same way: e0ea0928 ("Fix gpio includes of mt8173 platform
      to avoid collision."). More recently, this patch has had similar
      problems: 46f9b2c3 ("drivers: add tzc380 support").
      
      This problem was introduced in commit 4ecca339
      
       ("Move include and
      source files to logical locations"). At that time, there weren't too
      many headers so it wasn't a real issue. However, time has shown that
      this creates problems.
      
      Platforms that want to preserve the way they include headers may add the
      removed paths to PLAT_INCLUDES, but this is discouraged.
      
      Change-Id: I39dc53ed98f9e297a5966e723d1936d6ccf2fc8f
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      09d40e0e
  13. 26 Nov, 2018 1 commit
    • Joel Hutton's avatar
      Initial Spectre V1 mitigations (CVE-2017-5753). · 9edd8912
      Joel Hutton authored
      Initial Spectre Variant 1 mitigations (CVE-2017-5753).
      A potential speculative data leak was found in PSCI code, this depends
      on a non-robust implementation of the `plat_get_core_pos_by_mpidr()`
      function. This is considered very low-risk. This patch adds a macro to
      mitigate this. Note not all code paths could be analyzed with current
      tools.
      
      Add a macro which makes a variable 'speculation safe', using the
       __builtin_speculation_safe_value function of GCC and llvm. This will be
      available in GCC 9, and is planned for llvm, but is not currently in
      mainline GCC or llvm. In order to implement this mitigation the compiler
      must support this builtin. Support is indicated by the
      __HAVE_SPECULATION_SAFE_VALUE flag.
      
      The -mtrack-speculation option maintains a 'tracker' register, which
      determines if the processor is in false speculation at any point. This
      adds instructions and increases code size, but avoids the performance
      impact of a hard barrier.
      
      Without the -mtrack-speculation option, __builtin_speculation_safe_value
      expands to a
      
          ISB
          DSB SY
      
      sequence after a conditional branch, before the
      speculation safe variable is used. With -mtrack-speculation a
      
          CSEL tracker, tracker, XZR, [cond];
          AND safeval,tracker;
          CSDB
      
      sequence is added instead, clearing the vulnerable variable by
      AND'ing it with the tracker register, which is zero during speculative
      execution. [cond] are the status flags which will only be true during
      speculative execution. For more information on
      __builtin_speculation_safe_value and the -mtrack-speculation option see
      https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/compiler-support-for-mitigations
      
      
      
      The -mtracking option was not added, as the performance impact of the
      mitigation is low, and there is only one occurence.
      
      Change-Id: Ic9e66d1f4a5155e42e3e4055594974c230bfba3c
      Signed-off-by: default avatarJoel Hutton <Joel.Hutton@Arm.com>
      9edd8912
  14. 11 Oct, 2018 1 commit
    • ldts's avatar
      psci: platform control of SYSTEM_SUSPEND entry · a4065abd
      ldts authored
      Some platforms can only resume from system suspend from the boot
      CPU, hence they should only enter that state from that same core.
      
      The following commit presents an interface that allows the platform to
      reject system suspend entry near its very last stage (last CPU).
      a4065abd
  15. 10 Oct, 2018 2 commits
  16. 03 Oct, 2018 1 commit
  17. 28 Sep, 2018 3 commits
  18. 07 Aug, 2018 1 commit
    • Antonio Nino Diaz's avatar
      xlat v2: Flush xlat tables after being modified · 3e318e40
      Antonio Nino Diaz authored
      During cold boot, the initial translation tables are created with data
      caches disabled, so all modifications go to memory directly. After the
      MMU is enabled and data cache is enabled, any modification to the tables
      goes to data cache, and eventually may get flushed to memory.
      
      If CPU0 modifies the tables while CPU1 is off, CPU0 will have the
      modified tables in its data cache. When CPU1 is powered on, the MMU is
      enabled, then it enables coherency, and then it enables the data cache.
      Until this is done, CPU1 isn't in coherency, and the translation tables
      it sees can be outdated if CPU0 still has some modified entries in its
      data cache.
      
      This can be a problem in some cases. For example, the warm boot code
      uses only the tables mapped during cold boot, which don't normally
      change. However, if they are modified (and a RO page is made RW, or a XN
      page is made executable) the CPU will see the old attributes and crash
      when it tries to access it.
      
      This doesn't happen in systems with HW_ASSISTED_COHERENCY or
      WARMBOOT_ENABLE_DCACHE_EARLY. In these systems, the data cache is
      enabled at the same time as the MMU. As soon as this happens, the CPU is
      in coherency.
      
      There was an attempt of a fix in psci_helpers.S, but it didn't solve the
      problem. That code has been deleted. The code was introduced in commit
      <26441030
      
      > ("Invalidate TLB entries during warm boot").
      
      Now, during a map or unmap operation, the memory associated to each
      modified table is flushed. Traversing a table will also flush it's
      memory, as there is no way to tell in the current implementation if the
      table that has been traversed has also been modified.
      
      Change-Id: I4b520bca27502f1018878061bc5fb82af740bb92
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      3e318e40
  19. 02 Aug, 2018 1 commit
  20. 26 Jul, 2018 1 commit
  21. 24 Jul, 2018 4 commits
  22. 20 Jul, 2018 3 commits
  23. 12 Jun, 2018 1 commit
    • Daniel Boulby's avatar
      Fix MISRA Rule 5.3 Part 2 · 896a5902
      Daniel Boulby authored
      
      
      Use a _ prefix for Macro arguments to prevent that argument from
      hiding variables of the same name in the outer scope
      
      Rule 5.3: An identifier declared in an inner scope shall not
                hide an identifier declared in an outer scope
      
      Fixed For:
          make LOG_LEVEL=50 PLAT=fvp
      
      Change-Id: I67b6b05cbad4aeca65ce52981b4679b340604708
      Signed-off-by: default avatarDaniel Boulby <daniel.boulby@arm.com>
      896a5902
  24. 27 Mar, 2018 1 commit
  25. 26 Mar, 2018 1 commit
  26. 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
  27. 28 Feb, 2018 1 commit
  28. 27 Feb, 2018 1 commit
    • Antonio Nino Diaz's avatar
      Invalidate TLB entries during warm boot · 26441030
      Antonio Nino Diaz authored
      
      
      During the warm boot sequence:
      
      1. The MMU is enabled with the data cache disabled. The MMU table walker
         is set up to access the translation tables as in cacheable memory,
         but its accesses are non-cacheable because SCTLR_EL3.C controls them
         as well.
      2. The interconnect is set up and the CPU enters coherency with the
         rest of the system.
      3. The data cache is enabled.
      
      If the support for dynamic translation tables is enabled and another CPU
      makes changes to a region, the changes may only be present in the data
      cache, not in RAM. The CPU that is booting isn't in coherency with the
      rest of the system, so the table walker of that CPU isn't either. This
      means that it may read old entries from RAM and it may have invalid TLB
      entries corresponding to the dynamic mappings.
      
      This is not a problem for the boot code because the mapping is 1:1 and
      the regions are static. However, the code that runs after the boot
      sequence may need to access the dynamically mapped regions.
      
      This patch invalidates all TLBs during warm boot when the dynamic
      translation tables support is enabled to prevent this problem.
      
      Change-Id: I80264802dc0aa1cb3edd77d0b66b91db6961af3d
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      26441030
  29. 29 Jan, 2018 1 commit
  30. 11 Jan, 2018 1 commit
  31. 20 Nov, 2017 1 commit
  32. 08 Nov, 2017 1 commit