All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Ilias Stamatis <ilstam@amazon.com>,
	kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
	oliver.upton@linux.dev, joey.gouly@arm.com,
	suzuki.poulose@arm.com, yuzenghui@huawei.com,
	eric.auger@redhat.com, andre.przywara@arm.com, will@kernel.org,
	jgrall@amazon.co.uk, ugurus@amazon.co.uk,
	nh-open-source@amazon.com
Subject: Re: [RFC] ARM vGIC-ITS tables serialization when running protected VMs
Date: Sun, 27 Apr 2025 17:43:18 +0100	[thread overview]
Message-ID: <86cycxk121.wl-maz@kernel.org> (raw)
In-Reply-To: <6ff7bf8388303c75092d0cc1078d40f018d2bbc4.camel@infradead.org>

On Tue, 22 Apr 2025 11:47:46 +0100,
David Woodhouse <dwmw2@infradead.org> wrote:
> 
> [1  <text/plain; UTF-8 (quoted-printable)>]
> On Tue, 2025-04-15 at 10:44 +0100, David Woodhouse wrote:
> >  
> > 
> > > > Another issue is that it's actually hard for the lowvisor to know where these
> > > > tables live without trusting the EL1 host which virtualizes the ITS. It is
> > > > especially hard knowing the locations of the ITTs (compared to
> > > > Collection/Device tables) because that probably means having to parse the ITS
> > > > command queue from EL2 which is complex and undesirable.
> > > > 
> > > > # An alternative: Serializing ITTs into a userspace buffer
> > > 
> > > NAK.
> > > 
> > > Share the page-aligned memory with the rest of the hypervisor, and use
> > > the existing API.
> > 
> > That seems like a bad choice. All this is just using guest memory to
> > store KVM's state.
> > 
> > Yes, the guest provides a buffer which the virtual hardware *may* use
> > if it wants, but with no IOMMU or access control defined in the
> > specification.
> > 
> > It seems like it would be much cleaner just to let KVM pass its state
> > up to userspace for serialization like we do for all *other* KVM state,
> > which is what Ilias is proposing.
> 
> Ping?
> 
> Redefining the GIC specification to implicitly share whole pages with
> the hypervisor in a protected guest, when they happen to have an ITT
> somewhere inside the page, seems like a very bad idea. Did you have
> some proposed wording for the specification update though, if that's
> the approach you're proposing?

That's already a requirement for CCA when used with GICv3/GICv4.

> And *implementing* it by making the lowvisor snoop on the ITS command
> queue is also awful.

Not only the command queue. *ANY* RD and ITS access. If you don't, it
is rather easy for the host to use the GIC to repaint your privileged
code and confidential guest, one bit at a time.

But that has nothing to do with sharing the ITT memory, which is only
manipulated by the KVM emulation.

	M.

-- 
Without deviation from the norm, progress is not possible.

  reply	other threads:[~2025-04-27 16:43 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-14 11:12 [RFC] ARM vGIC-ITS tables serialization when running protected VMs Ilias Stamatis
2025-04-14 11:12 ` [RFC PATCH 1/1] KVM: arm64: vgic-its: Add flag for saving ITTs in userspace buffer Ilias Stamatis
2025-04-15  8:35 ` [RFC] ARM vGIC-ITS tables serialization when running protected VMs Marc Zyngier
2025-04-15  9:44   ` David Woodhouse
2025-04-22 10:47     ` David Woodhouse
2025-04-27 16:43       ` Marc Zyngier [this message]
2025-06-26  6:22       ` David Woodhouse
2025-04-27 16:37     ` 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=86cycxk121.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=andre.przywara@arm.com \
    --cc=dwmw2@infradead.org \
    --cc=eric.auger@redhat.com \
    --cc=ilstam@amazon.com \
    --cc=jgrall@amazon.co.uk \
    --cc=joey.gouly@arm.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=nh-open-source@amazon.com \
    --cc=oliver.upton@linux.dev \
    --cc=suzuki.poulose@arm.com \
    --cc=ugurus@amazon.co.uk \
    --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.