1. 22 Feb, 2021 2 commits
  2. 19 Feb, 2021 4 commits
  3. 18 Feb, 2021 1 commit
  4. 17 Feb, 2021 1 commit
  5. 16 Feb, 2021 4 commits
  6. 12 Feb, 2021 4 commits
  7. 11 Feb, 2021 8 commits
  8. 10 Feb, 2021 3 commits
  9. 09 Feb, 2021 5 commits
    • Manish V Badarkhe's avatar
      plat/arm: fvp: Protect GICR frames for fused/unused cores · f98630fb
      Manish V Badarkhe authored
      
      
      Currently, BLs are mapping the GIC memory region as read-write
      for all cores on boot-up.
      
      This opens up the security hole where the active core can write
      the GICR frame of fused/inactive core. To avoid this issue, disable
      the GICR frame of all inactive cores as below:
      
      1. After primary CPU boots up, map GICR region of all cores as
         read-only.
      2. After primary CPU boots up, map its GICR region as read-write
         and initialize its redistributor interface.
      3. After secondary CPU boots up, map its GICR region as read-write
         and initialize its redistributor interface.
      4. All unused/fused core's redistributor regions remain read-only and
         write attempt to such protected regions results in an exception.
      
      As mentioned above, this patch offers only the GICR memory-mapped
      region protection considering there is no facility at the GIC IP
      level to avoid writing the redistributor area.
      
      These changes are currently done in BL31 of Arm FVP and guarded under
      the flag 'FVP_GICR_REGION_PROTECTION'.
      
      As of now, this patch is tested manually as below:
      1. Disable the FVP cores (core 1, 2, 3) with core 0 as an active core.
      2. Verify data abort triggered by manually updating the ‘GICR_CTLR’
         register of core 1’s(fused) redistributor from core 0(active).
      
      Change-Id: I86c99c7b41bae137b2011cf2ac17fad0a26e776d
      Signed-off-by: default avatarManish V Badarkhe <Manish.Badarkhe@arm.com>
      f98630fb
    • Manish V Badarkhe's avatar
      doc: Build option to protect GICR frame · d30a6615
      Manish V Badarkhe authored
      
      
      Added a build option 'FVP_GICR_REGION_PROTECTION' to make
      redistributor frame of fused/unused cores as read only.
      
      Change-Id: Ie85f86e2465b93321a92a888ce8712a3144e4ccb
      Signed-off-by: default avatarManish V Badarkhe <Manish.Badarkhe@arm.com>
      d30a6615
    • Manish V Badarkhe's avatar
      plat/arm: fvp: Do not map GIC region in BL1 and BL2 · e0cea783
      Manish V Badarkhe authored
      
      
      GIC memory region is not getting used in BL1 and BL2.
      Hence avoid its mapping in BL1 and BL2 that freed some
      page table entries to map other memory regions in the
      future.
      
      Retains mapping of CCN interconnect region in BL1 and BL2
      overlapped with the GIC memory region.
      
      Change-Id: I880dd0690f94b140e59e4ff0c0d436961b9cb0a7
      Signed-off-by: default avatarManish V Badarkhe <Manish.Badarkhe@arm.com>
      e0cea783
    • Sandrine Bailleux's avatar
    • Usama Arif's avatar
      fdts: use scmi_dvfs clock index 1 for cores 4-7 · a97c390b
      Usama Arif authored
      
      
      This allows Matterhorn cores to operate at their optimal OPPs.
      Signed-off-by: default avatarUsama Arif <usama.arif@arm.com>
      Change-Id: I2e1b784da10154a1f1f65dd0e3a39213e7683116
      a97c390b
  10. 08 Feb, 2021 1 commit
  11. 05 Feb, 2021 5 commits
  12. 04 Feb, 2021 1 commit
  13. 03 Feb, 2021 1 commit
    • Julius Werner's avatar
      qti: spmi_arb: Fix NUM_APID and REG_APID_MAP() argument · de67080f
      Julius Werner authored
      
      
      The NUM_APID value was derived from kernel device tree sources, but I
      made a conversion mistake: the amount of bytes in the APID map is the
      total size of the "core" register range (0x1100) minus the offset of the
      APID map in that range (0x900). This is of course 0x1100 - 0x900 = 0x800
      and not 0x200, so the amount of 4-byte integers it can fit is not 0x80
      but 0x200. Fix this and make the math more explicit so it can be more
      easily factored out and adjusted if that becomes necessary for a future
      SoC.
      
      Also fix a dangerous typo in REG_APID_MAP() where the macro would
      reference a random variable `i` rather than its argument (`apid`), and
      we just got lucky that the only caller in the current code happened to
      pass in a variable called `i` as that argument.
      Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      Change-Id: I049dd044fa5aeb65be0e7b12150afd6eb4bac0fa
      de67080f