linux-kernel - Re: [RFC PATCH 0/2] powerpc/pseries: add support for local secure storage called Platform Keystore(PKS)

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]

Message-ID: <Yfk6gucNmJuR/egi@kroah.com>
Date:   Tue, 1 Feb 2022 14:49:54 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Daniel Axtens <dja@...ens.net>
Cc:     Nayna Jain <nayna@...ux.ibm.com>, linuxppc-dev@...ts.ozlabs.org,
        Michael Ellerman <mpe@...erman.id.au>,
        George Wilson <gcwilson@...ux.ibm.com>,
        Douglas Miller <dougmill@...ux.vnet.ibm.com>, gjoyce@....com,
        linux-kernel@...r.kernel.org, mjg59@...f.ucam.org
Subject: Re: [RFC PATCH 0/2] powerpc/pseries: add support for local secure
 storage called Platform Keystore(PKS)

On Mon, Jan 24, 2022 at 11:25:17AM +1100, Daniel Axtens wrote:
> Hi Greg,
> 
> > Ok, this is like the 3rd or 4th different platform-specific proposal for
> > this type of functionality.  I think we need to give up on
> > platform-specific user/kernel apis on this (random sysfs/securityfs
> > files scattered around the tree), and come up with a standard place for
> > all of this.
> 
> I agree that we do have a number of platforms exposing superficially
> similar functionality. Indeed, back in 2019 I had a crack at a unified
> approach: [1] [2].
> 
> Looking back at it now, I am not sure it ever would have worked because
> the semantics of the underlying firmware stores are quite
> different. Here are the ones I know about:
> 
>  - OpenPower/PowerNV Secure Variables:
>  
>    * Firmware semantics:
>      - flat variable space
>      - variables are fixed in firmware, can neither be created nor
>         destroyed
>      - variable names are ASCII
>      - no concept of policy/attributes
>      
>    * Current kernel interface semantics:
>      - names are case sensitive
>      - directory per variable     
> 
> 
>  - (U)EFI variables:
>  
>    * Firmware semantics:
>      - flat variable space
>      - variables can be created/destroyed but the semantics are fiddly
>         [3]
>      - variable names are UTF-16 + UUID
>      - variables have 32-bit attributes
> 
>    * efivarfs interface semantics:
>      - file per variable
>      - attributes are the first 4 bytes of the file
>      - names are partially case-insensitive (UUID part) and partially
>         case-sensitive ('name' part)
> 
>    * sysfs interface semantics (as used by CONFIG_GOOGLE_SMI)
>      - directory per variable
>      - attributes are a separate sysfs file
>      - to create a variable you write a serialised structure to
>         `/sys/firmware/efi/vars/new_var`, to delete a var you write
>         to `.../del_var`
>      - names are case-sensitive including the UUID
> 
> 
>  - PowerVM Partition Key Store Variables:
>  
>    * Firmware semantics:
>      - _not_ a flat space, there are 3 domains ("consumers"): firmware,
>         bootloader and OS (not yet supported by the patch set)
>      - variables can be created and destroyed but the semantics are
>         fiddly and fiddly in different ways to UEFI [4]
>      - variable names are arbitrary byte strings: the hypervisor permits
>         names to contain nul and /.
>      - variables have 32-bit attributes ("policy") that don't align with
>         UEFI attributes
> 
>    * No stable kernel interface yet
> 
> Even if we could come up with some stable kernel interface features
> (e.g. decide if we want file per variable vs directory per variable), I
> don't know how easy it would be to deal with the underlying semantic
> differences - I think userspace would still need substantial
> per-platform knowledge.
> 
> Or have I misunderstood what you're asking for? (If you want them all to
> live under /sys/firmware, these ones all already do...)

I want them to be unified in some way, right now there are lots of
proposals for the same type of thing, but in different places (sysfs,
securityfs, somewhere else), and with different names.

Please work together.

thanks,

greg k-h