1. 30 Jul, 2020 1 commit
  2. 24 Jun, 2020 1 commit
    • Louis Mayencourt's avatar
      tbbr/dualroot: Add fw_config image in chain of trust · 243875ea
      Louis Mayencourt authored
      
      
      fw_config image is authenticated using secure boot framework by
      adding it into the single root and dual root chain of trust.
      
      The COT for fw_config image looks as below:
      
      +------------------+       +-------------------+
      | ROTPK/ROTPK Hash |------>| Trusted Boot fw   |
      +------------------+       | Certificate       |
                                 | (Auth Image)      |
                                /+-------------------+
                               /                   |
                              /                    |
                             /                     |
                            /                      |
                           L                       v
      +------------------+       +-------------------+
      | fw_config hash   |------>| fw_config         |
      |                  |       | (Data Image)      |
      +------------------+       +-------------------+
      Signed-off-by: default avatarLouis Mayencourt <louis.mayencourt@arm.com>
      Signed-off-by: default avatarManish V Badarkhe <Manish.Badarkhe@arm.com>
      Change-Id: I08fc8ee95c29a95bb140c807dd06e772474c7367
      243875ea
  3. 09 Jun, 2020 2 commits
    • Madhukar Pappireddy's avatar
      plat/fvp: Add support for dynamic description of secure interrupts · 452d5e5e
      Madhukar Pappireddy authored
      
      
      Using the fconf framework, the Group 0 and Group 1 secure interrupt
      descriptors are moved to device tree and retrieved in runtime. This
      feature is enabled by the build flag SEC_INT_DESC_IN_FCONF.
      
      Change-Id: I360c63a83286c7ecc2426cd1ff1b4746d61e633c
      Signed-off-by: default avatarMadhukar Pappireddy <madhukar.pappireddy@arm.com>
      452d5e5e
    • Manish Pandey's avatar
      dualroot: add chain of trust for secure partitions · 44f1aa8e
      Manish Pandey authored
      
      
      A new certificate "sip-sp-cert" has been added for Silicon Provider(SiP)
      owned Secure Partitions(SP). A similar support for Platform owned SP can
      be added in future. The certificate is also protected against anti-
      rollback using the trusted Non-Volatile counter.
      
      To avoid deviating from TBBR spec, support for SP CoT is only provided
      in dualroot.
      Secure Partition content certificate is assigned image ID 31 and SP
      images follows after it.
      
      The CoT for secure partition look like below.
      +------------------+       +-------------------+
      | ROTPK/ROTPK Hash |------>| Trusted Key       |
      +------------------+       | Certificate       |
                                 | (Auth Image)      |
                                /+-------------------+
                               /                   |
                              /                    |
                             /                     |
                            /                      |
                           L                       v
      +------------------+       +-------------------+
      | Trusted World    |------>| SiP owned SPs     |
      | Public Key       |       | Content Cert      |
      +------------------+       | (Auth Image)      |
                              /   +-------------------+
                             /                      |
                            /                      v|
      +------------------+ L     +-------------------+
      | SP_PKG1 Hash     |------>| SP_PKG1           |
      |                  |       | (Data Image)      |
      +------------------+       +-------------------+
              .                           .
              .                           .
              .                           .
      +------------------+       +-------------------+
      | SP_PKG8 Hash     |------>| SP_PKG8           |
      |                  |       | (Data Image)      |
      +------------------+       +-------------------+
      Signed-off-by: default avatarManish Pandey <manish.pandey2@arm.com>
      Change-Id: Ia31546bac1327a3e0b5d37e8b99c808442d5e53f
      44f1aa8e
  4. 15 May, 2020 1 commit
  5. 29 Apr, 2020 1 commit
    • Andre Przywara's avatar
      fdt/wrappers: Replace fdtw_read_cells() implementation · ff4e6c35
      Andre Przywara authored
      Our fdtw_read_cells() implementation goes to great lengths to
      sanity-check every parameter and result, but leaves a big hole open:
      The size of the storage the value pointer points at needs to match the
      number of cells given. This can't be easily checked at compile time,
      since we lose the size information by using a void pointer.
      Regardless the current usage of this function is somewhat wrong anyways,
      since we use it on single-element, fixed-length properties only, for
      which the DT binding specifies the size.
      Typically we use those functions dealing with a number of cells in DT
      context to deal with *dynamically* sized properties, which depend on
      other properties (#size-cells, #clock-cells, ...), to specify the number
      of cells needed.
      
      Another problem with the current implementation is the use of
      ambiguously sized types (uintptr_t, size_t) together with a certain
      expectation about their size. In general there is no relation between
      the length of a DT property and the bitness of the code that parses the
      DTB: AArch64 code could encounter 32-bit addresses (where the physical
      address space is limited to 4GB [1]), while AArch32 code could read
      64-bit sized properties (/memory nodes on LPAE systems, [2]).
      
      To make this more clear, fix the potential issues and also align more
      with other DT users (Linux and U-Boot), introduce functions to explicitly
      read uint32 and uint64 properties. As the other DT consumers, we do this
      based on the generic "read array" function.
      Convert all users to use either of those two new functions, and make
      sure we never use a pointer to anything other than uint32_t or uint64_t
      variables directly.
      
      This reveals (and fixes) a bug in plat_spmd_manifest.c, where we write
      4 bytes into a uint16_t variable (passed via a void pointer).
      
      Also we change the implementation of the function to better align with
      other libfdt users, by using the right types (fdt32_t) and common
      variable names (*prop, prop_names).
      
      [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi#n874
      [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/ecx-2000.dts
      
      
      
      Change-Id: I718de960515117ac7a3331a1b177d2ec224a3890
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      ff4e6c35
  6. 28 Apr, 2020 1 commit
    • Andre Przywara's avatar
      fdt/wrappers: Generalise fdtw_read_array() · 6e3a89f4
      Andre Przywara authored
      
      
      Currently our fdtw_read_array() implementation requires the length of
      the property to exactly match the requested size, which makes it less
      flexible for parsing generic device trees.
      Also the name is slightly misleading, since we treat the cells of the
      array as 32 bit unsigned integers, performing the endianess conversion.
      
      To fix those issues and align the code more with other DT users (Linux
      kernel or U-Boot), rename the function to "fdt_read_uint32_array", and
      relax the length check to only check if the property covers at least the
      number of cells we request.
      This also changes the variable names to be more in-line with other DT
      users, and switches to the proper data types.
      
      This makes this function more useful in later patches.
      
      Change-Id: Id86f4f588ffcb5106d4476763ecdfe35a735fa6c
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      6e3a89f4
  7. 16 Mar, 2020 1 commit
    • Louis Mayencourt's avatar
      fconf: Clean Arm IO · a6de824f
      Louis Mayencourt authored
      
      
      Merge the previously introduced arm_fconf_io_storage into arm_io_storage. This
      removes the duplicate io_policies and functions definition.
      
      This patch:
      - replace arm_io_storage.c with the content of arm_fconf_io_storage.c
      - rename the USE_FCONF_BASED_IO option into ARM_IO_IN_DTB.
      - use the ARM_IO_IN_DTB option to compile out io_policies moved in dtb.
      - propagate DEFINES when parsing dts.
      - use ARM_IO_IN_DTB to include or not uuid nodes in fw_config dtb.
      - set the ARM_IO_IN_DTB to 0 by default for fvp. This ensure that the behavior
        of fvp stays the same as it was before the introduction of fconf.
      
      Change-Id: Ia774a96d1d3a2bccad29f7ce2e2b4c21b26c080e
      Signed-off-by: default avatarLouis Mayencourt <louis.mayencourt@arm.com>
      a6de824f
  8. 11 Mar, 2020 1 commit
    • Madhukar Pappireddy's avatar
      fconf: enhancements to firmware configuration framework · 25d740c4
      Madhukar Pappireddy authored
      
      
      A populate() function essentially captures the value of a property,
      defined by a platform, into a fconf related c structure. Such a
      callback is usually platform specific and is associated to a specific
      configuration source.
      For example, a populate() function which captures the hardware topology
      of the platform can only parse HW_CONFIG DTB. Hence each populator
      function must be registered with a specific 'config_type' identifier.
      It broadly represents a logical grouping of configuration properties
      which is usually a device tree source file.
      
      Example:
      > TB_FW: properties related to trusted firmware such as IO policies,
      	 base address of other DTBs, mbedtls heap info etc.
      > HW_CONFIG: properties related to hardware configuration of the SoC
      	 such as topology, GIC controller, PSCI hooks, CPU ID etc.
      
      This patch modifies FCONF_REGISTER_POPULATOR macro and fconf_populate()
      to register and invoke the appropriate callbacks selectively based on
      configuration type.
      
      Change-Id: I6f63b1fd7a8729c6c9137d5b63270af1857bb44a
      Signed-off-by: default avatarMadhukar Pappireddy <madhukar.pappireddy@arm.com>
      25d740c4
  9. 04 Mar, 2020 1 commit
    • Manish Pandey's avatar
      SPMD: loading Secure Partition payloads · cb3b5344
      Manish Pandey authored
      
      
      This patch implements loading of Secure Partition packages using
      existing framework of loading other bl images.
      
      The current framework uses a statically defined array to store all the
      possible image types and at run time generates a link list and traverse
      through it to load different images.
      
      To load SPs, a new array of fixed size is introduced which will be
      dynamically populated based on number of SPs available in the system
      and it will be appended to the loadable images list.
      
      Change-Id: I8309f63595f2a71b28a73b922d20ccba9c4f6ae4
      Signed-off-by: default avatarManish Pandey <manish.pandey2@arm.com>
      cb3b5344
  10. 03 Mar, 2020 1 commit
  11. 27 Feb, 2020 1 commit
    • Louis Mayencourt's avatar
      fconf: Fix misra issues · 845db722
      Louis Mayencourt authored
      
      
      MISRA C-2012 Rule 20.7:
      Macro parameter expands into an expression without being wrapped by parentheses.
      
      MISRA C-2012 Rule 12.1:
      Missing explicit parentheses on sub-expression.
      
      MISRA C-2012 Rule 18.4:
      Essential type of the left hand operand is not the same as that of the right
      operand.
      
      Include does not provide any needed symbols.
      
      Change-Id: Ie1c6451cfbc8f519146c28b2cf15c50b1f36adc8
      Signed-off-by: default avatarLouis Mayencourt <louis.mayencourt@arm.com>
      845db722
  12. 07 Feb, 2020 1 commit
    • Louis Mayencourt's avatar
      fconf: Move platform io policies into fconf · 0a6e7e3b
      Louis Mayencourt authored
      
      
      Use the firmware configuration framework to store the io_policies
      information inside the configuration device tree instead of the static
      structure in the code base.
      
      The io_policies required by BL1 can't be inside the dtb, as this one is
      loaded by BL1, and only available at BL2.
      
      This change currently only applies to FVP platform.
      
      Change-Id: Ic9c1ac3931a4a136aa36f7f58f66d3764c1bfca1
      Signed-off-by: default avatarLouis Mayencourt <louis.mayencourt@arm.com>
      0a6e7e3b