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 55207C04FFE for ; Mon, 20 May 2024 16:54:02 +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=uLGEIUXStIGdtj8HCiqOa362ghwhcJyKtHWAcknNuHc=; b=qjUOFLwK/tFkSo HZl1R/jR8AZdkMFT36JLHg/qMFcuJn8Jlt7+HapViMrgmsA18qTuU38GoH1KDGPY9X0vupF3NkUll epv/uumRecQzhHXlzbAfLMsvUSKnFCy0u0SqM/OPZ8sGL2OdRT+FIbFPebZnFBF7r7gLemCUpBbML z7TsPisqy0MHZK5e8phd/nh4on/3myomTA6JIQSfLHt0CxB5P0hOUE6DzQutXlK3FNb6CSeuNxB4S MZyHTw5niS52Z3A8To7XtpkNWmtGodyV8jpCPZpHT/AF1yVHkhzz+ATxsYcJqOexHkIsHKtkK6rog wXr4DR5jpxsikISGb92A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1s96Gj-0000000F3Vx-0Cvk; Mon, 20 May 2024 16:53:49 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1s96Gf-0000000F3Tp-0SyT for linux-arm-kernel@lists.infradead.org; Mon, 20 May 2024 16:53:47 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id F3A53DA7; Mon, 20 May 2024 09:54:04 -0700 (PDT) Received: from arm.com (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 876AC3F641; Mon, 20 May 2024 09:53:31 -0700 (PDT) Date: Mon, 20 May 2024 17:53:25 +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-20240520_095345_723104_95E3A17F X-CRM114-Status: GOOD ( 26.34 ) 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: > > > static int change_page_range(pte_t *ptep, unsigned long addr, void *data) > > > @@ -41,6 +45,7 @@ static int change_page_range(pte_t *ptep, unsigned long addr, void *data) > > > pte = clear_pte_bit(pte, cdata->clear_mask); > > > pte = set_pte_bit(pte, cdata->set_mask); > > > + /* TODO: Break before make for PROT_NS_SHARED updates */ > > > __set_pte(ptep, pte); > > > return 0; > > > > Oh, this TODO is problematic, not sure we can do it safely. There are > > some patches on the list to trap faults from other CPUs if they happen > > to access the page when broken but so far we pushed back as complex and > > at risk of getting the logic wrong. > > > > From an architecture perspective, you are changing the output address > > and D8.16.1 requires a break-before-make sequence (FEAT_BBM doesn't > > help). So we either come up with a way to do BMM safely (stop_machine() > > maybe if it's not too expensive or some way to guarantee no accesses to > > this page while being changed) or we get the architecture clarified on > > the possible side-effects here ("unpredictable" doesn't help). > > Thanks, we need to sort this out. Thanks for the clarification on RIPAS states and behaviour in one of your replies. Thinking about this, since the page is marked as RIPAS_EMPTY prior to changing the PTE, the address is going to fault anyway as SEA if accessed. So actually breaking the PTE, TLBI, setting the new PTE would not add any new behaviour. Of course, this assumes that set_memory_decrypted() is never called on memory being currently accessed (can we guarantee this?). So, we need to make sure that there is no access to the linear map between set_memory_range_shared() and the actual pte update with __change_memory_common() in set_memory_decrypted(). At a quick look, this seems to be the case (ignoring memory scrubbers, though dummy ones just accessing memory are not safe anyway and unlikely to run in a guest). (I did come across the hv_uio_probe() which, if I read correctly, it ends up calling set_memory_decrypted() with a vmalloc() address; let's pretend this code doesn't exist ;)) -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel