| Message ID | afe88d0bbab0fbed289cceceec009be99120effa.1631802163.git.yu.c.chen@intel.com (mailing list archive) |
|---|---|
| State | Changes Requested, archived |
| Headers | show |
| Series | Introduce Platform Firmware Runtime Update and Telemetry drivers | expand |
On Thu, Sep 16, 2021 at 5:54 PM Chen Yu <yu.c.chen@intel.com> wrote: > > Platform Firmware Runtime Update image starts with UEFI headers, and the > headers are defined in UEFI specification, but some of them have not been > defined in the kernel yet. > > For example, the header layout of a capsule file looks like this: > > EFI_CAPSULE_HEADER > EFI_FIRMWARE_MANAGEMENT_CAPSULE_HEADER > EFI_FIRMWARE_MANAGEMENT_CAPSULE_IMAGE_HEADER > EFI_FIRMWARE_IMAGE_AUTHENTICATION > > These structures would be used by the Platform Firmware Runtime Update > driver to parse the format of capsule file to verify if the corresponding > version number is valid. The EFI_CAPSULE_HEADER has been defined in the > kernel, however the rest are not, thus introduce corresponding UEFI > structures accordingly. > > The reason why efi_manage_capsule_header_t and > efi_manage_capsule_image_header_t are packedi might be that: > According to the uefi spec, > [Figure 23-6 Firmware Management and Firmware Image Management headers] > EFI_FIRMWARE_MANAGEMENT_CAPSULE_HEADER is located at the lowest offset > within the body of the capsule. And this structure is designed to be > unaligned to save space, because in this way the adjacent drivers and > binary payload elements could start on byte boundary with no padding. > And the EFI_FIRMWARE_MANAGEMENT_CAPSULE_IMAGE_HEADER is at the head of > each payload, so packing this structure also makes room for more data. IMO it would be sufficient to say that both EFI_FIRMWARE_MANAGEMENT_CAPSULE_HEADER and EFI_FIRMWARE_MANAGEMENT_CAPSULE_IMAGE_HEADER need not be aligned and so the corresponding data types should be packed. > > Signed-off-by: Chen Yu <yu.c.chen@intel.com> > --- > include/linux/efi.h | 50 +++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 50 insertions(+) > > diff --git a/include/linux/efi.h b/include/linux/efi.h > index 6b5d36babfcc..19ff834e1388 100644 > --- a/include/linux/efi.h > +++ b/include/linux/efi.h > @@ -148,6 +148,56 @@ typedef struct { > u32 imagesize; > } efi_capsule_header_t; > > +#pragma pack(1) > + > +/* EFI_FIRMWARE_MANAGEMENT_CAPSULE_HEADER */ > +typedef struct { > + u32 ver; > + u16 emb_drv_cnt; > + u16 payload_cnt; > + /* > + * Variable array indicated by number of > + * (emb_drv_cnt + payload_cnt) > + */ > + u64 offset_list[]; > +} efi_manage_capsule_header_t; > + > +/* EFI_FIRMWARE_MANAGEMENT_CAPSULE_IMAGE_HEADER */ > +typedef struct { > + u32 ver; > + guid_t image_type_id; > + u8 image_index; > + u8 reserved_bytes[3]; > + u32 image_size; > + u32 vendor_code_size; > + /* ver = 2. */ > + u64 hw_ins; > + /* ver = v3. */ > + u64 capsule_support; > +} efi_manage_capsule_image_header_t; > + > +#pragma pack() > + > +/* WIN_CERTIFICATE */ > +typedef struct { > + u32 len; > + u16 rev; > + u16 cert_type; > +} win_cert_t; > + > +/* WIN_CERTIFICATE_UEFI_GUID */ > +typedef struct { > + win_cert_t hdr; > + guid_t cert_type; > + u8 cert_data[]; > +} win_cert_uefi_guid_t; > + > +/* EFI_FIRMWARE_IMAGE_AUTHENTICATIO */ > +typedef struct { > + u64 mon_count; > + win_cert_uefi_guid_t auth_info; > +} efi_image_auth_t; > + > /* > * EFI capsule flags > */ > -- > 2.25.1 >
diff --git a/include/linux/efi.h b/include/linux/efi.h index 6b5d36babfcc..19ff834e1388 100644 --- a/include/linux/efi.h +++ b/include/linux/efi.h @@ -148,6 +148,56 @@ typedef struct { u32 imagesize; } efi_capsule_header_t; +#pragma pack(1) + +/* EFI_FIRMWARE_MANAGEMENT_CAPSULE_HEADER */ +typedef struct { + u32 ver; + u16 emb_drv_cnt; + u16 payload_cnt; + /* + * Variable array indicated by number of + * (emb_drv_cnt + payload_cnt) + */ + u64 offset_list[]; +} efi_manage_capsule_header_t; + +/* EFI_FIRMWARE_MANAGEMENT_CAPSULE_IMAGE_HEADER */ +typedef struct { + u32 ver; + guid_t image_type_id; + u8 image_index; + u8 reserved_bytes[3]; + u32 image_size; + u32 vendor_code_size; + /* ver = 2. */ + u64 hw_ins; + /* ver = v3. */ + u64 capsule_support; +} efi_manage_capsule_image_header_t; + +#pragma pack() + +/* WIN_CERTIFICATE */ +typedef struct { + u32 len; + u16 rev; + u16 cert_type; +} win_cert_t; + +/* WIN_CERTIFICATE_UEFI_GUID */ +typedef struct { + win_cert_t hdr; + guid_t cert_type; + u8 cert_data[]; +} win_cert_uefi_guid_t; + +/* EFI_FIRMWARE_IMAGE_AUTHENTICATIO */ +typedef struct { + u64 mon_count; + win_cert_uefi_guid_t auth_info; +} efi_image_auth_t; + /* * EFI capsule flags */
Platform Firmware Runtime Update image starts with UEFI headers, and the headers are defined in UEFI specification, but some of them have not been defined in the kernel yet. For example, the header layout of a capsule file looks like this: EFI_CAPSULE_HEADER EFI_FIRMWARE_MANAGEMENT_CAPSULE_HEADER EFI_FIRMWARE_MANAGEMENT_CAPSULE_IMAGE_HEADER EFI_FIRMWARE_IMAGE_AUTHENTICATION These structures would be used by the Platform Firmware Runtime Update driver to parse the format of capsule file to verify if the corresponding version number is valid. The EFI_CAPSULE_HEADER has been defined in the kernel, however the rest are not, thus introduce corresponding UEFI structures accordingly. The reason why efi_manage_capsule_header_t and efi_manage_capsule_image_header_t are packedi might be that: According to the uefi spec, [Figure 23-6 Firmware Management and Firmware Image Management headers] EFI_FIRMWARE_MANAGEMENT_CAPSULE_HEADER is located at the lowest offset within the body of the capsule. And this structure is designed to be unaligned to save space, because in this way the adjacent drivers and binary payload elements could start on byte boundary with no padding. And the EFI_FIRMWARE_MANAGEMENT_CAPSULE_IMAGE_HEADER is at the head of each payload, so packing this structure also makes room for more data. Signed-off-by: Chen Yu <yu.c.chen@intel.com> --- include/linux/efi.h | 50 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 50 insertions(+)