Received-SPF: pass (google.com: domain of linux-kernel+bounces-180719-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Thu, 16 May 2024 08:48:34 +0100
From: Catalin Marinas <catalin.marinas@arm.com>
To: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Steven Price <steven.price@arm.com>, kvm@vger.kernel.org,
	kvmarm@lists.linux.dev, Marc Zyngier <maz@kernel.org>,
	Will Deacon <will@kernel.org>, James Morse <james.morse@arm.com>,
	Oliver Upton <oliver.upton@linux.dev>,
	Zenghui Yu <yuzenghui@huawei.com>,
	linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
	Joey Gouly <joey.gouly@arm.com>,
	Alexandru Elisei <alexandru.elisei@arm.com>,
	Christoffer Dall <christoffer.dall@arm.com>,
	Fuad Tabba <tabba@google.com>, linux-coco@lists.linux.dev,
	Ganapatrao Kulkarni <gankulkarni@os.amperecomputing.com>
Subject: Re: [PATCH v2 09/14] arm64: Enable memory encrypt for Realms
Message-ID: <ZkW6UgrwJT6G9UN-@arm.com>
References: <20240412084213.1733764-1-steven.price@arm.com>
 <20240412084213.1733764-10-steven.price@arm.com>
 <ZkOmrMIMFCgEKuVw@arm.com>
 <5b2db977-7f0f-4c3a-b278-f195c7ddbd80@arm.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5b2db977-7f0f-4c3a-b278-f195c7ddbd80@arm.com>

On Wed, May 15, 2024 at 11:47:02AM +0100, Suzuki K Poulose wrote:
> On 14/05/2024 19:00, Catalin Marinas wrote:
> > On Fri, Apr 12, 2024 at 09:42:08AM +0100, Steven Price wrote:
> > Can someone summarise what the point of this protection bit is? The IPA
> > memory is marked as protected/unprotected already via the RSI call and
> > presumably the RMM disables/permits sharing with a non-secure hypervisor
> > accordingly irrespective of which alias the realm guest has the linear
> > mapping mapped to. What does it do with the top bit of the IPA? Is it
> > that the RMM will prevent (via Stage 2) access if the IPA does not match
> > the requested protection? IOW, it unmaps one or the other at Stage 2?
> 
> The Realm's IPA space is split in half. The lower half is "protected"
> and all pages backing the "protected" IPA is in the Realm world and
> thus cannot be shared with the hypervisor. The upper half IPA is
> "unprotected" (backed by Non-secure PAS pages) and can be accessed
> by the Host/hyp.

What about emulated device I/O where there's no backing RAM at an IPA.
Does it need to have the top bit set?

> The RSI call (RSI_IPA_STATE_SET) doesn't make an IPA unprotected. It
> simply "invalidates" a (protected) IPA to "EMPTY" implying the Realm doesn't
> intend to use the "ipa" as RAM anymore and any access to it from
> the Realm would trigger an SEA into the Realm. The RSI call triggers an exit
> to the host with the information and is a hint to the hypervisor to reclaim
> the page backing the IPA.
> 
> Now, given we need dynamic "sharing" of pages (instead of a dedicated
> set of shared pages), "aliasing" of an IPA gives us shared pages.
> i.e., If OS wants to share a page "x" (protected IPA) with the host,
> we mark that as EMPTY via RSI call and then access the "x" with top-bit
> set (aliasing the IPA x). This fault allows the hyp to map the page backing
> IPA "x" as "unprotected" at ALIAS(x) address.

Does the RMM sanity-checks that the NS hyp mappings are protected or
unprotected depending on the IPA range?

I assume that's also the case if the NS hyp is the first one to access a
page before the realm (e.g. inbound virtio transfer; no page allocated
yet because of a realm access).

-- 
Catalin