linux-kernel - [RFC 0/3] Expose Confidential Computing capabilities on sysfs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20220309220608.16844-1-alejandro.j.jimenez@oracle.com>
Date:   Wed,  9 Mar 2022 17:06:05 -0500
From:   Alejandro Jimenez <alejandro.j.jimenez@...cle.com>
To:     tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
        dave.hansen@...ux.intel.com, luto@...nel.org, peterz@...radead.org,
        x86@...nel.org, linux-kernel@...r.kernel.org
Cc:     thomas.lendacky@....com, brijesh.singh@....com,
        kirill.shutemov@...ux.intel.com, hpa@...or.com,
        pbonzini@...hat.com, seanjc@...gle.com, srutherford@...gle.com,
        ashish.kalra@....com, darren.kenny@...cle.com,
        venu.busireddy@...cle.com, boris.ostrovsky@...cle.com,
        alejandro.j.jimenez@...cle.com
Subject: [RFC 0/3] Expose Confidential Computing capabilities on sysfs

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