linux-kernel - Re: [RFC PATCH 26/39] KVM: guest_memfd: Track faultability within a struct kvm_gmem

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: <2686a5ae-e1e5-48d6-ae4b-31face5284ca@amazon.co.uk>
Date: Fri, 18 Oct 2024 08:15:50 +0100
From: Patrick Roy <roypat@...zon.co.uk>
To: Jason Gunthorpe <jgg@...dia.com>, Peter Xu <peterx@...hat.com>
CC: David Hildenbrand <david@...hat.com>, Ackerley Tng
	<ackerleytng@...gle.com>, <tabba@...gle.com>, <quic_eberman@...cinc.com>,
	<rientjes@...gle.com>, <fvdl@...gle.com>, <jthoughton@...gle.com>,
	<seanjc@...gle.com>, <pbonzini@...hat.com>, <zhiquan1.li@...el.com>,
	<fan.du@...el.com>, <jun.miao@...el.com>, <isaku.yamahata@...el.com>,
	<muchun.song@...ux.dev>, <erdemaktas@...gle.com>, <vannapurve@...gle.com>,
	<qperret@...gle.com>, <jhubbard@...dia.com>, <willy@...radead.org>,
	<shuah@...nel.org>, <brauner@...nel.org>, <bfoster@...hat.com>,
	<kent.overstreet@...ux.dev>, <pvorel@...e.cz>, <rppt@...nel.org>,
	<richard.weiyang@...il.com>, <anup@...infault.org>, <haibo1.xu@...el.com>,
	<ajones@...tanamicro.com>, <vkuznets@...hat.com>,
	<maciej.wieczor-retman@...el.com>, <pgonda@...gle.com>,
	<oliver.upton@...ux.dev>, <linux-kernel@...r.kernel.org>,
	<linux-mm@...ck.org>, <kvm@...r.kernel.org>,
	<linux-kselftest@...r.kernel.org>
Subject: Re: [RFC PATCH 26/39] KVM: guest_memfd: Track faultability within a
 struct kvm_gmem_private



On Thu, 2024-10-17 at 20:18 +0100, Jason Gunthorpe wrote:
> On Thu, Oct 17, 2024 at 03:11:10PM -0400, Peter Xu wrote:
>> On Thu, Oct 17, 2024 at 02:10:10PM -0300, Jason Gunthorpe wrote:
>>>> If so, maybe that's a non-issue for non-CoCo, where the VM object /
>>>> gmemfd object (when created) can have a flag marking that it's
>>>> always shared and can never be converted to private for any page
>>>> within.
>>>
>>> What is non-CoCo? Does it include the private/shared concept?
>>
>> I used that to represent the possible gmemfd use cases outside confidential
>> computing.
>>
>> So the private/shared things should still be around as fundamental property
>> of gmemfd, but it should be always shared and no convertion needed for the
>> whole lifecycle of the gmemfd when marked !CoCo.
> 
> But what does private mean in this context?
> 
> Is it just like a bit of additional hypervisor security that the page
> is not mapped anyplace except the KVM stage 2 and the hypervisor can
> cause it to become mapped/shared at any time? But the guest has no
> idea about this?
> 
> Jason

Yes, this is pretty much exactly what I'm after when I say "non-CoCo".
No direct map entries to provide defense-in-depth for guests against
various speculative execution issues, but not a full confidential
computing setup (e.g. the guest should be completely oblivious to this,
and not require any modifications).