1. 28 Jan, 2015 8 commits
    • Juan Castillo's avatar
      TBB: add authentication module interface · 40febc3a
      Juan Castillo authored
      This patch provides an API to access the authentication module that
      will be used to verify the authenticity of the images loaded into
      memory as part of the Trusted Board Boot process.
      
      To include the authentication module as part of the build, set the
      boolean build option TRUSTED_BOARD_BOOT. One single authentication
      module must be registered at build time by setting the build option
      AUTH_MOD=<mod_name>. All authentication modules will be located in
      'common/auth/<mod_name>' and must present the <mod_name>.mk file that
      will be included by the build system to compile the module sources.
      
      To create an authentication module, an instance of auth_mod_t called
      'auth_mod' must be declared in the module sources. The initialization
      and verification functions provided by the module will be exported
      through the function pointers specified when declaring this instance.
      
      If an authentication module includes third party sources that do not
      adhere to the C99 standard, the -pedantic option may be removed from
      the build options by setting the flag DISABLE_PEDANTIC in the module
      file <mod_name>.mk.
      
      Change-Id: I080bb04bd421029bcdf22ec2c63807afbf061dcd
      40febc3a
    • Juan Castillo's avatar
      TBB: add PolarSSL based authentication module · db6071c9
      Juan Castillo authored
      This patch implements an authentication module based on the
      PolarSSL library (v1.3.9) to verify the Chain of Trust when
      Trusted Boot is enabled.
      
      PolarSSL sources must be fetched separately. The POLARSSL_DIR
      build option may be used to indicate the path to the PolarSSL
      main directory (this directory must contain the 'include' and
      'library' subdirectories).
      
      To be able to build PolarSSL sources as a part of the Trusted
      Firmware build process, the DISABLE_PEDANTIC flag in polarssl.mk
      will tell the build system to remove the -pedantic option from
      the CFLAGS.
      
      Inclusion of PolarSSL increases the memory requirements of the BL1
      and BL2 images. The following are the changes made to the FVP and
      Juno platforms to cater for this when TRUSTED_BOARD_BOOT is
      defined:
      
      Changes on FVP:
      
        - BL1 and BL2 stacks have been increased to 4 KB
        - BL1(rw) section has been increased to 32 KB.
        - BL2 memory region has been increased to 112 KB
      
      Changes on Juno:
      
        - BL1 and BL2 stacks have been increased to 4 KB
        - BL1(rw) section has been increased to 32 KB.
        - Trusted ROM region in Flash has been increased to 128 KB.
        - BL2 memory region has been increased to 116 KB
      
      Change-Id: Ie87d80d43408eb6239c4acd0ec5ab2120e4e9e80
      db6071c9
    • Juan Castillo's avatar
      stdlib: add missing features to build PolarSSL · e509d057
      Juan Castillo authored
      This patch adds the missing features to the C library included
      in the Trusted Firmware to build PolarSSL:
      
        - strcasecmp() function
        - exit() function
        - sscanf()* function
        - time.h header file (and its dependencies)
      
      * NOTE: the sscanf() function is not a real implementation. It just
      returns the number of expected arguments by counting the number of
      '%' characters present in the formar string. This return value is
      good enough for PolarSSL because during the certificate parsing
      only the return value is checked. The certificate validity period
      is ignored.
      
      Change-Id: I43bb3742f26f0bd458272fccc3d72a7f2176ab3d
      e509d057
    • Juan Castillo's avatar
      TBB: add a platform specific function to validate the ROTPK · 6eadf762
      Juan Castillo authored
      This patch adds the function plat_match_rotpk() to the platform
      porting layer to provide a Root Of Trust Public key (ROTPK)
      verification mechanism. This function is called during the
      Trusted Board Boot process and receives a supposed valid copy
      of the ROTPK as a parameter, usually obtained from an external
      source (for instance, a certificate). It returns 0 (success) if
      that key matches the actual ROTPK stored in the system or any
      other value otherwise.
      
      The mechanism to access the actual ROTPK stored in the system
      is platform specific and should be implemented as part of this
      function. The format of the ROTPK is also platform specific
      (to save memory, some platforms might store a hash of the key
      instead of the whole key).
      
      TRUSTED_BOARD_BOOT build option has been added to allow the user
      to enable the Trusted Board Boot features. The implementation of
      the plat_match_rotpk() funtion is mandatory when Trusted Board
      Boot is enabled.
      
      For development purposes, FVP and Juno ports provide a dummy
      function that returns always success (valid key). A safe trusted
      boot implementation should provide a proper matching function.
      
      Documentation updated accordingly.
      
      Change-Id: I74ff12bc2b041556c48533375527d9e8c035b8c3
      6eadf762
    • Juan Castillo's avatar
      TBB: add support to include certificates in a FIP image · b7124ea7
      Juan Castillo authored
      This patch extends the FIP tool to include the certificates
      generated by the 'cert_create' tool.
      
      If GENERATE_COT build option is enabled, the Makefile adds the
      certificates as dependencies to create the FIP file. Thus, make
      target 'fip' will also build the certificates as part of the
      Trusted Firmware build process.
      
      Change-Id: I5eee500da7f7be6cfb6e3df0423599739d260074
      b7124ea7
    • Juan Castillo's avatar
      TBB: add tool to generate certificates · 6f971622
      Juan Castillo authored
      This patch adds a tool that generates all the necessary elements
      to establish the chain of trust (CoT) between the images.
      
      The tool reads the binary images and signing keys and outputs the
      corresponding certificates that will be used by the target at run
      time to verify the authenticity of the images.
      
      Note: the platform port must provide the file platform_oid.h. This
      file will define the OIDs of the x509 extensions that will be added
      to the certificates in order to establish the CoT.
      
      Change-Id: I2734d6808b964a2107ab3a4805110698066a04be
      6f971622
    • Juan Castillo's avatar
      Skip reserving memory for non-executable and BL3-0 images · c5fb47c3
      Juan Castillo authored
      This patch adds support to not reserve the memory where an image is
      loaded if the image is:
      
        1. A non-executable image e.g. a certificate
        2. An executable image which is not meant to run on the
           application CPU (e.g. BL3-0)
      
      Both types of images are characterized by a NULL entrypoint argument
      to the load_image() function. It is used to distinguish them from
      other type of images.
      
      Important: Use this feature carefully. The caller is responsible for
      providing a valid entrypoint while loading images which will execute
      on the application CPU to prevent a potential overwrite of the
      corresponding memory region.
      
      Change-Id: Ied482280d9db714c529ec12c33a6c1d918d77a4e
      c5fb47c3
    • danh-arm's avatar
      Merge pull request #248 from jcastillo-arm/jc/tf-issues/212_1 · 03b23703
      danh-arm authored
      Allow BL3-2 to be loaded into the secure region of DRAM
      03b23703
  2. 27 Jan, 2015 1 commit
  3. 26 Jan, 2015 11 commits
    • Yatharth Kochar's avatar
      Call reset handlers upon BL3-1 entry. · 79a97b2e
      Yatharth Kochar authored
      This patch adds support to call the reset_handler() function in BL3-1 in the
      cold and warm boot paths when another Boot ROM reset_handler() has already run.
      
      This means the BL1 and BL3-1 versions of the CPU and platform specific reset
      handlers may execute different code to each other. This enables a developer to
      perform additional actions or undo actions already performed during the first
      call of the reset handlers e.g. apply additional errata workarounds.
      
      Typically, the reset handler will be first called from the BL1 Boot ROM. Any
      additional functionality can be added to the reset handler when it is called
      from BL3-1 resident in RW memory. The constant FIRST_RESET_HANDLER_CALL is used
      to identify whether this is the first version of the reset handler code to be
      executed or an overridden version of the code.
      
      The Cortex-A57 errata workarounds are applied only if they have not already been
      applied.
      
      Fixes ARM-software/tf-issue#275
      
      Change-Id: Id295f106e4fda23d6736debdade2ac7f2a9a9053
      79a97b2e
    • danh-arm's avatar
      Merge pull request #246 from soby-mathew/sm/route_IRQ_EL3 · 9d212557
      danh-arm authored
      Demonstrate model for routing IRQs to EL3
      9d212557
    • Soby Mathew's avatar
      Demonstrate model for routing IRQs to EL3 · f4f1ae77
      Soby Mathew authored
      This patch provides an option to specify a interrupt routing model
      where non-secure interrupts (IRQs) are routed to EL3 instead of S-EL1.
      When such an interrupt occurs, the TSPD arranges a return to
      the normal world after saving any necessary context. The interrupt
      routing model to route IRQs to EL3 is enabled only during STD SMC
      processing. Thus the pre-emption of S-EL1 is disabled during Fast SMC
      and Secure Interrupt processing.
      
      A new build option TSPD_ROUTE_NS_INT_EL3 is introduced to change
      the non secure interrupt target execution level to EL3.
      
      Fixes ARM-software/tf-issues#225
      
      Change-Id: Ia1e779fbbb6d627091e665c73fa6315637cfdd32
      f4f1ae77
    • danh-arm's avatar
      Merge pull request #245 from danh-arm/sm/psci_version · 07ddb33a
      danh-arm authored
      Increment the PSCI VERSION to 1.0 (PR v2)
      07ddb33a
    • Soby Mathew's avatar
      Increment the PSCI VERSION to 1.0 · e8ca7d1e
      Soby Mathew authored
      This patch:
      
         * Bumps the PSCI VERSION to 1.0. This means that
           the PSCI_VERSION API will now return the value 0x00010000
           to indicate the version as 1.0. The firmware remains
           compatible with PSCI v0.2 clients.
      
         * The firmware design guide is updated to document the
           APIs supported by the Trusted Firmware generic code.
      
         * The FVP Device Tree Sources (dts) and Blobs(dtb) are also
           updated to add "psci-1.0" and "psci-0.2" to the list of
           compatible PSCI versions.
      
      Change-Id: Iafc2f549c92651dcd65d7e24a8aae35790d00f8a
      e8ca7d1e
    • danh-arm's avatar
      Merge pull request #244 from danh-arm/sm/psci_mig_feat · 126866f0
      danh-arm authored
      Rework PSCI migrate APIs and implement the FEATURES API v2
      126866f0
    • Soby Mathew's avatar
      Verify capabilities before handling PSCI calls · b234b2c4
      Soby Mathew authored
      This patch implements conditional checks in psci_smc_handler() to verify
      that the psci function invoked by the caller is supported by the platform
      or SPD implementation. The level of support is saved in the 'psci_caps'
      variable. This check allows the PSCI implementation to return an error
      early.
      
      As a result of the above verification, the checks performed within the psci
      handlers for the pm hooks are now removed and replaced with assertions.
      
      Change-Id: I9b5b646a01d8566dc28c4d77dd3aa54e9bf3981a
      b234b2c4
    • Soby Mathew's avatar
      Implement PSCI_FEATURES API · 90e8258e
      Soby Mathew authored
      This patch implements the PSCI_FEATURES function which is a mandatory
      API in the PSCI 1.0 specification. A capability variable is
      constructed during initialization by examining the plat_pm_ops and
      spd_pm_ops exported by the platform and the Secure Payload Dispatcher.
      This is used by the PSCI FEATURES function to determine which
      PSCI APIs are supported by the platform.
      
      Change-Id: I147ffc1bd5d90b469bd3cc4bbe0a20e95c247df7
      90e8258e
    • Soby Mathew's avatar
      Rework the PSCI migrate APIs · 8991eed7
      Soby Mathew authored
      This patch reworks the PSCI MIGRATE, MIGRATE_INFO_TYPE and
      MIGRATE_INFO_UP_CPU support for Trusted Firmware. The
      implementation does the appropriate validation of parameters
      and invokes the appropriate hook exported by the SPD.
      
      The TSP is a MP Trusted OS. Hence the ability to actually
      migrate a Trusted OS has not been implemented. The
      corresponding function is not populated in the spd_pm_hooks
      structure for the TSPD.
      
      The `spd_pm_ops_t` has undergone changes with this patch.
      SPD PORTS MAY NEED TO BE UPDATED.
      
      Fixes ARM-software/tf-issues#249
      
      Change-Id: Iabd87521bf7c530a5e4506b6d3bfd4f1bf87604f
      8991eed7
    • danh-arm's avatar
      Merge pull request #243 from soby-mathew/sm/psci_cleanup_1 · 860331aa
      danh-arm authored
      Clean-up PSCI code and introduce early validation of parameters v3
      860331aa
    • Juan Castillo's avatar
      FVP: Allow BL3-2 to sit in the secure region of DRAM · 513dd3a0
      Juan Castillo authored
      This patch allows the secure payload (BL3-2) to be loaded in the
      DRAM region secured by the TrustZone controller (top 16 MB of DRAM1).
      
      The location of BL3-2 can be selected at build time by setting the
      build flag FVP_TSP_RAM_LOCATION to one of the following options:
      
        - 'tsram' : Trusted SRAM (this is the default option)
        - 'tdram' : Trusted DRAM
        - 'dram'  : Secure region in DRAM1 (top 16MB configured by the
                    TrustZone controller)
      
      The number of MMU tables in BL3-2 depends on its location in
      memory: 3 in case it is loaded in DRAM, 2 otherwise.
      
      Documentation updated accordingly.
      
      Fixes ARM-software/tf-issues#212
      
      Change-Id: I371eef3a4159f06a0c9e3c6c1f4c905b2f93803a
      513dd3a0
  4. 23 Jan, 2015 6 commits
    • Soby Mathew's avatar
      Return success if an interrupt is seen during PSCI CPU_SUSPEND · 22f08973
      Soby Mathew authored
      This patch adds support to return SUCCESS if a pending interrupt is
      detected during a CPU_SUSPEND call to a power down state. The check
      is performed as late as possible without losing the ability to return
      to the caller. This reduces the overhead incurred by a CPU in
      undergoing a complete power cycle when a wakeup interrupt is already
      pending.
      
      Fixes ARM-Software/tf-issues#102
      
      Change-Id: I1aff04a74b704a2f529734428030d1d10750fd4b
      22f08973
    • Soby Mathew's avatar
      Validate power_state and entrypoint when executing PSCI calls · 539dcedb
      Soby Mathew authored
      This patch allows the platform to validate the power_state and
      entrypoint information from the normal world early on in PSCI
      calls so that we can return the error safely. New optional
      pm_ops hooks `validate_power_state` and `validate_ns_entrypoint`
      are introduced to do this.
      
      As a result of these changes, all the other pm_ops handlers except
      the PSCI_ON handler are expected to be successful. Also, the PSCI
      implementation will now assert if a PSCI API is invoked without the
      corresponding pm_ops handler being registered by the platform.
      
      NOTE : PLATFORM PORTS WILL BREAK ON MERGE OF THIS COMMIT. The
      pm hooks have 2 additional optional callbacks and the return type
      of the other hooks have changed.
      
      Fixes ARM-Software/tf-issues#229
      
      Change-Id: I036bc0cff2349187c7b8b687b9ee0620aa7e24dc
      539dcedb
    • Soby Mathew's avatar
      Save 'power_state' early in PSCI CPU_SUSPEND call · 31244d74
      Soby Mathew authored
      This patch adds support to save the "power state" parameter before the
      affinity level specific handlers are called in a CPU_SUSPEND call.
      This avoids the need to pass the power_state as a parameter to the
      handlers and Secure Payload Dispatcher (SPD) suspend spd_pm_ops.
      The power_state arguments in the spd_pm_ops operations are now reserved
      and must not be used. The SPD can query the relevant power_state fields
      by using the psci_get_suspend_afflvl() & psci_get_suspend_stateid() APIs.
      
      NOTE: THIS PATCH WILL BREAK THE SPD_PM_OPS INTERFACE. HENCE THE SECURE
      PAYLOAD DISPATCHERS WILL NEED TO BE REWORKED TO USE THE NEW INTERFACE.
      
      Change-Id: I1293d7dc8cf29cfa6a086a009eee41bcbf2f238e
      31244d74
    • Soby Mathew's avatar
      Rework internal API to save non-secure entry point info · 78879b9a
      Soby Mathew authored
      This patch replaces the internal psci_save_ns_entry() API with a
      psci_get_ns_ep_info() API. The new function splits the work done by the
      previous one such that it populates and returns an 'entry_point_info_t'
      structure with the information to enter the normal world upon completion
      of the CPU_SUSPEND or CPU_ON call. This information is used to populate
      the non-secure context structure separately.
      
      This allows the new internal API `psci_get_ns_ep_info` to return error
      and enable the code to return safely.
      
      Change-Id: Ifd87430a4a3168eac0ebac712f59c93cbad1b231
      78879b9a
    • Soby Mathew's avatar
      PSCI: Check early for invalid CPU state during CPU ON · 2f5aaded
      Soby Mathew authored
      This patch moves the check for valid CPU state during
      PSCI_CPU_ON to before the non secure entry point is programmed
      so as to enable it to return early on error.
      
      Change-Id: I1b1a21be421e2b2a6e33db236e91dee8688efffa
      2f5aaded
    • Soby Mathew's avatar
      Remove `ns_entrypoint` and `mpidr` from parameters in pm_ops · e146f4cc
      Soby Mathew authored
      This patch removes the non-secure entry point information being passed
      to the platform pm_ops which is not needed. Also, it removes the `mpidr`
      parameter for  platform pm hooks which are meant to do power management
      operations only on the current cpu.
      
      NOTE: PLATFORM PORTS MUST BE UPDATED AFTER MERGING THIS COMMIT.
      
      Change-Id: If632376a990b7f3b355f910e78771884bf6b12e7
      e146f4cc
  5. 22 Jan, 2015 5 commits
    • danh-arm's avatar
      Merge pull request #240 from danh-arm/sm/rem_coh_mem · eadd7a1b
      danh-arm authored
      Remove coherent memory v2
      eadd7a1b
    • Soby Mathew's avatar
      Remove coherent memory from the BL memory maps · ab8707e6
      Soby Mathew authored
      This patch extends the build option `USE_COHERENT_MEMORY` to
      conditionally remove coherent memory from the memory maps of
      all boot loader stages. The patch also adds necessary
      documentation for coherent memory removal in firmware-design,
      porting and user guides.
      
      Fixes ARM-Software/tf-issues#106
      
      Change-Id: I260e8768c6a5c2efc402f5804a80657d8ce38773
      ab8707e6
    • Soby Mathew's avatar
      Move bakery algorithm implementation out of coherent memory · 8c5fe0b5
      Soby Mathew authored
      This patch moves the bakery locks out of coherent memory to normal memory.
      This implies that the lock information needs to be placed on a separate cache
      line for each cpu. Hence the bakery_lock_info_t structure is allocated in the
      per-cpu data so as to minimize memory wastage. A similar platform per-cpu
      data is introduced for the platform locks.
      
      As a result of the above changes, the bakery lock api is completely changed.
      Earlier, a reference to the lock structure was passed to the lock implementation.
      Now a unique-id (essentially an index into the per-cpu data array) and an offset
      into the per-cpu data for bakery_info_t needs to be passed to the lock
      implementation.
      
      Change-Id: I1e76216277448713c6c98b4c2de4fb54198b39e0
      8c5fe0b5
    • Soby Mathew's avatar
      Add macros for domain specific barriers. · 5b1cd43b
      Soby Mathew authored
      This patch adds helper macros for barrier operations that specify
      the type of barrier (dmb, dsb) and the shareability domain (system,
      inner-shareable) it affects.
      
      Change-Id: I4bf95103e79da212c4fbdbc13d91ad8ac385d9f5
      5b1cd43b
    • Soby Mathew's avatar
      Remove the wfe() for bounded wait in bakery_lock · d4f4ad90
      Soby Mathew authored
      This patch is an optimization in the bakery_lock_get() function
      which removes the wfe() when waiting for other contenders to choose
      their ticket i.e when their `entering` flag is set. Since the time
      taken to execute bakery_get_ticket() by other contenders is bounded,
      this wait is a bounded time wait. Hence the removal of wfe() and the
      corresponding sev() and dsb() in bakery_get_ticket() may result
      in better time performance during lock acquisition.
      
      Change-Id: I141bb21294226b54cb6e89e7cac0175c553afd8d
      d4f4ad90
  6. 21 Jan, 2015 1 commit
    • Juan Castillo's avatar
      FVP: map non-secure DRAM1 in the MMU · 6fd9eaf3
      Juan Castillo authored
      This patch maps the non-secure region of DRAM1 in the MMU. The
      non-secure region comprises the whole DRAM1 (0x80000000 -
      0xffffffff) excluding the top 16 MB (0xff000000 - 0xffffffff).
      The TrustZone controller configures this 16 MB region as secure
      memory, so it can not be accessed in non-secure mode.
      
      The number of MMU tables in BL2 has been increased to 3 because
      the new size of the non-secure region in DRAM requires an extra L2
      table.
      
      Change-Id: I5ad080c6e181f6b6060e15cebb1d18b7fa128cf5
      6fd9eaf3
  7. 16 Jan, 2015 2 commits
  8. 13 Jan, 2015 1 commit
    • Soby Mathew's avatar
      Invalidate the dcache after initializing cpu-ops · 09997346
      Soby Mathew authored
      This patch fixes a crash due to corruption of cpu_ops
      data structure. During the secondary CPU boot, after the
      cpu_ops has been initialized in the per cpu-data, the
      dcache lines need to invalidated so that the update in
      memory can be seen later on when the dcaches are turned ON.
      Also, after initializing the psci per cpu data, the dcache
      lines are flushed so that they are written back to memory
      and dirty dcache lines are avoided.
      
      Fixes ARM-Software/tf-issues#271
      
      Change-Id: Ia90f55e9882690ead61226eea5a5a9146d35f313
      09997346
  9. 12 Jan, 2015 5 commits