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 04004C46CD2 for ; Sat, 27 Jan 2024 16:03:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 495636B0078; Sat, 27 Jan 2024 11:03:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 445676B007B; Sat, 27 Jan 2024 11:03:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 30D556B007D; Sat, 27 Jan 2024 11:03:44 -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 1E1F36B0078 for ; Sat, 27 Jan 2024 11:03:44 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id E3574160962 for ; Sat, 27 Jan 2024 16:03:43 +0000 (UTC) X-FDA: 81725561526.26.DF2350A Received: from mail.alien8.de (mail.alien8.de [65.109.113.108]) by imf30.hostedemail.com (Postfix) with ESMTP id 5A4618002A for ; Sat, 27 Jan 2024 16:03:41 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=alien8.de header.s=alien8 header.b=R8rDkWRY; dmarc=pass (policy=none) header.from=alien8.de; spf=pass (imf30.hostedemail.com: domain of bp@alien8.de designates 65.109.113.108 as permitted sender) smtp.mailfrom=bp@alien8.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706371422; 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=zJjvOvg09j/JxgCLQEW8hFY2bFZEzCn3tUUE3IeXvDI=; b=krGwRs0RMBuCWxLc6rzUzeDOkFdshQ0pU+MOaGuejR5UYjmPyg6O2E6gfIo889oEzRjZsM 0vR9hMfuZPUwUIsCPSBhJse+hyWRdJrrsNM/brX9pXT3ZJaNmOm2+NpeJamE2ExkNaSrKT k2O0TH4PTNFHgg4twX2Cbk8jodTIrzk= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=alien8.de header.s=alien8 header.b=R8rDkWRY; dmarc=pass (policy=none) header.from=alien8.de; spf=pass (imf30.hostedemail.com: domain of bp@alien8.de designates 65.109.113.108 as permitted sender) smtp.mailfrom=bp@alien8.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706371422; a=rsa-sha256; cv=none; b=5BJcQkPxfGttxpGqL5CwC7XBLNNMA1ClLXprOODhLNtrogL2bqr8iBdJb7Txcr9AvmglA+ GYOnyfqKjwB+dsbuxVAM7i7HdZK04ezVrCDXM/6kw7HsFMvvopaOJcuuNRIPhi0KbzSweU 6HHf2bRSja+KAjtrTUcNDnjLNe0LYhY= Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id 54F6740E01A9; Sat, 27 Jan 2024 16:03:37 +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 lu71nTCNoEp9; Sat, 27 Jan 2024 16:03:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1706371414; bh=zJjvOvg09j/JxgCLQEW8hFY2bFZEzCn3tUUE3IeXvDI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=R8rDkWRY9JApzGfMhoO/ltUpWhxXsJorl0xs3AW2oEMUGgqBJJ7et23aCsX/6rSk7 L1JZYSWGKq7guE8YqyGaMRXJrgA5qVJ9suCJL5LaRAjq9FgHLzJdkEZMxnSFMc2dtO gI4C12ZpMQGXlnS6ee8Hmd71QGrLYIjVdKj4p1Ryh0bmpobnRyMq49pcLhPYQikihj ue5l4fe7Nu2OCWJjYUTML+jOR/Z+9YoxQUnqYVWHEPdCUjY9UuUpJc4g+VS02kKWIW m6wXthg1Rtf8TnMSi5t1h7SkVGOiOlGC4YOldUaHQHzwLVqUUOuKrYZ3JBzjl4bi04 rs90xV6Ajdo+l1b0MRawQxxeu/ulhLAeopq07RMbJff6rXn1FQFYWl397VI847fDKM ETxBr43+USwVBUxwmJYsP0SHnk4yZUfN6etUbxgZlUqlH9uzKgyIY95J0r5YXAXZl6 iLYItOwjknaULfEgslHWFl6kTpSlysbnoqnWLxZeb/icAB9I6CmJ7keyRbjk7M3QFB liy7SwZp6fLivc4G3qmFGJ/LpDY3kVBGUC1ykFRxaYnoSobjO181UN8BzgedLbuQFB 1MtGE0JiOZbMIg+4bbG09P2gpteSN1AQ0jQW/wgSXWwaEcucT55dtP6lvCMlfx8Ozk GL8HCR0ME/5W6ZUstLeOYxkE= Received: from zn.tnic (pd953033e.dip0.t-ipconnect.de [217.83.3.62]) (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 64B8D40E016C; Sat, 27 Jan 2024 16:02:58 +0000 (UTC) Date: Sat, 27 Jan 2024 17:02:49 +0100 From: Borislav Petkov To: Michael Roth Cc: x86@kernel.org, kvm@vger.kernel.org, linux-coco@lists.linux.dev, linux-mm@kvack.org, linux-crypto@vger.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, tobin@ibm.com, vbabka@suse.cz, kirill@shutemov.name, ak@linux.intel.com, tony.luck@intel.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 Subject: Re: [PATCH v2 11/25] x86/sev: Adjust directmap to avoid inadvertant RMP faults Message-ID: <20240127160249.GDZbUpKW_cqRzdYn7Z@fat_crate.local> References: <20240126041126.1927228-1-michael.roth@amd.com> <20240126041126.1927228-12-michael.roth@amd.com> <20240126153451.GDZbPRG3KxaQik-0aY@fat_crate.local> <20240126170415.f7r4nvsrzgpzcrzv@amd.com> <20240126184340.GEZbP9XA13X91-eybA@fat_crate.local> <20240126235420.mu644waj2eyoxqx6@amd.com> <20240127114207.GBZbTsDyC3hFq8pQ3D@fat_crate.local> <20240127154506.v3wdio25zs6i2lc3@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20240127154506.v3wdio25zs6i2lc3@amd.com> X-Rspam-User: X-Stat-Signature: k887cozfagyiprsqt7yf1kxzggahw9o5 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 5A4618002A X-HE-Tag: 1706371421-461992 X-HE-Meta: U2FsdGVkX1+FLnWcJlbgWfYJ24AgjiyBHysk4PidswWjCHkLkl0Z7ftwZN9BMStCjLdwtzScuTmTRxSx7rwTid/ldWorskixujrPoUTBzMqlUxPYD6bCLc67OTK43feNIKNDnt3VtHh+zUP5O3l/HzLmGxQXZG/gxs/QHBmFPQzGJ5qVB6No/7FthiaWMtgEFpSppE8jhHB8CV7zS4hy9YtpA7tTQkKiyYelt2VZH4yXLdQOmArkbLOECdXaxemL6LGiKM+SG2zT28cFLtf1p3ziWq4Ivg7ib9eatEawxwedabMldPqKxDHstXOFYW5JHrZSFe4t4E5NIR22wzKcB2B+AVgrZKqX8gCZpn3/9lW+yz25H5nnew3QW/NuU8xGpk4lnBIBHMUXe7MLcJ5YEok1K4L5DUVwujSOZcDesrV6dAd1X1wHUV3SFkHPvLGf9uqyNifgPYhhec1FfcLew6UgTP8YCuqHprdqXSwlBTI8UUWnmm4IIFMjyfbplqwHfVKuPlMdAPWzzOZOBhq/Nsh4e5iEYrcoyn95fOorBMxfsji335P7lDEHZ7XSM4aPKJ6Spm9OlaNzwi6FpCF7kiSx+Tg3aNhb/ko4kx5TdnZO6EOMtffCJ10rdFzHAMfR5ciyqDW6tAHgvkygUYiHk/3O3kld++hSe//+uLFQVvGUGpIx/SbVn+3lv/qRcOV20ze1BSLfZ4mXJjYMOiaHWyAqYGIvy8MMKilcfJshvldrfgCzBDpKb6VAZ/vGhmSwbDWN/Qn/bKGh9ZzXaWVy2ifmX7DEq2a4sNBs2DBY8zUGqQ2L+rNM8Dx2q3VBT8svtEpaFRygNWauzd+qdW9Q5Sfyhk7P5LU6Wd2+ZUd3TzHCjyClMX0bUvRN1/uw/upMfKgMeFXlOwyNACwid/lm9zmjK1ufHXifG3fN7vFCYx/dZcIseE+jSJkgyVRdNmuchZ1OJO50P6oSydYxfaN bd3a3hCT dHXrgLLDlq+53XVaKAxR8GokTd9eynsfKIZ01Y9t4zFbyLFA6KCKywcsxm1Iqw5/5UFi36hvBRWPSpgJJjPHAekYySubAFGSwuzf8dE+CimMUFTrU0ZJKyVz9bRKO5ZaTzoRBGcHaTrhqT7hU+kYtf0gG8lk38cXmd6pjmTgMH3WTuxx6BqYKbxF/EoYVpK4iZLJfwdt5NqNvll8= 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 Sat, Jan 27, 2024 at 09:45:06AM -0600, Michael Roth wrote: > directmap maps all physical memory accessible by kernel, including text > pages, so those are valid PFNs as far as this function is concerned. Why don't you have a look at Documentation/arch/x86/x86_64/mm.rst to sync up on the nomenclature first? ffff888000000000 | -119.5 TB | ffffc87fffffffff | 64 TB | direct mapping of all physical memory (page_offset_base) ... ffffffff80000000 | -2 GB | ffffffff9fffffff | 512 MB | kernel text mapping, mapped to physical address 0 and so on. > The expectation is that the caller is aware of what PFNs it is passing in, There are no expectations. Have you written them down somewhere? > This function only splits mappings in the 0xffff888000000000 directmap > range. This function takes any PFN it gets passed in as it is. I don't care who its users are now or in the future and whether they pay attention what they pass into - it needs to be properly defined. Mike, please get on with the program. Use the right naming for the function and basta. IOW, this: diff --git a/arch/x86/virt/svm/sev.c b/arch/x86/virt/svm/sev.c index 0a8f9334ec6e..652ee63e87fd 100644 --- a/arch/x86/virt/svm/sev.c +++ b/arch/x86/virt/svm/sev.c @@ -394,7 +394,7 @@ EXPORT_SYMBOL_GPL(psmash); * More specifics on how these checks are carried out can be found in APM * Volume 2, "RMP and VMPL Access Checks". */ -static int adjust_direct_map(u64 pfn, int rmp_level) +static int split_pfn(u64 pfn, int rmp_level) { unsigned long vaddr = (unsigned long)pfn_to_kaddr(pfn); unsigned int level; @@ -405,7 +405,12 @@ static int adjust_direct_map(u64 pfn, int rmp_level) if (WARN_ON_ONCE(rmp_level > PG_LEVEL_2M)) return -EINVAL; - if (WARN_ON_ONCE(rmp_level == PG_LEVEL_2M && !IS_ALIGNED(pfn, PTRS_PER_PMD))) + if (!pfn_valid(pfn)) + return -EINVAL; + + if (rmp_level == PG_LEVEL_2M && + (!IS_ALIGNED(pfn, PTRS_PER_PMD) || + !pfn_valid(pfn + PTRS_PER_PMD - 1))) return -EINVAL; /* @@ -456,7 +461,7 @@ static int rmpupdate(u64 pfn, struct rmp_state *state) level = RMP_TO_PG_LEVEL(state->pagesize); - if (adjust_direct_map(pfn, level)) + if (split_pfn(pfn, level)) return -EFAULT; do { -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette