Re: [PATCH v4 06/20] KVM: s390: vsie: Move pin/unpin guest page

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Critical] pin_guest_page() acquires memory using FOLL_GET instead of FOLL_PIN, which is unsafe for hardware-direct memory accesses and exposes the host to the GUP-DMA data corruption bug.
--

--- Patch [6]: [PATCH v4 06/20] KVM: s390: vsie: Move pin/unpin guest page ---
commit 987f41bc833e63c2dc670459a5500894b2f97ace
Author: Christoph Schlameuss <[email protected]>

KVM: s390: vsie: Move pin/unpin guest page

Move {,un}pin_guest_page() up in preparation for the next patch. No change
intended.

> diff --git a/arch/s390/kvm/vsie.c b/arch/s390/kvm/vsie.c
> index 4b67bde0535fc..1b4f6b1691a27 100644
> --- a/arch/s390/kvm/vsie.c
> +++ b/arch/s390/kvm/vsie.c
[ ... ]
> @@ -150,6 +150,32 @@ static int prefix_is_mapped(struct vsie_page *vsie_page)
>  	return !(atomic_read(&vsie_page->scb_s.prog20) & PROG_REQUEST);
>  }
>  
> +/*
> + * Pin the guest page given by gpa and set hpa to the pinned host address.
> + * Will always be pinned writable.
> + *
> + * Returns: - 0 on success
> + *          - -EINVAL if the gpa is not valid guest storage
> + */
> +static int pin_guest_page(struct kvm *kvm, gpa_t gpa, hpa_t *hpa)
> +{
> +	struct page *page;
> +
> +	page = gfn_to_page(kvm, gpa_to_gfn(gpa));

[Severity: Critical]
This isn't a bug introduced by this patch, but is it safe for
pin_guest_page() to acquire memory using gfn_to_page() instead of FOLL_PIN?

Because gfn_to_page() only elevates the page refcount (FOLL_GET),
page_maybe_dma_pinned() evaluates to false. If a guest uses nested
virtualization and its hardware control blocks are backed by a file on the
host, could this expose the host to the GUP-DMA data corruption bug?

When the host filesystem performs writeback, it expects the page to remain
immutable and does not bounce the page. If the SIE hardware acts as an
independent DMA engine bypassing the host MMU, it might continue writing to
the physical memory while the data is in-flight to disk.

Could this cause checksum failures or data corruption in host filesystems
like ext4 or btrfs? Should this be updated to use a FOLL_PIN-enabled helper
(for example, configuring kvm_follow_pfn with .pin = true) to properly lock
the page for hardware access?

> +	if (!page)
> +		return -EINVAL;
> +	*hpa = (hpa_t)page_to_phys(page) + (gpa & ~PAGE_MASK);
> +	return 0;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=6