1. 25 Sep, 2019 1 commit
    • Sandrine Bailleux's avatar
      FVP: Fix plat_set_nv_ctr() function · bd363d35
      Sandrine Bailleux authored
      The Fast Models provide a non-volatile counter component, which is used
      in the Trusted Board Boot implementation to protect against rollback
      attacks.
      
      This component comes in 2 versions (see [1]).
      
      - Version 0 is the default and models a locked non-volatile counter,
        whose value is fixed.
      
      - Version 1 of the counter may be incremented in a monotonic fashion.
      
      plat_set_nv_ctr() must cope with both versions. This is achieved by:
      1) Attempting to write the new value in the counter.
      2) Reading the value back.
      3) If there is a mismatch, we know the counter upgrade failed.
      
      When using version 0 of the counter, no upgrade is possible so the
      function is expected to fail all the time. However, the code is
      missing a compiler barrier between the write operation and the next
      read. Thus, the compiler may optimize and remove the read operation on
      the basis that the counter value has not changed. With the default
      optimization level used in TF-A (-Os), this is what's happening.
      
      The fix introduced in this patch marks the write and subsequent read
      accesses to the counter as volatile, such that the compiler makes no
      assumption about the value of the counter.
      
      Note that the comment above plat_set_nv_ctr() was clearly stating
      that when using the read-only version of the non-volatile counter,
      "we expect the values in the certificates to always match the RO
      values so that this function is never called". However, the fact that
      the counter value was read back seems to contradict this comment, as
      it is implementing a counter-measure against misuse of the
      function. The comment has been reworded to avoid any confusion.
      
      Without this patch, this bug may be demonstrated on the Base AEM FVP:
      - Using version 0 of the non-volatile counter (default version).
      - With certificates embedding a revision number value of 32
        (compiling TF-A with TFW_NVCTR_VAL=32).
      
      In this configuration, the non-volatile counter is tied to value 31 by
      default. When BL1 loads the Trusted Boot Firmware certificate, it
      notices that the two values do not match and tries to upgrade the
      non-volatile counter. This write operation is expected to fail
      (because the counter is locked) and the function is expected to return
      an error but it succeeds instead.
      
      As a result, the trusted boot does not abort as soon as it should and
      incorrectly boots BL2. The boot is finally aborted when BL2 verifies
      the BL31 image and figures out that the version of the SoC Firmware
      Key Certificate does not match. On Arm platforms, only certificates
      signed with the Root-of-Trust Key may trigger an upgrade of the
      non-volatile Trusted counter.
      
      [1] https://developer.arm.com/docs/100964/1160/fast-models-components/peripheral-components/nonvolatilecounter
      
      
      
      Change-Id: I9979f29c23b47b338b9b484013d1fb86c59db92f
      Signed-off-by: default avatarSandrine Bailleux <sandrine.bailleux@arm.com>
      bd363d35
  2. 20 Sep, 2019 2 commits
    • Kever Yang's avatar
      rockchip: Update BL31_BASE to 0x40000 · 0aad563c
      Kever Yang authored
      
      
      Rockchip platform is using the first 1MB of DRAM as secure ram space,
      and there is a vendor loader who loads and runs the BL31/BL32/BL33,
      this loader is usually load by SoC BootRom to the start addres of DRAM,
      we need to reserve enough space for this loader so that it doesn't need
      to do the relocate when loading the BL31. eg.
      We use U-Boot SPL to load ATF BL31 and U-Boot proper as BL33, the SPL
      TEXT BASE is offset 0 of DRAM which is decide by Bootrom; if we update
      the BL31_BASE to offset 0x40000(256KB), then the 0~0x40000 should be
      enough for SPL and no need to do the relocate while the space size
      0x10000(64KB) may not enough for SPL.
      After this update, the BL31 can use the rest 768KB of the first 1MB,
      which is also enough, and the loader who is using BL31 elf file can
      support this update without any change.
      
      Change-Id: I66dc685594d77f10f9a49c3be015fd6729250ece
      Signed-off-by: default avatarKever Yang <kever.yang@rock-chips.com>
      0aad563c
    • Kever Yang's avatar
      rockchip: Fix typo for TF content text · 382ddb3d
      Kever Yang authored
      
      
      The 'txet' should be 'text'.
      
      Change-Id: I2217a1adf50c3b86f3087b83c77d9291b280627c
      Signed-off-by: default avatarKever Yang <kever.yang@rock-chips.com>
      382ddb3d
  3. 18 Sep, 2019 4 commits
  4. 17 Sep, 2019 1 commit
  5. 16 Sep, 2019 6 commits
  6. 13 Sep, 2019 11 commits
    • Andre Przywara's avatar
      rpi3: Do prescaler and control setup in C · dcf6d4f8
      Andre Przywara authored
      
      
      To initialise the arch timer configuration and some clock prescaler, we
      need to do two MMIO access *once*, early during boot.
      
      As tempting as it may sound, plat_reset_handler() is not the right place
      to do this, as it will be called on every CPU coming up, both for
      secondary cores as well as during warmboots. So this access will be done
      multiple times, and even during a rich OS' runtime. Whether doing so anyway
      is actually harmful is hard to say, but we should definitely avoid this if
      possible.
      
      Move the initialisation of these registers to C code in
      bl1_early_platform_setup(), where it will still be executed early enough
      (before enabling the console), but only once during the whole boot
      process.
      
      Change-Id: I081c41a5476d424411411488ff8f633e87d3bcc5
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      dcf6d4f8
    • Andre Przywara's avatar
      rpi3: Move rng driver to drivers · 990ab78e
      Andre Przywara authored
      
      
      To allow sharing the driver between the RPi3 and RPi4, move the random
      number generator driver into the generic driver directory.
      
      Change-Id: Iae94d7cb22c6bce3af9bff709d76d4caf87b14d1
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      990ab78e
    • Andre Przywara's avatar
      rpi3: Add "rpi" platform directory · ab13addd
      Andre Przywara authored
      
      
      With the incoming support for the Raspberry Pi 4 boards, one directory
      to serve both versions will not end up well.
      
      Create an additional layer by inserting a "rpi" directory betweeen /plat
      and rpi3, so that we can more easily share or separate files between the
      two later.
      
      Change-Id: I75adbb054fe7902f34db0fd5e579a55612dd8a5f
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      ab13addd
    • Andre Przywara's avatar
      rpi3: Prepare for supporting a GIC (in RPi4) · e6fd00ab
      Andre Przywara authored
      
      
      As the PSCI "power" management functions for the Raspberry Pi 3 port
      will be shared with the upcoming RPi4 support, we need to prepare them
      for dealing with the GIC interrupt controller.
      Splitting this code just for those simple calls to the generic GIC
      routines does not seem worthwhile, so just use a #define the protect the
      GIC code from being included by the existing RPi3 code.
      
      Change-Id: Iaca6b0214563852b28ad4a088ec45348ae8be40d
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      e6fd00ab
    • Andre Przywara's avatar
      qemu: Move and generalise FDT PSCI fixup · f240728b
      Andre Przywara authored
      
      
      The QEMU platform port scans its device tree to advertise PSCI as the
      CPU enable method. It does this by scanning *every* node in the DT and
      check whether its compatible string starts with "arm,cortex-a". Then it
      sets the enable-method to PSCI, if it doesn't already have one.
      
      Other platforms might want to use this functionality as well, so let's
      move it out of the QEMU platform directory and make it more robust by
      fixing some shortcomings:
      - A compatible string starting with a certain prefix is not a good way
      to find the CPU nodes. For instance a "arm,cortex-a72-pmu" node will
      match as well and is in turn favoured with an enable-method.
      - If the DT already has an enable-method, we won't change this to PSCI.
      
      Those two issues will for instance fail on the Raspberry Pi 4 DT.
      To fix those problems, we adjust the scanning method:
      The DT spec says that all CPU nodes are subnodes of the mandatory
      /cpus node, which is a subnode of the root node. Also each CPU node has
      to have a device_type = "cpu" property. So we find the /cpus node, then
      scan for a subnode with the proper device_type, forcing the
      enable-method to "psci".
      We have to restart this search after a property has been patched, as the
      node offsets might have changed meanwhile.
      
      This allows this routine to be reused for the Raspberry Pi 4 later.
      
      Change-Id: I00cae16cc923d9f8bb96a9b2a2933b9a79b06139
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      f240728b
    • Andre Przywara's avatar
      rpi3: Move VC mailbox driver into generic drivers directory · c0031189
      Andre Przywara authored
      
      
      To allow sharing the driver between the RPi3 and RPi4, move the mailbox
      driver into the generic driver directory.
      
      Change-Id: I463e49acf82b02bf004f3d56482b7791f3020bc0
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      c0031189
    • Andre Przywara's avatar
      rpi3: Make SHARED_RAM optional · a95e6415
      Andre Przywara authored
      
      
      The existing Raspberry Pi 3 port sports a number of memory regions,
      which are used for several purposes. The upcoming RPi4 port will not use
      all of those, so make the SHARED_RAM region optional, by only mapping it
      if it has actually been defined. This helps to get a cleaner RPi4 port.
      
      Change-Id: Id69677b7fb6ed48d9f238854b610896785db8cab
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      a95e6415
    • Andre Przywara's avatar
      rpi3: Move rpi3_hw.h header file to include/rpi_hw.h · 4666d046
      Andre Przywara authored
      
      
      With the advent of Raspberry Pi 4 support, we need to separate some
      board specific headers between the RPi3 and RPi4.
      Rename and move the "rpi3_hw.h" header, so that .c files just include
      rpi_hw.h, and automatically get the correct version.
      
      Change-Id: I03b39063028d2bee1429bffccde71dddfe2dcde8
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      4666d046
    • Andre Przywara's avatar
      rpi3: Rename RPI3_IO_BASE to RPI_IO_BASE · 110fd1fe
      Andre Przywara authored
      
      
      The location of the MMIO window is different between a Raspberry Pi 3
      and 4: the former has it just below 1GB, the latter below 4GB.
      The relative location of the peripherals is mostly compatible though.
      
      To allow sharing code between the two models, let's rename the symbol
      used for the MMIO base to the more generic RPI_IO_BASE name.
      
      Change-Id: I3c2762fb30fd56cca743348e79d72ef8c60ddb03
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      110fd1fe
    • Andre Przywara's avatar
      rpi3: Move shared rpi3 files into common directory · 4f2b9848
      Andre Przywara authored
      
      
      To be able to share code more easily between the existing Raspberry Pi 3
      and the upcoming Raspberry Pi 4 platform, move some code which is not
      board specific into a "common" directory.
      
      Change-Id: I9211ab2d754b040128fac13c2f0a30a5cc8c7f2c
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      4f2b9848
    • 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 4 commits
  8. 11 Sep, 2019 4 commits
    • Carlo Caione's avatar
      amlogic: Fix includes order · b5621874
      Carlo Caione authored
      
      
      As part of the code refactoring fix the order of the include files
      across all the source files.
      Signed-off-by: default avatarCarlo Caione <ccaione@baylibre.com>
      Change-Id: Ice72f687cc26ee881a9051168149467688100cfb
      b5621874
    • Carlo Caione's avatar
      amlogic: Fix header guards · 421b67b6
      Carlo Caione authored
      
      
      Make the header guards more generic and contextually remove the
      GXBB_BL31_PLAT_PARAM_VAL value that is unused on the GXL platform.
      Signed-off-by: default avatarCarlo Caione <ccaione@baylibre.com>
      Change-Id: I842fa2e084e71280ae17b39c67877e844821a171
      421b67b6
    • John Tsichritzis's avatar
      Modify FVP makefile for cores that support both AArch64/32 · cd3c5b4c
      John Tsichritzis authored
      
      
      Some cores support only AArch64 from EL1 and above, e.g. A76, N1 etc. If
      TF-A is compiled with CTX_INCLUDE_AARCH32_REGS=0 so as to properly
      handle those cores, only the AArch64 cores' assembly is included in the
      TF-A binary. In other words, for FVP, TF-A assumes that AArch64 only
      cores will never exist in the same cluster with cores that also support
      AArch32.
      
      However, A55 and A75 can be used as AArch64 only cores, despite
      supporting AArch32, too. This patch enables A55 and A75 to exist in
      clusters together with AArch64 cores.
      
      Change-Id: I58750ad6c3d76ce77eb354784c2a42f2c179031d
      Signed-off-by: default avatarJohn Tsichritzis <john.tsichritzis@arm.com>
      cd3c5b4c
    • Justin Chadwell's avatar
      Add UBSAN support and handlers · 1f461979
      Justin Chadwell authored
      
      
      This patch adds support for the Undefined Behaviour sanitizer. There are
      two types of support offered - minimalistic trapping support which
      essentially immediately crashes on undefined behaviour and full support
      with full debug messages.
      
      The full support relies on ubsan.c which has been adapted from code used
      by OPTEE.
      
      Change-Id: I417c810f4fc43dcb56db6a6a555bfd0b38440727
      Signed-off-by: default avatarJustin Chadwell <justin.chadwell@arm.com>
      1f461979
  9. 10 Sep, 2019 7 commits