Skip to content
Snippets Groups Projects
  1. Jul 19, 2024
  2. Jul 18, 2024
  3. Jul 16, 2024
  4. Jul 11, 2024
  5. Jul 04, 2024
    • Mostafa Saleh's avatar
      arm64/dts: gs201: Add Alive S2MPU · 7b40bac4
      Mostafa Saleh authored
      
      Alive S2MPU is fully trusted and is not managed by the kernel.
      However, we need to make sure the kernel can’t map it to use
      it in emulation mode of the S2MPU.
      
      So we define it as:
      - “deny-all”: So it never gets power managed or updated
      - “off-at-boot”: Never configured at boot.
      
      Which mainly means it remains unconfigured but it's MMIO is not
      accessible to the kernel.
      
      Bug: 342511931
      Change-Id: I844cdd4e2485fbae416c618b0b8a83e30b847065
      Signed-off-by: default avatarMostafa Saleh <smostafa@google.com>
      7b40bac4
    • Mostafa Saleh's avatar
      arm64/dts: gs201: Add AoC S2MPU · d913e04f
      Mostafa Saleh authored
      
      AoC is only controlled by TZ.
      
      However, SysMMU has an emulation feature that can be misused to read
      from arbitrary memory locations, and with SysMMU under the control of
      the kernel, we need to configure S2MPU to block such potentially
      malicious transactions.
      
      Add the AoC S2MPU with the new flag “deny-all” which would mainly
      unmap the S2MPU interface and configure it to deny all traffic.
      
      Bug: 342511931
      Change-Id: I38a1a2af556eaca83be3bd93db1b5dd400034255
      Signed-off-by: default avatarMostafa Saleh <smostafa@google.com>
      d913e04f
    • Mostafa Saleh's avatar
      arm64/s2mpu: Add deny-all support · 0f1c59c0
      Mostafa Saleh authored
      
      Add "deny-all" propery for S2MPUs, this has the same purpose as other
      branches but implemented in a slightly different way.
      
      Mainly, we want to ensure that this device is not accessible from
      host and in deny-all state, at probe the device is set to deny state
      and then all PM calls are blocked so the hypervisor would never touch
      any of its MMIO
      But they are registered with the hypervisor so they are not accessible
      from host.
      
      Bug: 342511931
      Change-Id: Id8a38b38310ec950841074b288797041355a3ec7
      Signed-off-by: default avatarMostafa Saleh <smostafa@google.com>
      0f1c59c0
  6. Jun 26, 2024
  7. Jun 25, 2024
    • Woody Lin's avatar
      watchdog: s3c2410_wdt: Assign s3c_wdt[] until probe complete · d69b4928
      Woody Lin authored
      
      Assigns device data to `s3c_wdt[cluster_index]` only when probe function
      completes. Several functions of s3c2410_wdt use the existence of
      `s3c_wdt[*]` to decide whether the device data is ready to be accessed.
      This causes an invalid access issue as long as the probe function puts
      device data to `s3c_wdt[cluster_index]` before completely preparing the
      content. Fixes the issue by rearranging the assignment order.
      
      Bug: 342585125
      Change-Id: Idb4c3b71fb2e0518725c697db01e708aa0c7c86b
      Signed-off-by: default avatarWoody Lin <woodylin@google.com>
      (cherry picked from commit d7bd15571d51e658a081d98dfbcc17e3aa104585)
      d69b4928
  8. Jun 24, 2024
  9. Jun 21, 2024
  10. Jun 20, 2024
  11. Jun 14, 2024
    • Kalesh Singh's avatar
      ANDROID: 16K: Only check basename of linker context · 28a6e1ad
      Kalesh Singh authored
      
      Depending on the platform binary being executed, the linker
      (interpreter) requested can be one of:
      
          1) /system/bin/bootstrap/linker64
          2) /system/bin/linker64
          3) /apex/com.android.runtime/bin/linker64
      
      Relax the check to the basename (linker64), instead of the path.
      
      Bug: 330767927
      Bug: 335584973
      Bug: 347106837
      Change-Id: I4a1f95b7cecd126f85ad8cefd9ff10d272947f9e
      Signed-off-by: default avatarKalesh Singh <kaleshsingh@google.com>
      (cherry picked from commit 38965378)
      28a6e1ad
  12. Jun 13, 2024
  13. Jun 12, 2024
    • Kalesh Singh's avatar
      ANDROID: 16K: Only check basename of linker context · 38965378
      Kalesh Singh authored
      
      Depending on the platform binary being executed, the linker
      (interpreter) requested can be one of:
      
          1) /system/bin/bootstrap/linker64
          2) /system/bin/linker64
          3) /apex/com.android.runtime/bin/linker64
      
      Relax the check to the basename (linker64), instead of the path.
      
      Bug: 330767927
      Bug: 335584973
      Change-Id: I4a1f95b7cecd126f85ad8cefd9ff10d272947f9e
      Signed-off-by: default avatarKalesh Singh <kaleshsingh@google.com>
      38965378
  14. Jun 11, 2024
  15. Jun 07, 2024
  16. Jun 06, 2024
  17. Jun 05, 2024
  18. Jun 04, 2024
  19. Jun 03, 2024
Loading