From: Tom Lendacky <email@example.com>
To: Tejun Heo <firstname.lastname@example.org>, Vipin Sharma <email@example.com>
Cc: firstname.lastname@example.org, email@example.com,
firstname.lastname@example.org, email@example.com, firstname.lastname@example.org,
email@example.com, firstname.lastname@example.org, email@example.com,
firstname.lastname@example.org, email@example.com, firstname.lastname@example.org,
email@example.com, firstname.lastname@example.org, email@example.com,
firstname.lastname@example.org, email@example.com, firstname.lastname@example.org,
email@example.com, firstname.lastname@example.org, email@example.com,
firstname.lastname@example.org, email@example.com, firstname.lastname@example.org,
Subject: Re: [Patch v4 1/2] cgroup: svm: Add Encryption ID controller
Date: Thu, 21 Jan 2021 08:55:07 -0600 [thread overview]
Message-ID: <email@example.com> (raw)
On 1/20/21 10:40 AM, Tejun Heo wrote:
> On Tue, Jan 19, 2021 at 11:13:51PM -0800, Vipin Sharma wrote:
>>> 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.
> So, I'm looking for is a bit more in-depth analysis than that. ie. What's
> the downside of SEV && !SEV-ES and is the disticntion something inherently
>> 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
> Here's an excerpt from the AMD's system programming manual, section 15.35.2:
> On some systems, there is a limitation on which ASID values can be used on
> SEV guests that are run with SEV-ES disabled. While SEV-ES may be enabled
> on any valid SEV ASID (as defined by CPUID Fn8000_001F[ECX]), there are
> restrictions on which ASIDs may be used for SEV guests with SEV- ES
> disabled. CPUID Fn8000_001F[EDX] indicates the minimum ASID value that
> must be used for an SEV-enabled, SEV-ES-disabled guest. For example, if
> CPUID Fn8000_001F[EDX] returns the value 5, then any VMs which use ASIDs
> 1-4 and which enable SEV must also enable SEV-ES.
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.
>> We are not mixing the two types of ASIDs, they are separate and used
> Maybe in practice, the key management on the BIOS side is implemented in a
> more restricted way but at least the processor manual says differently.
>>> 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.
> What's implemented is a shared place where similar things can be thrown in
> bu from user's perspective the underlying hardware feature isn't really
> abstracted. It's just exposing whatever hardware knobs there are. If you
> look at any other cgroup controllers, nothing is exposing this level of
> hardware dependent details and I'd really like to keep it that way.
> So, what I'm asking for is more in-depth analysis of the landscape and
> inherent differences among different vendor implementations to see whether
> there can be better approaches or we should just wait and see.
>>> * 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.
> Do TDX and SEID have multiple key types tho?
>>> * 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?
> Attaching the interface to kvm side, most likely, instead of exposing the
> feature through cgroup.
next prev parent reply other threads:[~2021-01-21 14:57 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
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 [this message]
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
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 \
* 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).