linux-kernel - Re: [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 for Android: free password hash cracker in your pocket

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

Message-ID: <8498cff4-3c31-f596-04fe-62013b94d7a4@intel.com>
Date:   Wed, 9 Mar 2022 14:40:29 -0800
From:   Dave Hansen <dave.hansen@...el.com>
To:     Alejandro Jimenez <alejandro.j.jimenez@...cle.com>,
        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
Subject: Re: [RFC 0/3] Expose Confidential Computing capabilities on sysfs

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?

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.