Received-SPF: pass (google.com: domain of linux-crypto+bounces-1687-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Fri, 26 Jan 2024 19:43:40 +0100
From: Borislav Petkov <bp@alien8.de>
To: Michael Roth <michael.roth@amd.com>
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: <20240126184340.GEZbP9XA13X91-eybA@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>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20240126170415.f7r4nvsrzgpzcrzv@amd.com>

On Fri, Jan 26, 2024 at 11:04:15AM -0600, Michael Roth wrote:
> vaddr comes from pfn_to_kaddr(pfn), i.e. __va(paddr), so it will
> necessarily be a direct-mapped address above __PAGE_OFFSET.

Ah, true.

> For upper-end, a pfn_valid(pfn) check might suffice, since only a valid
> PFN would have a possibly-valid mapping wthin the directmap range.

Looking at it, yap, that could be a sensible thing to check.

> These are PFNs that are owned/allocated-to the caller. Due to the nature
> of the directmap it's possible non-owners would write to a mapping that
> overlaps, but vmalloc()/etc. would not create mappings for any pages that
> were not specifically part of an allocation that belongs to the caller,
> so I don't see where there's any chance for an overlap there. And the caller
> of these functions would not be adjusting directmap for PFNs that might be
> mapped into other kernel address ranges like kernel-text/etc unless the
> caller was specifically making SNP-aware adjustments to those ranges, in
> which case it would be responsible for making those other adjustments,
> or implementing the necessary helpers/etc.

Why does any of that matter?

If you can make this helper as generic as possible now, why don't you?

> I'm not aware of such cases in the current code, and I don't think it makes
> sense to attempt to try to handle them here generically until such a case
> arises, since it will likely involve more specific requirements than what
> we can anticipate from a theoretical/generic standpoint.

Then that's a different story. If it will likely involve more specific
handling, then that function should deal with pfns for which it can DTRT
and for others warn loudly so that the code gets fixed in time.

IOW, then it should check for the upper pfn of the direct map here and
we have two, depending on the page sizes used...

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette