linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


             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).