1. 29 Jan, 2023 6 commits
  2. 21 Jan, 2023 2 commits
  3. 05 Jan, 2023 6 commits
  4. 03 Jan, 2023 3 commits
    • Marc Zyngier's avatar
      KVM: arm64: Convert FSC_* over to ESR_ELx_FSC_* · b0803ba7
      Marc Zyngier authored
      The former is an AArch32 legacy, so let's move over to the
      verbose (and strictly identical) version.
      
      This involves moving some of the #defines that were private
      to KVM into the more generic esr.h.
      Signed-off-by: default avatarMarc Zyngier <maz@kernel.org>
      b0803ba7
    • Marc Zyngier's avatar
      KVM: arm64: Document the behaviour of S1PTW faults on RO memslots · b8f8d190
      Marc Zyngier authored
      Although the KVM API says that a write to a RO memslot must result
      in a KVM_EXIT_MMIO describing the write, the arm64 architecture
      doesn't provide the *data* written by a Stage-1 page table walk
      (we only get the address).
      
      Since there isn't much userspace can do with so little information
      anyway, document the fact that such an access results in a guest
      exception, not an exit. This is consistent with the guest being
      terminally broken anyway.
      Reviewed-by: default avatarOliver Upton <oliver.upton@linux.dev>
      Signed-off-by: default avatarMarc Zyngier <maz@kernel.org>
      b8f8d190
    • Marc Zyngier's avatar
      KVM: arm64: Fix S1PTW handling on RO memslots · 406504c7
      Marc Zyngier authored
      A recent development on the EFI front has resulted in guests having
      their page tables baked in the firmware binary, and mapped into the
      IPA space as part of a read-only memslot. Not only is this legitimate,
      but it also results in added security, so thumbs up.
      
      It is possible to take an S1PTW translation fault if the S1 PTs are
      unmapped at stage-2. However, KVM unconditionally treats S1PTW as a
      write to correctly handle hardware AF/DB updates to the S1 PTs.
      Furthermore, KVM injects an exception into the guest for S1PTW writes.
      In the aforementioned case this results in the guest taking an abort
      it won't recover from, as the S1 PTs mapping the vectors suffer from
      the same problem.
      
      So clearly our handling is... wrong.
      
      Instead, switch to a two-pronged approach:
      
      - On S1PTW translation fault, handle the fault as a read
      
      - On S1PTW permission fault, handle the fault as a write
      
      This is of no consequence to SW that *writes* to its PTs (the write
      will trigger a non-S1PTW fault), and SW that uses RO PTs will not
      use HW-assisted AF/DB anyway, as that'd be wrong.
      
      Only in the case described in c4ad98e4 ("KVM: arm64: Assume write
      fault on S1PTW permission fault on instruction fetch") do we end-up
      with two back-to-back faults (page being evicted and faulted back).
      I don't think this is a case worth optimising for.
      
      Fixes: c4ad98e4 ("KVM: arm64: Assume write fault on S1PTW permission fault on instruction fetch")
      Reviewed-by: default avatarOliver Upton <oliver.upton@linux.dev>
      Reviewed-by: default avatarArd Biesheuvel <ardb@kernel.org>
      Regression-tested-by: default avatarArd Biesheuvel <ardb@kernel.org>
      Signed-off-by: default avatarMarc Zyngier <maz@kernel.org>
      Cc: stable@vger.kernel.org
      406504c7
  5. 01 Jan, 2023 6 commits
  6. 31 Dec, 2022 2 commits
  7. 30 Dec, 2022 15 commits