All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Paolo Bonzini" <pbonzini@redhat.com>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH v2 22/28] KVM: x86/mmu: Issue memory fault exit if walk failed due to memory attribute
Date: Fri, 18 Sep 2026 08:37:28 +0000	[thread overview]
Message-ID: <20260918083728.931541F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260918081543.139871-23-pbonzini@redhat.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] kvm: KVM_EXIT_MEMORY_FAULT reports original access type instead of PTE read
- [High] kvm: memory attribute violations during emulation inject spurious #PF
--

commit f13a0662fba26c69b7ab24d7639e44c8da7ee24c
Author: Nicolas Saenz Julienne <nsaenz@amazon.com>

KVM: x86/mmu: Issue memory fault exit if walk failed due to memory attribute

This patch adds a check during guest page table walks to identify if a walk
fails due to a memory attribute restriction. When this occurs, it populates
the newly added memory_attributes_fault flag and attempts to exit to userspace
with a memory fault.

> diff --git a/arch/x86/kvm/mmu/paging_tmpl.h b/arch/x86/kvm/mmu/paging_tmpl.h
> index b031123fcb369..d2836a327bc99 100644
> --- a/arch/x86/kvm/mmu/paging_tmpl.h
> +++ b/arch/x86/kvm/mmu/paging_tmpl.h
[ ... ]
> @@ -411,6 +413,12 @@ static int FNAME(walk_addr_generic)(struct guest_walker *walker,
>  		if (unlikely(kvm_is_error_hva(host_addr)))
>  			goto error;
>  
> +		if (!kvm_mem_attributes_may_read_gfn(vcpu->kvm, gpa_to_gfn(real_gpa))) {
> +			walker->memory_attributes_fault = true;
> +			walker->gfn = gpa_to_gfn(real_gpa);
> +			goto error;
> +		}
> +

[Severity: High]
When this flag is set and FNAME(walk_addr_generic)() returns an error, how is
it handled by other callers that aren't updated in this patch?

For example, in arch/x86/kvm/mmu/paging_tmpl.h within FNAME(gva_to_gpa)():

static gpa_t FNAME(gva_to_gpa)(struct kvm_vcpu *vcpu, struct kvm_pagewalk *w,
			       gpa_t addr, u64 access,
			       struct x86_exception *exception)
{
	struct guest_walker walker;
	gpa_t gpa = INVALID_GPA;
	int r;

	r = FNAME(walk_addr_generic)(&walker, vcpu, w, addr, access);

	if (r) {
		gpa = gfn_to_gpa(walker.gfn);
		gpa |= addr & ~PAGE_MASK;
	} else if (exception)
		*exception = walker.fault;

If instruction emulation encounters a memory attribute violation here during a
page table walk, does this drop the walker.memory_attributes_fault flag and
blindly return the fabricated #PF exception?

Could this inject a spurious #PF into the guest instead of exiting to userspace
with KVM_EXIT_MEMORY_FAULT?

[ ... ]
> @@ -820,6 +828,12 @@ static int FNAME(page_fault)(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault
>  	 * The page is not mapped by the guest.  Let the guest handle it.
>  	 */
>  	if (!r) {
> +		if (walker.memory_attributes_fault) {
> +			fault->gfn = walker.gfn;
> +			kvm_mmu_prepare_memory_fault_exit(vcpu, fault);
> +			return -EFAULT;
> +		}
> +

[Severity: High]
In arch/x86/kvm/mmu/paging_tmpl.h within FNAME(page_fault)(), if
walker.memory_attributes_fault is true, we prepare a memory fault exit.

However, does kvm_mmu_prepare_memory_fault_exit() use the original fault's
properties (fault->write, fault->exec) instead of the properties of the page
table read itself?

Could this incorrectly report the access flags to userspace (e.g., reporting
WRITE or EXEC instead of READ) when a page table walk fails due to KVM memory
attributes?

>  		if (!fault->prefetch)
>  			__kvm_inject_emulated_page_fault(vcpu, &walker.fault, true);
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260918081543.139871-1-pbonzini@redhat.com?part=22

  reply	other threads:[~2026-09-18  8:37 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-18  8:15 [PATCH v2 00/28] KVM: x86: Introduce memory protection attributes Paolo Bonzini
2026-09-18  8:15 ` [PATCH v2 01/28] KVM: selftests: Take into account mixed memory fault flags Paolo Bonzini
2026-09-18  8:15 ` [PATCH v2 02/28] KVM: Define and communicate KVM_EXIT_MEMORY_FAULT RWX flags to userspace Paolo Bonzini
2026-09-18  8:27   ` sashiko-bot
2026-09-18  8:15 ` [PATCH v2 03/28] KVM: selftests: Test address translation for Hyper-V direct L2 hypercalls Paolo Bonzini
2026-09-18  8:30   ` sashiko-bot
2026-09-18  8:15 ` [PATCH v2 04/28] KVM: apply nGPA->GPA translation to KVM_HC_CLOCK_PAIRING Paolo Bonzini
2026-09-18  8:34   ` sashiko-bot
2026-09-18  8:15 ` [PATCH v2 05/28] KVM: x86: Introduce memory fault on invalid hypercalls reads/writes Paolo Bonzini
2026-09-18  8:33   ` sashiko-bot
2026-09-18  8:15 ` [PATCH v2 06/28] KVM: selftests: test hypercall memory fault exits Paolo Bonzini
2026-09-18  8:24   ` sashiko-bot
2026-09-18  8:15 ` [PATCH v2 07/28] KVM: x86/mmu: intersect writability from __kvm_faultin_pfn with fault->map_writable Paolo Bonzini
2026-09-18  8:15 ` [PATCH v2 08/28] KVM: x86/mmu: Extend map_writable to a full ACC_* mask Paolo Bonzini
2026-09-18  8:15 ` [PATCH v2 09/28] KVM: x86/mmu: Init memslot hugepage information for non-private_mem VMs too Paolo Bonzini
2026-09-18  8:15 ` [PATCH v2 10/28] KVM: pass kvm == NULL case to kvm_arch_has_private_mem Paolo Bonzini
2026-09-18  8:15 ` [PATCH v2 11/28] KVM: adjust for presence of more than one attribute Paolo Bonzini
2026-09-18  8:15 ` [PATCH v2 12/28] KVM: Introduce NR/NW/NX memory attributes Paolo Bonzini
2026-09-18  8:36   ` sashiko-bot
2026-09-18  8:15 ` [PATCH v2 13/28] KVM: Include memory protections in result of gfn->hva conversion Paolo Bonzini
2026-09-18  8:15 ` [PATCH v2 14/28] KVM: Introduce kvm_fetch_guest_page() and use it for x86 Paolo Bonzini
2026-09-18  8:15 ` [PATCH v2 15/28] KVM: Take memory protections into account for memory read/write/fetch Paolo Bonzini
2026-09-18  8:34   ` sashiko-bot
2026-09-18  8:15 ` [PATCH v2 16/28] KVM: Encapsulate memattrs array into anonymous struct Paolo Bonzini
2026-09-18  8:15 ` [PATCH v2 17/28] KVM: Introduce kvm_check_gen()/kvm_memslots_check_gen() Paolo Bonzini
2026-09-18  8:15 ` [PATCH v2 18/28] KVM: Introduce a generation number for memory attributes Paolo Bonzini
2026-09-18  8:39   ` sashiko-bot
2026-09-18  8:15 ` [PATCH v2 19/28] KVM: Take memory protections into account for accesses with cached gfn->hva Paolo Bonzini
2026-09-18  8:38   ` sashiko-bot
2026-09-18  8:15 ` [PATCH v2 20/28] KVM: pfncache: Fail to refresh if it contains memory protections Paolo Bonzini
2026-09-18  8:15 ` [PATCH v2 21/28] KVM: x86/mmu: Take memory protection attributes into account during faults Paolo Bonzini
2026-09-18  8:46   ` sashiko-bot
2026-09-18  8:15 ` [PATCH v2 22/28] KVM: x86/mmu: Issue memory fault exit if walk failed due to memory attribute Paolo Bonzini
2026-09-18  8:37   ` sashiko-bot [this message]
2026-09-18  8:15 ` [PATCH v2 23/28] KVM: x86/mmu: Do not update accessed/dirty if guest PTE is read-only Paolo Bonzini
2026-09-18  8:15 ` [PATCH v2 24/28] KVM: x86/mmu: Do not prefetch sptes on gfns backed by memory attributes Paolo Bonzini
2026-09-18  8:36   ` sashiko-bot
2026-09-18  8:15 ` [PATCH v2 25/28] KVM: x86/mmu: Obsolete all roots if memattr contains gPTEs Paolo Bonzini
2026-09-18  8:43   ` sashiko-bot
2026-09-18  8:15 ` [PATCH v2 26/28] KVM: x86: selftests: Introduce memory protection attributes test Paolo Bonzini
2026-09-18  8:39   ` sashiko-bot
2026-09-18  8:15 ` [PATCH v2 27/28] KVM: x86: selftests: Introduce memory attributes PTE test Paolo Bonzini
2026-09-18  8:15 ` [PATCH v2 28/28] KVM: x86: selftests: Introduce memory attributes side-channel tests Paolo Bonzini
2026-09-18  8:43   ` 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=20260918083728.931541F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --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.