1. 12 Jun, 2018 2 commits
    • Daniel Boulby's avatar
      Fix MISRA Rule 5.7 Part 3 · 776ff52a
      Daniel Boulby authored
      
      
      Rule 5.7: A tag name shall be a unique identifier
      
      Follow convention of shorter names for smaller scope to fix
      violations of MISRA rule 5.7
      
      Fixed For:
          make ARM_TSP_RAM_LOCATION=tdram LOG_LEVEL=50 PLAT=fvp SPD=opteed
      
      Change-Id: I5fbb5d6ebddf169550eddb07ed880f5c8076bb76
      Signed-off-by: default avatarDaniel Boulby <daniel.boulby@arm.com>
      776ff52a
    • Daniel Boulby's avatar
      Fix MISRA Rule 5.3 Part 3 · 7c934242
      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 PLAT=fvp SPD=tspd
      
      Change-Id: I2d711b9584c4cb9ba3814ecd2ca65a42b7e24179
      Signed-off-by: default avatarDaniel Boulby <daniel.boulby@arm.com>
      7c934242
  2. 08 Jun, 2018 1 commit
  3. 23 May, 2018 8 commits
  4. 15 May, 2018 1 commit
    • Sandrine Bailleux's avatar
      SPM: Do not trap S-EL0 access to SVE/SIMD/FP regs · 39848945
      Sandrine Bailleux authored
      
      
      This allows secure partitions to access these registers. This is
      needed in some cases. For example, it has been reported that in order
      to implement secure storage services, a secure partition needs to
      encrypt/decrypt some authentication variables, which requires FP/SIMD
      support.
      
      Note that SPM will not do any saving/restoring of these registers on
      behalf of the SP. This falls under the SP's responsibility.
      
      Also note that if the SP gets preempted, it might not get a chance to
      save/restore FP/SIMD registers first. This patch does not address this
      problem. It only serves as a temporary solution to unblock development
      on the secure partition side.
      
      Change-Id: I3b8ccdebdac0219f6ac96ad66ab2be0be8374ad3
      Signed-off-by: default avatarSandrine Bailleux <sandrine.bailleux@arm.com>
      39848945
  5. 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
      Fix pointer type mismatch of handlers · 57d1e5fa
      Masahiro Yamada authored
      Commit 4c0d0390
      
       ("Rework type usage in Trusted Firmware") changed
      the type usage in struct declarations, but did not touch the definition
      side.  Fix the type mismatch.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      57d1e5fa
  6. 21 Apr, 2018 1 commit
  7. 17 Apr, 2018 1 commit
  8. 13 Apr, 2018 2 commits
  9. 03 Apr, 2018 1 commit
  10. 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
  11. 26 Mar, 2018 1 commit
  12. 21 Mar, 2018 2 commits
    • 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
    • Sandrine Bailleux's avatar
      Trusty: Fix sanity check on NS entry point · 0d3feba9
      Sandrine Bailleux authored
      
      
      This patch fixes the sanity check on the non-secure entrypoint value
      returned by bl31_plat_get_next_image_ep_info(). This issue has been
      reported by Coverity Scan Online:
      
        CID 264893 (#1 of 1): Dereference null return value (NULL_RETURNS)
        Dereferencing a null pointer ns_ep_info.
      
      Change-Id: Ia0f64d8c8b005f042608f1422ecbd42bc90b2fb4
      Signed-off-by: default avatarSandrine Bailleux <sandrine.bailleux@arm.com>
      0d3feba9
  13. 14 Mar, 2018 1 commit
    • Dimitris Papastamos's avatar
      Fixup `SMCCC_ARCH_FEATURES` semantics · a205a56e
      Dimitris Papastamos authored
      
      
      When querying `SMCCC_ARCH_WORKAROUND_1` through `SMCCC_ARCH_FEATURES`,
      return either:
        * -1 to indicate the PE on which `SMCCC_ARCH_FEATURES` is called
          requires firmware mitigation for CVE-2017-5715 but the mitigation
          is not compiled in.
        * 0 to indicate that firmware mitigation is required, or
        * 1 to indicate that no firmware mitigation is required.
      
      This patch complies with v1.2 of the firmware interfaces
      specification (ARM DEN 0070A).
      
      Change-Id: Ibc32d6620efdac6c340758ec502d95554a55f02a
      Signed-off-by: default avatarDimitris Papastamos <dimitris.papastamos@arm.com>
      a205a56e
  14. 02 Mar, 2018 1 commit
  15. 01 Mar, 2018 3 commits
  16. 28 Feb, 2018 1 commit
  17. 27 Feb, 2018 2 commits
    • Jeenu Viswambharan's avatar
      TSPD: Register preempted SMC error code with EHF · 472be0f7
      Jeenu Viswambharan authored
      
      
      An earlier patch extended ehf_allow_ns_preemption() API to also register
      an error code to offer to Non-secure when a Yielding SMC is preempted by
      SDEI interrupt. In TSPD's case, register the error code TSP_PREEMPTED.
      
      Change-Id: I31992b6651f80694e83bc5092b044ef7a3eda690
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      472be0f7
    • Jeenu Viswambharan's avatar
      SDEI: Pop dispatch context only after error checking · 8e3032f9
      Jeenu Viswambharan authored
      
      
      Currently, when the client attempts to do SDEI_EVENT_COMPLETE or
      SDEI_EVENT_COMPLETE_AND_RESUME, the dispatcher pops off the outstanding
      dispatch context for sanity check. There are however other checks
      following this, which could potentially return failure. If that happens,
      by popping the context, the dispatcher has inadvertently discarded a
      valid context.
      
      This patch fixes this bug by inspecting (not actually popping) the
      outstanding context. The context is popped only after all error checks
      are completed.
      
      Change-Id: Ie199f6442f871a8177a8247a0c646543bad76d21
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      8e3032f9
  18. 22 Feb, 2018 1 commit
  19. 21 Feb, 2018 1 commit
  20. 14 Feb, 2018 1 commit
    • Antonio Nino Diaz's avatar
      Remove URLs from comments · fb1198b1
      Antonio Nino Diaz authored
      
      
      This fixes all defects according to MISRA Rule 3.1: "The character
      sequences /* and // shall not be used within a comment". This affects
      all URLs in comments, so they have been removed:
      
      - The link in `sdei_state.c` can also be found in the documentation file
        `docs/sdei.rst`.
      
      - The bug that the file `io_fip.c` talks about doesn't affect the
        currently supported version of GCC, so it doesn't make sense to keep
        the comment. Note that the version of GCC officially supported is the
        one that comes with Linaro Release 17.10, which is GCC 6.2.
      
      - The link in `tzc400.c` was broken, and it didn't correctly direct to
        the Technical Reference Manual it should. The link has been replaced
        by the title of the document, which is more convenient when looking
        for the document.
      
      Change-Id: I89f60c25f635fd4c008a5d3a14028f814c147bbe
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      fb1198b1
  21. 06 Feb, 2018 2 commits
    • Jeenu Viswambharan's avatar
      TSPD: Require NS preemption along with EL3 exception handling · 6027796f
      Jeenu Viswambharan authored
      
      
      At present, the build option TSP_NS_INTR_ASYNC_PREEMPT controls how
      Non-secure interrupt affects TSPs execution. When TSP is executing:
      
        1. When TSP_NS_INTR_ASYNC_PREEMPT=0, Non-secure interrupts are received
           at the TSP's exception vector, and TSP voluntarily preempts itself.
      
        2. When TSP_NS_INTR_ASYNC_PREEMPT=1, Non-secure interrupts causes a
           trap to EL3, which preempts TSP execution.
      
      When EL3 exception handling is in place (i.e.,
      EL3_EXCEPTION_HANDLING=1), FIQs are always trapped to EL3. On a system
      with GICv3, pending NS interrupts while TSP is executing will be
      signalled as FIQ (which traps to EL3). This situation necessitates the
      same treatment applied to case (2) above.
      
      Therefore, when EL3 exception handling is in place, additionally
      require that TSP_NS_INTR_ASYNC_PREEMPT is set to one 1.
      
      Strictly speaking, this is not required on a system with GICv2, but the
      same model is uniformly followed regardless, for simplicity.
      
      Relevant documentation updated.
      
      Change-Id: I928a8ed081fb0ac96e8b1dfe9375c98384da1ccd
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      6027796f
    • Jeenu Viswambharan's avatar
      TSPD: Explicitly allow NS preemption for Yielding SMCs · 1dd022ca
      Jeenu Viswambharan authored
      
      
      When EL3 exception handling is in effect (i.e.,
      EL3_EXCEPTION_HANDLING=1), Non-secure interrupts can't preempt Secure
      execution. However, for yielding SMCs, preemption by Non-secure
      interupts is intended.
      
      This patch therefore adds a call to ehf_allow_ns_preemption() before
      dispatching a Yielding SMC to TSP.
      
      Change-Id: Ia3a1ae252f3adc0f14e6d7e0502f251bdb349bdf
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      1dd022ca
  22. 01 Feb, 2018 1 commit
  23. 29 Jan, 2018 1 commit
  24. 25 Jan, 2018 2 commits