From: Nayna Jain <nayna@linux.ibm.com>
To: linuxppc-dev@ozlabs.org, linux-efi@vger.kernel.org
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Eric Ricther <erichte@linux.ibm.com>,
Nayna Jain <nayna@linux.ibm.com>,
linux-kernel@vger.kernel.org, Mimi Zohar <zohar@linux.ibm.com>,
Claudio Carvalho <cclaudio@linux.ibm.com>,
Matthew Garret <matthew.garret@nebula.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Paul Mackerras <paulus@samba.org>, Jeremy Kerr <jk@ozlabs.org>,
Elaine Palmer <erpalmer@us.ibm.com>,
linux-integrity@vger.kernel.org,
George Wilson <gcwilson@linux.ibm.com>
Subject: [PATCH 0/2] powerpc/powernv: expose secure variables to userspace
Date: Thu, 13 Jun 2019 16:50:25 -0400 [thread overview]
Message-ID: <1560459027-5248-1-git-send-email-nayna@linux.ibm.com> (raw)
This patch set is part of a series that implements secure boot on PowerNV
systems[1]. The original series had been split into two patchsets:
1. powerpc: enable ima arch specific policies[2]
2. powerpc/powernv: expose secure variables to userspace, which is this
patchset.
Since there are major changes in this patchset compared to the previous
one[1], I am posting it as new series rather than v2.
As part of PowerNV secure boot support, NV OS verification keys are stored
and controlled by OPAL as secure variables. However, to allow users to
manage these keys, the secure variables need to be exposed to userspace.
OPAL provides the runtime services for the kernel to be able to access the
secure variables[3]. This patchset defines the kernel interface for the
OPAL APIs. These APIs are used by the hooks, which expose these variables
to userspace for reading/writing.
In order to reuse the existing tools, we currently use the efi hooks to
expose the secure variables via sysfs. Keeping the usability and
maintainability in mind, we are starting with this scheme as simple sysfs
implementation. We expect to refine it over time as we incorporate the
feedback.
The patchset makes substantial reuse of drivers/firmware/efi/efivars.c and
drivers/firmware/efi/vars.c, however because POWER platforms do not use
EFI, a new config, POWER_SECVAR_SYSFS, is defined to enable this sysfs
interface in POWER.
This patchset has a pre-requisiste of other OPAL APIs which are posted as
part of ima arch specific patches[2].
[1]https://patchwork.kernel.org/cover/10882149/
[2]https://lkml.org/lkml/2019/6/11/868
[3]https://patchwork.ozlabs.org/project/skiboot/list/?series=112868
Claudio Carvalho (1):
powerpc/powernv: add OPAL APIs for secure variables
Nayna Jain (1):
powerpc: expose secure variables via sysfs
arch/powerpc/Kconfig | 2 +
arch/powerpc/include/asm/opal-api.h | 3 +
arch/powerpc/include/asm/opal-secvar.h | 9 +
arch/powerpc/include/asm/opal.h | 8 +
arch/powerpc/platforms/powernv/opal-call.c | 3 +
arch/powerpc/platforms/powernv/opal-secvar.c | 60 +++-
drivers/firmware/Makefile | 1 +
drivers/firmware/efi/efivars.c | 2 +-
drivers/firmware/powerpc/Kconfig | 12 +
drivers/firmware/powerpc/Makefile | 3 +
drivers/firmware/powerpc/efi_error.c | 46 +++
drivers/firmware/powerpc/secvar.c | 326 +++++++++++++++++++
12 files changed, 473 insertions(+), 2 deletions(-)
create mode 100644 drivers/firmware/powerpc/Kconfig
create mode 100644 drivers/firmware/powerpc/Makefile
create mode 100644 drivers/firmware/powerpc/efi_error.c
create mode 100644 drivers/firmware/powerpc/secvar.c
--
2.20.1
next reply other threads:[~2019-06-13 20:53 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-13 20:50 Nayna Jain [this message]
2019-06-13 20:50 ` [PATCH 1/2] powerpc/powernv: add OPAL APIs for secure variables Nayna Jain
2019-06-13 20:50 ` [PATCH 2/2] powerpc: expose secure variables via sysfs Nayna Jain
2019-06-14 6:34 ` Greg Kroah-Hartman
2019-06-14 13:13 ` Nayna
2019-07-05 6:05 ` Michael Ellerman
2019-07-23 14:35 ` Nayna
2019-07-24 9:52 ` Oliver O'Halloran
2019-07-22 10:19 ` Oliver O'Halloran
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=1560459027-5248-1-git-send-email-nayna@linux.ibm.com \
--to=nayna@linux.ibm.com \
--cc=ard.biesheuvel@linaro.org \
--cc=cclaudio@linux.ibm.com \
--cc=erichte@linux.ibm.com \
--cc=erpalmer@us.ibm.com \
--cc=gcwilson@linux.ibm.com \
--cc=gregkh@linuxfoundation.org \
--cc=jk@ozlabs.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=matthew.garret@nebula.com \
--cc=paulus@samba.org \
--cc=zohar@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).