• David Hildenbrand's avatar
    proc/vmcore: don't fake reading zeroes on surprise vmcore_cb unregistration · 25bc5b0d
    David Hildenbrand authored
    In commit cc5f2704 ("proc/vmcore: convert oldmem_pfn_is_ram callback
    to more generic vmcore callbacks"), we added detection of surprise
    vmcore_cb unregistration after the vmcore was already opened.  Once
    detected, we warn the user and simulate reading zeroes from that point
    on when accessing the vmcore.
    
    The basic reason was that unexpected unregistration, for example, by
    manually unbinding a driver from a device after opening the vmcore, is
    not supported and could result in reading oldmem the vmcore_cb would
    have actually prohibited while registered.  However, something like that
    can similarly be trigger by a user that's really looking for trouble
    simply by unbinding the relevant driver before opening the vmcore -- or
    by disallowing loading the driver in the first place.  So it's actually
    of limited help.
    
    Currently, unregistration can only be triggered via virtio-mem when
    manually unbinding the driver from the device inside the VM; there is no
    way to trigger it from the hypervisor, as hypervisors don't allow for
    unplugging virtio-mem devices -- ripping out system RAM from a VM
    without coordination with the guest is usually not a good idea.
    
    The important part is that unbinding the driver and unregistering the
    vmcore_cb while concurrently reading the vmcore won't crash the system,
    and that is handled by the rwsem.
    
    To make the mechanism more future proof, let's remove the "read zero"
    part, but leave the warning in place.  For example, we could have a
    future driver (like virtio-balloon) that will contact the hypervisor to
    figure out if we already populated a page for a given PFN.
    Hotunplugging such a device and consequently unregistering the vmcore_cb
    could be triggered from the hypervisor without harming the system even
    while kdump is running.  In that case, we don't want to silently end up
    with a vmcore that contains wrong data, because the user inside the VM
    might be unaware of the hypervisor action and might easily miss the
    warning in the log.
    
    Link: https://lkml.kernel.org/r/20211111192243.22002-1-david@redhat.comSigned-off-by: default avatarDavid Hildenbrand <david@redhat.com>
    Acked-by: default avatarBaoquan He <bhe@redhat.com>
    Cc: Dave Young <dyoung@redhat.com>
    Cc: Vivek Goyal <vgoyal@redhat.com>
    Cc: Philipp Rudo <prudo@redhat.com>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    25bc5b0d
vmcore.c 41.1 KB