From: Marc Zyngier <maz@kernel.org>
To: David Matlack <dmatlack@google.com>
Cc: Oliver Upton <oliver.upton@linux.dev>,
kvm@vger.kernel.org, James Morse <james.morse@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>, Will Deacon <will@kernel.org>,
Marcelo Tosatti <mtosatti@redhat.com>,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
stable@vger.kernel.org, Sean Christopherson <seanjc@google.com>
Subject: Re: [PATCH] KVM: arm64: Retry fault if vma_lookup() results become invalid
Date: Tue, 14 Mar 2023 16:31:38 +0000 [thread overview]
Message-ID: <86fsa7xpjp.wl-maz@kernel.org> (raw)
In-Reply-To: <20230313235454.2964067-1-dmatlack@google.com>
[Dropping Christoffer's 11 year obsolete address...]
On Mon, 13 Mar 2023 23:54:54 +0000,
David Matlack <dmatlack@google.com> wrote:
>
> Read mmu_invalidate_seq before dropping the mmap_lock so that KVM can
> detect if the results of vma_lookup() (e.g. vma_shift) become stale
> before it acquires kvm->mmu_lock. This fixes a theoretical bug where a
> VMA could be changed by userspace after vma_lookup() and before KVM
> reads the mmu_invalidate_seq, causing KVM to install page table entries
> based on a (possibly) no-longer-valid vma_shift.
>
> Re-order the MMU cache top-up to earlier in user_mem_abort() so that it
> is not done after KVM has read mmu_invalidate_seq (i.e. so as to avoid
> inducing spurious fault retries).
>
> This bug has existed since KVM/ARM's inception. It's unlikely that any
> sane userspace currently modifies VMAs in such a way as to trigger this
> race. And even with directed testing I was unable to reproduce it. But a
> sufficiently motivated host userspace might be able to exploit this
> race.
>
> Fixes: 94f8e6418d39 ("KVM: ARM: Handle guest faults in KVM")
Ah, good luck with that one! :D user_mem_abort() used to be so nice
and simple at the time! And yet...
> Cc: stable@vger.kernel.org
> Reported-by: Sean Christopherson <seanjc@google.com>
> Signed-off-by: David Matlack <dmatlack@google.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Oliver, how do you want to deal with this one? queue it right now? Or
wait until the dust settles on my two other patches?
I don't mind either way, I can either take it as part of the same
series, or rebase my stuff on it.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: David Matlack <dmatlack@google.com>
Cc: Oliver Upton <oliver.upton@linux.dev>,
kvm@vger.kernel.org, James Morse <james.morse@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>, Will Deacon <will@kernel.org>,
Marcelo Tosatti <mtosatti@redhat.com>,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
stable@vger.kernel.org, Sean Christopherson <seanjc@google.com>
Subject: Re: [PATCH] KVM: arm64: Retry fault if vma_lookup() results become invalid
Date: Tue, 14 Mar 2023 16:31:38 +0000 [thread overview]
Message-ID: <86fsa7xpjp.wl-maz@kernel.org> (raw)
In-Reply-To: <20230313235454.2964067-1-dmatlack@google.com>
[Dropping Christoffer's 11 year obsolete address...]
On Mon, 13 Mar 2023 23:54:54 +0000,
David Matlack <dmatlack@google.com> wrote:
>
> Read mmu_invalidate_seq before dropping the mmap_lock so that KVM can
> detect if the results of vma_lookup() (e.g. vma_shift) become stale
> before it acquires kvm->mmu_lock. This fixes a theoretical bug where a
> VMA could be changed by userspace after vma_lookup() and before KVM
> reads the mmu_invalidate_seq, causing KVM to install page table entries
> based on a (possibly) no-longer-valid vma_shift.
>
> Re-order the MMU cache top-up to earlier in user_mem_abort() so that it
> is not done after KVM has read mmu_invalidate_seq (i.e. so as to avoid
> inducing spurious fault retries).
>
> This bug has existed since KVM/ARM's inception. It's unlikely that any
> sane userspace currently modifies VMAs in such a way as to trigger this
> race. And even with directed testing I was unable to reproduce it. But a
> sufficiently motivated host userspace might be able to exploit this
> race.
>
> Fixes: 94f8e6418d39 ("KVM: ARM: Handle guest faults in KVM")
Ah, good luck with that one! :D user_mem_abort() used to be so nice
and simple at the time! And yet...
> Cc: stable@vger.kernel.org
> Reported-by: Sean Christopherson <seanjc@google.com>
> Signed-off-by: David Matlack <dmatlack@google.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Oliver, how do you want to deal with this one? queue it right now? Or
wait until the dust settles on my two other patches?
I don't mind either way, I can either take it as part of the same
series, or rebase my stuff on it.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-03-14 16:31 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-13 23:54 [PATCH] KVM: arm64: Retry fault if vma_lookup() results become invalid David Matlack
2023-03-13 23:54 ` David Matlack
2023-03-14 16:31 ` Marc Zyngier [this message]
2023-03-14 16:31 ` Marc Zyngier
2023-03-14 16:46 ` Oliver Upton
2023-03-14 16:46 ` Oliver Upton
2023-03-14 18:10 ` Oliver Upton
2023-03-14 18:10 ` Oliver Upton
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=86fsa7xpjp.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=dmatlack@google.com \
--cc=james.morse@arm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mtosatti@redhat.com \
--cc=oliver.upton@linux.dev \
--cc=seanjc@google.com \
--cc=stable@vger.kernel.org \
--cc=suzuki.poulose@arm.com \
--cc=will@kernel.org \
--cc=yuzenghui@huawei.com \
/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.