Re: Rename restrictedmem => guardedmem? (was: Re: [PATCH v10 0/9] KVM: mm: fd-based approach for supporting KVM)

[David Hildenbrand]

On 19.04.23 17:17, Sean Christopherson wrote:
> On Wed, Apr 19, 2023, David Hildenbrand wrote:
> > On 19.04.23 02:47, Sean Christopherson wrote:
> > > On Tue, Apr 18, 2023, David Hildenbrand wrote:
> > > > "memfd_vm" / "vm_mem" would be sooo (feel free to add some more o's here)
> > > > much easier to get. It's a special fd to be used to back VM memory. Depending
> > > > on the VM type (encrypted/protected/whatever), restrictions might apply (not
> > > > able to mmap, not able to read/write ...). For example, there really is no
> > > > need to disallow mmap/read/write when using that memory to back a simple VM
> > > > where all we want to do is avoid user-space page tables.
> > >
> > > In seriousness, I do agree with Jason's very explicit objection[2] against naming
> > > a non-KVM uAPI "guest", or any variation thereof.
> >
> > While I agree, it's all better than the naming we use right now ...
> >
> >
> > Let me throw "tee_mem" / "memfd_tee" into the picture. That could eventually
> > catch what we want to have.
> >
> > Or "coco_mem" / "memfd_coco".
> >
> > Of course, both expect that people know the terminology (just like what "vm"
> > stands for), but it's IMHO significantly better than
> > restricted/guarded/opaque/whatsoever.
> >
> > Again, expresses what it's used for, not why it behaves in weird ways.
>
> I don't want to explicitly tie this to trusted execution or confidential compute,
> as there is value in backing "normal" guests with memory that cannot be accessed
> by the host userspace without jumping through a few extra hoops, e.g. to add a
> layer of protection against data corruption due to host userspace bugs.

Nothing speaks against using tee_mem for the same purpose I guess. I 
like the sound of it after all. :)

--
Thanks,

David / dhildenb