linux-kernel - Re: [PATCH v11 0/8] KVM: allow mapping non-refcounted pages

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZfG801lYHRxlhZGT@google.com>
Date: Wed, 13 Mar 2024 07:48:51 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: "Christian König" <christian.koenig@....com>
Cc: David Stevens <stevensd@...omium.org>, Christoph Hellwig <hch@...radead.org>, 
	Paolo Bonzini <pbonzini@...hat.com>, Yu Zhang <yu.c.zhang@...ux.intel.com>, 
	Isaku Yamahata <isaku.yamahata@...il.com>, Zhi Wang <zhi.wang.linux@...il.com>, 
	Maxim Levitsky <mlevitsk@...hat.com>, kvmarm@...ts.linux.dev, linux-kernel@...r.kernel.org, 
	kvm@...r.kernel.org
Subject: Re: [PATCH v11 0/8] KVM: allow mapping non-refcounted pages

On Wed, Mar 13, 2024, Christian König wrote:
> Am 13.03.24 um 14:34 schrieb Sean Christopherson:
> > On Wed, Mar 13, 2024, Christian König wrote:
> > > And when you have either of those two functionalities the requirement to add
> > > a long term reference to the struct page goes away completely. So when this
> > > is done right you don't need to grab a reference in the first place.
> > The KVM issue that this series is solving isn't that KVM grabs a reference, it's
> > that KVM assumes that any non-reserved pfn that is backed by "struct page" is
> > refcounted.
> 
> Well why does it assumes that? When you have a MMU notifier that seems
> unnecessary.

Indeed, it's legacy code that we're trying to clean up.  It's the bulk of this
series.

> > What Christoph is objecting to is that, in this series, KVM is explicitly adding
> > support for mapping non-compound (huge)pages into KVM guests.  David is arguing
> > that Christoph's objection to _KVM_ adding support is unfair, because the real
> > problem is that the kernel already maps such pages into host userspace.  I.e. if
> > the userspace mapping ceases to exist, then there are no mappings for KVM to follow
> > and propagate to KVM's stage-2 page tables.
> 
> And I have to agree with Christoph that this doesn't make much sense. KVM
> should *never* map (huge) pages from VMAs marked with VM_PFNMAP into KVM
> guests in the first place.
> 
> What it should do instead is to mirror the PFN from the host page tables
> into the guest page tables.

That's exactly what this series does.  Christoph is objecting to KVM playing nice
with non-compound hugepages, as he feels that such mappings should not exist
*anywhere*.

I.e. Christoph is (implicitly) saying that instead of modifying KVM to play nice,
we should instead fix the TTM allocations.  And David pointed out that that was
tried and got NAK'd.