• David Hildenbrand's avatar
    virtio-mem: kdump mode to sanitize /proc/vmcore access · ce281462
    David Hildenbrand authored
    Although virtio-mem currently supports reading unplugged memory in the
    hypervisor, this will change in the future, indicated to the device via
    a new feature flag.
    
    We similarly sanitized /proc/kcore access recently.  [1]
    
    Let's register a vmcore callback, to allow vmcore code to check if a PFN
    belonging to a virtio-mem device is either currently plugged and should
    be dumped or is currently unplugged and should not be accessed, instead
    mapping the shared zeropage or returning zeroes when reading.
    
    This is important when not capturing /proc/vmcore via tools like
    "makedumpfile" that can identify logically unplugged virtio-mem memory
    via PG_offline in the memmap, but simply by e.g., copying the file.
    
    Distributions that support virtio-mem+kdump have to make sure that the
    virtio_mem module will be part of the kdump kernel or the kdump initrd;
    dracut was recently [2] extended to include virtio-mem in the generated
    initrd.  As long as no special kdump kernels are used, this will
    automatically make sure that virtio-mem will be around in the kdump
    initrd and sanitize /proc/vmcore access -- with dracut.
    
    With this series, we'll send one virtio-mem state request for every ~2
    MiB chunk of virtio-mem memory indicated in the vmcore that we intend to
    read/map.
    
    In the future, we might want to allow building virtio-mem for kdump mode
    only, even without CONFIG_MEMORY_HOTPLUG and friends: this way, we could
    support special stripped-down kdump kernels that have many other config
    options disabled; we'll tackle that once required.  Further, we might
    want to try sensing bigger blocks (e.g., memory sections) first before
    falling back to device blocks on demand.
    
    Tested with Fedora rawhide, which contains a recent kexec-tools version
    (considering "System RAM (virtio_mem)" when creating the vmcore header)
    and a recent dracut version (including the virtio_mem module in the
    kdump initrd).
    
    Link: https://lkml.kernel.org/r/20210526093041.8800-1-david@redhat.com [1]
    Link: https://github.com/dracutdevs/dracut/pull/1157 [2]
    Link: https://lkml.kernel.org/r/20211005121430.30136-10-david@redhat.comSigned-off-by: default avatarDavid Hildenbrand <david@redhat.com>
    Cc: Baoquan He <bhe@redhat.com>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Cc: Dave Young <dyoung@redhat.com>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jason Wang <jasowang@redhat.com>
    Cc: Juergen Gross <jgross@suse.com>
    Cc: "Michael S. Tsirkin" <mst@redhat.com>
    Cc: Michal Hocko <mhocko@suse.com>
    Cc: Mike Rapoport <rppt@kernel.org>
    Cc: Oscar Salvador <osalvador@suse.de>
    Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
    Cc: Stefano Stabellini <sstabellini@kernel.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Vivek Goyal <vgoyal@redhat.com>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    ce281462
virtio_mem.c 78.1 KB