Message-ID: <d9d35115-0fb5-4e8e-a99c-ff85ba4a7967@arm.com>
Date: Thu, 16 May 2024 10:06:39 +0100
From: Suzuki K Poulose <suzuki.poulose@....com>
To: Catalin Marinas <catalin.marinas@....com>
Cc: Steven Price <steven.price@....com>, kvm@...r.kernel.org,
 kvmarm@...ts.linux.dev, Marc Zyngier <maz@...nel.org>,
 Will Deacon <will@...nel.org>, James Morse <james.morse@....com>,
 Oliver Upton <oliver.upton@...ux.dev>, Zenghui Yu <yuzenghui@...wei.com>,
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
 Joey Gouly <joey.gouly@....com>, Alexandru Elisei
 <alexandru.elisei@....com>, Christoffer Dall <christoffer.dall@....com>,
 Fuad Tabba <tabba@...gle.com>, linux-coco@...ts.linux.dev,
 Ganapatrao Kulkarni <gankulkarni@...amperecomputing.com>
Subject: Re: [PATCH v2 09/14] arm64: Enable memory encrypt for Realms

Hi Catalin

On 16/05/2024 08:48, Catalin Marinas wrote:
> 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 behaviour depends on the IPA (i.e, protected vs unprotected).

1. Unprotected : All stage2 faults in the Unprotected half are serviced
by the Host, including the areas that may be "Memory" backed. RMM 
doesn't provide any guarantees on accesses to the unprotected half. 
i.e., host could even inject a Synchronous External abort, if an MMIO
region is not understood by it.

2. Protected : The behaviour depends on the "IPA State" (only applicable 
for the protected IPAs). The possible states are RIPAS_RAM,  RIPAS_EMPTY 
and RIPAS_DESTROYED(not visible for the Realm).

The default IPA state is RIPAS_EMPTY for all IPA and the state is 
controlled by Realm with the help of RMM (serviced by Host), except
during the Realm initialisation. i.e., the Host is allowed to "mark"
some IPAs as RIPAS_RAM (for e.g., initial images loaded into the Realm)
during Realm initiliasation (via RMI_RTT_INIT_RIPAS), which gets
measured by the RMM (and affects the Realm Initial Measurement). After
the Realm is activated, the Host can only perform the changes requested
by the Realm (RMM monitors this). Hence, the Realm at boot up, marks all
of its "Described RAM" areas as RIPAS_RAM (via RSI_IPA_STATE_SET), so
that it can go ahead and acccess the RAM as normal.


a) RIPAS_EMPTY: Any access to an IPA in RIPAS_EMPTY generates a 
Synchronous External Abort back to the Realm. (In the future, this may
be serviced by another entity in the Realm).

b) RIPAS_RAM: A stage2 fault at a mapped entry triggers a Realm Exit to 
the Host (except Instruction Aborts) and the host is allowed to map a
page (that is "scrubbed" by RMM) at stage2 and continue the execution.

[ ---->8  You may skip this ---
  c) RIPAS_DESTROYED: An IPA is turned to RIPAS_DESTROYED, if the host
     "unmaps" a protected IPA in RIPAS_RAM (via RMI_DATA_DESTROY). This
     implies that the Realm contents were destroyed with no way of
     restoring back. Any access to such IPA from the Realm also causes
     a Realm EXIT, however, the Host is not allowed to map anything back
     there and thus the vCPU cannot proceed with the execution.
----<8----
]

> 
>> 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?

RMM moderates the mappings in the protected half (as mentioned above).
Any mapping in the unprotected half is not monitored. The host is
allowed unmap, remap with anything in the unprotected half.

> 
> 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).
> 

Correct. The host need not map anything upfront in the Unprotected half
as it is allowed to map a page "with contents" at any time. A stage2 
fault can be serviced by the host to load a page with contents.

Suzuki

Powered by blists - more mailing lists