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

Date:   Tue, 8 Jun 2021 22:48:10 +0300
From:   Dov Murik <dovmurik@...ux.ibm.com>
To:     jejb@...ux.ibm.com, Andi Kleen <ak@...ux.intel.com>,
        "Dr. David Alan Gilbert" <dgilbert@...hat.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>,
        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 24/05/2021 20:12, James Bottomley wrote:
> On Mon, 2021-05-24 at 09:31 -0700, Andi Kleen wrote:
>> 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.
> 
> This RFC contained the FS code.  In size terms its very comparable to
> your ioctl.
> 
>> 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.
> 
> Enumeration looks to be problematic with your interface ... what are
> you supposed to do, keep calling ACPI_SVKL_GET_KEY_INFO on an advancing
> index until it gives you an error and then try to work out what key
> you're interested in by one of its numeric properties?
> 
> I think a GUIDed structure actually helps here because we don't have to
> have someone assign, say, u16 types to keys we're interested in and the
> filesystem does all the enumeration for us.  It also means new use
> cases can simply expand the properties without waiting for any
> internals to catch up.
> 


Following the discussion here (and in various other meetings), the next
version of this patch series will keep the securityfs interface but will
introduce an unlink operation for the securityfs entries that will do
the following:

1. Remove the file entry from the securityfs dir

2. Overwrite the secret data memory (memzero_explicit)

3. Overwrite the GUID in the data memory with some invalid GUID
(ffffffff-ffff-.... ?), so that if the module is removed and loaded
again, the securityfs dir will not contain this entry (we'll ignore
these invalid GUIDs in the iteration).



Dov