linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Nayna Jain <nayna@linux.ibm.com>
To: linuxppc-dev@lists.ozlabs.org, linux-fsdevel@vger.kernel.org
Cc: Matthew Garrett <mjg59@srcf.ucam.org>,
	linux-efi@vger.kernel.org, Andrew Donnellan <ajd@linux.ibm.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org, npiggin@gmail.com,
	Dov Murik <dovmurik@linux.ibm.com>,
	Dave Hansen <dave.hansen@intel.com>,
	linux-security-module <linux-security-module@vger.kernel.org>,
	Paul Mackerras <paulus@samba.org>,
	George Wilson <gcwilson@linux.ibm.com>,
	Nayna Jain <nayna@linux.ibm.com>,
	Stefan Berger <stefanb@linux.ibm.com>
Subject: [PATCH 0/4] powerpc/pseries: expose firmware security variables via filesystem
Date: Sun,  6 Nov 2022 16:07:40 -0500	[thread overview]
Message-ID: <20221106210744.603240-1-nayna@linux.ibm.com> (raw)

PowerVM provides an isolated Platform KeyStore (PKS)[1] storage allocation
for each logical partition (LPAR) with individually managed access controls
to store sensitive information securely. The Linux kernel can access this
storage by interfacing with the hypervisor using a new set of hypervisor
calls.
 
The PowerVM guest secure boot feature intends to use PKS for the purpose of
storing public keys. Secure boot requires public keys in order to verify
GRUB and the boot kernel. To allow authenticated manipulation of keys, PKS
supports variables to store key authorities namely, PK and KEK. Other
variables are used to store code signing keys, db and grubdb. It also
supports deny lists to disallow booting GRUB or kernels even if they are
signed with valid keys. This is done via deny list databases stored in dbx
and sbat variables. These variables are stored in PKS and are managed and
controlled by firmware.

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

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

securityfs is meant for Linux security subsystems to expose policies, logs,
and other information and it does not interact with firmware for managing
these variables. However, there are various firmware security features that
expose their variables for user management via pseudo filesystems as
discussed above. There is currently no single place to expose these
variables. Different platforms use sysfs, platform-specific filesystems
such as efivars, or securityfs as they have found appropriate. This has
resulted in interfaces scattered around the tree. The multiple interfac
 problem can be addressed by providing a single pseudo filesystem for all
platforms to expose their variables for firmware security features. Doing
so simplifies the interface for users of these platforms.

This patchset introduces a new firmware security pseudo filesystem,
fwsecurityfs. Any platform can expose the variables that are required by
firmware security features via this interface. It provides 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 should be mounted on a new well-known mountpoint,
   /sys/firmware/security.
2. Platform-specific layer for these variables that implements underlying
   semantics. Platforms can expose their variables as files allowing
   read/write/add/delete operations by defining their own inode and file
   functions.

This patchset adds:
1. An update to the PLPKS driver to support the signed update H_CALL for
   authenticated variables used in guest secure boot.
2. A firmware security filesystem named fwsecurityfs.
3. An interface to expose secure variables stored in the LPAR's PKS via
   fwsecurityfs.
 
Note: This patchset is not intended to modify existing interfaces already
used by OpenPOWER or EFI but rather to ensure that new similar interfaces
have a common base going forward.

The first patch related to PLPKS driver is dependent on bugfixes posted
as part of patchset[4].

Changelog:

First non-RFC version after RFC versions[2,3].
Feedback from non-RFC version are included to update fwsecurityfs.
 * PLPKS driver patch had been upstreamed separately. In this set, Patch 1
 updates existing driver to include signed update support.
 * Fix fwsecurityfs to also pin the file system, refactor and cleanup. The
 consideration of namespacing has been done and is concluded that currently
 no firmware object or entity is handled by namespacing. The purpose of
 fwsecurityfs is to expose firmware space which is similar to exposing
 space in TPM. And TPM is also not currently namespaced. If containers have
 to make use of some such space in the future, it would have to be some
 software space. With that, this currently only considers the host using the
 firmware space.
 * Fix secvars support for powerpc. It supports policy handling within the
 kernel, supports UCS2 naming and cleanups.
 * Read-only PLPKS configuration is exposed.
 * secvars directory is now moved within a new parent directory plpks.
 * Patch is now no more an RFC version.

[1] https://community.ibm.com/community/user/power/blogs/chris-engel1/2020/11/20/powervm-introduces-the-platform-keystore
[2] RFC v2: https://lore.kernel.org/linuxppc-dev/20220622215648.96723-1-nayna@linux.ibm.com/ 
[3] RFC v1: https://lore.kernel.org/linuxppc-dev/20220122005637.28199-1-nayna@linux.ibm.com/
[4] https://lore.kernel.org/linuxppc-dev/20221106205839.600442-1-nayna@linux.ibm.com/T/#t

Nayna Jain (4):
  powerpc/pseries: Add new functions to PLPKS driver
  fs: define a firmware security filesystem named fwsecurityfs
  powerpc/pseries: initialize fwsecurityfs with plpks arch-specific
    structure
  powerpc/pseries: expose authenticated variables stored in LPAR PKS

 arch/powerpc/include/asm/hvcall.h             |   3 +-
 arch/powerpc/platforms/pseries/Kconfig        |  20 +
 arch/powerpc/platforms/pseries/Makefile       |   2 +
 .../platforms/pseries/fwsecurityfs_arch.c     | 124 ++++++
 arch/powerpc/platforms/pseries/plpks.c        | 112 +++++-
 arch/powerpc/platforms/pseries/plpks.h        |  38 ++
 arch/powerpc/platforms/pseries/secvars.c      | 365 ++++++++++++++++++
 fs/Kconfig                                    |   1 +
 fs/Makefile                                   |   1 +
 fs/fwsecurityfs/Kconfig                       |  14 +
 fs/fwsecurityfs/Makefile                      |  10 +
 fs/fwsecurityfs/super.c                       | 263 +++++++++++++
 include/linux/fwsecurityfs.h                  |  33 ++
 include/uapi/linux/magic.h                    |   1 +
 14 files changed, 981 insertions(+), 6 deletions(-)
 create mode 100644 arch/powerpc/platforms/pseries/fwsecurityfs_arch.c
 create mode 100644 arch/powerpc/platforms/pseries/secvars.c
 create mode 100644 fs/fwsecurityfs/Kconfig
 create mode 100644 fs/fwsecurityfs/Makefile
 create mode 100644 fs/fwsecurityfs/super.c
 create mode 100644 include/linux/fwsecurityfs.h

-- 
2.31.1

             reply	other threads:[~2022-11-06 21:09 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-06 21:07 Nayna Jain [this message]
2022-11-06 21:07 ` [PATCH 1/4] powerpc/pseries: Add new functions to PLPKS driver Nayna Jain
2022-11-06 21:07 ` [PATCH 2/4] fs: define a firmware security filesystem named fwsecurityfs Nayna Jain
2022-11-07  9:35   ` kernel test robot
2022-11-09 13:46   ` Greg Kroah-Hartman
2022-11-09 20:10     ` Nayna
2022-11-10  9:58       ` Greg Kroah-Hartman
2022-11-14 23:03         ` Nayna
2022-11-17 21:27           ` Greg Kroah-Hartman
2022-11-19  6:20             ` Nayna
2022-11-20 16:13               ` Greg Kroah-Hartman
2022-11-21  3:14                 ` James Bottomley
2022-11-21 11:05                   ` Greg Kroah-Hartman
2022-11-21 14:03                     ` James Bottomley
2022-11-21 15:05                       ` Greg Kroah-Hartman
2022-11-21 17:33                         ` James Bottomley
2022-11-21 18:12                           ` Greg Kroah-Hartman
2022-11-21 16:12                       ` David Laight
2022-11-21 19:34                   ` Nayna
2022-11-19 11:48       ` Ritesh Harjani (IBM)
2022-11-22 23:21         ` Nayna
2022-11-23 15:05           ` Nayna
2022-11-23 15:57             ` Greg Kroah-Hartman
2022-11-23 18:57               ` Nayna
2022-12-12  0:58                 ` Andrew Donnellan
2022-12-12  6:11                   ` Greg Kroah-Hartman
2022-11-06 21:07 ` [PATCH 3/4] powerpc/pseries: initialize fwsecurityfs with plpks arch-specific structure Nayna Jain
2022-11-07  3:52   ` kernel test robot
2022-11-06 21:07 ` [PATCH 4/4] powerpc/pseries: expose authenticated variables stored in LPAR PKS Nayna Jain

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221106210744.603240-1-nayna@linux.ibm.com \
    --to=nayna@linux.ibm.com \
    --cc=ajd@linux.ibm.com \
    --cc=dave.hansen@intel.com \
    --cc=dovmurik@linux.ibm.com \
    --cc=gcwilson@linux.ibm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mjg59@srcf.ucam.org \
    --cc=npiggin@gmail.com \
    --cc=paulus@samba.org \
    --cc=stefanb@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).