All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Naresh Kamboju <naresh.kamboju@linaro.org>
Cc: linux- stable <stable@vger.kernel.org>,
	Marc Zyngier <maz@kernel.org>, Will Deacon <will@kernel.org>,
	kernel-team@android.com, lkft-triage@lists.linaro.org
Subject: Re: [PATCH stable-5.8] KVM: arm64: Assume write fault on S1PTW permission fault on instruction fetch
Date: Tue, 29 Sep 2020 09:01:18 +0200	[thread overview]
Message-ID: <20200929070118.GE2439787@kroah.com> (raw)
In-Reply-To: <CA+G9fYs5DpC7fq6Ukqs6iS4wEOz2+g5zwgup3B5JPnE52_fvYA@mail.gmail.com>

On Tue, Sep 29, 2020 at 01:16:34AM +0530, Naresh Kamboju wrote:
> On Mon, 28 Sep 2020 at 23:16, Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Mon, Sep 28, 2020 at 06:18:50PM +0100, Marc Zyngier wrote:
> > > Commit c4ad98e4b72cb5be30ea282fce935248f2300e62 upstream.
> > >
> > > KVM currently assumes that an instruction abort can never be a write.
> > > This is in general true, except when the abort is triggered by
> > > a S1PTW on instruction fetch that tries to update the S1 page tables
> > > (to set AF, for example).
> > >
> > > This can happen if the page tables have been paged out and brought
> > > back in without seeing a direct write to them (they are thus marked
> > > read only), and the fault handling code will make the PT executable(!)
> > > instead of writable. The guest gets stuck forever.
> > >
> > > In these conditions, the permission fault must be considered as
> > > a write so that the Stage-1 update can take place. This is essentially
> > > the I-side equivalent of the problem fixed by 60e21a0ef54c ("arm64: KVM:
> > > Take S1 walks into account when determining S2 write faults").
> > >
> > > Update kvm_is_write_fault() to return true on IABT+S1PTW, and introduce
> > > kvm_vcpu_trap_is_exec_fault() that only return true when no faulting
> > > on a S1 fault. Additionally, kvm_vcpu_dabt_iss1tw() is renamed to
> > > kvm_vcpu_abt_iss1tw(), as the above makes it plain that it isn't
> > > specific to data abort.
> > >
> > > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > > Reviewed-by: Will Deacon <will@kernel.org>
> > > Cc: stable@vger.kernel.org
> > > Link: https://lore.kernel.org/r/20200915104218.1284701-2-maz@kernel.org
> >
> > Thanks for all 3 of these, now queued up!
> 
> stable rc branch 4.19 arm64 build broken.
> 
> ../arch/arm64/kvm/../../../virt/kvm/arm/mmu.c:1283:13: error:
> redefinition of ‘kvm_is_write_fault’
>  1283 | static bool kvm_is_write_fault(struct kvm_vcpu *vcpu)
>       |             ^~~~~~~~~~~~~~~~~~
> 
> Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>

Thanks, I'll go drop this patch from the 4.19.y queue and wait for a
fixed up version from Marc.

greg k-h

  reply	other threads:[~2020-09-29  7:01 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-28 17:18 [PATCH stable-5.8] KVM: arm64: Assume write fault on S1PTW permission fault on instruction fetch Marc Zyngier
2020-09-28 17:46 ` Greg KH
2020-09-28 19:46   ` Naresh Kamboju
2020-09-29  7:01     ` Greg KH [this message]
2020-09-29  7:36       ` Marc Zyngier

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=20200929070118.GE2439787@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=kernel-team@android.com \
    --cc=lkft-triage@lists.linaro.org \
    --cc=maz@kernel.org \
    --cc=naresh.kamboju@linaro.org \
    --cc=stable@vger.kernel.org \
    --cc=will@kernel.org \
    /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.