linux-kernel - Re: [PATCH RFC 0/5] mm/gup: Introduce exclusive GUP pinning

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: <20240620230034.GL2494510@nvidia.com>
Date: Thu, 20 Jun 2024 20:00:34 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Sean Christopherson <seanjc@...gle.com>
Cc: David Hildenbrand <david@...hat.com>, Fuad Tabba <tabba@...gle.com>,
	Christoph Hellwig <hch@...radead.org>,
	John Hubbard <jhubbard@...dia.com>,
	Elliot Berman <quic_eberman@...cinc.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Shuah Khan <shuah@...nel.org>, Matthew Wilcox <willy@...radead.org>,
	maz@...nel.org, kvm@...r.kernel.org, linux-arm-msm@...r.kernel.org,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	linux-kselftest@...r.kernel.org, pbonzini@...hat.com
Subject: Re: [PATCH RFC 0/5] mm/gup: Introduce exclusive GUP pinning

> This is the step that concerns me.   "Relatively short time" is, well, relative.
> Hmm, though I suppose if userspace managed to map a shared page into something
> that pins the page, and can't force an unpin, e.g. by stopping I/O?, then either
> there's a host userspace bug or a guest bug, and so effectively hanging the vCPU
> that is waiting for the conversion to complete is ok.

The whole entire point of FOLL_LONGTERM is to interact with
ZONE_MOVABLE stuff such that only FOLL_LONGTERM users will cause
unlimited refcount elevation.

Blocking FOLL_LONGTERM is supposed to result result in pins that go to
zero on their own in some entirely kernel controlled time
frame. Userspace is not supposed to be able to do anything to prevent
this.

This is not necessarily guarenteed "fast", but it is certainly largely
under the control of hypervisor kernel and VMM. ie if you do O_DIRECT
to the shared memory then the memory will remain pinned until the
storage completes. Which might be ms or it might be a xx second
storage timeout.

But putting it in the full context, if the guest tries to make a page
private that is actively undergoing IO while shared, then I think it
is misbehaving and it is quite reasonable to stall its call for
private until the page refs drop to zero. If guests want shared to
private to be fast then guests need to ensure there is no outstanding
IO.

In other words the page ref scheme would only be protective against
hostile guests and in real workloads we'd never expect to have to
wait. The same as ZONE_MOVABLE.

Jason