1. 20 Aug, 2018 2 commits
  2. 10 Aug, 2018 1 commit
  3. 06 Aug, 2018 1 commit
  4. 01 Aug, 2018 1 commit
  5. 15 Jul, 2018 1 commit
  6. 13 Jul, 2018 1 commit
  7. 11 Jul, 2018 2 commits
  8. 22 Jun, 2018 3 commits
  9. 21 Jun, 2018 3 commits
    • Jeenu Viswambharan's avatar
      SDEI: Make dispatches synchronous · cdb6ac94
      Jeenu Viswambharan authored
      
      
      SDEI event dispatches currently only sets up the Non-secure context
      before returning to the caller. The actual dispatch only happens upon
      exiting EL3 next time.
      
      However, for various error handling scenarios, it's beneficial to have
      the dispatch happen synchronously. I.e. when receiving SDEI interrupt,
      or for a successful sdei_dispatch_event() call, the event handler is
      executed; and upon the event completion, dispatcher execution resumes
      after the point of dispatch. The jump primitives introduced in the
      earlier patch facilitates this feature.
      
      With this patch:
      
        - SDEI interrupts and calls to sdei_dispatch_event prepares the NS
          context for event dispatch, then sets a jump point, and immediately
          exits EL3. This results in the client handler executing in
          Non-secure.
      
        - When the SDEI client completes the dispatched event, the SDEI
          dispatcher does a longjmp to the jump pointer created earlier. For
          the caller of the sdei_dispatch_event() in particular, this would
          appear as if call returned successfully.
      
      The dynamic workaround for CVE_2018_3639 is slightly shifted around as
      part of related minor refactoring. It doesn't affect the workaround
      functionality.
      
      Documentation updated.
      
      NOTE: This breaks the semantics of the explicit dispatch API, and any
      exiting usages should be carefully reviewed.
      
      Change-Id: Ib9c876d27ea2af7fb22de49832e55a0da83da3f9
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      cdb6ac94
    • Jeenu Viswambharan's avatar
      SDEI: Determine client EL from NS context's SCR_EL3 · 2ccfcb2e
      Jeenu Viswambharan authored
      
      
      Currently, the dispatcher reads from SCR_EL3 register directly to
      determine the EL of SDEI client. This is with the assumption that
      SCR_EL3 is not modified throughout. However, with RAS work flows, it's
      possible that SCR_EL3 register contains values corresponding to Secure
      world, and therefore EL determination can go wrong. To mitigate this,
      always read the register from the saved Non-secure context.
      
      Change-Id: Ic85e4021deb18eb58757f676f9a001174998543a
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      2ccfcb2e
    • Jeenu Viswambharan's avatar
      SDEI: Allow platforms to define explicit events · af2c9ecd
      Jeenu Viswambharan authored
      
      
      The current macros only allow to define dynamic and statically-bound
      SDEI events. However, there ought be a mechanism to define SDEI events
      that are explicitly dispatched; i.e., events that are dispatched as a
      result of a previous secure interrupt or other exception
      
      This patch introduces SDEI_EXPLICIT_EVENT() macro to define an explicit
      event. They must be placed under private mappings. Only the priority
      flags are allowed to be additionally specified.
      
      Documentation updated.
      
      Change-Id: I2e12f5571381195d6234c9dfbd5904608ad41db3
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      af2c9ecd
  10. 20 Jun, 2018 1 commit
  11. 15 Jun, 2018 1 commit
  12. 14 Jun, 2018 1 commit
    • Roberto Vargas's avatar
      Make TF UUID RFC 4122 compliant · 03364865
      Roberto Vargas authored
      
      
      RFC4122 defines that fields are stored in network order (big endian),
      but TF-A stores them in machine order (little endian by default in TF-A).
      We cannot change the future UUIDs that are already generated, but we can store
      all the bytes using arrays and modify fiptool to generate the UUIDs with
      the correct byte order.
      
      Change-Id: I97be2d3168d91f4dee7ccfafc533ea55ff33e46f
      Signed-off-by: default avatarRoberto Vargas <roberto.vargas@arm.com>
      03364865
  13. 13 Jun, 2018 2 commits
    • Antonio Nino Diaz's avatar
      xlat v2: Introduce xlat granule size helpers · a0b9bb79
      Antonio Nino Diaz authored
      
      
      The function xlat_arch_is_granule_size_supported() can be used to check
      if a specific granule size is supported. In Armv8, AArch32 only supports
      4 KiB pages. AArch64 supports 4 KiB, 16 KiB or 64 KiB depending on the
      implementation, which is detected at runtime.
      
      The function xlat_arch_get_max_supported_granule_size() returns the max
      granule size supported by the implementation.
      
      Even though right now they are only used by SPM, they may be useful in
      other places in the future. This patch moves the code currently in SPM
      to the xlat tables lib so that it can be reused.
      
      Change-Id: If54624a5ecf20b9b9b7f38861b56383a03bbc8a4
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      a0b9bb79
    • Antonio Nino Diaz's avatar
      SPM: Initialize SP args as expected by cm library · 83a393ba
      Antonio Nino Diaz authored
      
      
      In the context management library, cm_setup_context() takes the
      information in ep_info to fill the registers x0-x7. This patch replaces
      the current code that sets them manually by the correct initialization
      code.
      
      Change-Id: Id1fdf4681b154026c2e3af1f9b05b19582b7d16d
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      83a393ba
  14. 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
  15. 08 Jun, 2018 1 commit
  16. 23 May, 2018 8 commits
  17. 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
  18. 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
  19. 21 Apr, 2018 1 commit
  20. 17 Apr, 2018 1 commit
  21. 13 Apr, 2018 2 commits
  22. 03 Apr, 2018 1 commit
  23. 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