From: Tejun Heo <tj@kernel.org>
To: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Vipin Sharma <vipinsh@google.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: Thu, 21 Jan 2021 10:55:13 -0500 [thread overview]
Message-ID: <YAmj4Q2J9htW2Fe8@mtj.duckdns.org> (raw)
In-Reply-To: <be699d89-1bd8-25ae-fc6f-1e356b768c75@amd.com>
Hello,
On Thu, Jan 21, 2021 at 08:55:07AM -0600, Tom Lendacky wrote:
> The hardware will allow any SEV capable ASID to be run as SEV-ES, however,
> the SEV firmware will not allow the activation of an SEV-ES VM to be
> assigned to an ASID greater than or equal to the SEV minimum ASID value. The
> reason for the latter is to prevent an !SEV-ES ASID starting out as an
> SEV-ES guest and then disabling the SEV-ES VMCB bit that is used by VMRUN.
> This would result in the downgrading of the security of the VM without the
> VM realizing it.
>
> As a result, you have a range of ASIDs that can only run SEV-ES VMs and a
> range of ASIDs that can only run SEV VMs.
I see. That makes sense. What's the downside of SEV-ES compared to SEV w/o
ES? Are there noticeable performance / feature penalties or is the split
mostly for backward compatibility?
Thanks.
--
tejun
WARNING: multiple messages have this Message-ID (diff)
From: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
To: Tom Lendacky <thomas.lendacky-5C7GfCeVMHo@public.gmane.org>
Cc: Vipin Sharma <vipinsh-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
brijesh.singh-5C7GfCeVMHo@public.gmane.org,
jon.grimm-5C7GfCeVMHo@public.gmane.org,
eric.vantassell-5C7GfCeVMHo@public.gmane.org,
pbonzini-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
seanjc-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org,
lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org,
hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org,
frankja-tEXmvtCZX7AybS5Ee8rs3A@public.gmane.org,
borntraeger-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org,
corbet-T1hC0tSOHrs@public.gmane.org,
joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org,
vkuznets-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
wanpengli-1Nz4purKYjRBDgjK7y7TUQ@public.gmane.org,
jmattson-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org,
tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org,
mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
bp-Gina5bIWoIWzQB+pC5nmwQ@public.gmane.org,
hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org,
gingell-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org,
rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org,
dionnaglaze-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org,
kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [Patch v4 1/2] cgroup: svm: Add Encryption ID controller
Date: Thu, 21 Jan 2021 10:55:13 -0500 [thread overview]
Message-ID: <YAmj4Q2J9htW2Fe8@mtj.duckdns.org> (raw)
In-Reply-To: <be699d89-1bd8-25ae-fc6f-1e356b768c75-5C7GfCeVMHo@public.gmane.org>
Hello,
On Thu, Jan 21, 2021 at 08:55:07AM -0600, Tom Lendacky wrote:
> The hardware will allow any SEV capable ASID to be run as SEV-ES, however,
> the SEV firmware will not allow the activation of an SEV-ES VM to be
> assigned to an ASID greater than or equal to the SEV minimum ASID value. The
> reason for the latter is to prevent an !SEV-ES ASID starting out as an
> SEV-ES guest and then disabling the SEV-ES VMCB bit that is used by VMRUN.
> This would result in the downgrading of the security of the VM without the
> VM realizing it.
>
> As a result, you have a range of ASIDs that can only run SEV-ES VMs and a
> range of ASIDs that can only run SEV VMs.
I see. That makes sense. What's the downside of SEV-ES compared to SEV w/o
ES? Are there noticeable performance / feature penalties or is the split
mostly for backward compatibility?
Thanks.
--
tejun
next prev parent reply other threads:[~2021-01-21 16:50 UTC|newest]
Thread overview: 34+ 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-08 1:28 ` 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 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
2021-01-20 7:13 ` Vipin Sharma
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 14:55 ` Tom Lendacky
2021-01-21 15:55 ` Tejun Heo [this message]
2021-01-21 15:55 ` Tejun Heo
2021-01-21 23:12 ` Tom Lendacky
2021-01-21 23:12 ` Tom Lendacky
2021-01-22 1:25 ` Sean Christopherson
2021-01-26 20:49 ` David Rientjes
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 1:11 ` Vipin Sharma
2021-01-27 14:10 ` Tejun Heo
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YAmj4Q2J9htW2Fe8@mtj.duckdns.org \
--to=tj@kernel.org \
--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=vipinsh@google.com \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.