linux-kernel - Re: [RFC PATCH 0/3] Allow access to confidential computing secret area

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-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 24 May 2021 09:31:29 -0700
From:   Andi Kleen <ak@...ux.intel.com>
To:     "Dr. David Alan Gilbert" <dgilbert@...hat.com>,
        Dov Murik <dovmurik@...ux.ibm.com>
Cc:     Brijesh Singh <brijesh.singh@....com>, linux-efi@...r.kernel.org,
        Tobin Feldman-Fitzthum <tobin@...ux.ibm.com>,
        Tobin Feldman-Fitzthum <tobin@....com>,
        Jim Cadden <jcadden@....com>,
        James Bottomley <jejb@...ux.ibm.com>,
        Hubertus Franke <frankeh@...ibm.com>,
        Mike Rapoport <rppt@...ux.ibm.com>,
        Laszlo Ersek <lersek@...hat.com>,
        Ashish Kalra <ashish.kalra@....com>,
        Tom Lendacky <thomas.lendacky@....com>,
        Ard Biesheuvel <ardb@...nel.org>,
        James Morris <jmorris@...ei.org>,
        "Serge E. Hallyn" <serge@...lyn.com>,
        linux-security-module@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Kuppuswamy Sathyanarayanan 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>
Subject: Re: [RFC PATCH 0/3] Allow access to confidential computing secret
 area


On 5/24/2021 5:08 AM, Dr. David Alan Gilbert wrote:
> * Andi K
> Is there any way we could merge these two so that the TDX/SVKL would
> look similar to SEV/ES to userspace?  If we needed some initrd glue here
> for luks it would be great if we could have one piece of glue.
> [I'm not sure if the numbering/naming of the secrets, and their format
> are defined in the same way]
Maybe. There might well be differences in the contents as you say. So 
far SVKL doesn't really exist yet,  initially there will be the initrd 
based agents. The agents definitely will need to know about TDX.
>
> Do you think the ioctl is preferable to read+ftruncate/unlink ?
> And if it was an ioctl, again could we get some standardisation here -
> i.e.
> maybe a /dev/confguest with a CONF_COMP_GET_KEY etc ?

The advantage of the two ioctls is that they are very simple. Anything 
with a file system would be a lot more complicated. For security related 
code simplicity is a virtue.

Also since it's a really simple read and clear model I don't expect the 
value to be used widely, since it will be gone after boot anyways.

-andi