kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vipin Sharma <vipinsh@google.com>
To: Tejun Heo <tj@kernel.org>
Cc: thomas.lendacky@amd.com, brijesh.singh@amd.com,
	jon.grimm@amd.com, eric.vantassell@amd.com, pbonzini@redhat.com,
	seanjc@google.com, lizefan@huawei.com, hannes@cmpxchg.org,
	frankja@linux.ibm.com, borntraeger@de.ibm.com, corbet@lwn.net,
	joro@8bytes.org, vkuznets@redhat.com, wanpengli@tencent.com,
	jmattson@google.com, tglx@linutronix.de, mingo@redhat.com,
	bp@alien8.de, hpa@zytor.com, gingell@google.com,
	rientjes@google.com, dionnaglaze@google.com, kvm@vger.kernel.org,
	x86@kernel.org, cgroups@vger.kernel.org,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [Patch v4 1/2] cgroup: svm: Add Encryption ID controller
Date: Tue, 19 Jan 2021 23:13:51 -0800	[thread overview]
Message-ID: <YAfYL7V6E4/P83Mg@google.com> (raw)
In-Reply-To: <YAb//EYCkZ7wnl6D@mtj.duckdns.org>

On Tue, Jan 19, 2021 at 10:51:24AM -0500, Tejun Heo wrote:
> Hello,
> On Fri, Jan 15, 2021 at 08:32:19PM -0800, Vipin Sharma wrote:
> > SEV-ES has stronger memory encryption gurantees compared to SEV, apart
> > from encrypting the application memory it also encrypts register state
> > among other things. In a single host ASIDs can be distributed between
> > these two types by BIOS settings.
> > 
> > Currently, Google Cloud has Confidential VM machines offering using SEV.
> > ASIDs are not compatible between SEV and SEV-ES, so a VM running on SEV
> > cannot run on SEV-ES and vice versa
> > 
> > There are use cases for both types of VMs getting used in future.
> Can you please elaborate? I skimmed through the amd manual and it seemed to
> say that SEV-ES ASIDs are superset of SEV but !SEV-ES ASIDs. What's the use
> case for mixing those two?

For example, customers can be given options for which kind of protection they
want to choose for their workloads based on factors like data protection
requirement, cost, speed, etc.

In terms of features SEV-ES is superset of SEV but that doesn't mean SEV
ASIDs are superset of SEV ASIDs. SEV ASIDs cannot be used for SEV-ES VMs
and similarly SEV-ES ASIDs cannot be used for SEV VMs. Once a system is
booted, based on the BIOS settings each type will have their own
capacity and that number cannot be changed until the next boot and BIOS

We are not mixing the two types of ASIDs, they are separate and used

> > > > > > Other ID types can be easily added in the controller in the same way.
> > > > > 
> > > > > I'm not sure this is necessarily a good thing.
> > > > 
> > > > This is to just say that when Intel and PowerPC changes are ready it
> > > > won't be difficult for them to add their controller.
> > > 
> > > I'm not really enthused about having per-hardware-type control knobs. None
> > > of other controllers behave that way. Unless it can be abstracted into
> > > something common, I'm likely to object.
> > 
> > There was a discussion in Patch v1 and consensus was to have individual
> > files because it makes kernel implementation extremely simple.
> > 
> > https://lore.kernel.org/lkml/alpine.DEB.2.23.453.2011131615510.333518@chino.kir.corp.google.com/#t
> I'm very reluctant to ack vendor specific interfaces for a few reasons but
> most importantly because they usually indicate abstraction and/or the
> underlying feature not being sufficiently developed and they tend to become
> baggages after a while. So, here are my suggestions:

My first patch was only for SEV, but soon we got comments that this can
be abstracted and used by TDX and SEID for their use cases.

I see this patch as providing an abstraction for simple accounting of
resources used for creating secure execution contexts. Here, secure
execution is achieved through different means. SEID, TDX, and SEV
provide security using different features and capabilities. I am not
sure if we will reach a point where all three and other vendors will use
the same approach and technology for this purpose.

Instead of each one coming up with their own resource tracking for their
features, this patch is providing a common framework and cgroup for
tracking these resources.

> * If there can be a shared abstraction which hopefully makes intuitive
>   sense, that'd be ideal. It doesn't have to be one knob but it shouldn't be
>   something arbitrary to specific vendors.

I think we should see these as features provided on a host. Tasks can
be executed securely on a host with the guarantees provided by the
specific feature (SEV, SEV-ES, TDX, SEID) used by the task.

I don't think each H/W vendor can agree to a common set of security
guarantees and approach.

> * If we aren't there yet and vendor-specific interface is a must, attach
>   that part to an interface which is already vendor-aware.
Sorry, I don't understand this approach. Can you please give more
details about it?


  reply	other threads:[~2021-01-20  7:15 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-08  1:28 [Patch v4 0/2] cgroup: KVM: New Encryption IDs cgroup controller Vipin Sharma
2021-01-08  1:28 ` [Patch v4 1/2] cgroup: svm: Add Encryption ID controller Vipin Sharma
2021-01-13 15:19   ` Brijesh Singh
2021-01-15 20:59   ` Tejun Heo
2021-01-15 22:18     ` Vipin Sharma
2021-01-16  3:43       ` Tejun Heo
2021-01-16  4:32         ` Vipin Sharma
2021-01-19 15:51           ` Tejun Heo
2021-01-20  7:13             ` Vipin Sharma [this message]
2021-01-20 16:40               ` Tejun Heo
2021-01-20 23:18                 ` Vipin Sharma
2021-01-20 23:32                   ` Tejun Heo
2021-01-22  0:09                     ` Vipin Sharma
2021-01-21 14:55                 ` Tom Lendacky
2021-01-21 15:55                   ` Tejun Heo
2021-01-21 23:12                     ` Tom Lendacky
2021-01-22  1:25                       ` Sean Christopherson
2021-01-26 20:49                         ` David Rientjes
2021-01-26 22:01                           ` Tejun Heo
2021-01-26 22:02                             ` Tejun Heo
2021-01-27  1:11                             ` Vipin Sharma
2021-01-27 14:10                               ` Tejun Heo
2021-01-08  1:28 ` [Patch v4 2/2] cgroup: svm: Encryption IDs cgroup documentation Vipin Sharma
2021-01-15 21:00   ` Tejun Heo
2021-01-15 21:41     ` Vipin Sharma

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YAfYL7V6E4/P83Mg@google.com \
    --to=vipinsh@google.com \
    --cc=borntraeger@de.ibm.com \
    --cc=bp@alien8.de \
    --cc=brijesh.singh@amd.com \
    --cc=cgroups@vger.kernel.org \
    --cc=corbet@lwn.net \
    --cc=dionnaglaze@google.com \
    --cc=eric.vantassell@amd.com \
    --cc=frankja@linux.ibm.com \
    --cc=gingell@google.com \
    --cc=hannes@cmpxchg.org \
    --cc=hpa@zytor.com \
    --cc=jmattson@google.com \
    --cc=jon.grimm@amd.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizefan@huawei.com \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=rientjes@google.com \
    --cc=seanjc@google.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    --cc=tj@kernel.org \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.com \
    --cc=x86@kernel.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).