In order to verify the OS kernel on PowerNV systems, secure boot requires
X.509 certificates trusted by the platform. These are stored in secure
variables controlled by OPAL, called OPAL secure variables. In order to
enable users to manage the 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[1]. This patchset defines the kernel interface for the
OPAL APIs. These APIs are used by the hooks, which load these variables
to the keyring and expose them to the userspace for reading/writing.
The previous version[2] of the patchset added support only for the sysfs
interface. This patch adds two more patches that involves loading of
the firmware trusted keys to the kernel keyring. This patchset is
dependent on the base CONFIG PPC_SECURE_BOOT added by ima arch specific
patches for POWER[3]
Overall, this patchset adds the following support:
* expose secure variables to the kernel via OPAL Runtime API interface
* expose secure variables to the userspace via kernel sysfs interface
* load kernel verification and revocation keys to .platform and
.blacklist keyring respectively.
The secure variables can be read/written using simple linux utilities
cat/hexdump.
For example:
Path to the secure variables is:
/sys/firmware/secvar/vars
Each secure variable is listed as directory.
$ ls -l
total 0
drwxr-xr-x. 2 root root 0 Aug 20 21:20 db
drwxr-xr-x. 2 root root 0 Aug 20 21:20 KEK
drwxr-xr-x. 2 root root 0 Aug 20 21:20 PK
The attributes of each of the secure variables are(for example: PK):
[PK]$ ls -l
total 0
-r--r--r--. 1 root root 32000 Aug 21 08:28 data
-r--r--r--. 1 root root 65536 Aug 21 08:28 name
-r--r--r--. 1 root root 65536 Aug 21 08:28 size
--w-------. 1 root root 32000 Aug 21 08:28 update
The "data" is used to read the existing variable value using hexdump. The
data is stored in ESL format.
The "update" is used to write a new value using cat. The update is
to be submitted as AUTH file.
[1] Depends on skiboot OPAL API changes which removes metadata from
the API. The new version with the changes are going to be posted soon.
[2] https://lkml.org/lkml/2019/6/13/1644
[3] https://lkml.org/lkml/2019/8/19/402
Changelog:
v2:
* removes complete efi-sms from the sysfs implementation and is simplified
* includes Greg's and Oliver's feedbacks:
* adds sysfs documentation
* moves sysfs code to arch/powerpc
* other code related feedbacks.
* adds two new patches to load keys to .platform and .blacklist keyring.
These patches are added to this series as they are also dependent on
OPAL APIs.
Nayna Jain (4):
powerpc/powernv: Add OPAL API interface to access secure variable
powerpc: expose secure variables to userspace via sysfs
x86/efi: move common keyring handler functions to new file
powerpc: load firmware trusted keys into kernel keyring
Documentation/ABI/testing/sysfs-secvar | 27 +++
arch/powerpc/Kconfig | 9 +
arch/powerpc/include/asm/opal-api.h | 5 +-
arch/powerpc/include/asm/opal.h | 6 +
arch/powerpc/include/asm/secvar.h | 55 +++++
arch/powerpc/kernel/Makefile | 3 +-
arch/powerpc/kernel/secvar-ops.c | 25 +++
arch/powerpc/kernel/secvar-sysfs.c | 210 ++++++++++++++++++
arch/powerpc/platforms/powernv/Kconfig | 6 +
arch/powerpc/platforms/powernv/Makefile | 1 +
arch/powerpc/platforms/powernv/opal-call.c | 3 +
arch/powerpc/platforms/powernv/opal-secvar.c | 102 +++++++++
arch/powerpc/platforms/powernv/opal.c | 5 +
security/integrity/Kconfig | 9 +
security/integrity/Makefile | 6 +-
.../platform_certs/keyring_handler.c | 80 +++++++
.../platform_certs/keyring_handler.h | 35 +++
.../integrity/platform_certs/load_powerpc.c | 94 ++++++++
security/integrity/platform_certs/load_uefi.c | 67 +-----
19 files changed, 679 insertions(+), 69 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-secvar
create mode 100644 arch/powerpc/include/asm/secvar.h
create mode 100644 arch/powerpc/kernel/secvar-ops.c
create mode 100644 arch/powerpc/kernel/secvar-sysfs.c
create mode 100644 arch/powerpc/platforms/powernv/opal-secvar.c
create mode 100644 security/integrity/platform_certs/keyring_handler.c
create mode 100644 security/integrity/platform_certs/keyring_handler.h
create mode 100644 security/integrity/platform_certs/load_powerpc.c
--
2.20.1
@@ -988,6 +990,9 @@ static int __init opal_init(void)/* Initialise OPAL Power control interface */opal_power_control_init();+if(is_powerpc_secvar_supported())+secvar_init();+return0;}machine_subsys_initcall(powernv,opal_init);
PowerNV secure variables, which store the keys used for OS kernel
verification, are managed by the firmware. These secure variables need to
be accessed by the userspace for addition/deletion of the certificates.
This patch adds the sysfs interface to expose secure variables for PowerNV
secureboot. The users shall use this interface for manipulating
the keys stored in the secure variables.
Signed-off-by: Nayna Jain <nayna@linux.ibm.com>
---
Documentation/ABI/testing/sysfs-secvar | 27 ++++
arch/powerpc/Kconfig | 9 ++
arch/powerpc/kernel/Makefile | 1 +
arch/powerpc/kernel/secvar-sysfs.c | 210 +++++++++++++++++++++++++
4 files changed, 247 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-secvar
create mode 100644 arch/powerpc/kernel/secvar-sysfs.c
@@ -0,0 +1,27 @@+What: /sys/firmware/secvar+Date: August 2019+Contact: Nayna Jain <nayna@linux.ibm.com>+Description:+ This directory exposes interfaces for interacting with+ the secure variables managed by OPAL firmware.++ This is only for the powerpc/powernv platform.++ Directory:+ vars: This directory lists all the variables that+ are supported by the OPAL. The variables are+ represented in the form of directories with+ their variable names. The variable name is+ unique and is in ASCII representation. The data+ and size can be determined by reading their+ respective attribute files.++ Each variable directory has the following files:+ name: An ASCII representation of the variable name+ data: A read-only file containing the value of the+ variable+ size: An integer representation of the size of the+ content of the variable. In other works, it+ represents the size of the data+ update: A write-only file that is used to submit the new+ value for the variable.
@@ -0,0 +1,210 @@+// SPDX-License-Identifier: GPL-2.0++/*+*Copyright(C)2019IBMCorporation<nayna@linux.ibm.com>+*+*Thiscodeexposessecurevariablestouserviasysfs+*/++#include<linux/module.h>+#include<linux/slab.h>+#include<linux/compat.h>+#include<linux/string.h>+#include<asm/opal.h>+#include<asm/secvar.h>++//Approximating it for now, it is bound to change.+#define VARIABLE_MAX_SIZE 32000++staticstructkobject*powerpc_kobj;+staticstructsecvar_operations*secvarops;+structkset*secvar_kset;++staticssize_tname_show(structkobject*kobj,structkobj_attribute*attr,+char*buf)+{+returnsprintf(buf,"%s",kobj->name);+}++staticssize_tsize_show(structkobject*kobj,structkobj_attribute*attr,+char*buf)+{+unsignedlongdsize;+intrc;++rc=secvarops->get_variable(kobj->name,strlen(kobj->name)+1,NULL,+&dsize);+if(rc){+pr_err("Error retrieving variable size %d\n",rc);+returnrc;+}++rc=sprintf(buf,"%ld",dsize);++returnrc;+}++staticssize_tdata_read(structfile*filep,structkobject*kobj,+structbin_attribute*attr,char*buf,loff_toff,+size_tcount)+{+unsignedlongdsize;+intrc;+char*data;++rc=secvarops->get_variable(kobj->name,strlen(kobj->name)+1,NULL,+&dsize);+if(rc){+pr_err("Error getting variable size %d\n",rc);+returnrc;+}+pr_debug("dsize is %ld\n",dsize);++data=kzalloc(dsize,GFP_KERNEL);+if(!data)+return-ENOMEM;++rc=secvarops->get_variable(kobj->name,strlen(kobj->name)+1,data,+&dsize);+if(rc){+pr_err("Error getting variable %d\n",rc);+gotodata_fail;+}++rc=memory_read_from_buffer(buf,count,&off,data,dsize);++data_fail:+kfree(data);+returnrc;+}++staticssize_tupdate_write(structfile*filep,structkobject*kobj,+structbin_attribute*attr,char*buf,loff_toff,+size_tcount)+{+intrc;++pr_debug("count is %ld\n",count);+rc=secvarops->set_variable(kobj->name,strlen(kobj->name)+1,buf,+count);+if(rc){+pr_err("Error setting the variable %s\n",kobj->name);+returnrc;+}++returncount;+}++staticstructkobj_attributename_attr=+__ATTR(name,0444,name_show,NULL);++staticstructkobj_attributesize_attr=+__ATTR(size,0444,size_show,NULL);++staticstructbin_attributedata_attr={+.attr={.name="data",.mode=0444},+.size=VARIABLE_MAX_SIZE,+.read=data_read,+};+++staticstructbin_attributeupdate_attr={+.attr={.name="update",.mode=0200},+.size=VARIABLE_MAX_SIZE,+.write=update_write,+};++staticstructbin_attribute*secvar_bin_attrs[]={+&data_attr,+&update_attr,+NULL,+};++staticstructattribute*secvar_attrs[]={+&name_attr.attr,+&size_attr.attr,+NULL,+};++conststructattribute_groupsecvar_attr_group={+.attrs=secvar_attrs,+.bin_attrs=secvar_bin_attrs,+};++intsecvar_sysfs_load(void)+{++char*name;+unsignedlongnamesize;+structkobject*kobj;+intstatus;+intrc=0;++name=kzalloc(1024,GFP_KERNEL);+if(!name)+return-ENOMEM;++do{++status=secvarops->get_next_variable(name,&namesize,1024);+if(status!=OPAL_SUCCESS)+break;++pr_info("name is %s\n",name);+kobj=kobject_create_and_add(name,&(secvar_kset->kobj));+if(kobj){+rc=sysfs_create_group(kobj,&secvar_attr_group);+if(rc)+pr_err("Error creating attributes for %s variable\n",+name);+}else{+pr_err("Error creating sysfs entry for %s variable\n",+name);+rc=-EINVAL;+}++}while((status==OPAL_SUCCESS)&&(rc==0));++kfree(name);+returnrc;+}++intsecvar_sysfs_init(void)+{+powerpc_kobj=kobject_create_and_add("secvar",firmware_kobj);+if(!powerpc_kobj){+pr_err("secvar: Failed to create firmware kobj\n");+return-ENODEV;+}++secvar_kset=kset_create_and_add("vars",NULL,powerpc_kobj);+if(!secvar_kset){+pr_err("secvar: sysfs kobject registration failed.\n");+return-ENODEV;+}++secvarops=get_secvar_ops();+if(!secvarops){+kobject_put(powerpc_kobj);+pr_err("secvar: failed to retrieve secvar operations.\n");+return-ENODEV;+}++secvar_sysfs_load();+pr_info("Secure variables sysfs initialized");++return0;+}+EXPORT_SYMBOL_GPL(secvar_sysfs_init);++staticvoidsecvar_sysfs_exit(void)+{+kobject_put(powerpc_kobj);+}+EXPORT_SYMBOL_GPL(secvar_sysfs_exit);++module_init(secvar_sysfs_init);+module_exit(secvar_sysfs_exit);++MODULE_AUTHOR("Nayna Jain<nayna@linux.ibm.com>");+MODULE_DESCRIPTION("sysfs interface to POWER secure variables");+MODULE_LICENSE("GPL");
The keys used to verify the Host OS kernel are managed by OPAL as secure
variables. This patch loads the verification keys into the .platform
keyring and revocation keys into .blacklist keyring. This enables
verification and loading of the kernels signed by the boot time keys which
are trusted by firmware.
Signed-off-by: Nayna Jain <nayna@linux.ibm.com>
---
security/integrity/Kconfig | 9 ++
security/integrity/Makefile | 3 +
.../integrity/platform_certs/load_powerpc.c | 94 +++++++++++++++++++
3 files changed, 106 insertions(+)
create mode 100644 security/integrity/platform_certs/load_powerpc.c
@@ -0,0 +1,94 @@+// SPDX-License-Identifier: GPL-2.0+/*+*Copyright(C)2019IBMCorporation+*Author:NaynaJain<nayna@linux.ibm.com>+*+*load_powernv.c+*-loadskeysandcertsstoredandcontrolled+*bythefirmware.+*/+#include<linux/kernel.h>+#include<linux/sched.h>+#include<linux/cred.h>+#include<linux/err.h>+#include<linux/slab.h>+#include<asm/secboot.h>+#include<asm/secvar.h>+#include"keyring_handler.h"++staticstructsecvar_operations*secvarops;++/*+*GetacertificatelistblobfromthenamedEFIvariable.+*/+static__initvoid*get_cert_list(u8*key,unsignedlongkeylen,+unsignedlong*size)+{+intrc;+void*db;++rc=secvarops->get_variable(key,keylen,NULL,size);+if(rc){+pr_err("Couldn't get size: %d\n",rc);+returnNULL;+}++db=kmalloc(*size,GFP_KERNEL);+if(!db)+returnNULL;++rc=secvarops->get_variable(key,keylen,db,size);+if(rc){+kfree(db);+pr_err("Error reading db var: %d\n",rc);+returnNULL;+}++returndb;+}++/*+*LoadthecertscontainedintheUEFIdatabasesintotheplatformtrusted+*keyringandtheUEFIblacklistedX.509certSHA256hashesintotheblacklist+*keyring.+*/+staticint__initload_powerpc_certs(void)+{+void*db=NULL,*dbx=NULL;+unsignedlongdbsize=0,dbxsize=0;+intrc=0;++secvarops=get_secvar_ops();+if(!secvarops)+return-ENOENT;++/* Get db, and dbx. They might not exist, so it isn't+*anerrorifwecan'tgetthem.+*/+db=get_cert_list("db",3,&dbsize);+if(!db){+pr_err("Couldn't get db list from OPAL\n");+}else{+rc=parse_efi_signature_list("OPAL:db",+db,dbsize,get_handler_for_db);+if(rc)+pr_err("Couldn't parse db signatures: %d\n",+rc);+kfree(db);+}++dbx=get_cert_list("dbx",3,&dbxsize);+if(!dbx){+pr_info("Couldn't get dbx list from OPAL\n");+}else{+rc=parse_efi_signature_list("OPAL:dbx",+dbx,dbxsize,+get_handler_for_dbx);+if(rc)+pr_err("Couldn't parse dbx signatures: %d\n",rc);+kfree(dbx);+}++returnrc;+}+late_initcall(load_powerpc_certs);
@@ -0,0 +1,27 @@+What: /sys/firmware/secvar+Date: August 2019+Contact: Nayna Jain <nayna@linux.ibm.com>+Description:+ This directory exposes interfaces for interacting with+ the secure variables managed by OPAL firmware.++ This is only for the powerpc/powernv platform.++ Directory:+ vars: This directory lists all the variables that+ are supported by the OPAL. The variables are+ represented in the form of directories with+ their variable names. The variable name is+ unique and is in ASCII representation. The data+ and size can be determined by reading their+ respective attribute files.++ Each variable directory has the following files:+ name: An ASCII representation of the variable name+ data: A read-only file containing the value of the+ variable+ size: An integer representation of the size of the+ content of the variable. In other works, it+ represents the size of the data+ update: A write-only file that is used to submit the new+ value for the variable.
Can you break this out into one-entry-per-file like most other entries
are defined? That makes it easier for tools to parse (specifically the
tool in the tree right now...)
@@ -925,6 +925,15 @@ config PPC_SECURE_BOOTallowsusertoenableOSSecureBootonPowerPCsystemsthathavefirmwaresecurebootsupport.+configSECVAR_SYSFS+tristate"Enable sysfs interface for POWER secure variables"+depends onPPC_SECURE_BOOT
No depends on SYSFS?
+ help
+ POWER secure variables are managed and controlled by firmware.
+ These variables are exposed to userspace via sysfs to enable
+ read/write operations on these variables. Say Y if you have
+ secure boot enabled and want to expose variables to userspace.
@@ -0,0 +1,210 @@+// SPDX-License-Identifier: GPL-2.0++/*+*Copyright(C)2019IBMCorporation<nayna@linux.ibm.com>+*+*Thiscodeexposessecurevariablestouserviasysfs+*/++#include<linux/module.h>+#include<linux/slab.h>+#include<linux/compat.h>+#include<linux/string.h>+#include<asm/opal.h>+#include<asm/secvar.h>++//Approximating it for now, it is bound to change.
You just raced userspace and lost :(
If you set your kobj_type to have the attribute group you will not race
and loose, the core will handle it for you.
On Wed, Aug 21, 2019 at 11:08:23AM -0400, Nayna Jain wrote:
quoted hunk
The keys used to verify the Host OS kernel are managed by OPAL as secure
variables. This patch loads the verification keys into the .platform
keyring and revocation keys into .blacklist keyring. This enables
verification and loading of the kernels signed by the boot time keys which
are trusted by firmware.
Signed-off-by: Nayna Jain <nayna@linux.ibm.com>
---
security/integrity/Kconfig | 9 ++
security/integrity/Makefile | 3 +
.../integrity/platform_certs/load_powerpc.c | 94 +++++++++++++++++++
3 files changed, 106 insertions(+)
create mode 100644 security/integrity/platform_certs/load_powerpc.c
@@ -72,6 +72,15 @@ config LOAD_IPL_KEYSdepends onS390def_booly+configLOAD_PPC_KEYS+bool"Enable loading of platform and revocation keys for POWER"+depends onINTEGRITY_PLATFORM_KEYRING+depends onPPC_SECURE_BOOT+def_booly
def_bool y only for things that the system will not boot if it is not
enabled because you added a new feature. Otherwise just do not set the
default.
quoted hunk
+ help
+ Enable loading of db keys to the .platform keyring and dbx keys to
+ the .blacklist keyring for powerpc based platforms.
+
config INTEGRITY_AUDIT
bool "Enables integrity auditing support "
depends on AUDIT
That's not the name of this file :(
And the perfect example of why you NEVER have the name of the file in
the file itself, as it's not needed and easy to get wrong :)
thanks,
greg k-h
Everything in asm/opal.h is intended for consumption by the kernel, so
use a useful kernel type (or annotation) rather than blank uint64_t for
the parameters that are actually pointers. You should also ditch the k_
prefix since it doesn't make much sense having it inside the kernel.
As a general comment, don't use extern on function prototypes. They're
extern by default and, more importantly, it's contrary to the normal
kernel style.
+
+struct secvar_operations {
+ int (*get_variable)(const char *key, unsigned long key_len, u8 *data,
+ unsigned long *data_size);
+ int (*get_next_variable)(const char *key, unsigned long *key_len,
+ unsigned long keysize);
+ int (*set_variable)(const char *key, unsigned long key_len, u8 *data,
+ unsigned long data_size);
+};
Calling them requires writing code like:
secvar_ops->get_variable(blah);
Why not shorten it to:
secvar_ops->get(blah);
+ pr_err("OPAL doesn't support secure variables\n");
This should only print an error if OPAL has advertised support for
secure variables through the DT, but doesn't support the OPAL
calls. Otherwise we'll get a spurious error message on any system
running currently released firmware.
+ opal_secvar_supported = false;
+ } else {
+ opal_secvar_supported = true;
+ }
+
+ initialized = true;
+
+ return opal_secvar_supported;
+}
+
+static int opal_get_variable(const char *key, unsigned long ksize,
+ u8 *data, unsigned long *dsize)
+{
+ int rc;
+
+ if (!is_opal_secvar_supported())
+ return OPAL_UNSUPPORTED;
This should be -ENXIO or -ENOSUPP. OPAL_UNSUPPORTED is an OPAL return
code, not a kernel one. That said, if the firmware doesn't support
secure variables we should never be calling this function anyway since
the ops pointer is never set.
+
+ if (dsize)
+ *dsize = cpu_to_be64(*dsize);
+
+ rc = opal_secvar_get(__pa(key), ksize,
+ __pa(data), __pa(dsize));
+
+ if (dsize)
+ *dsize = be64_to_cpu(*dsize);
+
+ return rc;
+}
+
+static int opal_get_next_variable(const char *key, unsigned long *keylen,
+ unsigned long keysize)
+{
+ int rc;
+
+ if (!is_opal_secvar_supported())
+ return OPAL_UNSUPPORTED;
+
+ if (keylen)
+ *keylen = cpu_to_be64(*keylen);
+
+ rc = opal_secvar_get_next(__pa(key), __pa(keylen), keysize);
+
+ if (keylen)
+ *keylen = be64_to_cpu(*keylen);
+
+ return rc;
+}
+
+static int opal_set_variable(const char *key, unsigned long ksize, u8 *data,
+ unsigned long dsize)
+{
+ int rc;
+
+ if (!is_opal_secvar_supported())
+ return OPAL_UNSUPPORTED;
+
+ rc = opal_secvar_enqueue_update(__pa(key), ksize, __pa(data), dsize);
+
+ return rc;
+}
+
@@ -988,6 +990,9 @@ static int __init opal_init(void)/* Initialise OPAL Power control interface */opal_power_control_init();+if(is_powerpc_secvar_supported())+secvar_init();+
The usual pattern here is to have the init function check for support
internally.
Also, is_powerpc_secvar_supported() doesn't appear to be defined
anywhere. Is that supposed to be is_opal_secvar_supported()? Or is this
series supposed to be applied on top of another series?
From: Oliver O'Halloran <oohall@gmail.com> Date: 2019-08-22 05:18:35
On Wed, 2019-08-21 at 11:08 -0400, Nayna Jain wrote:
quoted hunk
PowerNV secure variables, which store the keys used for OS kernel
verification, are managed by the firmware. These secure variables need to
be accessed by the userspace for addition/deletion of the certificates.
This patch adds the sysfs interface to expose secure variables for PowerNV
secureboot. The users shall use this interface for manipulating
the keys stored in the secure variables.
Signed-off-by: Nayna Jain <nayna@linux.ibm.com>
---
Documentation/ABI/testing/sysfs-secvar | 27 ++++
arch/powerpc/Kconfig | 9 ++
arch/powerpc/kernel/Makefile | 1 +
arch/powerpc/kernel/secvar-sysfs.c | 210 +++++++++++++++++++++++++
4 files changed, 247 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-secvar
create mode 100644 arch/powerpc/kernel/secvar-sysfs.c
@@ -0,0 +1,27 @@+What: /sys/firmware/secvar+Date: August 2019+Contact: Nayna Jain <nayna@linux.ibm.com>+Description:+ This directory exposes interfaces for interacting with+ the secure variables managed by OPAL firmware.++ This is only for the powerpc/powernv platform.++ Directory:+ vars: This directory lists all the variables that+ are supported by the OPAL. The variables are+ represented in the form of directories with+ their variable names. The variable name is+ unique and is in ASCII representation. The data+ and size can be determined by reading their+ respective attribute files.++ Each variable directory has the following files:+ name: An ASCII representation of the variable name+ data: A read-only file containing the value of the+ variable+ size: An integer representation of the size of the+ content of the variable. In other works, it+ represents the size of the data+ update: A write-only file that is used to submit the new+ value for the variable.
@@ -0,0 +1,210 @@+// SPDX-License-Identifier: GPL-2.0++/*+*Copyright(C)2019IBMCorporation<nayna@linux.ibm.com>+*+*Thiscodeexposessecurevariablestouserviasysfs+*/++#include<linux/module.h>+#include<linux/slab.h>+#include<linux/compat.h>+#include<linux/string.h>+#include<asm/opal.h>+#include<asm/secvar.h>++//Approximating it for now, it is bound to change.+#define VARIABLE_MAX_SIZE 32000
this needs to be communicated from the secvar backend, maybe via a
field in the ops structure?
+
+static struct kobject *powerpc_kobj;
Call it secvar_kobj or something.
+static struct secvar_operations *secvarops;
Ah, the old I-can't-believe-it's-not-global trick.
Where'd the 1024 restriction on the length of the variable name come
from? is that enforced by firmware? If so, how does firmware
communicate the limited key length?
+
+ do {
+
+ status = secvarops->get_next_variable(name, &namesize, 1024);
does namesize need to be initialised for the first call?
+ if (status != OPAL_SUCCESS)
+ break;
You might want to differentiate between the error case and the "no
extra variables" case. Come to think of it, since the point of
abstracting secvar ops is to make this code indepdendent of the backend
why are we checking for OPAL_SUCCESS? The ops functions should be
returning linux return code (EIO, etc) rather than OPAL codes.
Not having secvar support isn't an error. IMO checking if the ops are
defined is the first thing you should be doing. If we don't have a
defined set of ops then we don't need to do anything else.
@@ -988,6 +990,9 @@ static int __init opal_init(void)/* Initialise OPAL Power control interface */opal_power_control_init();+if(is_powerpc_secvar_supported())+secvar_init();+
The usual pattern here is to have the init function check for support
internally.
Also, is_powerpc_secvar_supported() doesn't appear to be defined
anywhere. Is that supposed to be is_opal_secvar_supported()? Or is this
series supposed to be applied on top of another series?
To answer my own question, yes it depends on the series at [1] which
adds IMA support. Turns out actually reading the cover letter helps,
who knew.
That said, I'm still not entirely sure about this. The implementation
of is_powerpc_secvar_supported() in [2] parses the DT and seems to
assume the DT bindings that OPAL produces. Are those common with the
DT bindings produced by OF when running on pseries?
[1] http://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=125961
[2] http://patchwork.ozlabs.org/patch/1149257/
@@ -0,0 +1,27 @@+What: /sys/firmware/secvar+Date: August 2019+Contact: Nayna Jain<nayna@linux.ibm.com>+Description:+ This directory exposes interfaces for interacting with+ the secure variables managed by OPAL firmware.++ This is only for the powerpc/powernv platform.++ Directory:+ vars: This directory lists all the variables that+ are supported by the OPAL. The variables are+ represented in the form of directories with+ their variable names. The variable name is+ unique and is in ASCII representation. The data+ and size can be determined by reading their+ respective attribute files.++ Each variable directory has the following files:+ name: An ASCII representation of the variable name+ data: A read-only file containing the value of the+ variable+ size: An integer representation of the size of the+ content of the variable. In other works, it+ represents the size of the data+ update: A write-only file that is used to submit the new+ value for the variable.
Can you break this out into one-entry-per-file like most other entries
are defined? That makes it easier for tools to parse (specifically the
tool in the tree right now...)
@@ -925,6 +925,15 @@ config PPC_SECURE_BOOTallowsusertoenableOSSecureBootonPowerPCsystemsthathavefirmwaresecurebootsupport.+configSECVAR_SYSFS+tristate"Enable sysfs interface for POWER secure variables"+depends onPPC_SECURE_BOOT
No depends on SYSFS?
quoted
+ help
+ POWER secure variables are managed and controlled by firmware.
+ These variables are exposed to userspace via sysfs to enable
+ read/write operations on these variables. Say Y if you have
+ secure boot enabled and want to expose variables to userspace.
@@ -0,0 +1,210 @@+// SPDX-License-Identifier: GPL-2.0++/*+*Copyright(C)2019IBMCorporation<nayna@linux.ibm.com>+*+*Thiscodeexposessecurevariablestouserviasysfs+*/++#include<linux/module.h>+#include<linux/slab.h>+#include<linux/compat.h>+#include<linux/string.h>+#include<asm/opal.h>+#include<asm/secvar.h>++//Approximating it for now, it is bound to change.
You just raced userspace and lost :(
If you set your kobj_type to have the attribute group you will not race
and loose, the core will handle it for you.
Do not be noisy when all goes just fine. The kernel log should be quiet
when all goes well.
Thanks Greg for feedback. I just posted v3 version with the fixes
suggested by you and Oliver.
Currently, the name length as 1024 is taken from examples of efivars.
Probably a smaller one is fine.
In v3 version, it is still 1024 but made it #define.
Thanks & Regards,
- Nayna
On Wed, 2019-08-21 at 11:08 -0400, Nayna Jain wrote:
quoted
PowerNV secure variables, which store the keys used for OS kernel
verification, are managed by the firmware. These secure variables need to
be accessed by the userspace for addition/deletion of the certificates.
This patch adds the sysfs interface to expose secure variables for PowerNV
secureboot. The users shall use this interface for manipulating
the keys stored in the secure variables.
Signed-off-by: Nayna Jain<nayna@linux.ibm.com>
---
Documentation/ABI/testing/sysfs-secvar | 27 ++++
arch/powerpc/Kconfig | 9 ++
arch/powerpc/kernel/Makefile | 1 +
arch/powerpc/kernel/secvar-sysfs.c | 210 +++++++++++++++++++++++++
4 files changed, 247 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-secvar
create mode 100644 arch/powerpc/kernel/secvar-sysfs.c
@@ -0,0 +1,27 @@+What: /sys/firmware/secvar+Date: August 2019+Contact: Nayna Jain<nayna@linux.ibm.com>+Description:+ This directory exposes interfaces for interacting with+ the secure variables managed by OPAL firmware.++ This is only for the powerpc/powernv platform.++ Directory:+ vars: This directory lists all the variables that+ are supported by the OPAL. The variables are+ represented in the form of directories with+ their variable names. The variable name is+ unique and is in ASCII representation. The data+ and size can be determined by reading their+ respective attribute files.++ Each variable directory has the following files:+ name: An ASCII representation of the variable name+ data: A read-only file containing the value of the+ variable+ size: An integer representation of the size of the+ content of the variable. In other works, it+ represents the size of the data+ update: A write-only file that is used to submit the new+ value for the variable.
@@ -0,0 +1,210 @@+// SPDX-License-Identifier: GPL-2.0++/*+*Copyright(C)2019IBMCorporation<nayna@linux.ibm.com>+*+*Thiscodeexposessecurevariablestouserviasysfs+*/++#include<linux/module.h>+#include<linux/slab.h>+#include<linux/compat.h>+#include<linux/string.h>+#include<asm/opal.h>+#include<asm/secvar.h>++//Approximating it for now, it is bound to change.+#define VARIABLE_MAX_SIZE 32000
this needs to be communicated from the secvar backend, maybe via a
field in the ops structure?
Thanks Oliver, I have just posted v3 version which includes yours and
Greg's feedbacks.
And giving some of the responses here.
Yes for this one, thinking of doing it via device-tree as they will be
fixed values for a particular platform
quoted
+
+static struct kobject *powerpc_kobj;
Call it secvar_kobj or something.
quoted
+static struct secvar_operations *secvarops;
Ah, the old I-can't-believe-it's-not-global trick.
Where'd the 1024 restriction on the length of the variable name come
from? is that enforced by firmware? If so, how does firmware
communicate the limited key length?
It is not enforced by the firmware. Currently, it is sort of agreed upon
value between the firmware and the kernel, and taken from the examples
of efivars. Probably it can be reduced.