Re: [PATCH v2 09/14] arm64: Enable memory encrypt for Realms
From: Catalin Marinas <catalin.marinas@arm.com>
Date: 2024-05-16 07:48:39
Also in:
kvm, kvmarm, linux-coco, lkml
On Wed, May 15, 2024 at 11:47:02AM +0100, Suzuki K Poulose wrote:
On 14/05/2024 19:00, Catalin Marinas wrote:quoted
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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel