KVM: arm64: Ensure user_mem_abort() return value is initialised
Will Deacon
maintainerPATCH 1/1 KVM: arm64: Ensure user_mem_abort() return value is initialised
From: Will Deacon <[email protected]>
If a change in the MMU notifier sequence number forces user_mem_abort() to return early when attempting to handle a stage-2 fault, we return uninitialised stack to kvm_handle_guest_abort(), which could potentially result in the injection of an external abort into the guest or a spurious return to userspace. Neither or these are what we want to do.
Initialise 'ret' to 0 in user_mem_abort() so that bailing due to a change in the MMU notrifier sequence number is treated as though the fault was handled.
---
Applies on top of kvmarm/next.
arch/arm64/kvm/mmu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm64/kvm/mmu.c +1 -1
@@ -742,7 +742,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, struct kvm_memory_slot *memslot, unsigned long hva, unsigned long fault_status) { - int ret; + int ret = 0;bool write_fault, writable, force_pte = false;bool exec_fault;bool device = false;
Signature · 6 lines
2.28.0.709.gb0816b6eb0-goog _______________________________________________ kvmarm mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Will Deacon
maintainerQuoted 1 line · Will Deacon
From: Will Deacon <[email protected]>
Bugger, sorry, committed this in the wrong tree and got the wrong address on it. Patch is still fine, but the author should be my kernel.org address, to match the SoB.
Will
_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Hi Will,
Quoted 29 lines · Will Deacon
From: Will Deacon <[email protected]>
If a change in the MMU notifier sequence number forces
user_mem_abort()to return early when attempting to handle a stage-2 fault, we return uninitialised stack tokvm_handle_guest_abort(), which could potentially result in the injection of an external abort into the guest or a spurious return to userspace. Neither or these are what we want to do.Initialise 'ret' to 0 in
user_mem_abort()so that bailing due to a change in the MMU notrifier sequence number is treated as though the fault was handled.Cc Gavin Shan <[email protected]>Cc Alexandru Elisei <[email protected]>Reported-by kernel test robot <[email protected]>Reported-by Dan Carpenter <[email protected]>Signed-off-by Will Deacon <[email protected]>---
Applies on top of kvmarm/next.
arch/arm64/kvm/mmu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)arch/arm64/kvm/mmu.c +0
-0
arch/arm64/kvm/mmu.c static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, · line 748
Quoted 8 lines
arch/arm64/kvm/mmu.c +1
-1@@ -742,7 +742,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, struct kvm_memory_slot *memslot, unsigned long hva, unsigned long fault_status) { - int ret; + int ret = 0;bool write_fault, writable, force_pte = false;bool exec_fault;bool device = false;
This matches the current behavior of user_mem_abort(), where ret = 0 from the call to kvm_mmu_topup_memory_cache(), which was made conditional by the EL2 page table rewrite. It makes sense to me - we return to the guest and take the fault again until the changes to the translation tables have been executed (mmu_notifier_seq remains the same and mmu_notifier_count == 0):
_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Quoted 12 lines · Will Deacon
From: Will Deacon <[email protected]>
If a change in the MMU notifier sequence number forces
user_mem_abort()to return early when attempting to handle a stage-2 fault, we return uninitialised stack tokvm_handle_guest_abort(), which could potentially result in the injection of an external abort into the guest or a spurious return to userspace. Neither or these are what we want to do.Initialise 'ret' to 0 in
user_mem_abort()so that bailing due to a change in the MMU notrifier sequence number is treated as though the fault was handled.
Quoted 7 lines
Cc Gavin Shan <[email protected]>Cc Alexandru Elisei <[email protected]>Reported-by kernel test robot <[email protected]>Reported-by Dan Carpenter <[email protected]>Signed-off-by Will Deacon <[email protected]>---
Quoted 11 lines
Applies on top of kvmarm/next.
arch/arm64/kvm/mmu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)arch/arm64/kvm/mmu.c +0
-0
arch/arm64/kvm/mmu.c static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, · line 748
Quoted 8 lines
arch/arm64/kvm/mmu.c +1
-1@@ -742,7 +742,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, struct kvm_memory_slot *memslot, unsigned long hva, unsigned long fault_status) { - int ret; + int ret = 0;bool write_fault, writable, force_pte = false;bool exec_fault;bool device = false;
_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Quoted 9 lines · Will Deacon
If a change in the MMU notifier sequence number forces
user_mem_abort()to return early when attempting to handle a stage-2 fault, we return uninitialised stack tokvm_handle_guest_abort(), which could potentially result in the injection of an external abort into the guest or a spurious return to userspace. Neither or these are what we want to do.Initialise 'ret' to 0 in
user_mem_abort()so that bailing due to a change in the MMU notrifier sequence number is treated as though the fault was handled.
Applied to next, thanks!
[1/1] KVM: arm64: Ensure user_mem_abort() return value is initialised
commit: 84cd7df693f07df94d617049773f7c757a2b7847
Cheers,
M.
Signature · 7 lines
Without deviation from the norm, progress is not possible. _______________________________________________ kvmarm mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/kvmarm