Bug 647964

Summary: KVM: Write protect memory after slot swap
Product: Red Hat Enterprise Linux 6 Reporter: jason wang <jasowang>
Component: kernelAssignee: jason wang <jasowang>
Status: CLOSED DUPLICATE QA Contact: Virtualization Bugs <virt-bugs>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 6.0CC: akong
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-11-05 03:26:26 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description jason wang 2010-10-30 03:25:49 UTC
Description of problem:

We need write protect memory after the slot swap in kvm_vm_ioctl_get_dirty_log() otherwise we may miss dirty pages.

This issue have been fixed in upstream in:

    KVM: Write protect memory after slot swap
    
    I have observed the following bug trigger:
    
    1. userspace calls GET_DIRTY_LOG
    2. kvm_mmu_slot_remove_write_access is called and makes a page ro
    3. page fault happens and makes the page writeable
       fault is logged in the bitmap appropriately
    4. kvm_vm_ioctl_get_dirty_log swaps slot pointers
    
    a lot of time passes
    
    5. guest writes into the page
    6. userspace calls GET_DIRTY_LOG
    
    At point (5), bitmap is clean and page is writeable,
    thus, guest modification of memory is not logged
    and GET_DIRTY_LOG returns an empty bitmap.
    
    The rule is that all pages are either dirty in the current bitmap,
    or write-protected, which is violated here.
    
    It seems that just moving kvm_mmu_slot_remove_write_access down
    to after the slot pointer swap should fix this bug.
    
    KVM-Stable-Tag.
    Signed-off-by: Michael S. Tsirkin <mst>
    Signed-off-by: Avi Kivity <avi>


Version-Release number of selected component (if applicable):
6.0

How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 2 jason wang 2010-11-05 03:26:26 UTC

*** This bug has been marked as a duplicate of bug 647367 ***