KVM: arm64: Assume write fault on S1PTW permission fault on instruction fetch
authorMarc Zyngier <maz@kernel.org>
Tue, 15 Sep 2020 10:42:17 +0000 (11:42 +0100)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 1 Oct 2020 15:36:35 +0000 (17:36 +0200)
commit8b76d62a9986abbc6f7e5dad658ef65ed7e8c9e6
tree75ebe73f5b4aca6db1e70013d19d1f375b3ac001
parent3bd50397031b6a7bef33a071eb619dcb1b6d0a26
KVM: arm64: Assume write fault on S1PTW permission fault on instruction fetch

commit c4ad98e4b72cb5be30ea282fce935248f2300e62 upstream.

KVM currently assumes that an instruction abort can never be a write.
This is in general true, except when the abort is triggered by
a S1PTW on instruction fetch that tries to update the S1 page tables
(to set AF, for example).

This can happen if the page tables have been paged out and brought
back in without seeing a direct write to them (they are thus marked
read only), and the fault handling code will make the PT executable(!)
instead of writable. The guest gets stuck forever.

In these conditions, the permission fault must be considered as
a write so that the Stage-1 update can take place. This is essentially
the I-side equivalent of the problem fixed by 60e21a0ef54c ("arm64: KVM:
Take S1 walks into account when determining S2 write faults").

Update kvm_is_write_fault() to return true on IABT+S1PTW, and introduce
kvm_vcpu_trap_is_exec_fault() that only return true when no faulting
on a S1 fault. Additionally, kvm_vcpu_dabt_iss1tw() is renamed to
kvm_vcpu_abt_iss1tw(), as the above makes it plain that it isn't
specific to data abort.

Signed-off-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Will Deacon <will@kernel.org>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200915104218.1284701-2-maz@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
arch/arm64/include/asm/kvm_emulate.h
arch/arm64/kvm/hyp/switch.c
arch/arm64/kvm/mmio.c
arch/arm64/kvm/mmu.c