| 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
| ||
|
Message-ID: <0959c72ec635688f4b6c1b516815f79f52543b31.camel@intel.com>
Date: Mon, 23 Jan 2023 23:01:17 +0000
From: "Huang, Kai" <kai.huang@...el.com>
To: "chao.p.peng@...ux.intel.com" <chao.p.peng@...ux.intel.com>,
"vbabka@...e.cz" <vbabka@...e.cz>
CC: "tglx@...utronix.de" <tglx@...utronix.de>,
"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"jmattson@...gle.com" <jmattson@...gle.com>,
"Lutomirski, Andy" <luto@...nel.org>,
"ak@...ux.intel.com" <ak@...ux.intel.com>,
"kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
"Hocko, Michal" <mhocko@...e.com>,
"tabba@...gle.com" <tabba@...gle.com>,
"qemu-devel@...gnu.org" <qemu-devel@...gnu.org>,
"david@...hat.com" <david@...hat.com>,
"michael.roth@....com" <michael.roth@....com>,
"corbet@....net" <corbet@....net>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"dhildenb@...hat.com" <dhildenb@...hat.com>,
"bfields@...ldses.org" <bfields@...ldses.org>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
"x86@...nel.org" <x86@...nel.org>, "bp@...en8.de" <bp@...en8.de>,
"ddutile@...hat.com" <ddutile@...hat.com>,
"rppt@...nel.org" <rppt@...nel.org>,
"shuah@...nel.org" <shuah@...nel.org>,
"vkuznets@...hat.com" <vkuznets@...hat.com>,
"naoya.horiguchi@....com" <naoya.horiguchi@....com>,
"linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
"qperret@...gle.com" <qperret@...gle.com>,
"arnd@...db.de" <arnd@...db.de>,
"pbonzini@...hat.com" <pbonzini@...hat.com>,
"Annapurve, Vishal" <vannapurve@...gle.com>,
"mail@...iej.szmigiero.name" <mail@...iej.szmigiero.name>,
"Christopherson,, Sean" <seanjc@...gle.com>,
"wanpengli@...cent.com" <wanpengli@...cent.com>,
"yu.c.zhang@...ux.intel.com" <yu.c.zhang@...ux.intel.com>,
"hughd@...gle.com" <hughd@...gle.com>,
"aarcange@...hat.com" <aarcange@...hat.com>,
"mingo@...hat.com" <mingo@...hat.com>,
"hpa@...or.com" <hpa@...or.com>,
"Nakajima, Jun" <jun.nakajima@...el.com>,
"jlayton@...nel.org" <jlayton@...nel.org>,
"joro@...tes.org" <joro@...tes.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"Wang, Wei W" <wei.w.wang@...el.com>,
"steven.price@....com" <steven.price@....com>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
"Hansen, Dave" <dave.hansen@...el.com>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"linmiaohe@...wei.com" <linmiaohe@...wei.com>
Subject: Re: [PATCH v10 1/9] mm: Introduce memfd_restricted system call to
create restricted user memory
On Mon, 2023-01-23 at 15:03 +0100, Vlastimil Babka wrote:
> On 12/22/22 01:37, Huang, Kai wrote:
> > > > I argue that this page pinning (or page migration prevention) is not
> > > > tied to where the page comes from, instead related to how the page will
> > > > be used. Whether the page is restrictedmem backed or GUP() backed, once
> > > > it's used by current version of TDX then the page pinning is needed. So
> > > > such page migration prevention is really TDX thing, even not KVM generic
> > > > thing (that's why I think we don't need change the existing logic of
> > > > kvm_release_pfn_clean()).
> > > >
> > This essentially boils down to who "owns" page migration handling, and sadly,
> > page migration is kinda "owned" by the core-kernel, i.e. KVM cannot handle page
> > migration by itself -- it's just a passive receiver.
> >
> > For normal pages, page migration is totally done by the core-kernel (i.e. it
> > unmaps page from VMA, allocates a new page, and uses migrate_pape() or a_ops-
> > > migrate_page() to actually migrate the page).
> > In the sense of TDX, conceptually it should be done in the same way. The more
> > important thing is: yes KVM can use get_page() to prevent page migration, but
> > when KVM wants to support it, KVM cannot just remove get_page(), as the core-
> > kernel will still just do migrate_page() which won't work for TDX (given
> > restricted_memfd doesn't have a_ops->migrate_page() implemented).
> >
> > So I think the restricted_memfd filesystem should own page migration handling,
> > (i.e. by implementing a_ops->migrate_page() to either just reject page migration
> > or somehow support it).
>
> While this thread seems to be settled on refcounts already,
>
I am not sure but will let Sean/Paolo to decide.
> just wanted
> to point out that it wouldn't be ideal to prevent migrations by
> a_ops->migrate_page() rejecting them. It would mean cputime wasted (i.e.
> by memory compaction) by isolating the pages for migration and then
> releasing them after the callback rejects it (at least we wouldn't waste
> time creating and undoing migration entries in the userspace page tables
> as there's no mmap). Elevated refcount on the other hand is detected
> very early in compaction so no isolation is attempted, so from that
> aspect it's optimal.
I am probably missing something, but IIUC the checking of refcount happens at
very last stage of page migration too, for instance:
migrate_folio(...) ->
migrate_folio_extra(..., 0 /* extra_count */) ->
folio_migrate_mapping(...).
And it is folio_migrate_mapping() who does the actual compare with the refcount,
which is at very late stage too:
int folio_migrate_mapping(struct address_space *mapping,
struct folio *newfolio, struct folio *folio, int extra_count)
{
...
int expected_count = folio_expected_refs(mapping, folio) + extra_count;
if (!mapping) {
/* Anonymous page without mapping */
if (folio_ref_count(folio) != expected_count)
return -EAGAIN;
....
return MIGRATEPAGE_SUCCESS;
}
....
if (!folio_ref_freeze(folio, expected_count)) {
xas_unlock_irq(&xas);
return -EAGAIN;
}
...
}
Powered by blists - more mailing lists