linux-kernel - Re: [PATCH] KVM: x86/mmu: Prevent installing hugepages when mem attributes are changing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250429125737.ygddoivogz2pf4mj@amd.com>
Date: Tue, 29 Apr 2025 07:57:37 -0500
From: Michael Roth <michael.roth@....com>
To: Yan Zhao <yan.y.zhao@...el.com>
CC: Sean Christopherson <seanjc@...gle.com>, Paolo Bonzini
	<pbonzini@...hat.com>, <kvm@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] KVM: x86/mmu: Prevent installing hugepages when mem
 attributes are changing

On Tue, Apr 29, 2025 at 09:23:13AM +0800, Yan Zhao wrote:
> On Mon, Apr 28, 2025 at 07:50:21AM -0700, Sean Christopherson wrote:
> > On Mon, Apr 28, 2025, Yan Zhao wrote:
> > > On Fri, Apr 25, 2025 at 05:10:56PM -0700, Sean Christopherson wrote:
> > > > @@ -7686,6 +7707,37 @@ bool kvm_arch_pre_set_memory_attributes(struct kvm *kvm,
> > > >  	if (WARN_ON_ONCE(!kvm_arch_has_private_mem(kvm)))
> > > >  		return false;
> > > >  
> > > > +	if (WARN_ON_ONCE(range->end <= range->start))
> > > > +		return false;
> > > > +
> > > > +	/*
> > > > +	 * If the head and tail pages of the range currently allow a hugepage,
> > > > +	 * i.e. reside fully in the slot and don't have mixed attributes, then
> > > > +	 * add each corresponding hugepage range to the ongoing invalidation,
> > > > +	 * e.g. to prevent KVM from creating a hugepage in response to a fault
> > > > +	 * for a gfn whose attributes aren't changing.  Note, only the range
> > > > +	 * of gfns whose attributes are being modified needs to be explicitly
> > > > +	 * unmapped, as that will unmap any existing hugepages.
> > > > +	 */
> > > > +	for (level = PG_LEVEL_2M; level <= KVM_MAX_HUGEPAGE_LEVEL; level++) {
> > > > +		gfn_t start = gfn_round_for_level(range->start, level);
> > > > +		gfn_t end = gfn_round_for_level(range->end - 1, level);
> > > > +		gfn_t nr_pages = KVM_PAGES_PER_HPAGE(level);
> > > > +
> > > > +		if ((start != range->start || start + nr_pages > range->end) &&
> > > > +		    start >= slot->base_gfn &&
> > > > +		    start + nr_pages <= slot->base_gfn + slot->npages &&
> > > > +		    !hugepage_test_mixed(slot, start, level))
> > > Instead of checking mixed flag in disallow_lpage, could we check disallow_lpage
> > > directly?
> > > 
> > > So, if mixed flag is not set but disallow_lpage is 1, there's no need to update
> > > the invalidate range.
> > > 
> > > > +			kvm_mmu_invalidate_range_add(kvm, start, start + nr_pages);
> > > > +
> > > > +		if (end == start)
> > > > +			continue;
> > > > +
> > > > +		if ((end + nr_pages) <= (slot->base_gfn + slot->npages) &&
> > > > +		    !hugepage_test_mixed(slot, end, level))
> > > if ((end + nr_pages > range->end) &&
> Checking "end + nr_pages > range->end" is necessary?
> 
> if range->end equals to
> "gfn_round_for_level(range->end - 1, level) + KVM_PAGES_PER_HPAGE(level)",
> there's no need to do other checks to update the invalidate range.

It's not really necessary, but yah, it would avoid an uneeded call to
kvm_mmu_invalidate_range_add(), and it would more closely match the
logic for the 'start' hugepage which similarly skips the call in that
case.

-Mike

> 
> > >     ((end + nr_pages) <= (slot->base_gfn + slot->npages)) &&
> > >     !lpage_info_slot(gfn, slot, level)->disallow_lpage)
> > > 
> > > ?
> 
>