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 B11A7C61DF4 for ; Fri, 24 Nov 2023 14:21:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1F0CF6B06EF; Fri, 24 Nov 2023 09:21:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 17B796B06F0; Fri, 24 Nov 2023 09:21:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 01A926B06F2; Fri, 24 Nov 2023 09:21:32 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id E41E86B06EF for ; Fri, 24 Nov 2023 09:21:32 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id B0955B68A0 for ; Fri, 24 Nov 2023 14:21:32 +0000 (UTC) X-FDA: 81493060824.19.912A16D Received: from mail.alien8.de (mail.alien8.de [65.109.113.108]) by imf16.hostedemail.com (Postfix) with ESMTP id 861FD180029 for ; Fri, 24 Nov 2023 14:21:29 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=alien8.de header.s=alien8 header.b="Ctooe/e9"; spf=pass (imf16.hostedemail.com: domain of bp@alien8.de designates 65.109.113.108 as permitted sender) smtp.mailfrom=bp@alien8.de; dmarc=pass (policy=none) header.from=alien8.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1700835690; a=rsa-sha256; cv=none; b=GEd54Qo6JGffXj2OdrZXWzTxB4NoRHvLpRw61WGmOlkDXlt8+SUfIWZ7ERfZN7LfiL9bz5 Hi6BTON9AMe2iq90hFWzOKcWXu1TXTTzs5VhSKal0hA/SiVBCI7OvVKf8NNvg5MxgdfB5c OHQ/mE2Tq4jdVaAUC0MwOokhcpLd98Q= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=alien8.de header.s=alien8 header.b="Ctooe/e9"; spf=pass (imf16.hostedemail.com: domain of bp@alien8.de designates 65.109.113.108 as permitted sender) smtp.mailfrom=bp@alien8.de; dmarc=pass (policy=none) header.from=alien8.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1700835690; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=70iKoPUGxr70BVQmnLb6A91Gn+tCho1RWbxI7o21LXI=; b=dpZJykLSm0GOK8Situ1rl6Xc9q72G3tK7QJ4FKXfFphQBAGdfHWigTmMdkKF7utjy7DDPS 25o60x0PPhUL4UPTD8SBwkIhzjTXZVrWHghk94zYhzLDkB8HrzNg0dtwa/1pgybvEKq1wH mEfsyDYdwFVDIHFdSKz3QGmDSmo80Nw= Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id EDE9D40E014B; Fri, 24 Nov 2023 14:21:26 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mail.alien8.de Received: from mail.alien8.de ([127.0.0.1]) by localhost (mail.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id YSeBXnDxtyE4; Fri, 24 Nov 2023 14:21:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1700835684; bh=70iKoPUGxr70BVQmnLb6A91Gn+tCho1RWbxI7o21LXI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Ctooe/e9xdy7g9A5Dt3Co0Eih6gkBFObocpqY9kf+AVVX2JHHnrhGw956oEpX2JSl pWLZ+ahyE8qbumSobifYHrDWkNgjqRE2iukzLYGxMCdUQe23vykj1F8o+tPwuVVJeX 8FDKfwXuaG1ThoXbxS2ho06wnEKITKqosOxfM+NS+c5QbXPzFqdbQOnEv7pu3M1sAS ch19QwIEi5sim25VWG59lh+/w9JdOgZ3Pk9zZWj4KUKSCaQkY6V21JUmGpqCKJEDeq GeyndQcsiIhyBcDub9T5+b2SkMCQ3PAXXJX55NKbmMxfVWfNd/sIt1YcDglyMRKGD3 Tw4vME3fA66qWtvNS0bhOMQo7RlE6dIOBNfdMuDqxRfDAvwOUuHaw0AA6KDANfVEA1 gqSfIZGxL2/3bnUeNNZ3vhPytb603QwpgcLvmYQQDfpp51v+P3sULMlfBLI6VqutPx T2sjDy5Q66tOUvH9FVsBs8vCfKtjTc7MujYkFp88FWTDu6VmN9lMgpYsTCFENJ+0Gh 9i8PFahOe9kp4ZGsyLzADxDhStdNLcg2Y3WYGs+G15F4ko4D83as9ax0X/aHqNuXE1 vW6e47/s0EI/jlEnPXTx52prR/UIzAk2uwbVXPuoUvaDNBaRKKTBvkLWPm9WqvnnHk od6sd/wlEQNH5QrX5sJdyX44= Received: from zn.tnic (pd95304da.dip0.t-ipconnect.de [217.83.4.218]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id E2DD740E01A5; Fri, 24 Nov 2023 14:20:43 +0000 (UTC) Date: Fri, 24 Nov 2023 15:20:43 +0100 From: Borislav Petkov To: Michael Roth Cc: kvm@vger.kernel.org, linux-coco@lists.linux.dev, linux-mm@kvack.org, linux-crypto@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com, jroedel@suse.de, thomas.lendacky@amd.com, hpa@zytor.com, ardb@kernel.org, pbonzini@redhat.com, seanjc@google.com, vkuznets@redhat.com, jmattson@google.com, luto@kernel.org, dave.hansen@linux.intel.com, slp@redhat.com, pgonda@google.com, peterz@infradead.org, srinivas.pandruvada@linux.intel.com, rientjes@google.com, dovmurik@linux.ibm.com, tobin@ibm.com, vbabka@suse.cz, kirill@shutemov.name, ak@linux.intel.com, tony.luck@intel.com, marcorr@google.com, sathyanarayanan.kuppuswamy@linux.intel.com, alpergun@google.com, jarkko@kernel.org, ashish.kalra@amd.com, nikunj.dadhania@amd.com, pankaj.gupta@amd.com, liam.merwick@oracle.com, zhi.a.wang@intel.com, Brijesh Singh Subject: Re: [PATCH v10 12/50] x86/sev: Invalidate pages from the direct map when adding them to the RMP table Message-ID: <20231124142043.GJZWCxOxeX0MLyZEWs@fat_crate.local> References: <20231016132819.1002933-1-michael.roth@amd.com> <20231016132819.1002933-13-michael.roth@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20231016132819.1002933-13-michael.roth@amd.com> X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 861FD180029 X-Stat-Signature: a9zuwqs6y7czzeqdhfb5b1ddh5frhjc6 X-Rspam-User: X-HE-Tag: 1700835689-180261 X-HE-Meta: U2FsdGVkX19RFVGq8e1FUt2uVUhME7CmX9pgU5KKip+3sUHrOZzCOSRZ2ubAhmR+4wlIM0Y/N2fU+2TsnImbX7h3k2TpyZ9YpRdHdkONuoLV8kQV008zTfginlZxaAkhPNGop2ZxmzRMC1gU7doeAOIzl9J+z+rHfZIOvZqDKiIo+qNrB4tLcGCKVQfeZKq5puzh6iDmnkFDpg26mctj1m/FzGShVkSKY7SzWcGUufxxeYbZZ7OukGHD9Gzi5ZXBnyDd2xM14C/d2lgxivQMLMeFD2jwO1vafGbtW7kQt5BwjVnvdcmxGXuBCBKkGJeowKmomP/zHvbGYOXjJUWh7E868f/4O9p7pY/+ZnL10ZlU/TOHgdOYtXW7V8k8tWIhdj1nn8E4U+0Nl6BHtGsloO/En/GghkV/a5S87NFT5X7F3SV6yuy57bRIGx61tWshftXzFIh6yWp2+LQ/owTztS0oX7/iVOI1WtMpjHy1yh+abruhNInB1aVBZ75CVg+Rxjky5BG3niNUSzeddF1ZGkKmzXrDvA1Z0nl4uju/h7gpynmrDQXE4hm7k0bou22yhF0MTYGz1p+RwY8gFyeuNvaqHVQGbGTIjclz7B0QkfhA0RkjCrT1EznFFsNA5O165ZgZbdPsAA5f4xr8y61VOqm0PbFQGDwtJLNq6VDuJ1oaQxMODRgdZ35hhYdVjM/yHhODyYIrABnzh9GVlqafhOjxWWs3E4ANCyj/aEyu+AS0MH73LV70CSXCDzlzFkhxMdwF41OMMQUJ2khzvl6qzgvlilrXyG2GeqZrFS1z29V6BaE1gvM567HCg1wA/DOOSmmNSOmoHndtZ2EshDcjYh5RQ5FkuaU6vwlCZPL5vZ1syk8zV6BwxNKhGO1q0JPO2UrsA3NlrT0Z5HYNYm8AGykHceYVq24VX2aEewVg6YvLqYSf9AnVLwBj3ftVmUjY9KS12eltnKNlRTHKibH Nj/VwDfp 6Pk7/gI7XYLAoDjqROiVF2/MnPrQ49d95ujSluEmI01WJu77nn3N+ex4cKTWKMVbTixMsyjq9fqMp05FrM2QMQ3gdCfTbdK0dYurIh+tAAzepdUIwjRbNDLxMKY1IH5yjK/5lz7sa6nEiZg+5GLgYDJqUdFri2C/cxjPhTGYCrB9DxstdxpnlfMvTknBe8LV27R3P7n5yRuJXQEmPpS5UZAyOdBxEbx5Iu+ff 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 Mon, Oct 16, 2023 at 08:27:41AM -0500, Michael Roth wrote: > From: Brijesh Singh > > The integrity guarantee of SEV-SNP is enforced through the RMP table. > The RMP is used with standard x86 and IOMMU page tables to enforce > memory restrictions and page access rights. The RMP check is enforced as > soon as SEV-SNP is enabled globally in the system. When hardware > encounters an RMP-check failure, it raises a page-fault exception. > > The rmp_make_private() and rmp_make_shared() helpers are used to add > or remove the pages from the RMP table. Improve the rmp_make_private() > to invalidate state so that pages cannot be used in the direct-map after > they are added the RMP table, and restored to their default valid > permission after the pages are removed from the RMP table. Brijesh's SOB comes <--- here, then Ashish's two tags. Please audit your whole set for such inconsistencies. > @@ -404,6 +440,21 @@ static int rmpupdate(u64 pfn, struct rmp_state *val) > if (!cpu_feature_enabled(X86_FEATURE_SEV_SNP)) > return -ENXIO; > > + level = RMP_TO_X86_PG_LEVEL(val->pagesize); > + npages = page_level_size(level) / PAGE_SIZE; > + > + /* > + * If page is getting assigned in the RMP table then unmap it from the > + * direct map. Here I'm missing the explanation *why* the pages need to be unmapped from the direct map. What happens if not? > + */ > + if (val->assigned) { > + if (invalidate_direct_map(pfn, npages)) { > + pr_err("Failed to unmap %d pages at pfn 0x%llx from the direct_map\n", > + npages, pfn); invalidate_direct_map() already dumps an error message - no need to do that here too. > + return -EFAULT; > + } > + } > + > do { > /* Binutils version 2.36 supports the RMPUPDATE mnemonic. */ > asm volatile(".byte 0xF2, 0x0F, 0x01, 0xFE" > @@ -422,6 +473,17 @@ static int rmpupdate(u64 pfn, struct rmp_state *val) > return -EFAULT; > } > > + /* > + * Restore the direct map after the page is removed from the RMP table. > + */ > + if (!val->assigned) { > + if (restore_direct_map(pfn, npages)) { > + pr_err("Failed to map %d pages at pfn 0x%llx into the direct_map\n", > + npages, pfn); Ditto. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette