Protocolo EFI del entorno de ejecución de confianza
Licencias: Microsoft acepta concederle una licencia sin cargo, libre de regalías a sus Reclamaciones necesarias sobre términos razonables y no discriminatorios únicamente para hacer, usar, vender, ofrecer para venta, importar o distribuir cualquier implementación de esta especificación. Las "reclamaciones necesarias" son las reclamaciones de patentes controladas por Microsoft o propiedad de Microsoft que técnicamente son necesarias para implementar las partes necesarias (que también incluyen los elementos necesarios de partes opcionales) de esta especificación, en las que la funcionalidad que provoca la infracción se describe en detalle y no se hace referencia simplemente en esta Especificación.
Introducción a la versión 1.0
En este documento se especifica un protocolo EFI para interactuar con un entorno de ejecución de confianza (TrEE), que implementa la funcionalidad de TPM 2.0 por un subconjunto de una especificación de biblioteca del módulo 2.0 trusted Platform Module 2.0 de un grupo de computación de confianza (TCG). En este documento también se especifican los requisitos de medición del firmware de la plataforma. El protocolo EFI definido aquí aprovecha en gran medida [TCG06a] y [TCG06b].
2.0 Estructuras y acrónimos de datos
2.1 Estructuras de datos
Como en [TCG06a], todos los valores de datos se representarán en Little-Endian formato. Las cadenas DEBEN representarse como una matriz de bytes ASCII con el carácter más izquierdo colocado en la ubicación de memoria más baja.
2.2 Acrónimos y convenciones
(Para los acrónimos no definidos aquí, consulte [TCG06a])
Entorno de ejecución trEETrusted
El uso de los términos "MUST" y "SHALL" en este documento deben interpretarse de acuerdo con [RFC2119].
3.0 Protocolo EFI TrEE
En esta sección se proporciona una descripción detallada del EFI_TREE_PROTOCOL y el EFI_TREE_SERVICE_BINDING_PROTOCOL. El protocolo TrEE EFI se usa para comunicarse con un TrEE.
3.1 Protocolo de enlace de servicio EFI trEE
En esta sección se define el protocolo de enlace de servicio EFI trEE.
Resumen : el protocolo de enlace de servicio TrEE EFI se usa para localizar dispositivos TrEE compatibles con un controlador del protocolo TrEE EFI y para crear y destruir instancias de controlador secundario del protocolo TrEE EFI que pueden usar el dispositivo TrEE subyacente.
GUID - #define EFI_TREE_SERVICE_BINDING_PROTOCOL_GUID \ {0x4cf01d0a, 0xc48c, 0x4271, 0xa2, 0x2a, 0xad, 0x8e, 0x55, 0x97,\ 0x81, 0x88}
DescripciónUna aplicación (o controlador) que requiere servicios TrEE puede usar uno de los servicios de controlador de protocolo, como BS-LocateHandleBuffer>(), para buscar dispositivos que publiquen un protocolo de enlace de servicio EFI TrEE. Cada dispositivo con un publicado EFI TrEE Service Binding Protocol admite el protocolo EFI TrEE y puede estar disponible para su uso.
Después de una llamada correcta al EFI_TREE_SERVICE_BINDING_PROTOCOL. La función CreateChild(), la instancia secundaria del controlador EFI TrEE Protocol está lista para su uso.
Antes de que una aplicación o controlador EFI finalice la ejecución, cada llamada correcta a la EFI_TREE_SERVICE_BINDING_PROTOCOL. La función CreateChild() debe coincidir con una llamada a la EFI_TREE_SERVICE_BINDING_PROTOCOL. Función DestroyChild().
3.2 Protocolo EFI trEE
Resumen : el protocolo EFI TrEE se usa para comunicarse con un TrEE, para enviar comandos a un TrEE, usarlo para las operaciones de ejecución de confianza y proporcionar acceso al registro de firmware de las medidas extendidas en trEE. El protocolo mantiene un registro de eventos de medidas registrado en trEE con un formato idéntico al registro de eventos TCG 1.2 (consulte [TCG06b]); se conoce como el registro de eventos TCG 1.2 del formato de registro de eventos trEE en esta especificación. Los implementadores pueden crear registros de eventos adicionales con otros formatos, pero esta versión del protocolo no define una manera de recuperarlos.
GUID - #define EFI_TREE_PROTOCOL_GUID \ {0x607f766c, 0x7455, 0x42be, 0x93, 0x0b, 0xe4, 0xd7, 0x6d, 0xb2,\ 0x72, 0x0f}
Estructura de interfaz de protocolo -
typedef struct _EFI_TREE_PROTOCOL {
EFI_TREE_GET_CAPABILITYGetCapability;
EFI_TREE_GET_EVENT_LOGGetEventLog;
EFI_TREE_HASH_LOG_EXTEND_EVENTHashLogExtendEvent;
EFI_TREE_SUBMIT_COMMANDSubmitCommand;
} EFI_TREE_PROTOCOL;
Parámetros
GetCapability |
Este servicio proporciona información sobre las funcionalidades trEE y firmware. |
GetEventLog |
Obtención de un puntero a un registro de eventos de firmware |
HashLogExtendEvent |
Este servicio hará que el controlador EFI TrEE extienda un evento y ,opcionalmente, escriba el evento en el registro trEE. |
SubmitCommand |
Este servicio envía un comando directamente al TrEE. |
Descripción : el EFI_TREE_PROTOCOL abstrae la actividad TrEE. Esta instancia de protocolo proporciona un servicio de arranque y se crea una instancia de como controlador de servicio de arranque.
Los controladores de servicio de arranque se finalizan cuando se llama a ExitBootServices ( ) y se liberan todos los recursos de memoria consumidos por los controladores de servicios de arranque para su uso en el entorno del sistema operativo.
Este servicio de arranque debe crear un evento de EVT_SIGNAL_EXIT_BOOT_SERVICES. El sistema notificará este evento cuando se invoque ExitBootServices ( ).
EVT_SIGNAL_EXIT_BOOT_SERVICES es un evento sincrónico utilizado para asegurarse de que ciertas actividades se producen después de una llamada a una función de interfaz específica; en este caso, es la limpieza que debe realizarse en respuesta a la función ExitBootServices ( ). ExitBootServices ( ) no se puede limpiar en nombre de los controladores que se han cargado en el sistema. Los controladores tienen que hacerlo por sí mismos mediante la creación de un evento cuyo tipo es EVT_SIGNAL_EXIT_BOOT_SERVICES y cuya función de notificación es una función dentro del propio controlador. A continuación, cuando ExitBootServices ( ) ha terminado su limpieza, señala el tipo de evento EVT_SIGNAL_EXIT_BOOT_SERVICES.
Para obtener detalles de implementación sobre cómo se EVT_SIGNAL_EXIT_BOOT_SERVICES crea una instancia de un servicio de arranque como controlador EFI, consulte la sección 6.1 de [UEFI12].
3.3 EFI_TREE_PROTOCOL. GetCapability
La llamada a la función GetCapability de EFI_TREE_PROTOCOL proporciona información de funcionalidad de protocolo e información de estado sobre trEE.
Prototipo
typedef
EFI_STATUS
(EFIAPI *EFI_TREE_GET_CAPABILITY) (
IN EFI_TREE_PROTOCOL *This,
IN OUT TREE_BOOT_SERVICE_CAPABILITY*ProtocolCapability,
);
Parámetros
Éste |
Indica el contexto de llamada. |
ProtocolCapability |
El autor de la llamada asigna memoria para una estructura de TREE_BOOT_SERVICE_CAPABILITY y establece el campo de tamaño en el tamaño de la estructura asignada. El destinatario rellena los campos con la información de funcionalidad del protocolo EFI y la información de estado trEE actual hasta el número de campos que caben dentro del tamaño de la estructura pasada. |
Definiciones relacionadas
typedef struct _TREE_VERSION {
UINT8 Major;
UINT8 Minor;
} TREE_VERSION;
typedef UINT64 EFI_PHYSICAL_ADDRESS;
typedef UINT32 TREE_EVENT_LOG_BITMAP;
typedef UINT32 TREE_EVENT_LOG_FORMAT;
#define TREE_EVENT_LOG_FORMAT_TCG_1_2 0x00000001
typedef struct _TREE_BOOT_SERVICE_CAPABILITY {
UINT8 Size;
TREE_VERSION StructureVersion;
TREE_VERSION ProtocolVersion;
UINT32 HashAlgorithmBitmap;
TREE_EVENT_LOG_BITMAPSupportedEventLogs;
BOOLEAN TrEEPresentFlag;
UINT16MaxCommandSize;
UINT16MaxResponseSize;
UINT32ManufacturerID;
} TREE_BOOT_SERVICE_CAPABILITY;
#define TREE_BOOT_HASH_ALG_SHA1 0x00000001
#define TREE_BOOT_HASH_ALG_SHA256 0x00000002
#define TREE_BOOT_HASH_ALG_SHA384 0x00000004
#define TREE_BOOT_HASH_ALG_SHA512 0x00000008
Tamaño |
Tamaño asignado de la estructura pasada |
StructureVersion |
Versión de la propia estructura TREE_BOOT_SERVICE_CAPABILITY. Para esta versión del protocolo, la versión principal se establecerá en 1 y la versión secundaria se establecerá en 0. |
ProtocolVersion |
Versión del protocolo TrEE. Para esta versión del protocolo, la versión principal se establecerá en 1 y la versión secundaria se establecerá en 0. |
HashAlgorithmBitMap |
Algoritmos hash admitidos |
SupportedEventLogs |
Mapa de bits de los formatos de registro de eventos admitidos (consulte más arriba) |
TrEEPresentFlag |
False = TrEE no presente |
MaxCommandSize |
Tamaño máximo (en bytes) de un comando que se puede enviar al TrEE |
MaxResponseSize |
Tamaño máximo (en bytes) de una respuesta que el TrEE puede proporcionar |
Id.Fabricante |
Id. de proveedor de 4 bytes (consulte la sección [TCG07], "Id. de proveedor de funcionalidades de TPM") |
Descripción
La llamada a función Get Capability de EFI_TREE_PROTOCOL proporciona información de funcionalidad y versión del protocolo EFI, así como información de estado sobre trEE. El autor de la llamada debe establecer el campo Tamaño de la estructura TREE_BOOT_SERVICE_CAPABILITY asignada. Se espera que las versiones futuras de esta llamada de función agreguen campos adicionales a la estructura. El valor Size pasado en permitirá que la función rellene solo los campos para los que el autor de la llamada haya asignado memoria. Por ejemplo:
ProtocolCapability.Size = sizeof(TREE_BOOT_SERVICE_CAPABILITY);
Para esta versión de la especificación:
Si los parámetros This o ProtocolCapability son NULL, la llamada funcional devolverá EFI_INVALID_PARAMETER.
Si protocolCapability.Size sizeof < (TREE_BOOT_SERVICE_CAPABILITY) de entrada, la función establecerá ProtocolCapability.Size igual a sizeof(TREE_BOOT_SERVICE_CAPABILITY) tal como se define en esta especificación y devolverá el código de error EFI_BUFFER_TOO_SMALL, los valores de los campos restantes no se definirán.
Se deben establecer los siguientes valores devueltos:
ProtocolCapability.StructureVersion.Major = 1
ProtocolCapability.StructureVersion.Minor = 0
ProtocolCapability.ProtocolVersion.Major = 1
ProtocolCapability.ProtocolVersion.Minor = 0
Si la plataforma no tiene un TrEE, se deben devolver los siguientes valores:
ProtocolCapability.SupportedEventLogs = 0
ProtocolCapability.HashAlgorithmBitmap = 0
ProtocolCapability.TrEEPresentFlag = FALSE
ProtocolCapability.MaxCommandSize = 0
ProtocolCapability.MaxResponseSize = 0
ProtocolCapability.ManufacturerID = 0
El valor mínimo de MaxCommandSize y MaxResponseSize DEBEN ser 0x500 (o superior) para Windows.
Códigos de estado devueltos
EFI_SUCCESS |
Operación completada correctamente. |
EFI_DEVICE_ERROR |
El comando no se realizó correctamente. La variable ProtocolCapability no se rellenará. |
EFI_INVALID_PARAMETER |
Uno o varios de los parámetros son incorrectos. La variable ProtocolCapability no se rellenará. |
EFI_BUFFER_TOO_SMALL |
La variable ProtocolCapability es demasiado pequeña para contener la respuesta completa. Se rellenará parcialmente (se establecerá el campo Tamaño obligatorio). |
3.4 EFI_TREE_PROTOCOL. GetEventLog
La llamada a la función Get Event Log de EFI_TREE_PROTOCOL permite a un autor de llamada recuperar la dirección de un registro de eventos determinado y su última entrada.
Prototipo
typedef
EFI_STATUS
(EFIAPI *EFI_TREE_GET_EVENT_LOG) (
IN EFI_TREE_PROTOCOL *This,
IN TREE_EVENT_LOG_FORMATEventLogFormat,
OUT EFI_PHYSICAL_ADDRESS*EventLogLocation,
OUT EFI_PHYSICAL_ADDRESS*EventLogLastEntry,
OUT BOOLEAN*EventLogTruncated
);
Parámetros
EventLogFormat |
Tipo del registro de eventos para el que se solicita la información. |
EventLogLocation |
Puntero a la dirección de memoria del registro de eventos. |
EventLogLastEntry |
Si el registro de eventos contiene más de una entrada, se trata de un puntero a la dirección del inicio de la última entrada en la memoria del registro de eventos. Para obtener información sobre los valores que se devuelven en este parámetro en los casos especiales de un registro de eventos vacío o un registro de eventos con una sola entrada, consulte la sección Descripción siguiente. |
EventLogTruncated |
Si falta al menos una entrada en el registro de eventos porque un evento habría superado el área asignada para los eventos, este valor se establece en TRUE. De lo contrario, el valor será FALSE y se completará el registro de eventos. |
Descripción
El firmware administra un registro de eventos de las medidas registradas en trEE durante el proceso de arranque. Durante el proceso de arranque, antes de la inicialización de la plataforma UEFI, se realiza una entrada en el registro de eventos para cada medida extendida en trEE. En el entorno UEFI, cada vez que se realiza una llamada a HashLogExtendEvent para extender una medida en trEE, un evento se registra generalmente en el registro de eventos que contiene la medida extendida. Si el área asignada por firmware para el registro de eventos era demasiado pequeña para contener todos los eventos agregados, la llamada de función indica que el registro de eventos se ha truncado y que faltan entradas. Esta versión de la especificación solo requiere que se mantenga un registro de eventos de medidas SHA1. Las versiones futuras de esta especificación pueden mantener registros de eventos adicionales que admiten algoritmos hash diferentes.
El área registro de eventos devuelta por esta función se libera cuando se llama a ExitBootServices ( ). Los autores de llamadas de este método no deben tener acceso al área después de llamar a ExitBootServices ( ). Para esta versión de la especificación:
Si EventLogFormat no es igual a TREE_EVENT_LOG_FORMAT_TCG_1_2, la llamada de función DEBE devolver EFI_INVALID_PARAMETER.
Si no hay trEE presente la función DEBE establecer los siguientes valores y devolver EFI_SUCCESS:
EventLogLocation = NULL
EventLogLastEntry = NULL
EventLogTruncated = FALSE
El valor EventLogLocation DEBE establecerse en el inicio del formato de registro de eventos especificado en la memoria.
Si el registro de eventos especificado:
no contiene ningún evento y, a continuación, EventLogLastEntry DEBE establecerse en 0.
contiene exactamente una entrada y, a continuación, EventLogLastEntry DEBE establecerse en el mismo valor que EventLogLocation.
contiene más de un evento y, a continuación, EventLogLastEntry DEBE establecerse en la dirección de inicio del último evento del registro de eventos especificado.
Si una llamada anterior a EFI_TREE_PROTOCOL. HashLogExtendEvent devuelto EFI_VOLUME_FULL, EventLogTruncated DEBE establecerse en TRUE; de lo contrario, debe establecerse en FALSE.
Códigos de estado devueltos
EFI_SUCCESS |
Operación completada correctamente. |
EFI_INVALID_PARAMETER |
Uno o varios de los parámetros son incorrectos (por ejemplo, pedir un registro de eventos cuyo formato no se admite). |
3.5 EFI_TREE_PROTOCOL. HashLogExtendEvent
La llamada a la función HashLogExtendEvent de EFI_TREE_PROTOCOL proporciona a los autores de llamadas la oportunidad de ampliar y, opcionalmente, registrar eventos sin necesidad de conocer los comandos de TPM reales. La operación de extensión se producirá incluso si esta función no puede crear una entrada de registro de eventos (por ejemplo, debido a que el registro de eventos está lleno).
Prototipo
typedef
EFI_STATUS
(EFIAPI * EFI_TREE_HASH_LOG_EXTEND_EVENT) (
IN EFI_TREE_PROTOCOL*This,
IN UINT64Flags,
IN EFI_PHYSICAL_ADDRESSDataToHash,
IN UINT64DataToHashLen,
IN TrEE_EVENT*Event,
);
Parámetros
Éste |
Indica el contexto de llamada. |
Marcas |
Mapa de bits que proporciona información adicional (consulte a continuación). |
DataToHash |
Dirección física del inicio del búfer de datos que se va a ser |
Hash. |
|
DataToHashLen |
Longitud en bytes del búfer al que hace referencia DataToHash. |
Evento |
Puntero al búfer de datos que contiene información sobre el evento. |
Definiciones relacionadas
#pragma pack(1)
typedef struct _TrEE_EVENT {
UINT32Size;
TrEE_EVENT_HEADERHeader;
UINT8Event[ANYSIZE_ARRAY];
} TrEE_EVENT;
typedef struct _TrEE_EVENT_HEADER {
UINT32HeaderSize;
UINT16HeaderVersion;
TrEE_PCRINDEXPCRIndex;
TrEE_EVENTTYPEEventType;
} TrEE_EVENT_HEADER;
#pragma pack()
typedef UINT32 TrEE_PCRINDEX;
typedef UINT32 TrEE_EVENTTYPE;
Tamaño |
Tamaño total del evento, incluido el componente Size, el encabezado y los datos del evento . |
HeaderSize |
Tamaño del propio encabezado de evento (sizeof(TrEE_EVENT_HEADER)). |
HeaderVersion |
Versión del encabezado. Para esta versión de esta especificación, el valor será 1. |
PCRIndex |
Índice de la PCR que se extenderá (0 - 23). |
EventType |
Tipo de evento que se extenderá (y, opcionalmente, se registrará). |
Valores de marca
La variable Flags es un mapa de bits que proporciona datos adicionales de la siguiente manera:
#define TREE_EXTEND_ONLY 0x0000000000000001
Este bit se establecerá cuando se extienda un evento, pero no se registre.
#define PE_COFF_IMAGE 0x0000000000000010
Este bit se establecerá cuando la intención sea medir una imagen PE/COFF.
Descripción
La llamada de función de extensión del registro hash de EFI_TREE_PROTOCOL calcula la medida de un búfer de datos (posiblemente que contenga una imagen binaria PE/COFF) y hace que el controlador TrEE extienda la medida. Además, el servicio crea opcionalmente una entrada del registro de eventos y la anexa al registro de eventos para cada formato de registro de eventos admitido por el servicio. El servicio permite que un autor de la llamada use el TrEE sin saber nada sobre comandos trEE específicos.
El uso de esta función para medir imágenes PE/COFF debe realizarse antes de que se hayan aplicado reubicaciones a la imagen. Nota: Tenga cuidado con este método para medir imágenes PE/COFF. Por lo general, las implementaciones que cargan imágenes PE/COFF eliminan datos importantes durante el proceso de carga de la imagen y pueden cambiar la alineación de la sección de imagen en memoria. El resultado neto es calcular el hash de una imagen en memoria no coincide con la medida real de la imagen como se calcula correctamente cuando se carga desde medios de almacenamiento.
Tras la invocación, la función realizará las siguientes acciones:
Si alguno de los parámetros This, DataToHash o Event son NULL, la función DEBE devolver EFI_INVALID_PARAMETER.
Si Event.Size es menor que Event.Header.HeaderSize + sizeof(UINT32), la función DEBE devolver EFI_INVALID_PARAMETER.
Si Event.Header.PCRIndex no es de 0 a 23, ambos incluidos, la función DEBE devolver EFI_INVALID_PARAMETER.
Si el mapa de bits Flags tiene el bit SET de PE_COFF_IMAGE pero la imagen PE/COFF está dañada o no entiende la función DEBE devolver EFI_UNSUPPORTED.
La función permite cualquier valor para el parámetro Event.Header.EventType.
La función DEBE calcular el resumen (medida) de los datos a partir de DataToHash con una longitud de DataToHashLen. Cuando se establece el bit de PE_COFF_IMAGE, la función DEBE calcular la medida de la imagen PE/COFF de acuerdo con la "Medición de una imagen PE/COFF" en el Apéndice A siguiente.
La función DEBE enviar correctamente el comando TPM2_PCR_Extend al TrEE para extender la PCR indicada por Event.Header.PCRIndex con el resumen de medición. Si el comando no se puede enviar correctamente, la función debe devolver EFI_DEVICE_ERROR. Si el firmware admite más algoritmos que SHA1, puede calcular resúmenes mediante otros algoritmos y ampliarlos también.
Si una llamada anterior a esta función devolvió EFI_VOLUME_FULL y el bit de TREE_EXTEND_ONLY se establece en el parámetro Flags, la función DEBE devolver EFI_VOLUME_FULL. (No se intenta agregar la entrada del registro de eventos al registro de eventos).
La función DEBE crear una entrada del registro de eventos TCG de la siguiente manera: (Nota: La estructura TCG_PCR_EVENT se define en [TCG06b] y se considerará byte-aligned).
TCG_PCR_EVENT. PCRIndex = Event.Header.PCRIndex
TCG_PCR_EVENT. EventType = Event.Header.EventType
TCG_PCR_EVENT. Digest = <el resumen de medición SHA1 calculado anteriormente>
TCG_PCR_EVENT. EventSize = Event.Size - sizeof(UINT32) - Event.Header.HeaderSize
TCG_PCR_EVENT. Event = Event.Event (Nota: se trata de una copia de memoria de bytes eventSize)
La función PUEDE crear entradas de registro de eventos similares para otros formatos de registro de eventos admitidos.
Si la entrada del registro de eventos de TCG_PCR_EVENT creada anteriormente no cabe en el área asignada para el registro de eventos TCG 1.2 del formato de registro de eventos TrEE, la función DEBE devolver EFI_VOLUME_FULL.
Si el firmware admite formatos de registro de eventos adicionales y cualquiera de los eventos creados para esos registros de eventos superaría el área asignada para el registro de eventos, la función DEBE devolver EFI_VOLUME_FULL.
La función DEBE anexar los eventos creados a sus registros de eventos correspondientes y el servicio DEBE actualizar su puntero interno al inicio del último evento para cada registro de eventos.
Códigos de estado devueltos.
|
EFI_SUCCESS |
Operación completada correctamente. |
EFI_DEVICE_ERROR |
El comando no se realizó correctamente. |
EFI_VOLUME_FULL |
Se produjo la operación de extensión, pero el evento no se pudo escribir en uno o varios registros de eventos. |
EFI_INVALID_PARAMETER |
Uno o varios de los parámetros son incorrectos. |
EFI_UNSUPPORTED |
No se admite el tipo de imagen PE/COFF. |
3.6 EFI_TREE_PROTOCOL. SubmitCommand
Este servicio permite el envío de comandos al TrEE.
Prototipo
typedef
EFI_STATUS
(EFIAPI *EFI_TREE_SUBMIT_COMMAND) (
IN EFI_TREE_PROTOCOL*This,
IN UINT32InputParameterBlockSize,
IN UINT8*InputParameterBlock,
IN UINT32OutputParameterBlockSize,
IN UINT8*OutputParameterBlock
);
Parámetros
|
Éste |
Indica el contexto de llamada. |
InputParameterBlockSize |
Tamaño del bloque de parámetros de entrada TrEE. |
InputParameterBlock |
Puntero al bloque de parámetros de entrada TrEE. |
OutputParameterBlockSize |
Tamaño del bloque de parámetros de salida TrEE. |
OutputParameterBlock |
Puntero al bloque de parámetros de salida TrEE. |
Descripción
La llamada de función Submit Command de EFI_TREE_PROTOCOL proporciona una funcionalidad de paso a través del autor de la llamada al TrEE del sistema.
El autor de la llamada es responsable de compilar la secuencia de bytes del comando que se enviará al TrEE y también es responsable de interpretar la secuencia de bytes resultante devuelta por el TrEE. Los operandos TrEE dentro y fuera de cada comando TrEE se definen en otro lugar.
Tenga en cuenta que los códigos de estado devueltos reflejan el resultado de la invocación de la función y no el éxito (o error) del comando TrEE subyacente.
El TPM 2.0 no DEBE devolver TPM2_RC_RETRY antes de completar la llamada a ExitBootServices(). (El motivo de este requisito es que el código de retorno bloquearía el proceso de arranque hasta que se pudiera compele el comando TPM).
El TPM 2.0 DEBE tener acceso a su almacenamiento persistente antes de que se complete la llamada a ExitBootServices. Si es posible que la implementación de TPM 2.0 no tenga acceso al almacenamiento persistente después de la llamada a ExitBootServices, póngase en contacto con Microsoft para conocer los requisitos adicionales.
Códigos de estado devueltos
EFI_SUCCESS |
La secuencia de bytes del comando se envió correctamente al dispositivo y se recibió correctamente una respuesta. |
EFI_DEVICE_ERROR |
El comando no se envió correctamente al dispositivo o una respuesta no se recibió correctamente del dispositivo. |
EFI_INVALID_PARAMETER |
Uno o varios de los parámetros son incorrectos. |
EFI_BUFFER_TOO_SMALL |
El bloque de parámetros de salida es demasiado pequeño. |
Referencias
[MSFT08] |
Microsoft Corporation, "Windows Authenticode Portable Executable Signature Format", versión 1.0, 21 de marzo de 2008. |
[RFC2119] |
Bradner, S., "Keywords for Use in RFC to Indicate Requirement Levels", IETF RFC 2119, marzo de 1997. |
[TCG06a] |
Trusted Computing Group, "TCG EFI Protocol", versión 1.20 Revisión 1.00, 9 de junio de 2006. |
[TCG06b] |
Trusted Computing Group, "TCG EFI Platform Specification", versión 1.20 Revisión 1.0, 7 de junio de 2006. |
[TCG07] |
Grupo informático de confianza, "Registro de id. de proveedor de TCG", versión 1.0, revisión 0.1, 31 de agosto de 2007. |
[UEFI12] |
UEFI, "Unified Extensible Firmware Interface Specification", versión 2.3.1 Errata C, |
Junio de 2012. |
Apéndice A: Raíz estática de medidas de confianza
Importante
Apéndice Una implementación de las mediciones de PCR[7] es obligatoria para los sistemas InstantGo.
En un nivel alto, el firmware es responsable de medir los siguientes componentes durante el arranque:
Firmware de la plataforma que contiene o mide los servicios de arranque UEFI y los servicios en tiempo de ejecución de UEFI
Variables relevantes de seguridad asociadas al firmware de la plataforma
Controladores UEFI o aplicaciones de arranque cargados por separado
Variables asociadas a controladores UEFI cargados por separado o aplicaciones de arranque UEFI
Las medidas anteriores se definen mediante la especificación de la Plataforma TCG EFI [TCG06b] Secciones 5.1 - 5.5 y no se hace referencia a más adelante en este documento. Las mediciones en PCR[1] y PCR[3] son opcionales en función de la configuración de la plataforma.
Para Windows, PCR[7] se usa para reflejar la directiva de arranque seguro ueFI 2.3.1. Esta directiva se basa en la autenticación del firmware de todos los componentes de arranque iniciados antes del entorno UEFI y el código de inicialización de la plataforma UEFI (o código de firmware anterior) de forma invariable que registra la información de la directiva de arranque seguro en PCR[7].
Por lo tanto, el firmware de la plataforma que se adhiere a la directiva debe medir los siguientes valores en PCR[7]:
El contenido de la variable PK
El contenido de la variable KEK
El contenido de la variable EFI_IMAGE_SECURITY_DATABASE
El contenido de la variable EFI_IMAGE_SECURITY_DATABASE1
Entradas del EFI_IMAGE_SECURITY_DATABASE que se usan para validar controladores EFI o aplicaciones de arranque EFI en la ruta de acceso de arranque
Contenido de la variable SecureBoot
Debido a lo anterior, las variables de UEFI PK, KEK, EFI_IMAGE_SECURITY_DATABASE, EFI_IMAGE_SECURITY_DATABASE1 y SecureBoot NO se medirán en PCR[3].
Además, si la plataforma proporciona un depurador de firmware que se puede iniciar antes del entorno UEFI, debe registrar este hecho en PCR[7]. Del mismo modo, si la plataforma proporciona un depurador para el entorno UEFI, el inicio del depurador debe registrarse en PCR[7].
Nota de implementación
La función UEFI LoadImage DEBE registrar mediciones en PCR[2] o PCR[4] por eventos descritos en [TCG06b] y también PCR[7] por eventos descritos en la sección "Medición de la configuración de UEFI en PCR[7]" a continuación. Para determinar si una medida de imagen se aplica a PCR[2] o PCR[4], LoadImage DEBE examinar el campo Subsistema en la imagen PE/COFF. Los valores IMAGE_SUBSYSTEM_EFI_BOOT_SERVICE_DRIVER, IMAGE_SUBSYSTEM_EFI_RUNTIME_DRIVER y IMAGE_SUBSYSTEM_EFI_ROM corresponden a PCR[2]. El valor IMAGE_SUBSYSTEM_EFI_APPLICATION corresponde a PCR[4]. Si la imagen cargada es de otro tipo, DEBE grabarse en PCR[4]. Las imágenes que LoadImage no se cargan debido a un error de comprobación de firma (a) o (b) porque la imagen no cumple con la directiva de arranque seguro UEFI 2.3.1 aplicada actualmente no es necesario medirla en una PCR.
Definiciones relacionadas
#define EV_EFI_VARIABLE_DRIVER_CONFIG \
0x80000001 /* Defined in [TCG06b] */
#define EV_EFI_ACTION 0x80000007 /* Defined in [TCG06b] */
#define EV_EFI_VARIABLE_AUTHORITY 0x800000E0
This specification requires a modified TCG structure definition for EFI_VARIABLE_DATA. The revised structure is:
typedef struct {
EFI_GUIDVariableName;
UINT64 UnicodeNameLength; // The TCG Defintion used UINTN
UINT64 VariableDataLength; // The TCG Defintion used UINTN
CHAR16 UnicodeName[1];
INT8 VariableData[1];
} EFI_VARIABLE_DATA;
Medición de una imagen PE/COFF
Al medir una imagen PE/COFF, eventType debe ser tal como se define en [TCG06b] (por ejemplo, al medir una aplicación de arranque EFI, eventType será EV_EFI_BOOT_SERVICES_APPLICATION) y el valor event será el valor de la estructura de EFI_IMAGE_LOAD_EVENT definida en [TCG06b].
El servicio HashLogExtendEvent DEBE aplicar un hash a la imagen PE/COFF de acuerdo con el procedimiento especificado en la sección "Cálculo del hash de imagen PE" de [MSFT08].
Medición de la configuración de UEFI en PCR[7]
Para todos los eventos de valor de variable EFI, eventType se definirá EV_EFI_VARIABLE_DRIVER_CONFIG anterior y el valor del evento será el valor de la estructura de EFI_VARIABLE_DATA definida anteriormente en esta especificación (esta estructura se considerará alineada por bytes). El resumen de medición será el hash SHA-1 de los datos del evento, que es la estructura EFI_VARIABLE_DATA. (Nota: Se trata de un resumen diferente al especificado por [TCG06b].) El EFI_VARIABLE_DATA. El valor UnicodeNameLength es el número de caracteres CHAR16 (no el número de bytes). El EFI_VARIABLE_DATA. El contenido de UnicodeName NO DEBE incluir un terminador NULO. Si la lectura de la variable EFI devuelve EFI_NOT_FOUND, el EFI_VARIABLE_DATA. El campo VariableDataLength DEBE establecerse en cero y EFI_VARIABLE_DATA. El campo VariableData tendrá un tamaño de cero.
Si la plataforma proporciona un modo de depurador de firmware que se puede usar antes del entorno UEFI o si la plataforma proporciona un depurador para el entorno UEFI, la plataforma extenderá un evento de EV_EFI_ACTION tal y como se especifica en [TCG06b] en PCR[7] antes de permitir el uso del depurador. La cadena de evento será "Modo de depuración ueFI". Además, la plataforma DEBE crear una entrada de registro de eventos TCG como se indica a continuación:
TCG_PCR_EVENT. PCRIndex = 7
TCG_PCR_EVENT. EventType = EV_EFI_ACTION
TCG_PCR_EVENT. Digest = <la síntesis SHA-1 del valor de cadena "UEFI Debug Mode" sin el carácter NULL de terminación>
TCG_PCR_EVENT. EventSize = strlen("Modo de depuración de UEFI")
TCG_PCR_EVENT. Evento = "Modo de depuración de UEFI"
La plataforma PUEDE crear entradas de registro de eventos similares para otros formatos de registro de eventos admitidos.
Antes de ejecutar cualquier código no autenticado criptográficamente como proporcionado por el fabricante de la plataforma, el firmware del fabricante de la plataforma DEBE medir los siguientes valores en el orden indicado mediante el tipo de evento EV_EFI_VARIABLE_DRIVER_CONFIG a PCR[7]:
Valor de la variable SecureBoot
Valor de la variable PK
Valor de la variable KEK
Valor de la variable EFI_IMAGE_SECURITY_DATABASE_GUID/EFI_IMAGE_SECURITY_DATABASE
Valor de la variable EFI_IMAGE_SECURITY_DATABASE_GUID/EFI_IMAGE_SECURITY_DATABASE1
Si la plataforma admite el cambio de cualquiera de las siguientes variables de directiva ueFI después de medirlas inicialmente en PCR[7] y antes de que ExitBootServices ( ) se haya completado sin reiniciar incondicionalmente la plataforma, debe medir la variable de nuevo inmediatamente después del cambio. Además, el proceso de actualización normal para establecer cualquiera de las variables UEFI siguientes DEBE producirse antes de la medición inicial en PCR[7] o después de que se haya completado la llamada a ExitBootServices().
Valor de la variable SecureBoot
Valor de la variable PK
Valor de la variable KEK
Valor de la variable EFI_IMAGE_SECURITY_DATABASE_GUID/EFI_IMAGE_SECURITY_DATABASE
Valor de la variable EFI_IMAGE_SECURITY_DATABASE_GUID/EFI_IMAGE_SECURITY_DATABASE1
El sistema medirá el evento de EV_SEPARATOR en PCR[7]. (Esto ocurre al mismo tiempo que el separador se mide a PCR[0] a TRAVÉS de PCR[7].)
Antes de iniciar un controlador EFI o una aplicación de arranque EFI (e independientemente de si el inicio se debe a que el Administrador de arranque EFI elige una imagen de las variables DriverOrder o BootOrder UEFI o una imagen ya iniciada que llama a la función UEFI LoadImage(), el firmware UEFI medirá la entrada en la variable EFI_IMAGE_SECURITY_DATABASE_GUID/EFI_IMAGE_SECURITY_DATABASE que se usó para validar la imagen EFI en PCR[7]. La medida DEBE producirse junto con la carga de la imagen. Para este evento, eventType se EV_EFI_VARIABLE_AUTHORITY y el valor del evento será el valor de la estructura EFI_VARIABLE_DATA (la estructura se define anteriormente en esta especificación con una definición diferente a la especificación TCG). El EFI_VARIABLE_DATA. El valor variableData será el valor EFI_SIGNATURE_DATA del EFI_SIGNATURE_LIST que contenía la autoridad que se usó para validar la imagen y el EFI_VARIABLE_DATA. VariableName se establecerá en EFI_IMAGE_SECURITY_DATABASE_GUID. El EFI_VARIABLE_DATA. UnicodeName se establecerá en el valor de EFI_IMAGE_SECURITY_DATABASE. El valor no incluirá el carácter NULL de terminación.
Antes de iniciar otros controladores EFI o aplicaciones de arranque EFI, el firmware UEFI comprobará si la entrada en la variable EFI_IMAGE_SECURITY_DATABASE_GUID/EFI_IMAGE_SECURITY_DATABASE que valida la imagen EFI se ha medido previamente con el tipo de evento EV_EFI_VARIABLE_AUTHORITY en PCR[7]. Si no lo ha sido, DEBE medirse como se describe en el paso anterior. Si se ha medido anteriormente, NO SE DEBE volver a medir.
Nota
Hay disponible un ejemplo de medición para las mediciones de PCR[7] a petición de Microsoft.