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: <ZfeYU6hqlVF7y9YO@infradead.org>
Date: Sun, 17 Mar 2024 18:26:43 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Christian König <christian.koenig@....com>
Cc: David Stevens <stevensd@...omium.org>,
	Sean Christopherson <seanjc@...gle.com>,
	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 Thu, Mar 14, 2024 at 12:51:40PM +0100, Christian König wrote:
> > Does Christoph's objection come from my poorly worded cover letter and
> > commit messages, then?
> 
> Yes, that could certainly be.

That's definitively a big part of it, but I think not the only one.

> > Fundamentally, what this series is doing is
> > allowing pfns returned by follow_pte to be mapped into KVM's shadow
> > MMU without inadvertently translating them into struct pages.
> 
> As far as I can tell that is really the right thing to do. Yes.

IFF your callers don't need pages and you just want to track the
mapping in the shadow mmu and never take a refcount that is a good
thing.

But unless I completely misunderstood the series that doesn't seem
to be the case - it builds a new kvm_follow_pfn API which is another
of these weird multiplexers like get_user_pages that can to tons of
different things depending on the flags.  And some of that still
grabs the refcount, right?

> Completely agree. In my thinking when you go a step further and offload
> grabbing the page reference to get_user_pages() then you are always on the
> save side.

Agreed.

> Because then it is no longer the responsibility of the KVM code to get all
> the rules around that right, instead you are relying on a core functionality
> which should (at least in theory) do the correct thing.

Exactly.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ