| Message ID | 20190328221754.20838-7-erichte@linux.ibm.com |
|---|---|
| State | RFC |
| Headers | show |
| Series | Initial Skiboot Secure Variable Support | expand |
| Context | Check | Description |
|---|---|---|
| snowpatch_ozlabs/apply_patch | warning | Failed to apply on branch master (050d8165ab05b6d9cdf4bfee42d9776969c77029) |
| snowpatch_ozlabs/apply_patch | fail | Failed to apply to any branch |
diff --git a/libstb/secureboot.c b/libstb/secureboot.c index 4f6a301d..a6bc1712 100644 --- a/libstb/secureboot.c +++ b/libstb/secureboot.c @@ -24,6 +24,7 @@ #include <opal-api.h> #include <inttypes.h> #include "secureboot.h" +#include "secvar.h" static const void* hw_key_hash = NULL; static size_t hw_key_hash_size; @@ -83,6 +84,8 @@ void secureboot_init(void) int version; size_t size; + secvar_init(); + node = dt_find_by_path(dt_root, "/ibm,secureboot"); if (!node) { prlog(PR_NOTICE, "secure boot not supported\n");
The secure variable storage needs to be loaded on boot, as the kernel or sysadmins may need to access the secure variables. This is a somewhat temporary initialization spot; it may be better initialized somewhere else. Secure variable access should be independent of firmware secure boot. Signed-off-by: Eric Richter <erichte@linux.ibm.com> --- libstb/secureboot.c | 3 +++ 1 file changed, 3 insertions(+)