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 9F6E6C27C55 for ; Mon, 10 Jun 2024 10:34:40 +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=+k7A5E7CjEYqgOVLiWYrgYDeLOAWwu69vrJpRXbfRp4=; b=HVXYvBFJAX7Sge t+yaflCCVVxYxKtRTp3/t6NJR6QE6+7Pg7yMPvot46SsHcMpgMsJOSstLzuDuD7Q+EB1b1PzXTMlH 9EHgZ60gVVt45I9ETe/sSmoGx0Ee+kTfIdWrbx9JLEsX6djWxjHLF07LULqZt0LdDp5r/xt1g/BMO KEGos7Cv4/Ljz6l5jp2VfqI5uwX+ppB0dryOHZdONvPhSO5KAjPJzGiyHOUv3h4cZtk/eu2J0DO+N y5Ddq/08xU7tyyMDjjaiILZR5qBGCXIGtcdLzyZBoS+C8MqYWos1HibVS6i8L39tttzFPA1X4tcuc 90RfsL47PuB4MuH21uzA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sGcM9-00000004frC-1Gtb; Mon, 10 Jun 2024 10:34:30 +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 1sGcM1-00000004foh-073P for linux-arm-kernel@lists.infradead.org; Mon, 10 Jun 2024 10:34:24 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 91990CE1173; Mon, 10 Jun 2024 10:34:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 92C0DC4AF1A; Mon, 10 Jun 2024 10:34:14 +0000 (UTC) Date: Mon, 10 Jun 2024 11:34:12 +0100 From: Catalin Marinas To: Michael Kelley Cc: Steven Price , "kvm@vger.kernel.org" , "kvmarm@lists.linux.dev" , Marc Zyngier , Will Deacon , James Morse , Oliver Upton , Suzuki K Poulose , 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 v3 00/14] arm64: Support for running as a guest in Arm CCA Message-ID: References: <20240605093006.145492-1-steven.price@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240610_033421_462927_B7CB93C8 X-CRM114-Status: GOOD ( 39.23 ) 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 Fri, Jun 07, 2024 at 04:36:18PM +0000, Michael Kelley wrote: > From: Catalin Marinas Sent: Friday, June 7, 2024 8:13 AM > > On Fri, Jun 07, 2024 at 01:38:15AM +0000, Michael Kelley wrote: > > > In the case of a vmalloc() address, load_unaligned_zeropad() could still > > > make an access to the underlying pages through the linear address. In > > > CoCo guests on x86, both the vmalloc PTE and the linear map PTE are > > > flipped, so the load_unaligned_zeropad() problem can occur only during > > > the transition between decrypted and encrypted. But even then, the > > > exception handlers have code to fixup this case and allow everything to > > > proceed normally. > > > > > > I haven't looked at the code in your patches, but do you handle that case, > > > or somehow prevent it? > > > > If we can guarantee that only full a vm_struct area is changed at a > > time, the vmap guard page would prevent this issue (not sure we can > > though). Otherwise I think we either change the set_memory_*() code to > > deal with the other mappings or we handle the exception. > > I don't think the vmap guard pages help. The vmalloc() memory consists > of individual pages that are scattered throughout the direct map. The stray > reference from load_unaligned_zeropad() will originate in a kmalloc'ed > memory page that precedes one of these scattered individual pages, and > will use a direct map kernel vaddr. So the guard page in vmalloc space don't > come into play. At least in the Hyper-V use case, an entire vmalloc allocation > *is* flipped as a unit, so the guard pages do prevent a stray reference from > load_unaligned_zeropad() that originates in vmalloc space. At one > point I looked to see if load_unaligned_zeropad() is ever used on vmalloc > addresses. I think the answer was "no", making the guard page question > moot, but I'm not sure. :-( My point was about load_unaligned_zeropad() originating in the vmalloc space. What I had in mind is changing the underlying linear map via set_memory_*() while we have live vmalloc() mappings. But I forgot about the case you mentioned in a previous thread: set_memory_*() being called on vmalloc()'ed memory directly: https://lore.kernel.org/r/SN6PR02MB41578D7BFEDE33BD2E8246EFD4E92@SN6PR02MB4157.namprd02.prod.outlook.com/ I wonder whether something like __GFP_DECRYPTED could be used to get shared memory from the allocation time and avoid having to change the vmalloc() ranges. This way functions like netvsc_init_buf() would get decrypted memory from the start and vmbus_establish_gpadl() would not need to call set_memory_decrypted() on a vmalloc() address. > Another thought: The use of load_unaligned_zeropad() is conditional on > CONFIG_DCACHE_WORD_ACCESS. There are #ifdef'ed alternate > implementations that don't use load_unaligned_zeropad() if it is not > enabled. I looked at just disabling it in CoCo VMs, but I don't know the > performance impact. I speculated that the benefits were more noticeable > in processors from a decade or more ago, and perhaps less so now, but > never did any measurements. There was also a snag in that x86-only > code has a usage of load_unaligned_zeropad() without an alternate > implementation, so I never went fully down that path. But arm64 would > probably "just work" if it were disabled. We shouldn't penalise the performance, especially as I expect a single image to run both as a guest or a host. However, I think now the linear map is handled correctly since we make the PTE invalid before making the page shared and this would force the fault path through the one that safely handles load_unaligned_zeropad(). Steven's patches also currently reject non-linear-map addresses, I guess this would be a separate addition. > > We also have potential user mappings, do we need to do anything about > > them? > > I'm unclear on the scenario here. Would memory with a user mapping > ever be flipped between decrypted and encrypted while the user mapping > existed? Maybe it doesn't matter. Do we expect it the underlying pages to be flipped while live mappings other than the linear map exist? I assume not, one would first allocate and configure the memory in the kernel before some remap_pfn_range() to user with the appropriate pgprot. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel