From: Sean Christopherson <seanjc@google.com>
To: Oliver Upton <oliver.upton@linux.dev>
Cc: Marc Zyngier <maz@kernel.org>,
kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
Joey Gouly <joey.gouly@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>,
stable@vger.kernel.org, Alexander Potapenko <glider@google.com>
Subject: Re: [PATCH] KVM: arm64: Don't eagerly teardown the vgic on init error
Date: Wed, 9 Oct 2024 12:36:32 -0700 [thread overview]
Message-ID: <ZwbbQGpZpGQXaNYK@google.com> (raw)
In-Reply-To: <ZwbYvHJdOqePYjDf@linux.dev>
On Wed, Oct 09, 2024, Oliver Upton wrote:
> On Wed, Oct 09, 2024 at 07:36:03PM +0100, Marc Zyngier wrote:
> > As there is very little ordering in the KVM API, userspace can
> > instanciate a half-baked GIC (missing its memory map, for example)
> > at almost any time.
> >
> > This means that, with the right timing, a thread running vcpu-0
> > can enter the kernel without a GIC configured and get a GIC created
> > behind its back by another thread. Amusingly, it will pick up
> > that GIC and start messing with the data structures without the
> > GIC having been fully initialised.
>
> Huh, I'm definitely missing something. Could you remind me where we open
> up this race between KVM_RUN && kvm_vgic_create()?
>
> I'd thought the fact that the latter takes all the vCPU mutexes and
> checks if any vCPU in the VM has run would be enough to guard against
> such a race, but clearly not...
Any chance that fixing bugs where vCPU0 can be accessed (and run!) before its
fully online help? E.g. if that closes the vCPU0 hole, maybe the vCPU1 case can
be handled a bit more gracefully?
[*] https://lore.kernel.org/all/20241009150455.1057573-1-seanjc@google.com
> > Similarly, a thread running vcpu-1 can enter the kernel, and try
> > to init the GIC that was previously created. Since this GIC isn't
> > properly configured (no memory map), it fails to correctly initialise.
> >
> > And that's the point where we decide to teardown the GIC, freeing all
> > its resources. Behind vcpu-0's back. Things stop pretty abruptly,
> > with a variety of symptoms. Clearly, this isn't good, we should be
> > a bit more careful about this.
> >
> > It is obvious that this guest is not viable, as it is missing some
> > important part of its configuration. So instead of trying to tear
> > bits of it down, let's just mark it as *dead*. It means that any
> > further interaction from userspace will result in -EIO. The memory
> > will be released on the "normal" path, when userspace gives up.
next prev parent reply other threads:[~2024-10-09 19:36 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-09 18:36 [PATCH] KVM: arm64: Don't eagerly teardown the vgic on init error Marc Zyngier
2024-10-09 19:25 ` Oliver Upton
2024-10-09 19:36 ` Sean Christopherson [this message]
2024-10-09 23:27 ` Oliver Upton
2024-10-09 23:30 ` Oliver Upton
2024-10-10 7:54 ` Marc Zyngier
2024-10-10 8:47 ` Oliver Upton
2024-10-10 12:47 ` Marc Zyngier
2024-10-10 16:47 ` Oliver Upton
2024-10-11 13:20 ` Marc Zyngier
2024-10-24 16:12 ` Mark Brown
2024-10-24 18:05 ` Marc Zyngier
2024-10-25 10:54 ` Mark Brown
2024-10-25 12:18 ` Eric Auger
2024-10-25 12:59 ` Mark Brown
2024-10-25 13:05 ` Eric Auger
2024-10-25 13:05 ` Marc Zyngier
2024-10-25 13:43 ` Mark Brown
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=ZwbbQGpZpGQXaNYK@google.com \
--to=seanjc@google.com \
--cc=glider@google.com \
--cc=joey.gouly@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=maz@kernel.org \
--cc=oliver.upton@linux.dev \
--cc=stable@vger.kernel.org \
--cc=suzuki.poulose@arm.com \
--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.