From: sashiko-bot@kernel.org
To: "David Woodhouse" <dwmw2@infradead.org>
Cc: media-ci@linuxtv.org, kvm@vger.kernel.org,
dri-devel@lists.freedesktop.org
Subject: Re: [RFC PATCH 03/11] KVM: SEV: Remove struct page dependency from SNP gmem paths
Date: Thu, 16 Jul 2026 15:30:46 +0000 [thread overview]
Message-ID: <20260716153047.0E18A1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <f069aec751d2c7f18666efbe213bb0a70dc76b67.1784194290.git.dwmw@amazon.co.uk>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] An unprivileged userspace process can trigger a host kernel warning in sev_clflush_pfn(), violating KVM subsystem rules.
--
--- Patch [3]: [RFC PATCH 03/11] KVM: SEV: Remove struct page dependency from SNP gmem paths ---
commit 23550409886d9ce92ccb0c443cb1bc2d231b31b3
Author: Connor Williamson <connordw@amazon.com>
KVM: SEV: Remove struct page dependency from SNP gmem paths
This commit updates KVM SEV-SNP paths to support memory without a struct page
by falling back to memremap() instead of relying on kmap_local_page(). It
relaxes RMP helpers and updates cache flush paths to handle page-less PFNs.
> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> index 4272293478766..2be9e3b80d85e 100644
> --- a/arch/x86/kvm/svm/sev.c
> +++ b/arch/x86/kvm/svm/sev.c
[ ... ]
> @@ -5117,6 +5155,28 @@ int sev_gmem_prepare(struct kvm *kvm, kvm_pfn_t pfn, gfn_t gfn, int max_order)
> return 0;
> }
>
> +/*
> + * Flush the CPU caches for a guest_memfd PFN. A PFN from an external
> + * guest_memfd provider may have no direct map alias, so fall back to a
> + * temporary memremap() mapping for the cache flush.
> + */
> +static void sev_clflush_pfn(kvm_pfn_t pfn, size_t size)
> +{
> + void *va;
> +
> + if (pfn_valid(pfn)) {
> + clflush_cache_range(__va(pfn_to_hpa(pfn)), size);
> + return;
> + }
> +
> + va = memremap(pfn_to_hpa(pfn), size, MEMREMAP_WB);
> + if (WARN_ON_ONCE(!va))
[Severity: High]
Is it safe to use WARN_ON_ONCE(!va) here when memremap() fails?
Since userspace can trigger sev_clflush_pfn() during guest_memfd hole-punching
(via sev_gmem_invalidate()), an unprivileged process might be able to trigger
this warning by inducing memory pressure or vmalloc space exhaustion.
This could result in a host denial of service if panic_on_warn is set.
Should we drop the assertion here to prevent unprivileged userspace from
intentionally triggering host warnings?
> + return;
> +
> + clflush_cache_range(va, size);
> + memunmap(va);
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/f09647f427565c1789a6979470045aab78661563.1784194290.git.dwmw@amazon.co.uk?part=3
next prev parent reply other threads:[~2026-07-16 15:30 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-16 9:31 [RFC PATCH 00/11] KVM: Allow alternative providers of guest_memfd backed by PFNMAP memory David Woodhouse
2026-07-16 9:31 ` [RFC PATCH 01/11] KVM: selftests: sev_smoke_test: Only run VM types the host offers David Woodhouse
2026-07-16 9:31 ` [RFC PATCH 02/11] KVM: selftests: sev_init2_tests: Derive SEV availability from KVM David Woodhouse
2026-07-16 9:31 ` [RFC PATCH 03/11] KVM: SEV: Remove struct page dependency from SNP gmem paths David Woodhouse
2026-07-16 15:30 ` sashiko-bot [this message]
2026-07-16 9:31 ` [RFC PATCH 04/11] KVM: guest_memfd: Introduce guest memory ops and route native gmem through them David Woodhouse
2026-07-16 15:30 ` sashiko-bot
2026-07-16 9:31 ` [RFC PATCH 05/11] iommufd: Look up private-interconnect phys via exporter symbols David Woodhouse
2026-07-16 15:33 ` sashiko-bot
2026-07-16 9:31 ` [RFC PATCH 06/11] iommufd: Plumb dma-buf memory-type (RAM vs MMIO) through the phys map David Woodhouse
2026-07-16 15:41 ` sashiko-bot
2026-07-16 9:31 ` [RFC PATCH 07/11] KVM: guest_memfd: Add ops-driven page revocation David Woodhouse
2026-07-16 15:42 ` sashiko-bot
2026-07-16 9:31 ` [RFC PATCH 08/11] samples/kvm: Add guest_memfd backing sample David Woodhouse
2026-07-16 15:53 ` sashiko-bot
2026-07-16 9:31 ` [RFC PATCH 09/11] selftests/kvm: gmem_provider KVM-only tests David Woodhouse
2026-07-16 15:46 ` sashiko-bot
2026-07-16 9:31 ` [RFC PATCH 10/11] selftests/kvm: gmem_provider iommufd tests David Woodhouse
2026-07-16 15:48 ` sashiko-bot
2026-07-16 9:31 ` [RFC PATCH 11/11] samples/kvm, selftests/kvm: Allow the gmem_provider NVMe DMA test on arm64 David Woodhouse
2026-07-16 15:54 ` sashiko-bot
2026-07-16 15:31 ` [RFC PATCH 01/11] KVM: selftests: sev_smoke_test: Only run VM types the host offers sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260716153047.0E18A1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=dwmw2@infradead.org \
--cc=kvm@vger.kernel.org \
--cc=media-ci@linuxtv.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.