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: <a21aa503-39ed-4f6d-ad2e-a6a4b9a636b2@redhat.com>
Date: Thu, 17 Oct 2024 21:29:57 +0200
From: David Hildenbrand <david@...hat.com>
To: Jason Gunthorpe <jgg@...dia.com>, Peter Xu <peterx@...hat.com>
Cc: Ackerley Tng <ackerleytng@...gle.com>, tabba@...gle.com,
 quic_eberman@...cinc.com, roypat@...zon.co.uk, 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 17.10.24 21:18, 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?

I think what Peter is trying to say is that it would all be shared. 
Private conversion is never triggered by the host or the guest.

No special security, nothing. Just like using hugetlb, but without the 
hugetlb.

-- 
Cheers,

David / dhildenb


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ