Skip to content

L
linux
Switch branch/tag
  1. 29 Jan, 2023 7 commits
  3. 21 Jan, 2023 2 commits
  5. 05 Jan, 2023 6 commits
  7. 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
  9. 01 Jan, 2023 6 commits
  11. 31 Dec, 2022 2 commits
  13. 30 Dec, 2022 14 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7