2018-05-07 21:02:21 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0+
|
efi_loader: efi variable support
Add EFI variable support, mapping to u-boot environment variables.
Variables are pretty important for setting up boot order, among other
things. If the board supports saveenv, then it will be called in
ExitBootServices() to persist variables set by the efi payload. (For
example, fallback.efi configuring BootOrder and BootXXXX load-option
variables.)
Variables are *not* currently exposed at runtime, post ExitBootServices.
On boards without a dedicated device for storage, which the loaded OS
is not trying to also use, this is rather tricky. One idea, at least
for boards that can persist RAM across reboot, is to keep a "journal"
of modified variables in RAM, and then turn halt into a reboot into
u-boot, plus store variables, plus halt. Whatever the solution, it
likely involves some per-board support.
Mapping between EFI variables and u-boot variables:
efi_$guid_$varname = {attributes}(type)value
For example:
efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported=
"{ro,boot,run}(blob)0000000000000000"
efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_BootOrder=
"(blob)00010000"
The attributes are a comma separated list of these possible
attributes:
+ ro - read-only
+ boot - boot-services access
+ run - runtime access
NOTE: with current implementation, no variables are available after
ExitBootServices, and all are persisted (if possible).
If not specified, the attributes default to "{boot}".
The required type is one of:
+ utf8 - raw utf8 string
+ blob - arbitrary length hex string
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
/*
|
2020-03-19 17:15:18 +00:00
|
|
|
* UEFI runtime variable services
|
efi_loader: efi variable support
Add EFI variable support, mapping to u-boot environment variables.
Variables are pretty important for setting up boot order, among other
things. If the board supports saveenv, then it will be called in
ExitBootServices() to persist variables set by the efi payload. (For
example, fallback.efi configuring BootOrder and BootXXXX load-option
variables.)
Variables are *not* currently exposed at runtime, post ExitBootServices.
On boards without a dedicated device for storage, which the loaded OS
is not trying to also use, this is rather tricky. One idea, at least
for boards that can persist RAM across reboot, is to keep a "journal"
of modified variables in RAM, and then turn halt into a reboot into
u-boot, plus store variables, plus halt. Whatever the solution, it
likely involves some per-board support.
Mapping between EFI variables and u-boot variables:
efi_$guid_$varname = {attributes}(type)value
For example:
efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported=
"{ro,boot,run}(blob)0000000000000000"
efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_BootOrder=
"(blob)00010000"
The attributes are a comma separated list of these possible
attributes:
+ ro - read-only
+ boot - boot-services access
+ run - runtime access
NOTE: with current implementation, no variables are available after
ExitBootServices, and all are persisted (if possible).
If not specified, the attributes default to "{boot}".
The required type is one of:
+ utf8 - raw utf8 string
+ blob - arbitrary length hex string
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
*
|
2020-03-19 17:15:18 +00:00
|
|
|
* Copyright (c) 2017 Rob Clark
|
efi_loader: efi variable support
Add EFI variable support, mapping to u-boot environment variables.
Variables are pretty important for setting up boot order, among other
things. If the board supports saveenv, then it will be called in
ExitBootServices() to persist variables set by the efi payload. (For
example, fallback.efi configuring BootOrder and BootXXXX load-option
variables.)
Variables are *not* currently exposed at runtime, post ExitBootServices.
On boards without a dedicated device for storage, which the loaded OS
is not trying to also use, this is rather tricky. One idea, at least
for boards that can persist RAM across reboot, is to keep a "journal"
of modified variables in RAM, and then turn halt into a reboot into
u-boot, plus store variables, plus halt. Whatever the solution, it
likely involves some per-board support.
Mapping between EFI variables and u-boot variables:
efi_$guid_$varname = {attributes}(type)value
For example:
efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported=
"{ro,boot,run}(blob)0000000000000000"
efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_BootOrder=
"(blob)00010000"
The attributes are a comma separated list of these possible
attributes:
+ ro - read-only
+ boot - boot-services access
+ run - runtime access
NOTE: with current implementation, no variables are available after
ExitBootServices, and all are persisted (if possible).
If not specified, the attributes default to "{boot}".
The required type is one of:
+ utf8 - raw utf8 string
+ blob - arbitrary length hex string
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
*/
|
|
|
|
|
2020-07-14 19:25:28 +00:00
|
|
|
#define LOG_CATEGORY LOGC_EFI
|
|
|
|
|
efi_loader: correct includes in efi_variable.c
'make tests' on an 32bit ARM system leads to
In file included from ../lib/efi_loader/efi_variable.c:9:
../include/malloc.h:364:7: error: conflicting types for ‘memset’
void* memset(void*, int, size_t);
^~~~~~
In file included from ../include/compiler.h:126,
from ../include/env.h:12,
from ../lib/efi_loader/efi_variable.c:8:
../include/linux/string.h:103:15:
note: previous declaration of ‘memset’ was here
extern void * memset(void *,int,__kernel_size_t);
^~~~~~
In file included from ../lib/efi_loader/efi_variable.c:9:
../include/malloc.h:365:7: error: conflicting types for ‘memcpy’
void* memcpy(void*, const void*, size_t);
^~~~~~
In file included from ../include/compiler.h:126,
from ../include/env.h:12,
from ../lib/efi_loader/efi_variable.c:8:
../include/linux/string.h:106:15:
note: previous declaration of ‘memcpy’ was here
extern void * memcpy(void *,const void *,__kernel_size_t);
^~~~~~
Use common.h as first include as recommended by the U-Boot coding style
guide.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-10-26 21:53:48 +00:00
|
|
|
#include <common.h>
|
efi_loader: efi variable support
Add EFI variable support, mapping to u-boot environment variables.
Variables are pretty important for setting up boot order, among other
things. If the board supports saveenv, then it will be called in
ExitBootServices() to persist variables set by the efi payload. (For
example, fallback.efi configuring BootOrder and BootXXXX load-option
variables.)
Variables are *not* currently exposed at runtime, post ExitBootServices.
On boards without a dedicated device for storage, which the loaded OS
is not trying to also use, this is rather tricky. One idea, at least
for boards that can persist RAM across reboot, is to keep a "journal"
of modified variables in RAM, and then turn halt into a reboot into
u-boot, plus store variables, plus halt. Whatever the solution, it
likely involves some per-board support.
Mapping between EFI variables and u-boot variables:
efi_$guid_$varname = {attributes}(type)value
For example:
efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported=
"{ro,boot,run}(blob)0000000000000000"
efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_BootOrder=
"(blob)00010000"
The attributes are a comma separated list of these possible
attributes:
+ ro - read-only
+ boot - boot-services access
+ run - runtime access
NOTE: with current implementation, no variables are available after
ExitBootServices, and all are persisted (if possible).
If not specified, the attributes default to "{boot}".
The required type is one of:
+ utf8 - raw utf8 string
+ blob - arbitrary length hex string
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
#include <efi_loader.h>
|
2020-06-22 16:10:27 +00:00
|
|
|
#include <efi_variable.h>
|
2020-05-10 17:40:03 +00:00
|
|
|
#include <env.h>
|
2019-08-02 15:44:25 +00:00
|
|
|
#include <env_internal.h>
|
efi_loader: correct includes in efi_variable.c
'make tests' on an 32bit ARM system leads to
In file included from ../lib/efi_loader/efi_variable.c:9:
../include/malloc.h:364:7: error: conflicting types for ‘memset’
void* memset(void*, int, size_t);
^~~~~~
In file included from ../include/compiler.h:126,
from ../include/env.h:12,
from ../lib/efi_loader/efi_variable.c:8:
../include/linux/string.h:103:15:
note: previous declaration of ‘memset’ was here
extern void * memset(void *,int,__kernel_size_t);
^~~~~~
In file included from ../lib/efi_loader/efi_variable.c:9:
../include/malloc.h:365:7: error: conflicting types for ‘memcpy’
void* memcpy(void*, const void*, size_t);
^~~~~~
In file included from ../include/compiler.h:126,
from ../include/env.h:12,
from ../lib/efi_loader/efi_variable.c:8:
../include/linux/string.h:106:15:
note: previous declaration of ‘memcpy’ was here
extern void * memcpy(void *,const void *,__kernel_size_t);
^~~~~~
Use common.h as first include as recommended by the U-Boot coding style
guide.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-10-26 21:53:48 +00:00
|
|
|
#include <hexdump.h>
|
2020-07-14 19:25:28 +00:00
|
|
|
#include <log.h>
|
efi_loader: correct includes in efi_variable.c
'make tests' on an 32bit ARM system leads to
In file included from ../lib/efi_loader/efi_variable.c:9:
../include/malloc.h:364:7: error: conflicting types for ‘memset’
void* memset(void*, int, size_t);
^~~~~~
In file included from ../include/compiler.h:126,
from ../include/env.h:12,
from ../lib/efi_loader/efi_variable.c:8:
../include/linux/string.h:103:15:
note: previous declaration of ‘memset’ was here
extern void * memset(void *,int,__kernel_size_t);
^~~~~~
In file included from ../lib/efi_loader/efi_variable.c:9:
../include/malloc.h:365:7: error: conflicting types for ‘memcpy’
void* memcpy(void*, const void*, size_t);
^~~~~~
In file included from ../include/compiler.h:126,
from ../include/env.h:12,
from ../lib/efi_loader/efi_variable.c:8:
../include/linux/string.h:106:15:
note: previous declaration of ‘memcpy’ was here
extern void * memcpy(void *,const void *,__kernel_size_t);
^~~~~~
Use common.h as first include as recommended by the U-Boot coding style
guide.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-10-26 21:53:48 +00:00
|
|
|
#include <malloc.h>
|
2020-04-14 02:51:41 +00:00
|
|
|
#include <rtc.h>
|
2019-01-21 11:43:13 +00:00
|
|
|
#include <search.h>
|
2020-05-10 17:39:52 +00:00
|
|
|
#include <uuid.h>
|
2020-04-21 00:38:17 +00:00
|
|
|
#include <crypto/pkcs7_parser.h>
|
2020-04-14 02:51:41 +00:00
|
|
|
#include <linux/compat.h>
|
2019-11-14 19:57:16 +00:00
|
|
|
#include <u-boot/crc.h>
|
2020-07-14 19:25:28 +00:00
|
|
|
#include <asm/sections.h>
|
2020-04-14 02:51:41 +00:00
|
|
|
|
|
|
|
#ifdef CONFIG_EFI_SECURE_BOOT
|
|
|
|
static u8 pkcs7_hdr[] = {
|
|
|
|
/* SEQUENCE */
|
|
|
|
0x30, 0x82, 0x05, 0xc7,
|
|
|
|
/* OID: pkcs7-signedData */
|
|
|
|
0x06, 0x09, 0x2a, 0x86, 0x48, 0x86, 0xf7, 0x0d, 0x01, 0x07, 0x02,
|
|
|
|
/* Context Structured? */
|
|
|
|
0xa0, 0x82, 0x05, 0xb8,
|
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
|
|
|
* efi_variable_parse_signature - parse a signature in variable
|
|
|
|
* @buf: Pointer to variable's value
|
|
|
|
* @buflen: Length of @buf
|
2020-08-12 00:37:50 +00:00
|
|
|
* @tmpbuf: Pointer to temporary buffer
|
2019-01-18 18:52:05 +00:00
|
|
|
*
|
2020-04-14 02:51:41 +00:00
|
|
|
* Parse a signature embedded in variable's value and instantiate
|
|
|
|
* a pkcs7_message structure. Since pkcs7_parse_message() accepts only
|
|
|
|
* pkcs7's signedData, some header needed be prepended for correctly
|
|
|
|
* parsing authentication data, particularly for variable's.
|
2020-08-12 00:37:50 +00:00
|
|
|
* A temporary buffer will be allocated if needed, and it should be
|
|
|
|
* kept valid during the authentication because some data in the buffer
|
|
|
|
* will be referenced by efi_signature_verify().
|
2019-01-18 18:52:05 +00:00
|
|
|
*
|
2020-04-14 02:51:41 +00:00
|
|
|
* Return: Pointer to pkcs7_message structure on success, NULL on error
|
2019-01-18 18:52:05 +00:00
|
|
|
*/
|
2020-04-14 02:51:41 +00:00
|
|
|
static struct pkcs7_message *efi_variable_parse_signature(const void *buf,
|
2020-08-12 00:37:50 +00:00
|
|
|
size_t buflen,
|
|
|
|
u8 **tmpbuf)
|
2020-04-14 02:51:41 +00:00
|
|
|
{
|
|
|
|
u8 *ebuf;
|
|
|
|
size_t ebuflen, len;
|
|
|
|
struct pkcs7_message *msg;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This is the best assumption to check if the binary is
|
|
|
|
* already in a form of pkcs7's signedData.
|
|
|
|
*/
|
|
|
|
if (buflen > sizeof(pkcs7_hdr) &&
|
|
|
|
!memcmp(&((u8 *)buf)[4], &pkcs7_hdr[4], 11)) {
|
|
|
|
msg = pkcs7_parse_message(buf, buflen);
|
2020-08-12 00:37:50 +00:00
|
|
|
if (IS_ERR(msg))
|
|
|
|
return NULL;
|
|
|
|
return msg;
|
2020-04-14 02:51:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Otherwise, we should add a dummy prefix sequence for pkcs7
|
|
|
|
* message parser to be able to process.
|
|
|
|
* NOTE: EDK2 also uses similar hack in WrapPkcs7Data()
|
|
|
|
* in CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs7VerifyCommon.c
|
|
|
|
* TODO:
|
|
|
|
* The header should be composed in a more refined manner.
|
|
|
|
*/
|
2020-06-09 05:09:34 +00:00
|
|
|
EFI_PRINT("Makeshift prefix added to authentication data\n");
|
2020-04-14 02:51:41 +00:00
|
|
|
ebuflen = sizeof(pkcs7_hdr) + buflen;
|
|
|
|
if (ebuflen <= 0x7f) {
|
2020-06-09 05:09:34 +00:00
|
|
|
EFI_PRINT("Data is too short\n");
|
2020-04-14 02:51:41 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
ebuf = malloc(ebuflen);
|
|
|
|
if (!ebuf) {
|
2020-06-09 05:09:34 +00:00
|
|
|
EFI_PRINT("Out of memory\n");
|
2020-04-14 02:51:41 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
memcpy(ebuf, pkcs7_hdr, sizeof(pkcs7_hdr));
|
|
|
|
memcpy(ebuf + sizeof(pkcs7_hdr), buf, buflen);
|
|
|
|
len = ebuflen - 4;
|
|
|
|
ebuf[2] = (len >> 8) & 0xff;
|
|
|
|
ebuf[3] = len & 0xff;
|
|
|
|
len = ebuflen - 0x13;
|
|
|
|
ebuf[0x11] = (len >> 8) & 0xff;
|
|
|
|
ebuf[0x12] = len & 0xff;
|
|
|
|
|
|
|
|
msg = pkcs7_parse_message(ebuf, ebuflen);
|
|
|
|
|
2020-08-12 00:37:50 +00:00
|
|
|
if (IS_ERR(msg)) {
|
|
|
|
free(ebuf);
|
2020-04-14 02:51:41 +00:00
|
|
|
return NULL;
|
2020-08-12 00:37:50 +00:00
|
|
|
}
|
2020-04-14 02:51:41 +00:00
|
|
|
|
2020-08-12 00:37:50 +00:00
|
|
|
*tmpbuf = ebuf;
|
2020-04-14 02:51:41 +00:00
|
|
|
return msg;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* efi_variable_authenticate - authenticate a variable
|
|
|
|
* @variable: Variable name in u16
|
|
|
|
* @vendor: Guid of variable
|
|
|
|
* @data_size: Size of @data
|
|
|
|
* @data: Pointer to variable's value
|
|
|
|
* @given_attr: Attributes to be given at SetVariable()
|
|
|
|
* @env_attr: Attributes that an existing variable holds
|
|
|
|
* @time: signed time that an existing variable holds
|
|
|
|
*
|
|
|
|
* Called by efi_set_variable() to verify that the input is correct.
|
|
|
|
* Will replace the given data pointer with another that points to
|
|
|
|
* the actual data to store in the internal memory.
|
|
|
|
* On success, @data and @data_size will be replaced with variable's
|
|
|
|
* actual data, excluding authentication data, and its size, and variable's
|
|
|
|
* attributes and signed time will also be returned in @env_attr and @time,
|
|
|
|
* respectively.
|
|
|
|
*
|
2020-05-03 14:29:00 +00:00
|
|
|
* Return: status code
|
2020-04-14 02:51:41 +00:00
|
|
|
*/
|
|
|
|
static efi_status_t efi_variable_authenticate(u16 *variable,
|
|
|
|
const efi_guid_t *vendor,
|
|
|
|
efi_uintn_t *data_size,
|
|
|
|
const void **data, u32 given_attr,
|
|
|
|
u32 *env_attr, u64 *time)
|
|
|
|
{
|
|
|
|
const struct efi_variable_authentication_2 *auth;
|
|
|
|
struct efi_signature_store *truststore, *truststore2;
|
|
|
|
struct pkcs7_message *var_sig;
|
|
|
|
struct efi_image_regions *regs;
|
|
|
|
struct efi_time timestamp;
|
|
|
|
struct rtc_time tm;
|
|
|
|
u64 new_time;
|
2020-08-12 00:37:50 +00:00
|
|
|
u8 *ebuf;
|
2020-07-15 10:40:35 +00:00
|
|
|
enum efi_auth_var_type var_type;
|
2020-04-14 02:51:41 +00:00
|
|
|
efi_status_t ret;
|
|
|
|
|
|
|
|
var_sig = NULL;
|
|
|
|
truststore = NULL;
|
|
|
|
truststore2 = NULL;
|
|
|
|
regs = NULL;
|
2020-08-12 00:37:50 +00:00
|
|
|
ebuf = NULL;
|
2020-04-14 02:51:41 +00:00
|
|
|
ret = EFI_SECURITY_VIOLATION;
|
|
|
|
|
|
|
|
if (*data_size < sizeof(struct efi_variable_authentication_2))
|
|
|
|
goto err;
|
|
|
|
|
|
|
|
/* authentication data */
|
|
|
|
auth = *data;
|
|
|
|
if (*data_size < (sizeof(auth->time_stamp)
|
|
|
|
+ auth->auth_info.hdr.dwLength))
|
|
|
|
goto err;
|
|
|
|
|
|
|
|
if (guidcmp(&auth->auth_info.cert_type, &efi_guid_cert_type_pkcs7))
|
|
|
|
goto err;
|
|
|
|
|
2020-07-01 10:44:00 +00:00
|
|
|
memcpy(×tamp, &auth->time_stamp, sizeof(timestamp));
|
|
|
|
if (timestamp.pad1 || timestamp.nanosecond || timestamp.timezone ||
|
|
|
|
timestamp.daylight || timestamp.pad2)
|
|
|
|
goto err;
|
|
|
|
|
2020-04-14 02:51:41 +00:00
|
|
|
*data += sizeof(auth->time_stamp) + auth->auth_info.hdr.dwLength;
|
|
|
|
*data_size -= (sizeof(auth->time_stamp)
|
|
|
|
+ auth->auth_info.hdr.dwLength);
|
|
|
|
|
|
|
|
memset(&tm, 0, sizeof(tm));
|
|
|
|
tm.tm_year = timestamp.year;
|
|
|
|
tm.tm_mon = timestamp.month;
|
|
|
|
tm.tm_mday = timestamp.day;
|
|
|
|
tm.tm_hour = timestamp.hour;
|
|
|
|
tm.tm_min = timestamp.minute;
|
|
|
|
tm.tm_sec = timestamp.second;
|
|
|
|
new_time = rtc_mktime(&tm);
|
|
|
|
|
|
|
|
if (!efi_secure_boot_enabled()) {
|
|
|
|
/* finished checking */
|
|
|
|
*time = new_time;
|
|
|
|
return EFI_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (new_time <= *time)
|
|
|
|
goto err;
|
|
|
|
|
|
|
|
/* data to be digested */
|
|
|
|
regs = calloc(sizeof(*regs) + sizeof(struct image_region) * 5, 1);
|
|
|
|
if (!regs)
|
|
|
|
goto err;
|
|
|
|
regs->max = 5;
|
|
|
|
efi_image_region_add(regs, (uint8_t *)variable,
|
|
|
|
(uint8_t *)variable
|
|
|
|
+ u16_strlen(variable) * sizeof(u16), 1);
|
|
|
|
efi_image_region_add(regs, (uint8_t *)vendor,
|
|
|
|
(uint8_t *)vendor + sizeof(*vendor), 1);
|
|
|
|
efi_image_region_add(regs, (uint8_t *)&given_attr,
|
|
|
|
(uint8_t *)&given_attr + sizeof(given_attr), 1);
|
|
|
|
efi_image_region_add(regs, (uint8_t *)×tamp,
|
|
|
|
(uint8_t *)×tamp + sizeof(timestamp), 1);
|
|
|
|
efi_image_region_add(regs, (uint8_t *)*data,
|
|
|
|
(uint8_t *)*data + *data_size, 1);
|
|
|
|
|
|
|
|
/* variable's signature list */
|
|
|
|
if (auth->auth_info.hdr.dwLength < sizeof(auth->auth_info))
|
|
|
|
goto err;
|
2020-08-12 00:37:50 +00:00
|
|
|
|
|
|
|
/* ebuf should be kept valid during the authentication */
|
2020-04-14 02:51:41 +00:00
|
|
|
var_sig = efi_variable_parse_signature(auth->auth_info.cert_data,
|
|
|
|
auth->auth_info.hdr.dwLength
|
2020-08-12 00:37:50 +00:00
|
|
|
- sizeof(auth->auth_info),
|
|
|
|
&ebuf);
|
2020-05-07 00:13:18 +00:00
|
|
|
if (!var_sig) {
|
2020-06-09 05:09:34 +00:00
|
|
|
EFI_PRINT("Parsing variable's signature failed\n");
|
2020-04-14 02:51:41 +00:00
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* signature database used for authentication */
|
2020-07-15 10:40:35 +00:00
|
|
|
var_type = efi_auth_var_get_type(variable, vendor);
|
|
|
|
switch (var_type) {
|
|
|
|
case EFI_AUTH_VAR_PK:
|
|
|
|
case EFI_AUTH_VAR_KEK:
|
2020-04-14 02:51:41 +00:00
|
|
|
/* with PK */
|
|
|
|
truststore = efi_sigstore_parse_sigdb(L"PK");
|
|
|
|
if (!truststore)
|
|
|
|
goto err;
|
2020-07-15 10:40:35 +00:00
|
|
|
break;
|
|
|
|
case EFI_AUTH_VAR_DB:
|
|
|
|
case EFI_AUTH_VAR_DBX:
|
2020-04-14 02:51:41 +00:00
|
|
|
/* with PK and KEK */
|
|
|
|
truststore = efi_sigstore_parse_sigdb(L"KEK");
|
|
|
|
truststore2 = efi_sigstore_parse_sigdb(L"PK");
|
|
|
|
if (!truststore) {
|
|
|
|
if (!truststore2)
|
|
|
|
goto err;
|
|
|
|
|
|
|
|
truststore = truststore2;
|
|
|
|
truststore2 = NULL;
|
|
|
|
}
|
2020-07-15 10:40:35 +00:00
|
|
|
break;
|
|
|
|
default:
|
2020-04-14 02:51:41 +00:00
|
|
|
/* TODO: support private authenticated variables */
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* verify signature */
|
2020-07-21 10:35:22 +00:00
|
|
|
if (efi_signature_verify(regs, var_sig, truststore, NULL)) {
|
2020-06-09 05:09:34 +00:00
|
|
|
EFI_PRINT("Verified\n");
|
2020-04-14 02:51:41 +00:00
|
|
|
} else {
|
|
|
|
if (truststore2 &&
|
2020-07-21 10:35:22 +00:00
|
|
|
efi_signature_verify(regs, var_sig, truststore2, NULL)) {
|
2020-06-09 05:09:34 +00:00
|
|
|
EFI_PRINT("Verified\n");
|
2020-04-14 02:51:41 +00:00
|
|
|
} else {
|
2020-06-09 05:09:34 +00:00
|
|
|
EFI_PRINT("Verifying variable's signature failed\n");
|
2020-04-14 02:51:41 +00:00
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* finished checking */
|
2020-06-30 10:02:14 +00:00
|
|
|
*time = new_time;
|
2020-04-14 02:51:41 +00:00
|
|
|
ret = EFI_SUCCESS;
|
|
|
|
|
|
|
|
err:
|
|
|
|
efi_sigstore_free(truststore);
|
|
|
|
efi_sigstore_free(truststore2);
|
|
|
|
pkcs7_free_message(var_sig);
|
2020-08-12 00:37:50 +00:00
|
|
|
free(ebuf);
|
2020-04-14 02:51:41 +00:00
|
|
|
free(regs);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
static efi_status_t efi_variable_authenticate(u16 *variable,
|
|
|
|
const efi_guid_t *vendor,
|
|
|
|
efi_uintn_t *data_size,
|
|
|
|
const void **data, u32 given_attr,
|
|
|
|
u32 *env_attr, u64 *time)
|
|
|
|
{
|
|
|
|
return EFI_SUCCESS;
|
|
|
|
}
|
|
|
|
#endif /* CONFIG_EFI_SECURE_BOOT */
|
|
|
|
|
2020-07-04 16:34:15 +00:00
|
|
|
efi_status_t __efi_runtime
|
|
|
|
efi_get_variable_int(u16 *variable_name, const efi_guid_t *vendor,
|
|
|
|
u32 *attributes, efi_uintn_t *data_size, void *data,
|
|
|
|
u64 *timep)
|
efi_loader: efi variable support
Add EFI variable support, mapping to u-boot environment variables.
Variables are pretty important for setting up boot order, among other
things. If the board supports saveenv, then it will be called in
ExitBootServices() to persist variables set by the efi payload. (For
example, fallback.efi configuring BootOrder and BootXXXX load-option
variables.)
Variables are *not* currently exposed at runtime, post ExitBootServices.
On boards without a dedicated device for storage, which the loaded OS
is not trying to also use, this is rather tricky. One idea, at least
for boards that can persist RAM across reboot, is to keep a "journal"
of modified variables in RAM, and then turn halt into a reboot into
u-boot, plus store variables, plus halt. Whatever the solution, it
likely involves some per-board support.
Mapping between EFI variables and u-boot variables:
efi_$guid_$varname = {attributes}(type)value
For example:
efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported=
"{ro,boot,run}(blob)0000000000000000"
efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_BootOrder=
"(blob)00010000"
The attributes are a comma separated list of these possible
attributes:
+ ro - read-only
+ boot - boot-services access
+ run - runtime access
NOTE: with current implementation, no variables are available after
ExitBootServices, and all are persisted (if possible).
If not specified, the attributes default to "{boot}".
The required type is one of:
+ utf8 - raw utf8 string
+ blob - arbitrary length hex string
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
{
|
2020-07-23 12:49:49 +00:00
|
|
|
return efi_get_variable_mem(variable_name, vendor, attributes, data_size, data, timep);
|
2019-01-21 11:43:13 +00:00
|
|
|
}
|
|
|
|
|
2020-07-04 16:34:15 +00:00
|
|
|
efi_status_t __efi_runtime
|
|
|
|
efi_get_next_variable_name_int(efi_uintn_t *variable_name_size,
|
|
|
|
u16 *variable_name, efi_guid_t *vendor)
|
efi_loader: efi variable support
Add EFI variable support, mapping to u-boot environment variables.
Variables are pretty important for setting up boot order, among other
things. If the board supports saveenv, then it will be called in
ExitBootServices() to persist variables set by the efi payload. (For
example, fallback.efi configuring BootOrder and BootXXXX load-option
variables.)
Variables are *not* currently exposed at runtime, post ExitBootServices.
On boards without a dedicated device for storage, which the loaded OS
is not trying to also use, this is rather tricky. One idea, at least
for boards that can persist RAM across reboot, is to keep a "journal"
of modified variables in RAM, and then turn halt into a reboot into
u-boot, plus store variables, plus halt. Whatever the solution, it
likely involves some per-board support.
Mapping between EFI variables and u-boot variables:
efi_$guid_$varname = {attributes}(type)value
For example:
efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported=
"{ro,boot,run}(blob)0000000000000000"
efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_BootOrder=
"(blob)00010000"
The attributes are a comma separated list of these possible
attributes:
+ ro - read-only
+ boot - boot-services access
+ run - runtime access
NOTE: with current implementation, no variables are available after
ExitBootServices, and all are persisted (if possible).
If not specified, the attributes default to "{boot}".
The required type is one of:
+ utf8 - raw utf8 string
+ blob - arbitrary length hex string
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
{
|
2020-07-23 12:49:49 +00:00
|
|
|
return efi_get_next_variable_name_mem(variable_name_size, variable_name, vendor);
|
efi_loader: efi variable support
Add EFI variable support, mapping to u-boot environment variables.
Variables are pretty important for setting up boot order, among other
things. If the board supports saveenv, then it will be called in
ExitBootServices() to persist variables set by the efi payload. (For
example, fallback.efi configuring BootOrder and BootXXXX load-option
variables.)
Variables are *not* currently exposed at runtime, post ExitBootServices.
On boards without a dedicated device for storage, which the loaded OS
is not trying to also use, this is rather tricky. One idea, at least
for boards that can persist RAM across reboot, is to keep a "journal"
of modified variables in RAM, and then turn halt into a reboot into
u-boot, plus store variables, plus halt. Whatever the solution, it
likely involves some per-board support.
Mapping between EFI variables and u-boot variables:
efi_$guid_$varname = {attributes}(type)value
For example:
efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported=
"{ro,boot,run}(blob)0000000000000000"
efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_BootOrder=
"(blob)00010000"
The attributes are a comma separated list of these possible
attributes:
+ ro - read-only
+ boot - boot-services access
+ run - runtime access
NOTE: with current implementation, no variables are available after
ExitBootServices, and all are persisted (if possible).
If not specified, the attributes default to "{boot}".
The required type is one of:
+ utf8 - raw utf8 string
+ blob - arbitrary length hex string
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
}
|
|
|
|
|
2020-06-22 16:10:27 +00:00
|
|
|
efi_status_t efi_set_variable_int(u16 *variable_name, const efi_guid_t *vendor,
|
|
|
|
u32 attributes, efi_uintn_t data_size,
|
|
|
|
const void *data, bool ro_check)
|
efi_loader: efi variable support
Add EFI variable support, mapping to u-boot environment variables.
Variables are pretty important for setting up boot order, among other
things. If the board supports saveenv, then it will be called in
ExitBootServices() to persist variables set by the efi payload. (For
example, fallback.efi configuring BootOrder and BootXXXX load-option
variables.)
Variables are *not* currently exposed at runtime, post ExitBootServices.
On boards without a dedicated device for storage, which the loaded OS
is not trying to also use, this is rather tricky. One idea, at least
for boards that can persist RAM across reboot, is to keep a "journal"
of modified variables in RAM, and then turn halt into a reboot into
u-boot, plus store variables, plus halt. Whatever the solution, it
likely involves some per-board support.
Mapping between EFI variables and u-boot variables:
efi_$guid_$varname = {attributes}(type)value
For example:
efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported=
"{ro,boot,run}(blob)0000000000000000"
efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_BootOrder=
"(blob)00010000"
The attributes are a comma separated list of these possible
attributes:
+ ro - read-only
+ boot - boot-services access
+ run - runtime access
NOTE: with current implementation, no variables are available after
ExitBootServices, and all are persisted (if possible).
If not specified, the attributes default to "{boot}".
The required type is one of:
+ utf8 - raw utf8 string
+ blob - arbitrary length hex string
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
{
|
2020-07-04 16:34:15 +00:00
|
|
|
struct efi_var_entry *var;
|
|
|
|
efi_uintn_t ret;
|
2020-04-14 02:51:41 +00:00
|
|
|
bool append, delete;
|
|
|
|
u64 time = 0;
|
2020-07-15 10:40:35 +00:00
|
|
|
enum efi_auth_var_type var_type;
|
efi_loader: efi variable support
Add EFI variable support, mapping to u-boot environment variables.
Variables are pretty important for setting up boot order, among other
things. If the board supports saveenv, then it will be called in
ExitBootServices() to persist variables set by the efi payload. (For
example, fallback.efi configuring BootOrder and BootXXXX load-option
variables.)
Variables are *not* currently exposed at runtime, post ExitBootServices.
On boards without a dedicated device for storage, which the loaded OS
is not trying to also use, this is rather tricky. One idea, at least
for boards that can persist RAM across reboot, is to keep a "journal"
of modified variables in RAM, and then turn halt into a reboot into
u-boot, plus store variables, plus halt. Whatever the solution, it
likely involves some per-board support.
Mapping between EFI variables and u-boot variables:
efi_$guid_$varname = {attributes}(type)value
For example:
efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported=
"{ro,boot,run}(blob)0000000000000000"
efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_BootOrder=
"(blob)00010000"
The attributes are a comma separated list of these possible
attributes:
+ ro - read-only
+ boot - boot-services access
+ run - runtime access
NOTE: with current implementation, no variables are available after
ExitBootServices, and all are persisted (if possible).
If not specified, the attributes default to "{boot}".
The required type is one of:
+ utf8 - raw utf8 string
+ blob - arbitrary length hex string
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
|
2019-06-12 21:28:42 +00:00
|
|
|
if (!variable_name || !*variable_name || !vendor ||
|
|
|
|
((attributes & EFI_VARIABLE_RUNTIME_ACCESS) &&
|
2020-07-04 16:34:15 +00:00
|
|
|
!(attributes & EFI_VARIABLE_BOOTSERVICE_ACCESS)))
|
|
|
|
return EFI_INVALID_PARAMETER;
|
2020-04-14 02:51:41 +00:00
|
|
|
|
|
|
|
/* check if a variable exists */
|
2020-07-04 16:34:15 +00:00
|
|
|
var = efi_var_mem_find(vendor, variable_name, NULL);
|
2020-04-14 02:51:41 +00:00
|
|
|
append = !!(attributes & EFI_VARIABLE_APPEND_WRITE);
|
|
|
|
attributes &= ~(u32)EFI_VARIABLE_APPEND_WRITE;
|
|
|
|
delete = !append && (!data_size || !attributes);
|
efi_loader: efi variable support
Add EFI variable support, mapping to u-boot environment variables.
Variables are pretty important for setting up boot order, among other
things. If the board supports saveenv, then it will be called in
ExitBootServices() to persist variables set by the efi payload. (For
example, fallback.efi configuring BootOrder and BootXXXX load-option
variables.)
Variables are *not* currently exposed at runtime, post ExitBootServices.
On boards without a dedicated device for storage, which the loaded OS
is not trying to also use, this is rather tricky. One idea, at least
for boards that can persist RAM across reboot, is to keep a "journal"
of modified variables in RAM, and then turn halt into a reboot into
u-boot, plus store variables, plus halt. Whatever the solution, it
likely involves some per-board support.
Mapping between EFI variables and u-boot variables:
efi_$guid_$varname = {attributes}(type)value
For example:
efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported=
"{ro,boot,run}(blob)0000000000000000"
efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_BootOrder=
"(blob)00010000"
The attributes are a comma separated list of these possible
attributes:
+ ro - read-only
+ boot - boot-services access
+ run - runtime access
NOTE: with current implementation, no variables are available after
ExitBootServices, and all are persisted (if possible).
If not specified, the attributes default to "{boot}".
The required type is one of:
+ utf8 - raw utf8 string
+ blob - arbitrary length hex string
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
|
2020-04-14 02:51:41 +00:00
|
|
|
/* check attributes */
|
2020-07-14 19:25:28 +00:00
|
|
|
var_type = efi_auth_var_get_type(variable_name, vendor);
|
2020-07-04 16:34:15 +00:00
|
|
|
if (var) {
|
|
|
|
if (ro_check && (var->attr & EFI_VARIABLE_READ_ONLY))
|
|
|
|
return EFI_WRITE_PROTECTED;
|
2019-09-06 06:09:52 +00:00
|
|
|
|
2020-07-14 19:25:28 +00:00
|
|
|
if (IS_ENABLED(CONFIG_EFI_VARIABLES_PRESEED)) {
|
|
|
|
if (var_type != EFI_AUTH_VAR_NONE)
|
|
|
|
return EFI_WRITE_PROTECTED;
|
|
|
|
}
|
|
|
|
|
2019-09-06 06:09:52 +00:00
|
|
|
/* attributes won't be changed */
|
2020-04-14 02:51:41 +00:00
|
|
|
if (!delete &&
|
2020-07-04 16:34:15 +00:00
|
|
|
((ro_check && var->attr != attributes) ||
|
|
|
|
(!ro_check && ((var->attr & ~(u32)EFI_VARIABLE_READ_ONLY)
|
2020-06-22 16:10:27 +00:00
|
|
|
!= (attributes & ~(u32)EFI_VARIABLE_READ_ONLY))))) {
|
2020-07-04 16:34:15 +00:00
|
|
|
return EFI_INVALID_PARAMETER;
|
2019-09-06 06:09:52 +00:00
|
|
|
}
|
2020-07-04 16:34:15 +00:00
|
|
|
time = var->time;
|
2019-09-06 06:09:52 +00:00
|
|
|
} else {
|
2020-07-04 16:34:15 +00:00
|
|
|
if (delete || append)
|
2019-09-26 19:40:18 +00:00
|
|
|
/*
|
|
|
|
* Trying to delete or to update a non-existent
|
|
|
|
* variable.
|
|
|
|
*/
|
2020-07-04 16:34:15 +00:00
|
|
|
return EFI_NOT_FOUND;
|
2020-04-14 02:51:41 +00:00
|
|
|
}
|
|
|
|
|
2020-07-15 10:40:35 +00:00
|
|
|
if (var_type != EFI_AUTH_VAR_NONE) {
|
2020-04-14 02:51:41 +00:00
|
|
|
/* authentication is mandatory */
|
|
|
|
if (!(attributes &
|
|
|
|
EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS)) {
|
2020-07-04 16:34:15 +00:00
|
|
|
EFI_PRINT("%ls: TIME_BASED_AUTHENTICATED_WRITE_ACCESS required\n",
|
2020-06-09 05:09:34 +00:00
|
|
|
variable_name);
|
2020-07-04 16:34:15 +00:00
|
|
|
return EFI_INVALID_PARAMETER;
|
2019-09-06 06:09:52 +00:00
|
|
|
}
|
2020-04-14 02:51:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* authenticate a variable */
|
|
|
|
if (IS_ENABLED(CONFIG_EFI_SECURE_BOOT)) {
|
2020-07-04 16:34:15 +00:00
|
|
|
if (attributes & EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS)
|
|
|
|
return EFI_INVALID_PARAMETER;
|
2020-04-14 02:51:41 +00:00
|
|
|
if (attributes &
|
|
|
|
EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS) {
|
2020-07-04 16:34:15 +00:00
|
|
|
u32 env_attr;
|
|
|
|
|
2020-04-14 02:51:41 +00:00
|
|
|
ret = efi_variable_authenticate(variable_name, vendor,
|
|
|
|
&data_size, &data,
|
2020-07-04 16:34:15 +00:00
|
|
|
attributes, &env_attr,
|
2020-04-14 02:51:41 +00:00
|
|
|
&time);
|
|
|
|
if (ret != EFI_SUCCESS)
|
2020-07-04 16:34:15 +00:00
|
|
|
return ret;
|
2020-04-14 02:51:41 +00:00
|
|
|
|
|
|
|
/* last chance to check for delete */
|
|
|
|
if (!data_size)
|
|
|
|
delete = true;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
if (attributes &
|
|
|
|
(EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS |
|
|
|
|
EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS)) {
|
2020-06-09 05:09:34 +00:00
|
|
|
EFI_PRINT("Secure boot is not configured\n");
|
2020-07-04 16:34:15 +00:00
|
|
|
return EFI_INVALID_PARAMETER;
|
2020-04-14 02:51:41 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (delete) {
|
2020-07-04 16:34:15 +00:00
|
|
|
/* EFI_NOT_FOUND has been handled before */
|
2020-11-02 18:32:24 +00:00
|
|
|
attributes = var->attr;
|
2020-04-14 02:51:41 +00:00
|
|
|
ret = EFI_SUCCESS;
|
2020-07-04 16:34:15 +00:00
|
|
|
} else if (append) {
|
|
|
|
u16 *old_data = var->name;
|
|
|
|
|
|
|
|
for (; *old_data; ++old_data)
|
|
|
|
;
|
|
|
|
++old_data;
|
|
|
|
ret = efi_var_mem_ins(variable_name, vendor, attributes,
|
|
|
|
var->length, old_data, data_size, data,
|
|
|
|
time);
|
2020-04-14 02:51:41 +00:00
|
|
|
} else {
|
2020-07-04 16:34:15 +00:00
|
|
|
ret = efi_var_mem_ins(variable_name, vendor, attributes,
|
|
|
|
data_size, data, 0, NULL, time);
|
efi_loader: efi variable support
Add EFI variable support, mapping to u-boot environment variables.
Variables are pretty important for setting up boot order, among other
things. If the board supports saveenv, then it will be called in
ExitBootServices() to persist variables set by the efi payload. (For
example, fallback.efi configuring BootOrder and BootXXXX load-option
variables.)
Variables are *not* currently exposed at runtime, post ExitBootServices.
On boards without a dedicated device for storage, which the loaded OS
is not trying to also use, this is rather tricky. One idea, at least
for boards that can persist RAM across reboot, is to keep a "journal"
of modified variables in RAM, and then turn halt into a reboot into
u-boot, plus store variables, plus halt. Whatever the solution, it
likely involves some per-board support.
Mapping between EFI variables and u-boot variables:
efi_$guid_$varname = {attributes}(type)value
For example:
efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported=
"{ro,boot,run}(blob)0000000000000000"
efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_BootOrder=
"(blob)00010000"
The attributes are a comma separated list of these possible
attributes:
+ ro - read-only
+ boot - boot-services access
+ run - runtime access
NOTE: with current implementation, no variables are available after
ExitBootServices, and all are persisted (if possible).
If not specified, the attributes default to "{boot}".
The required type is one of:
+ utf8 - raw utf8 string
+ blob - arbitrary length hex string
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
}
|
2020-07-04 16:34:15 +00:00
|
|
|
efi_var_mem_del(var);
|
efi_loader: efi variable support
Add EFI variable support, mapping to u-boot environment variables.
Variables are pretty important for setting up boot order, among other
things. If the board supports saveenv, then it will be called in
ExitBootServices() to persist variables set by the efi payload. (For
example, fallback.efi configuring BootOrder and BootXXXX load-option
variables.)
Variables are *not* currently exposed at runtime, post ExitBootServices.
On boards without a dedicated device for storage, which the loaded OS
is not trying to also use, this is rather tricky. One idea, at least
for boards that can persist RAM across reboot, is to keep a "journal"
of modified variables in RAM, and then turn halt into a reboot into
u-boot, plus store variables, plus halt. Whatever the solution, it
likely involves some per-board support.
Mapping between EFI variables and u-boot variables:
efi_$guid_$varname = {attributes}(type)value
For example:
efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported=
"{ro,boot,run}(blob)0000000000000000"
efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_BootOrder=
"(blob)00010000"
The attributes are a comma separated list of these possible
attributes:
+ ro - read-only
+ boot - boot-services access
+ run - runtime access
NOTE: with current implementation, no variables are available after
ExitBootServices, and all are persisted (if possible).
If not specified, the attributes default to "{boot}".
The required type is one of:
+ utf8 - raw utf8 string
+ blob - arbitrary length hex string
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
|
2020-07-04 16:34:15 +00:00
|
|
|
if (ret != EFI_SUCCESS)
|
|
|
|
return ret;
|
efi_loader: efi variable support
Add EFI variable support, mapping to u-boot environment variables.
Variables are pretty important for setting up boot order, among other
things. If the board supports saveenv, then it will be called in
ExitBootServices() to persist variables set by the efi payload. (For
example, fallback.efi configuring BootOrder and BootXXXX load-option
variables.)
Variables are *not* currently exposed at runtime, post ExitBootServices.
On boards without a dedicated device for storage, which the loaded OS
is not trying to also use, this is rather tricky. One idea, at least
for boards that can persist RAM across reboot, is to keep a "journal"
of modified variables in RAM, and then turn halt into a reboot into
u-boot, plus store variables, plus halt. Whatever the solution, it
likely involves some per-board support.
Mapping between EFI variables and u-boot variables:
efi_$guid_$varname = {attributes}(type)value
For example:
efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported=
"{ro,boot,run}(blob)0000000000000000"
efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_BootOrder=
"(blob)00010000"
The attributes are a comma separated list of these possible
attributes:
+ ro - read-only
+ boot - boot-services access
+ run - runtime access
NOTE: with current implementation, no variables are available after
ExitBootServices, and all are persisted (if possible).
If not specified, the attributes default to "{boot}".
The required type is one of:
+ utf8 - raw utf8 string
+ blob - arbitrary length hex string
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
|
2020-07-15 10:40:35 +00:00
|
|
|
if (var_type == EFI_AUTH_VAR_PK)
|
2020-07-04 16:34:15 +00:00
|
|
|
ret = efi_init_secure_state();
|
|
|
|
else
|
|
|
|
ret = EFI_SUCCESS;
|
efi_loader: efi variable support
Add EFI variable support, mapping to u-boot environment variables.
Variables are pretty important for setting up boot order, among other
things. If the board supports saveenv, then it will be called in
ExitBootServices() to persist variables set by the efi payload. (For
example, fallback.efi configuring BootOrder and BootXXXX load-option
variables.)
Variables are *not* currently exposed at runtime, post ExitBootServices.
On boards without a dedicated device for storage, which the loaded OS
is not trying to also use, this is rather tricky. One idea, at least
for boards that can persist RAM across reboot, is to keep a "journal"
of modified variables in RAM, and then turn halt into a reboot into
u-boot, plus store variables, plus halt. Whatever the solution, it
likely involves some per-board support.
Mapping between EFI variables and u-boot variables:
efi_$guid_$varname = {attributes}(type)value
For example:
efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported=
"{ro,boot,run}(blob)0000000000000000"
efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_BootOrder=
"(blob)00010000"
The attributes are a comma separated list of these possible
attributes:
+ ro - read-only
+ boot - boot-services access
+ run - runtime access
NOTE: with current implementation, no variables are available after
ExitBootServices, and all are persisted (if possible).
If not specified, the attributes default to "{boot}".
The required type is one of:
+ utf8 - raw utf8 string
+ blob - arbitrary length hex string
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
|
2020-03-19 18:21:58 +00:00
|
|
|
/* Write non-volatile EFI variables to file */
|
|
|
|
if (attributes & EFI_VARIABLE_NON_VOLATILE &&
|
|
|
|
ret == EFI_SUCCESS && efi_obj_list_initialized == EFI_SUCCESS)
|
|
|
|
efi_var_to_file();
|
|
|
|
|
2020-07-04 16:34:15 +00:00
|
|
|
return EFI_SUCCESS;
|
2020-04-14 02:51:41 +00:00
|
|
|
}
|
|
|
|
|
2020-06-26 15:57:48 +00:00
|
|
|
efi_status_t efi_query_variable_info_int(u32 attributes,
|
|
|
|
u64 *maximum_variable_storage_size,
|
|
|
|
u64 *remaining_variable_storage_size,
|
|
|
|
u64 *maximum_variable_size)
|
|
|
|
{
|
2020-07-04 16:34:15 +00:00
|
|
|
*maximum_variable_storage_size = EFI_VAR_BUF_SIZE -
|
|
|
|
sizeof(struct efi_var_file);
|
|
|
|
*remaining_variable_storage_size = efi_var_mem_free();
|
|
|
|
*maximum_variable_size = EFI_VAR_BUF_SIZE -
|
|
|
|
sizeof(struct efi_var_file) -
|
|
|
|
sizeof(struct efi_var_entry);
|
|
|
|
return EFI_SUCCESS;
|
2020-06-26 15:57:48 +00:00
|
|
|
}
|
|
|
|
|
2019-06-20 10:13:05 +00:00
|
|
|
/**
|
2020-06-26 15:57:48 +00:00
|
|
|
* efi_query_variable_info_runtime() - runtime implementation of
|
|
|
|
* QueryVariableInfo()
|
2019-06-20 10:13:05 +00:00
|
|
|
*
|
|
|
|
* @attributes: bitmask to select variables to be
|
|
|
|
* queried
|
|
|
|
* @maximum_variable_storage_size: maximum size of storage area for the
|
|
|
|
* selected variable types
|
|
|
|
* @remaining_variable_storage_size: remaining size of storage are for the
|
|
|
|
* selected variable types
|
|
|
|
* @maximum_variable_size: maximum size of a variable of the
|
|
|
|
* selected type
|
|
|
|
* Returns: status code
|
|
|
|
*/
|
2020-06-26 15:57:48 +00:00
|
|
|
efi_status_t __efi_runtime EFIAPI efi_query_variable_info_runtime(
|
2019-06-20 10:13:05 +00:00
|
|
|
u32 attributes,
|
|
|
|
u64 *maximum_variable_storage_size,
|
|
|
|
u64 *remaining_variable_storage_size,
|
|
|
|
u64 *maximum_variable_size)
|
|
|
|
{
|
|
|
|
return EFI_UNSUPPORTED;
|
|
|
|
}
|
2019-06-20 11:52:16 +00:00
|
|
|
|
2019-06-20 13:25:48 +00:00
|
|
|
/**
|
|
|
|
* efi_set_variable_runtime() - runtime implementation of SetVariable()
|
2019-07-14 10:11:16 +00:00
|
|
|
*
|
|
|
|
* @variable_name: name of the variable
|
|
|
|
* @vendor: vendor GUID
|
|
|
|
* @attributes: attributes of the variable
|
|
|
|
* @data_size: size of the buffer with the variable value
|
|
|
|
* @data: buffer with the variable value
|
|
|
|
* Return: status code
|
2019-06-20 13:25:48 +00:00
|
|
|
*/
|
|
|
|
static efi_status_t __efi_runtime EFIAPI
|
|
|
|
efi_set_variable_runtime(u16 *variable_name, const efi_guid_t *vendor,
|
|
|
|
u32 attributes, efi_uintn_t data_size,
|
|
|
|
const void *data)
|
|
|
|
{
|
|
|
|
return EFI_UNSUPPORTED;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* efi_variables_boot_exit_notify() - notify ExitBootServices() is called
|
|
|
|
*/
|
|
|
|
void efi_variables_boot_exit_notify(void)
|
|
|
|
{
|
2020-03-19 18:21:58 +00:00
|
|
|
/* Switch variable services functions to runtime version */
|
2019-06-20 13:25:48 +00:00
|
|
|
efi_runtime_services.get_variable = efi_get_variable_runtime;
|
|
|
|
efi_runtime_services.get_next_variable_name =
|
|
|
|
efi_get_next_variable_name_runtime;
|
|
|
|
efi_runtime_services.set_variable = efi_set_variable_runtime;
|
2020-06-26 15:57:48 +00:00
|
|
|
efi_runtime_services.query_variable_info =
|
|
|
|
efi_query_variable_info_runtime;
|
2019-06-20 13:25:48 +00:00
|
|
|
efi_update_table_header_crc32(&efi_runtime_services.hdr);
|
|
|
|
}
|
|
|
|
|
2019-06-20 11:52:16 +00:00
|
|
|
/**
|
|
|
|
* efi_init_variables() - initialize variable services
|
|
|
|
*
|
|
|
|
* Return: status code
|
|
|
|
*/
|
|
|
|
efi_status_t efi_init_variables(void)
|
|
|
|
{
|
2020-04-14 02:51:42 +00:00
|
|
|
efi_status_t ret;
|
|
|
|
|
2020-07-04 16:34:15 +00:00
|
|
|
ret = efi_var_mem_init();
|
|
|
|
if (ret != EFI_SUCCESS)
|
|
|
|
return ret;
|
|
|
|
|
2020-07-14 19:25:28 +00:00
|
|
|
if (IS_ENABLED(CONFIG_EFI_VARIABLES_PRESEED)) {
|
|
|
|
ret = efi_var_restore((struct efi_var_file *)
|
|
|
|
__efi_var_file_begin);
|
|
|
|
if (ret != EFI_SUCCESS)
|
|
|
|
log_err("Invalid EFI variable seed\n");
|
|
|
|
}
|
|
|
|
|
2020-08-13 08:05:29 +00:00
|
|
|
ret = efi_var_from_file();
|
|
|
|
if (ret != EFI_SUCCESS)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
return efi_init_secure_state();
|
2019-06-20 11:52:16 +00:00
|
|
|
}
|