lkml.org 
[lkml]   [2022]   [Jun]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Subject[RFC PATCH v2 0/3] powerpc/pseries: add support for local secure storage called Platform KeyStore(PKS)
    Date
    PowerVM provides an isolated Platform KeyStore(PKS)[1] storage allocation
    for each partition(LPAR) with individually managed access controls to store
    sensitive information securely. Linux Kernel can access this storage by
    interfacing with hypervisor using a new set of hypervisor calls.

    PowerVM guest secure boot feature intend to use Platform KeyStore for
    the purpose of storing public keys. Secure boot requires public keys to
    be able to verify the grub and boot kernel. To allow authenticated
    manipulation of keys, it supports variables to store key authorities
    - PK/KEK. Other variables are used to store code signing keys - db/grubdb.
    It also supports denied list to disallow booting even if signed with
    valid key. This is done via denied list database - dbx or sbat. These
    variables would be stored in PKS, and are managed and controlled by
    firmware.

    The purpose of this patchset is to add userspace interface to manage
    these variables.

    For v1[2] version, we received following feedback
    "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."

    Currently, OpenPOWER exposes variables via sysfs, while EFI platforms
    have used sysfs and then moved to their own efivarfs filesystem.
    Recently, coco feature is using securityfs to expose their
    secrets. All of these environments are different both syntactically and
    semantically.

    securityfs is meant for linux security subsystems to expose policies/logs
    or any other information, and do not interact with firmware for managing
    these variables. However, there are various firmware security
    features which expose their variables for user management via kernel as
    discussed above. There is currently no single place to expose these
    variables. Different platforms use sysfs/platform specific
    filesystem(efivarfs)/securityfs interface as find appropriate. This has
    resulted in interfaces scattered around the tree.

    This resulted in demand of a need for a common single place for new
    platform interfaces to expose their variables for firmware security
    features. This would simplify the interface for users of these platforms.
    This patchset proposes firmware security filesystem(fwsecurityfs). Any
    platform can expose the variables which are required by firmware security
    features via this interface. Going forward, this would give a common place
    for exposing variables managed by firmware while still allowing platforms
    to implement their own underlying semantics.

    This design consists of two parts:
    1. firmware security filesystem(fwsecurityfs) that provides platforms with
    APIs to create their own underlying directory and file structure. It is
    recommended to establish a well known mount point:
    i.e. /sys/firmware/security/

    2. platform specific implementation for these variables which implements
    underlying semantics. Platforms can expose their variables as files
    allowing read/write/add/delete operations by defining their own inode and
    file operations.

    This patchset defines:
    1. pseries driver to access LPAR Platform Key Store(PLPKS)
    2. firmware security filesystem named fwsecurityfs
    3. Interface to expose secure variables stored in LPAR PKS via fwsecurityfs

    [1] https://community.ibm.com/community/user/power/blogs/chris-engel1/2020/11/20/powervm-introduces-the-platform-keystore
    [2] https://lore.kernel.org/linuxppc-dev/20220122005637.28199-1-nayna@linux.ibm.com/

    Changelog:

    v1:

    * Defined unified interface(firmware security filesystem) for all platforms
    to expose their variables used for security features.
    * Expose secvars using firmware security fileystem.
    * Renamed PKS driver to PLPKS to avoid naming conflict as mentioned by
    Dave Hanson.

    Nayna Jain (3):
    powerpc/pseries: define driver for Platform KeyStore
    fs: define a firmware security filesystem named fwsecurityfs
    powerpc/pseries: expose authenticated variables stored in LPAR PKS

    arch/powerpc/include/asm/hvcall.h | 12 +-
    arch/powerpc/include/asm/plpks.h | 92 ++++
    arch/powerpc/platforms/pseries/Kconfig | 27 +
    arch/powerpc/platforms/pseries/Makefile | 2 +
    arch/powerpc/platforms/pseries/plpks/Makefile | 9 +
    .../pseries/plpks/fwsecurityfs_arch.c | 16 +
    .../platforms/pseries/plpks/internal.h | 18 +
    arch/powerpc/platforms/pseries/plpks/plpks.c | 517 ++++++++++++++++++
    .../powerpc/platforms/pseries/plpks/secvars.c | 239 ++++++++
    fs/Kconfig | 1 +
    fs/Makefile | 1 +
    fs/fwsecurityfs/Kconfig | 14 +
    fs/fwsecurityfs/Makefile | 10 +
    fs/fwsecurityfs/inode.c | 159 ++++++
    fs/fwsecurityfs/internal.h | 13 +
    fs/fwsecurityfs/super.c | 154 ++++++
    include/linux/fwsecurityfs.h | 33 ++
    include/uapi/linux/magic.h | 1 +
    18 files changed, 1317 insertions(+), 1 deletion(-)
    create mode 100644 arch/powerpc/include/asm/plpks.h
    create mode 100644 arch/powerpc/platforms/pseries/plpks/Makefile
    create mode 100644 arch/powerpc/platforms/pseries/plpks/fwsecurityfs_arch.c
    create mode 100644 arch/powerpc/platforms/pseries/plpks/internal.h
    create mode 100644 arch/powerpc/platforms/pseries/plpks/plpks.c
    create mode 100644 arch/powerpc/platforms/pseries/plpks/secvars.c
    create mode 100644 fs/fwsecurityfs/Kconfig
    create mode 100644 fs/fwsecurityfs/Makefile
    create mode 100644 fs/fwsecurityfs/inode.c
    create mode 100644 fs/fwsecurityfs/internal.h
    create mode 100644 fs/fwsecurityfs/super.c
    create mode 100644 include/linux/fwsecurityfs.h

    --
    2.27.0

    \
     
     \ /
      Last update: 2022-06-22 23:59    [W:4.064 / U:0.072 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site