aboutsummaryrefslogtreecommitdiff
path: root/libstb/secvar/Makefile.inc
AgeCommit message (Collapse)AuthorFilesLines
2020-10-01secvar: Clean up makefiles and fix out of tree buildsOliver O'Halloran1-10/+6
The secvar makefiles use $(SRC) in a few places they shouldn't and don't use it in a few places they should. Also drop the _SRCS rules and the pattern substuituion that turns them into _OBJS rules because chaining dependent rules is infuriating at the best of times. Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-03-12Re-license IBM written files as Apache 2.0 OR GPLv2+Stewart Smith1-1/+1
SPDX makes it a simpler diff. I have audited the commit history of each file to ensure that they are exclusively authored by IBM and thus we have the right to relicense. The motivation behind this is twofold: 1) We want to enable experiments with coreboot, which is GPLv2 licensed 2) An upcoming firmware component wants to incorporate code from skiboot and code from the Linux kernel, which is GPLv2 licensed. I have gone through the IBM internal way of gaining approval for this. The following files are not exclusively authored by IBM, so are *not* included in this update (I will be seeking approval from contributors): core/direct-controls.c core/flash.c core/pcie-slot.c external/common/arch_flash_unknown.c external/common/rules.mk external/gard/Makefile external/gard/rules.mk external/opal-prd/Makefile external/pflash/Makefile external/xscom-utils/Makefile hdata/vpd.c hw/dts.c hw/ipmi/ipmi-watchdog.c hw/phb4.c include/cpu.h include/phb4.h include/platform.h libflash/libffs.c libstb/mbedtls/sha512.c libstb/mbedtls/sha512.h platforms/astbmc/barreleye.c platforms/astbmc/garrison.c platforms/astbmc/mihawk.c platforms/astbmc/nicole.c platforms/astbmc/p8dnu.c platforms/astbmc/p8dtu.c platforms/astbmc/p9dsu.c platforms/astbmc/vesnin.c platforms/rhesus/ec/config.h platforms/rhesus/ec/gpio.h platforms/rhesus/gpio.c platforms/rhesus/rhesus.c platforms/astbmc/talos.c platforms/astbmc/romulus.c Signed-off-by: Stewart Smith <stewart@linux.ibm.com> [oliver: fixed up the drift] Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2019-11-12libstb/secvar: Fix makefileOliver O'Halloran1-1/+1
Breaks building on travis since the script does wierd builds. Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2019-11-07libstb/secvar: add secvar api implementationEric Richter1-0/+1
This patch provides the OPAL runtime service frontend for the host OS to retrieve secure variables, and append new ones for processing on the next reboot. These calls operate on the internal abstraction or utilize the platform-provided driver hooks, and therefore this API should not need to be updated to support changes in storage or backend drivers. Included are the following functions: - opal_secvar_get() - opal_secvar_get_next() - opal_secvar_enqueue_update() opal_secvar_get() retrieves the data blob associated with a given key. The data buffer may be set to NULL to only query for variable size. This runtime service only operates on the variable bank. opal_secvar_get_next() can be used to iterate through the list of variable keys in the variable bank. Supplying an empty key (or zero key length) returns the key of the first variable in the variable bank. Supplying a valid key returns the key of the next variable in sequence. opal_secvar_enqueue_update() provides a method for the host OS to submit a new variable for processing on next boot, by appending it to the update bank. As this does not affect the variable bank, appending a variable via this runtime service will not affect the output of the previous set of functions. The update queue is only processed during secvar initialization. Signed-off-by: Eric Richter <erichte@linux.ibm.com> [oliver: style fixes] Signed-off-by: Oliver O'Halloran <oohall@gmail.com> --- V2: - removed opal_secvar_backend, replaced by DT node - removed unnecessary argument casting - all calls return OPAL_RESOURCE if secvar failed to init V3: - remove metadata from API parameters - remove opal_secvar_get_size - change enqueue to replace an update with a repeat name, rather than enqueueing the duplicate - change enqueue to unstage an update matching a key if size is zero - make all key parameters const where possible - rename key_size to key_buf_size in _get_next - fix leaking node when enqueue could not allocate the secvar V4: - enqueue update now uses secvar alloc/realloc - use storage-defined max var size instead of hardcoded constant
2019-11-07libstb/secvar: add secure variable internal abstractionEric Richter1-0/+15
This patch implements a platform-independent abstraction for storing and retrieving secure variables, as required for host OS secure boot. This serves as the main entry point for initializing the in-memory cache of the secure variables, which also kicks off any platform-specific logic that may be needed. This patch also provides core functions for the subsequent patches in this series to utilize. The base secure variable implementation makes use of two types of drivers, to be selected by the platform: "storage" drivers, and "backend" drivers. The storage driver implements the hooks required to write the secure variables to some form of non-volatile memory, and load the variables on boot. The backend driver defines how the variables should be interpreted, and processed. Secure variables are stored in two types of banks, the "variable" bank and the "update" bank. Variables that have been validated and processed are stored in the variable bank. This bank is effectively read-only after the base secvar initialization. Any proposed variable updates are instead stored in the update bank. During secvar initialization, the backend driver processes variables from the update bank, and if valid, adds the new variable to the variable bank. NOTE: The name "backend" is subject to change. It operates more like a scheme, so unless a better name comes along, it will likely change to "scheme" or "schema" in the future. Signed-off-by: Eric Richter <erichte@linux.ibm.com> [oliver: added missing SPDX tags, removed unused definitions, style fixes] Signed-off-by: Oliver O'Halloran <oohall@gmail.com> --- V2: - added secvar device tree node as child of ibm,secureboot - added version and compatible properties to backend driver struct - added secvar_ready flag for the API to detect if secvar initialized successfully - moved pre-process step to after initial variable load - moved flags field from secvar struct to secvar node V3: - remove the metadata secvar field - add probe_secvar() to bump compatible flag - add device tree property for backend-agnostic secure mode setting - remove backend minor version field - remove static data allocation in secvar struct V4: - add alloc_secvar helpers - removed ibm,secureboot version bump to v3 - secvars now store their allocated size seperate from the data size (to permit overallocating) - split device tree functions into their own file - device tree changes: - secvar now a child of ibm,opal - compatible is "ibm,secvar-v1", backend creates its own node - secure-mode is now a boolean os-secure-enforcing property - storage and backends now have their own nodes V5: - removed storage device tree subnode - moved max-var-size to secvar node - added max-var-key-len - fixed SPDX header in include/secvar.h - removed obsolete enum - removed unused devtree wrappers - set secvar status prop earlier V6: - moved os-secureboot-enforcing to ibm,secureboot - set secvar compatible based on backend - removed backend node