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
