From: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
To: 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,
alejandro.j.jimenez@oracle.com
Subject: [RFC 0/3] Expose Confidential Computing capabilities on sysfs
Date: Wed, 9 Mar 2022 17:06:05 -0500 [thread overview]
Message-ID: <20220309220608.16844-1-alejandro.j.jimenez@oracle.com> (raw)
Given the growing number of Confidential Computing features (AMD SME/SEV, Intel
TDX), I believe it is useful to expose relevant state/parameters in sysfs.
e.g. For AMD memory encryption features, the distinction between possible states
(supported/enabled/active) is explained in the documentation at:
https://www.kernel.org/doc/Documentation/x86/amd-memory-encryption.txt
but there are currently no standard interfaces to determine state and other
relevant info (e.g. nr of SEV ASIDs) besides searching dmesg or manually reading
various CPUID leaves and MSRs.
This patchset implements a sysfs interface where only relevant attributes are
displayed depending on context (e.g. no SME entry or ASID attributes are created
when running on a guest)
On EPYC Milan host:
$ grep -r . /sys/kernel/mm/mem_encrypt/*
/sys/kernel/mm/mem_encrypt/c_bit_position:51
/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
On SEV guest running on EPYC Milan host (displays only relevant entries):
$ grep -r . /sys/kernel/mm/mem_encrypt/*
/sys/kernel/mm/mem_encrypt/c_bit_position:51
/sys/kernel/mm/mem_encrypt/sev/status:active
/sys/kernel/mm/mem_encrypt/sev_es/status:unsupported
The full directory tree looks like:
/sys/kernel/mm/mem_encrypt/
├── c_bit_position
├── sev
│ ├── nr_asid_available
│ ├── nr_sev_asid
│ └── status
├── sev_es
│ ├── nr_asid_available
│ ├── nr_sev_es_asid
│ └── status
└── sme
└── status
The goal is to be able to easily add new entries as new features (TDX, SEV-SNP)
are merged.
I'd appreciate any suggestions/comments.
Thank you,
Alejandro
Alejandro Jimenez (3):
x86: Expose Secure Memory Encryption capabilities in sysfs
x86: Expose SEV capabilities in sysfs
x86: Expose SEV-ES capabilities in sysfs
.../ABI/testing/sysfs-kernel-mm-mem-encrypt | 88 +++++
arch/x86/include/asm/mem_encrypt.h | 6 +
arch/x86/mm/mem_encrypt.c | 27 ++
arch/x86/mm/mem_encrypt_amd.c | 320 ++++++++++++++++++
4 files changed, 441 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-kernel-mm-mem-encrypt
--
2.34.1
next reply other threads:[~2022-03-09 22:11 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-09 22:06 Alejandro Jimenez [this message]
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
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=20220309220608.16844-1-alejandro.j.jimenez@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@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).