[PATCH v1 0/8] proc/vmcore: sanitize access to virtio-mem memory
David Hildenbrand
david at redhat.com
Tue Sep 28 11:22:50 PDT 2021
As so often with virtio-mem changes that mess with common MM
infrastructure, this might be a good candiate to go via Andrew's tree.
--
After removing /dev/kmem, sanitizing /proc/kcore and handling /dev/mem,
this series tackles the last sane way how a VM could accidentially access
logically unplugged memory managed by a virtio-mem device: /proc/vmcore
When dumping memory via "makedumpfile", PG_offline pages, used by
virtio-mem to flag logically unplugged memory, are already properly
excluded; however, especially when accessing/copying /proc/vmcore "the
usual way", we can still end up reading logically unplugged memory part of
a virtio-mem device.
Patch #1-#3 are cleanups. Patch #4 extends the existing oldmem_pfn_is_ram
mechanism. Patch #5-#7 are virtio-mem refactorings for patch #8, which
implements the virtio-mem logic to query the state of device blocks.
Patch #8:
"
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.
[...]
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.
"
This is the last remaining bit to support
VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE [3] in the Linux implementation of
virtio-mem.
Note: this is best-effort. We'll never be able to control what runs inside
the second kernel, really, but we also don't have to care: we only care
about sane setups where we don't want our VM getting zapped once we
touch the wrong memory location while dumping. While we usually expect sane
setups to use "makedumfile", nothing really speaks against just copying
/proc/vmcore, especially in environments where HWpoisioning isn't typically
expected. Also, we really don't want to put all our trust completely on the
memmap, so sanitizing also makes sense when just using "makedumpfile".
[1] https://lkml.kernel.org/r/20210526093041.8800-1-david@redhat.com
[2] https://github.com/dracutdevs/dracut/pull/1157
[3] https://lists.oasis-open.org/archives/virtio-comment/202109/msg00021.html
Cc: Andrew Morton <akpm at linux-foundation.org>
Cc: Thomas Gleixner <tglx at linutronix.de>
Cc: Ingo Molnar <mingo at redhat.com>
Cc: Borislav Petkov <bp at alien8.de>
Cc: "H. Peter Anvin" <hpa at zytor.com>
Cc: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Cc: Juergen Gross <jgross at suse.com>
Cc: Stefano Stabellini <sstabellini at kernel.org>
Cc: "Michael S. Tsirkin" <mst at redhat.com>
Cc: Jason Wang <jasowang at redhat.com>
Cc: Dave Young <dyoung at redhat.com>
Cc: Baoquan He <bhe at redhat.com>
Cc: Vivek Goyal <vgoyal at redhat.com>
Cc: Michal Hocko <mhocko at suse.com>
Cc: Oscar Salvador <osalvador at suse.de>
Cc: Mike Rapoport <rppt at kernel.org>
Cc: "Rafael J. Wysocki" <rafael.j.wysocki at intel.com>
Cc: x86 at kernel.org
Cc: xen-devel at lists.xenproject.org
Cc: virtualization at lists.linux-foundation.org
Cc: kexec at lists.infradead.org
Cc: linux-fsdevel at vger.kernel.org
Cc: linux-mm at kvack.org
David Hildenbrand (8):
x86/xen: update xen_oldmem_pfn_is_ram() documentation
x86/xen: simplify xen_oldmem_pfn_is_ram()
proc/vmcore: let pfn_is_ram() return a bool
proc/vmcore: convert oldmem_pfn_is_ram callback to more generic vmcore
callbacks
virtio-mem: factor out hotplug specifics from virtio_mem_init() into
virtio_mem_init_hotplug()
virtio-mem: factor out hotplug specifics from virtio_mem_probe() into
virtio_mem_init_hotplug()
virtio-mem: factor out hotplug specifics from virtio_mem_remove() into
virtio_mem_deinit_hotplug()
virtio-mem: kdump mode to sanitize /proc/vmcore access
arch/x86/kernel/aperture_64.c | 13 +-
arch/x86/xen/mmu_hvm.c | 31 ++--
drivers/virtio/virtio_mem.c | 297 ++++++++++++++++++++++++----------
fs/proc/vmcore.c | 105 ++++++++----
include/linux/crash_dump.h | 26 ++-
5 files changed, 332 insertions(+), 140 deletions(-)
base-commit: 5816b3e6577eaa676ceb00a848f0fd65fe2adc29
--
2.31.1
More information about the kexec
mailing list