From: "Rafael J. Wysocki" <rafael@kernel.org> To: Chen Yu <yu.c.chen@intel.com> Cc: ACPI Devel Maling List <linux-acpi@vger.kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, "Rafael J. Wysocki" <rafael@kernel.org>, Len Brown <len.brown@intel.com>, Dan Williams <dan.j.williams@intel.com>, Andy Shevchenko <andriy.shevchenko@intel.com>, Aubrey Li <aubrey.li@intel.com>, Ashok Raj <ashok.raj@intel.com>, Mike Rapoport <rppt@kernel.org>, Ard Biesheuvel <ardb@kernel.org>, linux-efi <linux-efi@vger.kernel.org> Subject: Re: [PATCH v3 2/5] efi: Introduce EFI_FIRMWARE_MANAGEMENT_CAPSULE_HEADER and corresponding structures Date: Mon, 27 Sep 2021 19:33:15 +0200 [thread overview] Message-ID: <CAJZ5v0ikSrHuJ25j74ARJxM1wedt63Q8F2kQ4YSgJFSbx+5nOw@mail.gmail.com> (raw) In-Reply-To: <afe88d0bbab0fbed289cceceec009be99120effa.1631802163.git.yu.c.chen@intel.com> 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 >
prev parent reply other threads:[~2021-09-27 17:34 UTC|newest] Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <cover.1631802162.git.yu.c.chen@intel.com> 2021-09-16 16:00 ` Chen Yu 2021-09-27 17:33 ` Rafael J. Wysocki [this message]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAJZ5v0ikSrHuJ25j74ARJxM1wedt63Q8F2kQ4YSgJFSbx+5nOw@mail.gmail.com \ --to=rafael@kernel.org \ --cc=andriy.shevchenko@intel.com \ --cc=ardb@kernel.org \ --cc=ashok.raj@intel.com \ --cc=aubrey.li@intel.com \ --cc=dan.j.williams@intel.com \ --cc=len.brown@intel.com \ --cc=linux-acpi@vger.kernel.org \ --cc=linux-efi@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=rppt@kernel.org \ --cc=yu.c.chen@intel.com \ --subject='Re: [PATCH v3 2/5] efi: Introduce EFI_FIRMWARE_MANAGEMENT_CAPSULE_HEADER and corresponding structures' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).