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
| ||
|
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.
Powered by blists - more mailing lists