From: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
To: Dave Hansen <dave.hansen@intel.com>,
tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
dave.hansen@linux.intel.com, luto@kernel.org,
peterz@infradead.org, x86@kernel.org,
linux-kernel@vger.kernel.org
Cc: thomas.lendacky@amd.com, brijesh.singh@amd.com,
kirill.shutemov@linux.intel.com, hpa@zytor.com,
pbonzini@redhat.com, seanjc@google.com, srutherford@google.com,
ashish.kalra@amd.com, darren.kenny@oracle.com,
venu.busireddy@oracle.com, boris.ostrovsky@oracle.com
Subject: Re: [RFC 0/3] Expose Confidential Computing capabilities on sysfs
Date: Thu, 10 Mar 2022 13:07:33 -0500 [thread overview]
Message-ID: <746497ff-992d-4659-aa32-a54c68ae83bf@oracle.com> (raw)
In-Reply-To: <8498cff4-3c31-f596-04fe-62013b94d7a4@intel.com>
On 3/9/2022 5:40 PM, Dave Hansen wrote:
> On 3/9/22 14:06, Alejandro Jimenez wrote:>
>> On EPYC Milan host:
>>
>> $ grep -r . /sys/kernel/mm/mem_encrypt/*
>> /sys/kernel/mm/mem_encrypt/c_bit_position:51
> Why on earth would we want to expose this to userspace?
>
>> /sys/kernel/mm/mem_encrypt/sev/nr_sev_asid:509
>> /sys/kernel/mm/mem_encrypt/sev/status:enabled
>> /sys/kernel/mm/mem_encrypt/sev/nr_asid_available:509
>> /sys/kernel/mm/mem_encrypt/sev_es/nr_sev_es_asid:0
>> /sys/kernel/mm/mem_encrypt/sev_es/status:enabled
>> /sys/kernel/mm/mem_encrypt/sev_es/nr_asid_available:509
>> /sys/kernel/mm/mem_encrypt/sme/status:active
> For all of this... What will userspace *do* with it?
In my case, this information was useful to know for debugging failures
when testing the various features (e.g. need to specify cbitpos property
on QEMU sev-guest object).
It helps get an account of what is currently supported/enabled/active on
the host/guest, given that some of these capabilities will interact with
other components and cause boot hangs or errors (e.g. AVIC+SME or
AVIC+SEV hangs at boot, SEV guests with some configurations need to
increase SWIOTLB limit).
The sysfs entry basically answers the questions in
https://github.com/AMDESE/AMDSEV#faq without needing to run
virsh/qmp-shell/rdmsr.
I am aware than having a new sysfs entry mostly to facilitate debugging
might not be warranted, so I have tagged this as an RFC to ask if others
working in this space have found additional use cases, or just want the
convenience of having the data for current and future CoCo features in a
single location.
>
> For nr_asid_available, I get it. It tells you how many guests you can
> still run. But, TDX will need the same logical thing. Should TDX hosts
> go looking for this in:
>
> /sys/kernel/mm/mem_encrypt/tdx/available_guest_key_ids
>
> ?
>
> If it's something that's common, it needs to be somewhere common.
I think it makes sense to have common attributes for all CoCo providers
under /sys/kernel/mm/mem_encrypt/. The various CoCo providers can create
entries under mem_encrypt/<feature> exposing the information relevant to
their specific features like these patches implement for the AMD case,
and populate or link the <common_attr> attribute with the appropriate value.
Then we can have:
/sys/kernel/mm/mem_encrypt/
-- common_attr
-- sme/
-- sev/
-- sev_es/
or:
/sys/kernel/mm/mem_encrypt/
-- common_attr
-- tdx/
Note that at any single time, we are only creating entries that are
applicable to the hardware we are running on, so there is not a mix of
tdx and sme/sev subdirs.
I suspect it will be difficult to agree on what is "common" or even a
descriptive name. Lets say this common attribute will be:
/sys/kernel/mm/mem_encrypt/common_key
Where common_key can represent AMD SEV ASIDs/AMD SEV-{ES,SNP} ASIDs, or
Intel TDX KeyIDs (private/shared), or s390x SEID (Secure Execution IDs),
or <insert relevant ARM CCA attribute>.
We can have a (probably long) discussion to agree on the above; this
patchset just attempts to provide a framework for registering different
providers, and implements the AMD current capabilities.
Thank you,
Alejandro
next prev parent reply other threads:[~2022-03-10 18:08 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-09 22:06 [RFC 0/3] Expose Confidential Computing capabilities on sysfs Alejandro Jimenez
2022-03-09 22:06 ` [RFC 1/3] x86: Expose Secure Memory Encryption capabilities in sysfs Alejandro Jimenez
2022-03-09 22:06 ` [RFC 2/3] x86: Expose SEV " Alejandro Jimenez
2022-03-09 22:06 ` [RFC 3/3] x86: Expose SEV-ES " Alejandro Jimenez
2022-03-09 22:40 ` [RFC 0/3] Expose Confidential Computing capabilities on sysfs Dave Hansen
2022-03-10 18:07 ` Alejandro Jimenez [this message]
2022-03-14 22:43 ` Isaku Yamahata
2022-03-15 1:17 ` Kai Huang
2022-03-15 13:30 ` Dave Hansen
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=746497ff-992d-4659-aa32-a54c68ae83bf@oracle.com \
--to=alejandro.j.jimenez@oracle.com \
--cc=ashish.kalra@amd.com \
--cc=boris.ostrovsky@oracle.com \
--cc=bp@alien8.de \
--cc=brijesh.singh@amd.com \
--cc=darren.kenny@oracle.com \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=seanjc@google.com \
--cc=srutherford@google.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=venu.busireddy@oracle.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 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).