From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 0DB5AC25B74 for ; Thu, 16 May 2024 07:49:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ynqw7vT/+MW/oKtDIB9NNiqq1WmcBAmBN94Gri+fnbk=; b=x2VYERMv3SfbNA 4WRCrXhz2BcrNSMiiONDqFkhTxeVOw0BCV+2Fo7tqY5KW3xkAyudiQj+hidIBJlqhw23h7fRfSOY+ dUKW8qVI0ncZEZSE1V+Y2ceEox8WlHhchdHfzr47lh67vjGHe/advw6qH/O7/hLNLoKFuyD35abht jJ7dO9ml1xiunLfn/d6fOqPMmcHR/PG+t1y+Ijsd8vnc1D136ftkaXywNkEWL6v5urufYwLZw/drG egFekZ2UJie5PHhTQ/IrB2o6eRo0QhyI3Z8JRJLU1MMoz0IaRvwL1/4cOG5nESSrQBYfkVh4K50Hd hguRO3P1d++8oZ6X04Rg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1s7Vr5-000000042EO-26gM; Thu, 16 May 2024 07:48:47 +0000 Received: from sin.source.kernel.org ([145.40.73.55]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1s7Vr3-000000042Dg-0DWD for linux-arm-kernel@lists.infradead.org; Thu, 16 May 2024 07:48:46 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id EECE0CE1371; Thu, 16 May 2024 07:48:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6F562C113CC; Thu, 16 May 2024 07:48:36 +0000 (UTC) Date: Thu, 16 May 2024 08:48:34 +0100 From: Catalin Marinas To: Suzuki K Poulose Cc: Steven Price , kvm@vger.kernel.org, kvmarm@lists.linux.dev, Marc Zyngier , Will Deacon , James Morse , Oliver Upton , Zenghui Yu , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Joey Gouly , Alexandru Elisei , Christoffer Dall , Fuad Tabba , linux-coco@lists.linux.dev, Ganapatrao Kulkarni Subject: Re: [PATCH v2 09/14] arm64: Enable memory encrypt for Realms Message-ID: References: <20240412084213.1733764-1-steven.price@arm.com> <20240412084213.1733764-10-steven.price@arm.com> <5b2db977-7f0f-4c3a-b278-f195c7ddbd80@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <5b2db977-7f0f-4c3a-b278-f195c7ddbd80@arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240516_004845_307197_1D0C9FBA X-CRM114-Status: GOOD ( 22.82 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel