Message ID | 20220113233020.3986005-1-dmatlack@google.com (mailing list archive) |
---|---|
Headers | show |
Series | KVM: x86/mmu: Fix write-protection bug in the TDP MMU | expand |
On 1/14/22 00:30, David Matlack wrote: > While attempting to understand the big comment in > kvm_mmu_slot_remove_write_access() about TLB flushing, I discovered a > bug in the way the TDP MMU write-protects GFNs. I have not managed to > reproduce the bug as it requires a rather complex set up of live > migrating a VM that is using nested virtualization while the TDP MMU is > enabled. > > Patch 1 fixes the bug and is CC'd to stable. > Patch 2-3 fix, document, and enforce invariants around MMU-writable > and Host-writable bits. > Patch 4 fixes up the aformentioned comment to be more readable. > > Tested using the kvm-unit-tests and KVM selftests. > > v2: > - Skip setting the SPTE when MMU-writable is already clear [Sean] > - Add patches for {MMU,Host}-writable invariants [Sean] > - Fix inaccuracies in kvm_mmu_slot_remove_write_access() comment [Sean] > > v1: https://lore.kernel.org/kvm/20220112215801.3502286-1-dmatlack@google.com/ > > David Matlack (4): > KVM: x86/mmu: Fix write-protection of PTs mapped by the TDP MMU > KVM: x86/mmu: Clear MMU-writable during changed_pte notifier > KVM: x86/mmu: Document and enforce MMU-writable and Host-writable > invariants > KVM: x86/mmu: Improve TLB flush comment in > kvm_mmu_slot_remove_write_access() > > arch/x86/kvm/mmu/mmu.c | 31 ++++++++++++++++++++-------- > arch/x86/kvm/mmu/spte.c | 1 + > arch/x86/kvm/mmu/spte.h | 42 ++++++++++++++++++++++++++++++++------ > arch/x86/kvm/mmu/tdp_mmu.c | 6 +++--- > 4 files changed, 62 insertions(+), 18 deletions(-) > > > base-commit: fea31d1690945e6dd6c3e89ec5591490857bc3d4 Queued, thanks. Paolo
On Mon, Jan 17, 2022 at 9:59 AM Paolo Bonzini <pbonzini@redhat.com> wrote: > > On 1/14/22 00:30, David Matlack wrote: > > While attempting to understand the big comment in > > kvm_mmu_slot_remove_write_access() about TLB flushing, I discovered a > > bug in the way the TDP MMU write-protects GFNs. I have not managed to > > reproduce the bug as it requires a rather complex set up of live > > migrating a VM that is using nested virtualization while the TDP MMU is > > enabled. > > > > Patch 1 fixes the bug and is CC'd to stable. > > Patch 2-3 fix, document, and enforce invariants around MMU-writable > > and Host-writable bits. > > Patch 4 fixes up the aformentioned comment to be more readable. > > > > Tested using the kvm-unit-tests and KVM selftests. > > > > v2: > > - Skip setting the SPTE when MMU-writable is already clear [Sean] > > - Add patches for {MMU,Host}-writable invariants [Sean] > > - Fix inaccuracies in kvm_mmu_slot_remove_write_access() comment [Sean] > > > > v1: https://lore.kernel.org/kvm/20220112215801.3502286-1-dmatlack@google.com/ > > > > David Matlack (4): > > KVM: x86/mmu: Fix write-protection of PTs mapped by the TDP MMU > > KVM: x86/mmu: Clear MMU-writable during changed_pte notifier > > KVM: x86/mmu: Document and enforce MMU-writable and Host-writable > > invariants > > KVM: x86/mmu: Improve TLB flush comment in > > kvm_mmu_slot_remove_write_access() > > > > arch/x86/kvm/mmu/mmu.c | 31 ++++++++++++++++++++-------- > > arch/x86/kvm/mmu/spte.c | 1 + > > arch/x86/kvm/mmu/spte.h | 42 ++++++++++++++++++++++++++++++++------ > > arch/x86/kvm/mmu/tdp_mmu.c | 6 +++--- > > 4 files changed, 62 insertions(+), 18 deletions(-) > > > > > > base-commit: fea31d1690945e6dd6c3e89ec5591490857bc3d4 > > Queued, thanks. Thanks Paolo. Patches 1 and 4 had some wordsmithing suggestions from Sean that I think would be worth taking. I'm fine if you want to fold his suggestions directly into the queued patches or I can resend. The feedback on Patch 3 would require a follow-up series to address, which I can handle separately. > > Paolo >
On 1/18/22 18:38, David Matlack wrote: > Thanks Paolo. > > Patches 1 and 4 had some wordsmithing suggestions from Sean that I > think would be worth taking. I'm fine if you want to fold his > suggestions directly into the queued patches or I can resend. > > The feedback on Patch 3 would require a follow-up series to address, > which I can handle separately. > Ok, I will fold it myself. Paolo