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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0FC48C3DA6E for ; Mon, 8 Jan 2024 19:24:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8E8586B0075; Mon, 8 Jan 2024 14:24:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 898606B007D; Mon, 8 Jan 2024 14:24:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 760576B0080; Mon, 8 Jan 2024 14:24:16 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 67AAA6B0075 for ; Mon, 8 Jan 2024 14:24:16 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 34C33160142 for ; Mon, 8 Jan 2024 19:24:16 +0000 (UTC) X-FDA: 81657119712.20.4B38F56 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by imf06.hostedemail.com (Postfix) with ESMTP id B5C0118001B for ; Mon, 8 Jan 2024 19:24:12 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="CB6d7ds/"; spf=none (imf06.hostedemail.com: domain of sathyanarayanan.kuppuswamy@linux.intel.com has no SPF policy when checking 134.134.136.65) smtp.mailfrom=sathyanarayanan.kuppuswamy@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1704741853; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=gydu7kvnbrUrxtgpcPZDq5EZAqWbuVifEuFYNGt70zA=; b=V5q1qqd79WMrSxo47k+Ai1vpNViHavYSlt4UW4YkJnrsptUND9dsW5RgI/2zWf8EEO0Auj /xrOdT9ee5YQRXgtE+1mZbP4WIunIYudaL4Lsl6c5FwbB+Fk2IS7THgSvmuusOePIlKP3I mOkOB3tE3d8p8DJfLswv50xVoIeTFpY= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="CB6d7ds/"; spf=none (imf06.hostedemail.com: domain of sathyanarayanan.kuppuswamy@linux.intel.com has no SPF policy when checking 134.134.136.65) smtp.mailfrom=sathyanarayanan.kuppuswamy@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1704741853; a=rsa-sha256; cv=none; b=OdvY7uzDfyHiWmChcCTCE8WcybqXgRc4MVSnwq+zTkm7evzA+xpv1vJPx8PCX+pPjwE1oR tnNl1FXrMa80epOgRV/OuirghPflVy/0hU/LQGHQCuShzo69wMt+rOHcPSnBRu+zehwQV8 FpRAD5eOjIZYeLUVRoZHwBdFWhIbUnY= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1704741852; x=1736277852; h=message-id:date:mime-version:subject:to:references:from: in-reply-to:content-transfer-encoding; bh=cJOrLgxgkebHcXJBcayOfWJpxDUa4IaN64xEo8IWidU=; b=CB6d7ds/aZi4bMaIG04UXLEVKjgw3hMKcVDOK6Ua65XUQ34VHBji97wG b2ebXGrCyRp/sRWJ2Mbfeib6zBcYp5cn50HWisJzFQz7b7uc9mVYHnX0e o/7ZSOb1MIl/zTtr2x7EAQB0b4uzYHD8CGwEO3yvMxHZbAS0kbJnF7Tts mBpQ4yOQaN25v96fVsgMF0rdhar7Kg1byWexZDHJZP+5omoFk6u6z6TTX RvBdnZLr5deVTxfDeiSGiwx8lLgAN9la34OY2GnGgPF3u/iLMsfHhQ7vO EitXQv/R0icVD5nkYz4TzzCd/OG5Lt8Curlmlc83m+M1TfK+sxUzcW8ka A==; X-IronPort-AV: E=McAfee;i="6600,9927,10947"; a="401777921" X-IronPort-AV: E=Sophos;i="6.04,180,1695711600"; d="scan'208";a="401777921" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jan 2024 11:24:10 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.04,180,1695711600"; d="scan'208";a="23282048" Received: from nsingiri-mobl2.amr.corp.intel.com (HELO [10.212.166.188]) ([10.212.166.188]) by orviesa002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jan 2024 11:24:10 -0800 Message-ID: <9f0c0b3d-6021-466d-8ee0-375f66c5006a@linux.intel.com> Date: Mon, 8 Jan 2024 11:24:06 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 3/3] x86/hyperv: Make encrypted/decrypted changes safe for load_unaligned_zeropad() Content-Language: en-US To: Michael Kelley , "tglx@linutronix.de" , "mingo@redhat.com" , "bp@alien8.de" , "dave.hansen@linux.intel.com" , "x86@kernel.org" , "hpa@zytor.com" , "kirill.shutemov@linux.intel.com" , "haiyangz@microsoft.com" , "wei.liu@kernel.org" , "decui@microsoft.com" , "luto@kernel.org" , "peterz@infradead.org" , "akpm@linux-foundation.org" , "urezki@gmail.com" , "hch@infradead.org" , "lstoakes@gmail.com" , "thomas.lendacky@amd.com" , "ardb@kernel.org" , "jroedel@suse.de" , "seanjc@google.com" , "rick.p.edgecombe@intel.com" , "linux-kernel@vger.kernel.org" , "linux-coco@lists.linux.dev" , "linux-hyperv@vger.kernel.org" , "linux-mm@kvack.org" References: <20240105183025.225972-1-mhklinux@outlook.com> <20240105183025.225972-4-mhklinux@outlook.com> From: Kuppuswamy Sathyanarayanan In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: B5C0118001B X-Rspam-User: X-Stat-Signature: qydmbihgappw8q9384guini9whke498a X-Rspamd-Server: rspam01 X-HE-Tag: 1704741852-937974 X-HE-Meta: U2FsdGVkX1+yhcfYQlQCh+OgMOCuw8PzPZOZb9g4FsNKSv23k07c22JRX+/oGkB8my8vXpucldPdbZU76yjc3hbICMg6qCw28ag0LOG+/Ro6VXDJcp8bIdKZvKlbPc70QX9km0+3eJ74xrjSBP6cJkwKm/EwmetAqh7fvdYHTj3LCPfvnVwXarwA23WqMKzuI1gHh0pSxb4smNT3TE7keBX26U87ZhYedjscOOtLSOzisyp3InC+RH4J4hg9Wn717oEvOWb03iS9aviR2mS7poGB60ehXzZxMCAfcQOzu5jx0isiGNo5XpILP1pWglLxVuT3ITfqL9cUAPsYf/st8SWYAYdSPq1CCvrGRQBRJzm6onWj6kFsA7VBSacaPCsn/HQTEtcU4+GzUa9FwjbdS40bn7Jg7hF9BI9xK+qZCJf2IIUuyJu6xP3X4/K4XkUSyaR5wx5xpUyznnykdO7CfiKk1HSeWXdOPq3yjnxqnoU2GokUgMUL/MKAu1KqVzfuvnM12oK9q2Dnr2jivViS6UIJBTtXwrT7wdqGsqo8LWEl4AJJidyrMiC81gfeICHxiXdZ1lJCXjv2KNPHGES1siesB+3W6kLYEEBUI7wWZJ+8EnDRflk19HCKtd9z1/edoBpVA2jmApxjPWSZ1vwJf2Cc1L1ynK20ul+Yj/33CYC5xFxzzPersEyXW8cLtPjwNOPC89iT5OTdNionsSybIGMdqXXQeeNnqBIrTdz7GRDOUxbhSHuQB2IGturFx3xMxEn234eUe22ZirNvjPW7tubJ2xfqD0+yecR9bg1OO83F1pIeOrE0oFJSpGxXF0U/yB5q61aFdB0iC3zx0l+6bhIj5wMDeO5HlddLvFefxOQ82SErbumYkWAGjtc+ITY78f4AJH0+QuKRxYkxncrJ9b85H1H0SLM6ZGEL+kmC6f95sgqL3YxL7P8rH+lcEN1aSAYt5IYcvWqxq3ShrXp Sqrmbmqx M/4lKiX4SWXaj8fmmwt9KiON4fkxQCxEqHpVY08OczRC/31qbHrZ1WWxq3RoGsDuzyXNs1HFCShaE+UP5nxu+0rztCpkdDk0L583Qz0uaYgXXbBcI4TQSeANdQ9c+HVse6SZF5YUgcm8pE7kscsViB1cncfXPURxps9ZJZcKnhleDWBnuZberxn6leQDYPLjmCGzoE69HtrXuS2x/FTXR7ou56+ttyX4tbsUEi6Wuu3V3qNBje8OsZgD8OcQovzShL/h3TYPz15UV2UCpQGYY98egHucIeOovb+0D1ZjctlI3wIep12QkxAtpBlWzgE9kD5v5QnJvDBWO8SY= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 1/8/2024 11:13 AM, Michael Kelley wrote: > From: Kuppuswamy Sathyanarayanan > Sent: Monday, January 8, 2024 10:37 AM >> >> On 1/5/2024 10:30 AM, mhkelley58@gmail.com wrote: >>> From: Michael Kelley >>> >>> In a CoCo VM, when transitioning memory from encrypted to decrypted, or >>> vice versa, the caller of set_memory_encrypted() or set_memory_decrypted() >>> is responsible for ensuring the memory isn't in use and isn't referenced >>> while the transition is in progress. The transition has multiple steps, >>> and the memory is in an inconsistent state until all steps are complete. >>> A reference while the state is inconsistent could result in an exception >>> that can't be cleanly fixed up. >>> >>> However, the kernel load_unaligned_zeropad() mechanism could cause a stray >>> reference that can't be prevented by the caller of set_memory_encrypted() >>> or set_memory_decrypted(), so there's specific code to handle this case. >>> But a CoCo VM running on Hyper-V may be configured to run with a paravisor, >>> with the #VC or #VE exception routed to the paravisor. There's no >>> architectural way to forward the exceptions back to the guest kernel, and >>> in such a case, the load_unaligned_zeropad() specific code doesn't work. >>> >>> To avoid this problem, mark pages as "not present" while a transition >>> is in progress. If load_unaligned_zeropad() causes a stray reference, a >>> normal page fault is generated instead of #VC or #VE, and the >>> page-fault-based fixup handlers for load_unaligned_zeropad() resolve the >>> reference. When the encrypted/decrypted transition is complete, mark the >>> pages as "present" again. >> >> Change looks good to me. But I am wondering why are adding it part of >> prepare and finish callbacks instead of directly in set_memory_encrypted() function. >> > > The prepare/finish callbacks are different for TDX, SEV-SNP, and > Hyper-V CoCo guests running with a paravisor -- so there are three sets > of callbacks. As described in the cover letter, I've given up on using this > scheme for the TDX and SEV-SNP cases, because of the difficulty with > the SEV-SNP callbacks needing a valid virtual address (whereas TDX and > Hyper-V paravisor need only a physical address). So it seems like the > callbacks specific to the Hyper-V paravisor are the natural place for the > code. That leaves the TDX and SEV-SNP code paths unchanged, which > was my intent. > Got it. Thanks for clarifying it. > Or maybe I'm not understanding your comment? If that's the case, > please elaborate. > > Michael > >> Reviewed-by: Kuppuswamy Sathyanarayanan >> >> -- Sathyanarayanan Kuppuswamy Linux Kernel Developer