| Message ID | 20191004145056.43267-3-hdegoede@redhat.com (mailing list archive) |
|---|---|
| State | Deferred, archived |
| Headers | show |
| Series | efi/firmware/platform-x86: Add EFI embedded fw support | expand |
On Fri, Oct 04, 2019 at 04:50:50PM +0200, Hans de Goede wrote: > +static int __init efi_check_md_for_embedded_firmware( > + efi_memory_desc_t *md, const struct efi_embedded_fw_desc *desc) > +{ > + const u64 prefix = *((u64 *)desc->prefix); > + struct sha256_state sctx; > + struct embedded_fw *fw; > + u8 sha256[32]; > + u64 i, size; > + void *map; > + > + size = md->num_pages << EFI_PAGE_SHIFT; > + map = memremap(md->phys_addr, size, MEMREMAP_WB); Since our limitaiton is the init process must have mostly finished, it implies early x86 boot code cannot use this, what measures can we take to prevent / check for such conditions to be detected and gracefully errored out? > + if (!map) { > + pr_err("Error mapping EFI mem at %#llx\n", md->phys_addr); > + return -ENOMEM; > + } > + > + size -= desc->length; Remind me again, why we decrement the size here? I was going to ask if we didn't need a: if (desc->length > size) { memunmap(map); return -EINVAL; } > + for (i = 0; i < size; i += 8) { > + u64 *mem = map + i; > + > + if (*mem != prefix) > + continue; > + > + sha256_init(&sctx); > + sha256_update(&sctx, map + i, desc->length); > + sha256_final(&sctx, sha256); > + if (memcmp(sha256, desc->sha256, 32) == 0) > + break; > + } > + if (i >= size) { > + memunmap(map); > + return -ENOENT; > + } > + > + pr_info("Found EFI embedded fw '%s'\n", desc->name); Otherwise looks good. Luis
Hi Luis, Thank you for the reviews and sorry for being a bit slow to respind. On 11-10-2019 16:48, Luis Chamberlain wrote: > On Fri, Oct 04, 2019 at 04:50:50PM +0200, Hans de Goede wrote: >> +static int __init efi_check_md_for_embedded_firmware( >> + efi_memory_desc_t *md, const struct efi_embedded_fw_desc *desc) >> +{ >> + const u64 prefix = *((u64 *)desc->prefix); >> + struct sha256_state sctx; >> + struct embedded_fw *fw; >> + u8 sha256[32]; >> + u64 i, size; >> + void *map; >> + >> + size = md->num_pages << EFI_PAGE_SHIFT; >> + map = memremap(md->phys_addr, size, MEMREMAP_WB); > > Since our limitaiton is the init process must have mostly finished, > it implies early x86 boot code cannot use this, what measures can we > take to prevent / check for such conditions to be detected and > gracefully errored out? As with all (EFI) early boot code, there simply is a certain order in which things need to be done. This needs to happen after the basic mm is setup, but before efi_free_boot_services() gets called, there isn't really a way to check for all these conditions. As with all early boot code, people making changes need to be careful to not break stuff. > >> + if (!map) { >> + pr_err("Error mapping EFI mem at %#llx\n", md->phys_addr); >> + return -ENOMEM; >> + } >> + >> + size -= desc->length; > > Remind me again, why we decrement the size here? Basically this is another way of writing: for (i = 0; (i + desc->length) < size; i += 8) { > I was going to ask if we didn't need a: > > if (desc->length > size) { > memunmap(map); > return -EINVAL; > } That is a good point, unlikely but still a good point, so I guess that writing: for (i = 0; (i + desc->length) < size; i += 8) { Instead would better as that avoids the need for that check. I will fix this for the next version. Regards, Hans > >> + for (i = 0; i < size; i += 8) { >> + u64 *mem = map + i; >> + >> + if (*mem != prefix) >> + continue; >> + >> + sha256_init(&sctx); >> + sha256_update(&sctx, map + i, desc->length); >> + sha256_final(&sctx, sha256); >> + if (memcmp(sha256, desc->sha256, 32) == 0) >> + break; >> + } >> + if (i >= size) { >> + memunmap(map); >> + return -ENOENT; >> + } >> + >> + pr_info("Found EFI embedded fw '%s'\n", desc->name); > > Otherwise looks good. > > Luis >
On Thu, Nov 14, 2019 at 12:27:01PM +0100, Hans de Goede wrote: > Hi Luis, > > Thank you for the reviews and sorry for being a bit slow to respind. > > On 11-10-2019 16:48, Luis Chamberlain wrote: > > On Fri, Oct 04, 2019 at 04:50:50PM +0200, Hans de Goede wrote: > > > +static int __init efi_check_md_for_embedded_firmware( > > > + efi_memory_desc_t *md, const struct efi_embedded_fw_desc *desc) > > > +{ > > > + const u64 prefix = *((u64 *)desc->prefix); > > > + struct sha256_state sctx; > > > + struct embedded_fw *fw; > > > + u8 sha256[32]; > > > + u64 i, size; > > > + void *map; > > > + > > > + size = md->num_pages << EFI_PAGE_SHIFT; > > > + map = memremap(md->phys_addr, size, MEMREMAP_WB); > > > > Since our limitaiton is the init process must have mostly finished, > > it implies early x86 boot code cannot use this, what measures can we > > take to prevent / check for such conditions to be detected and > > gracefully errored out? > > As with all (EFI) early boot code, there simply is a certain order > in which things need to be done. This needs to happen after the basic > mm is setup, but before efi_free_boot_services() gets called, there > isn't really a way to check for all these conditions. As with all > early boot code, people making changes need to be careful to not > break stuff. I rather we take a proactive measure here and add whatever it is we need to ensure the API works only when its supposed to, rather than try and fail, and then expect the user to know these things. I'd prefer if we at least try to address this. > > > + if (!map) { > > > + pr_err("Error mapping EFI mem at %#llx\n", md->phys_addr); > > > + return -ENOMEM; > > > + } > > > + > > > + size -= desc->length; > > > > Remind me again, why we decrement the size here? > > Basically this is another way of writing: > > for (i = 0; (i + desc->length) < size; i += 8) { > > > I was going to ask if we didn't need a: > > > > if (desc->length > size) { > > memunmap(map); > > return -EINVAL; > > } > > That is a good point, unlikely but still a good point, > so I guess that writing: > > for (i = 0; (i + desc->length) < size; i += 8) { > > Instead would better as that avoids the need for that check. > I will fix this for the next version. Great thanks. Luis
Hi, On 14-11-2019 20:42, Luis Chamberlain wrote: > On Thu, Nov 14, 2019 at 12:27:01PM +0100, Hans de Goede wrote: >> Hi Luis, >> >> Thank you for the reviews and sorry for being a bit slow to respind. >> >> On 11-10-2019 16:48, Luis Chamberlain wrote: >>> On Fri, Oct 04, 2019 at 04:50:50PM +0200, Hans de Goede wrote: >>>> +static int __init efi_check_md_for_embedded_firmware( >>>> + efi_memory_desc_t *md, const struct efi_embedded_fw_desc *desc) >>>> +{ >>>> + const u64 prefix = *((u64 *)desc->prefix); >>>> + struct sha256_state sctx; >>>> + struct embedded_fw *fw; >>>> + u8 sha256[32]; >>>> + u64 i, size; >>>> + void *map; >>>> + >>>> + size = md->num_pages << EFI_PAGE_SHIFT; >>>> + map = memremap(md->phys_addr, size, MEMREMAP_WB); >>> >>> Since our limitaiton is the init process must have mostly finished, >>> it implies early x86 boot code cannot use this, what measures can we >>> take to prevent / check for such conditions to be detected and >>> gracefully errored out? >> >> As with all (EFI) early boot code, there simply is a certain order >> in which things need to be done. This needs to happen after the basic >> mm is setup, but before efi_free_boot_services() gets called, there >> isn't really a way to check for all these conditions. As with all >> early boot code, people making changes need to be careful to not >> break stuff. > > I rather we take a proactive measure here and add whatever it is we need > to ensure the API works only when its supposed to, rather than try and > fail, and then expect the user to know these things. > > I'd prefer if we at least try to address this. This is purely internal x86/EFI API it is not intended for drivers or anything like that. It has only one caller under arch/x86 and it is not supposed to get any other callers outside of arch/* ever. Note that this all runs before even core_initcall-s get run, none if the code which runs before then has any sort of ordering checks and I don't see how this bit is special and thus does need ordering checks; and there really is no mechanism for such checks so early during boot. The drivers/firmware/efi/embedded-firmware.c file does add some API which can be used normally, specifically the efi_get_embedded_fw() but that has no special ordering constrains and it does not directly use the function we are discussing now. It reads back data stored by the earlier functions; and if somehow called before those functions run (*), then it will simply return -ENOENT. Regards, Hans *) which would mean before core_initcalls run so really really early
Hi, On 14-11-2019 21:13, Hans de Goede wrote: > Hi, > > On 14-11-2019 20:42, Luis Chamberlain wrote: >> On Thu, Nov 14, 2019 at 12:27:01PM +0100, Hans de Goede wrote: >>> Hi Luis, >>> >>> Thank you for the reviews and sorry for being a bit slow to respind. >>> >>> On 11-10-2019 16:48, Luis Chamberlain wrote: >>>> On Fri, Oct 04, 2019 at 04:50:50PM +0200, Hans de Goede wrote: >>>>> +static int __init efi_check_md_for_embedded_firmware( >>>>> + efi_memory_desc_t *md, const struct efi_embedded_fw_desc *desc) >>>>> +{ >>>>> + const u64 prefix = *((u64 *)desc->prefix); >>>>> + struct sha256_state sctx; >>>>> + struct embedded_fw *fw; >>>>> + u8 sha256[32]; >>>>> + u64 i, size; >>>>> + void *map; >>>>> + >>>>> + size = md->num_pages << EFI_PAGE_SHIFT; >>>>> + map = memremap(md->phys_addr, size, MEMREMAP_WB); >>>> >>>> Since our limitaiton is the init process must have mostly finished, >>>> it implies early x86 boot code cannot use this, what measures can we >>>> take to prevent / check for such conditions to be detected and >>>> gracefully errored out? >>> >>> As with all (EFI) early boot code, there simply is a certain order >>> in which things need to be done. This needs to happen after the basic >>> mm is setup, but before efi_free_boot_services() gets called, there >>> isn't really a way to check for all these conditions. As with all >>> early boot code, people making changes need to be careful to not >>> break stuff. >> >> I rather we take a proactive measure here and add whatever it is we need >> to ensure the API works only when its supposed to, rather than try and >> fail, and then expect the user to know these things. >> >> I'd prefer if we at least try to address this. > > This is purely internal x86/EFI API it is not intended for drivers > or anything like that. It has only one caller under arch/x86 and it is > not supposed to get any other callers outside of arch/* ever. > > Note that this all runs before even core_initcall-s get run, none > if the code which runs before then has any sort of ordering checks > and I don't see how this bit is special and thus does need ordering > checks; and there really is no mechanism for such checks so early > during boot. > > The drivers/firmware/efi/embedded-firmware.c file does add some API > which can be used normally, specifically the efi_get_embedded_fw() > but that has no special ordering constrains and it does not directly > use the function we are discussing now. It reads back data stored > by the earlier functions; and if somehow called before those functions > run (*), then it will simply return -ENOENT. Ok, I just realized that we may have some miscommunication here, when you wrote: "Since our limitation is the init process must have mostly finished, it implies early x86 boot code cannot use this, what measures can we take to prevent / check for such conditions to be detected and gracefully errored out?" I assumed you meant that to apply to the efi_check_md_for_embedded_firmware() helper or its caller. But I guess what you really want is some error to be thrown if someone calls firmware_request_platform() before we are ready. I guess I could make efi_check_for_embedded_firmwares() which scans for known firmwares and saved a copy set a flag that it has run. And then combine that with making efi_get_embedded_fw() (which underpins firmware_request_platform()) print a warning when called if that flag is not set yet. That would mean though that some code which runs earlier then a core_initcall would, would call firmware_request_platform() and such code is generally expected to know what they are doing. I just checked and the cpu microcode stuff which comes to mind for this uses a late_initcall so runs long after efi_get_embedded_fw() and I have a feeling that trying to use the fw_loader before core_initcalls have run is going to end poorly anyways. Still if you want I can add a pr_warn or maybe even a WARN_ON to efi_get_embedded_fw() in case it somehow gets called before efi_check_for_embedded_firmwares(). Regards, Hans
On Thu, Nov 14, 2019 at 09:48:38PM +0100, Hans de Goede wrote: > Hi, > > On 14-11-2019 21:13, Hans de Goede wrote: > > Hi, > > > > On 14-11-2019 20:42, Luis Chamberlain wrote: > > > On Thu, Nov 14, 2019 at 12:27:01PM +0100, Hans de Goede wrote: > > > > Hi Luis, > > > > > > > > Thank you for the reviews and sorry for being a bit slow to respind. > > > > > > > > On 11-10-2019 16:48, Luis Chamberlain wrote: > > > > > On Fri, Oct 04, 2019 at 04:50:50PM +0200, Hans de Goede wrote: > > > > > > +static int __init efi_check_md_for_embedded_firmware( > > > > > > + efi_memory_desc_t *md, const struct efi_embedded_fw_desc *desc) > > > > > > +{ > > > > > > + const u64 prefix = *((u64 *)desc->prefix); > > > > > > + struct sha256_state sctx; > > > > > > + struct embedded_fw *fw; > > > > > > + u8 sha256[32]; > > > > > > + u64 i, size; > > > > > > + void *map; > > > > > > + > > > > > > + size = md->num_pages << EFI_PAGE_SHIFT; > > > > > > + map = memremap(md->phys_addr, size, MEMREMAP_WB); > > > > > > > > > > Since our limitaiton is the init process must have mostly finished, > > > > > it implies early x86 boot code cannot use this, what measures can we > > > > > take to prevent / check for such conditions to be detected and > > > > > gracefully errored out? > > > > > > > > As with all (EFI) early boot code, there simply is a certain order > > > > in which things need to be done. This needs to happen after the basic > > > > mm is setup, but before efi_free_boot_services() gets called, there > > > > isn't really a way to check for all these conditions. As with all > > > > early boot code, people making changes need to be careful to not > > > > break stuff. > > > > > > I rather we take a proactive measure here and add whatever it is we need > > > to ensure the API works only when its supposed to, rather than try and > > > fail, and then expect the user to know these things. > > > > > > I'd prefer if we at least try to address this. > > > > This is purely internal x86/EFI API it is not intended for drivers > > or anything like that. It has only one caller under arch/x86 and it is > > not supposed to get any other callers outside of arch/* ever. > > > > Note that this all runs before even core_initcall-s get run, none > > if the code which runs before then has any sort of ordering checks > > and I don't see how this bit is special and thus does need ordering > > checks; and there really is no mechanism for such checks so early > > during boot. > > > > The drivers/firmware/efi/embedded-firmware.c file does add some API > > which can be used normally, specifically the efi_get_embedded_fw() > > but that has no special ordering constrains and it does not directly > > use the function we are discussing now. It reads back data stored > > by the earlier functions; and if somehow called before those functions > > run (*), then it will simply return -ENOENT. > > Ok, I just realized that we may have some miscommunication here, > when you wrote: > > "Since our limitation is the init process must have mostly finished, > it implies early x86 boot code cannot use this, what measures can we > take to prevent / check for such conditions to be detected and > gracefully errored out?" > > I assumed you meant that to apply to the efi_check_md_for_embedded_firmware() > helper or its caller. > > But I guess what you really want is some error to be thrown if someone > calls firmware_request_platform() before we are ready. Yes. > I guess I could make efi_check_for_embedded_firmwares() which scans > for known firmwares and saved a copy set a flag that it has run. > > And then combine that with making efi_get_embedded_fw() (which underpins > firmware_request_platform()) print a warning when called if that flag > is not set yet. > > That would mean though that some code which runs earlier then > a core_initcall would, would call firmware_request_platform() and > such code is generally expected to know what they are doing. > > I just checked and the cpu microcode stuff which comes to mind > for this uses a late_initcall so runs long after efi_get_embedded_fw() > and I have a feeling that trying to use the fw_loader before > core_initcalls have run is going to end poorly anyways. > > Still if you want I can add a pr_warn or maybe even a WARN_ON > to efi_get_embedded_fw() in case it somehow gets called before > efi_check_for_embedded_firmwares(). That'd be great. Luis
Hi, On 14-11-2019 22:50, Luis Chamberlain wrote: > On Thu, Nov 14, 2019 at 09:48:38PM +0100, Hans de Goede wrote: <snip> >> But I guess what you really want is some error to be thrown if someone >> calls firmware_request_platform() before we are ready. > > Yes. > >> I guess I could make efi_check_for_embedded_firmwares() which scans >> for known firmwares and saved a copy set a flag that it has run. >> >> And then combine that with making efi_get_embedded_fw() (which underpins >> firmware_request_platform()) print a warning when called if that flag >> is not set yet. <snip> > That'd be great. So I've been working on this, my first though was to use WARN_ON as calling this too early would be a bug, but there is a bunch of normal circumstances where efi_check_for_embedded_firmwares() never runs. One of the being classic BIOS boot, but e.g. also when running paravirtualized in a paravirt env. using UEFI. Normally we should not end up calling efi_get_embedded_fw() in those cases, for one it is unlikely for any drivers using firmware_request_platform() to be used in such an environment, and if we somehow do end up with a case where firmware_request_platform() is called, since the EFI emebedded fw fallback then will not work I would expect a copy of the necessary fw to be under /lib/firmware so we never hit the fallback. This all makes efi_get_embedded_fw() getting called in cases where efi_check_for_embedded_firmwares() will never run unlikely, but not impossible. Making a WARN_ON the wrong thing to do so for v8 of this patch-set I will add a pr_warn for this. Note I've looked into detecting all the circumstances where it is normal for efi_check_for_embedded_firmwares() to never run, but after tracing the call path leading up to it getting called I've found that a check for that is complicated and more importantly error-prone and likely to get out of sync with reality if any of the functions higher up the call path ever change the conditions. So a pr_warn it is, and since as explained one would normally not expect to ever hit the fallback on systems where efi_check_for_embedded_firmwares() does not get called, I see no harm in simply always printing the warning if efi_check_for_embedded_firmwares() was not called. Regards, Hans
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c index 847730f7e74b..5db2cc011dc1 100644 --- a/arch/x86/platform/efi/efi.c +++ b/arch/x86/platform/efi/efi.c @@ -1019,6 +1019,7 @@ static void __init __efi_enter_virtual_mode(void) panic("EFI call to SetVirtualAddressMap() failed!"); } + efi_check_for_embedded_firmwares(); efi_free_boot_services(); /* diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig index 178ee8106828..c2c003326265 100644 --- a/drivers/firmware/efi/Kconfig +++ b/drivers/firmware/efi/Kconfig @@ -193,6 +193,10 @@ config EFI_RCI2_TABLE Say Y here for Dell EMC PowerEdge systems. +config EFI_EMBEDDED_FIRMWARE + bool + select CRYPTO_LIB_SHA256 + endmenu config UEFI_CPER diff --git a/drivers/firmware/efi/Makefile b/drivers/firmware/efi/Makefile index 4ac2de4dfa72..42bd310657f4 100644 --- a/drivers/firmware/efi/Makefile +++ b/drivers/firmware/efi/Makefile @@ -26,6 +26,7 @@ obj-$(CONFIG_EFI_TEST) += test/ obj-$(CONFIG_EFI_DEV_PATH_PARSER) += dev-path-parser.o obj-$(CONFIG_APPLE_PROPERTIES) += apple-properties.o obj-$(CONFIG_EFI_RCI2_TABLE) += rci2-table.o +obj-$(CONFIG_EFI_EMBEDDED_FIRMWARE) += embedded-firmware.o arm-obj-$(CONFIG_EFI) := arm-init.o arm-runtime.o obj-$(CONFIG_ARM) += $(arm-obj-y) diff --git a/drivers/firmware/efi/embedded-firmware.c b/drivers/firmware/efi/embedded-firmware.c new file mode 100644 index 000000000000..75d652f3148b --- /dev/null +++ b/drivers/firmware/efi/embedded-firmware.c @@ -0,0 +1,143 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Support for extracting embedded firmware for peripherals from EFI code, + * + * Copyright (c) 2018 Hans de Goede <hdegoede@redhat.com> + */ + +#include <linux/dmi.h> +#include <linux/efi.h> +#include <linux/efi_embedded_fw.h> +#include <linux/io.h> +#include <linux/slab.h> +#include <linux/types.h> +#include <linux/vmalloc.h> +#include <crypto/sha.h> + +struct embedded_fw { + struct list_head list; + const char *name; + void *data; + size_t length; +}; + +static LIST_HEAD(found_fw_list); + +static const struct dmi_system_id * const embedded_fw_table[] = { + NULL +}; + +/* + * Note the efi_check_for_embedded_firmwares() code currently makes the + * following 2 assumptions. This may needs to be revisited if embedded firmware + * is found where this is not true: + * 1) The firmware is only found in EFI_BOOT_SERVICES_CODE memory segments + * 2) The firmware always starts at an offset which is a multiple of 8 bytes + */ +static int __init efi_check_md_for_embedded_firmware( + efi_memory_desc_t *md, const struct efi_embedded_fw_desc *desc) +{ + const u64 prefix = *((u64 *)desc->prefix); + struct sha256_state sctx; + struct embedded_fw *fw; + u8 sha256[32]; + u64 i, size; + void *map; + + size = md->num_pages << EFI_PAGE_SHIFT; + map = memremap(md->phys_addr, size, MEMREMAP_WB); + if (!map) { + pr_err("Error mapping EFI mem at %#llx\n", md->phys_addr); + return -ENOMEM; + } + + size -= desc->length; + for (i = 0; i < size; i += 8) { + u64 *mem = map + i; + + if (*mem != prefix) + continue; + + sha256_init(&sctx); + sha256_update(&sctx, map + i, desc->length); + sha256_final(&sctx, sha256); + if (memcmp(sha256, desc->sha256, 32) == 0) + break; + } + if (i >= size) { + memunmap(map); + return -ENOENT; + } + + pr_info("Found EFI embedded fw '%s'\n", desc->name); + + fw = kmalloc(sizeof(*fw), GFP_KERNEL); + if (!fw) { + memunmap(map); + return -ENOMEM; + } + + fw->data = kmemdup(map + i, desc->length, GFP_KERNEL); + memunmap(map); + if (!fw->data) { + kfree(fw); + return -ENOMEM; + } + + fw->name = desc->name; + fw->length = desc->length; + list_add(&fw->list, &found_fw_list); + + return 0; +} + +void __init efi_check_for_embedded_firmwares(void) +{ + const struct efi_embedded_fw_desc *fw_desc; + const struct dmi_system_id *dmi_id; + efi_memory_desc_t *md; + int i, r; + + for (i = 0; embedded_fw_table[i]; i++) { + dmi_id = dmi_first_match(embedded_fw_table[i]); + if (!dmi_id) + continue; + + fw_desc = dmi_id->driver_data; + for_each_efi_memory_desc(md) { + if (md->type != EFI_BOOT_SERVICES_CODE) + continue; + + r = efi_check_md_for_embedded_firmware(md, fw_desc); + if (r == 0) + break; + } + } +} + +int efi_get_embedded_fw(const char *name, void **data, size_t *size) +{ + struct embedded_fw *iter, *fw = NULL; + void *buf = *data; + + list_for_each_entry(iter, &found_fw_list, list) { + if (strcmp(name, iter->name) == 0) { + fw = iter; + break; + } + } + + if (!fw) + return -ENOENT; + + buf = vmalloc(fw->length); + if (!buf) + return -ENOMEM; + + memcpy(buf, fw->data, fw->length); + *size = fw->length; + *data = buf; + + return 0; +} +EXPORT_SYMBOL_GPL(efi_get_embedded_fw); diff --git a/include/linux/efi.h b/include/linux/efi.h index 2a30a1bd8bdf..429634be3ecf 100644 --- a/include/linux/efi.h +++ b/include/linux/efi.h @@ -1632,6 +1632,12 @@ static inline void efi_enable_reset_attack_mitigation(efi_system_table_t *sys_table_arg) { } #endif +#ifdef CONFIG_EFI_EMBEDDED_FIRMWARE +void efi_check_for_embedded_firmwares(void); +#else +static inline void efi_check_for_embedded_firmwares(void) { } +#endif + void efi_retrieve_tpm2_eventlog(efi_system_table_t *sys_table); /* diff --git a/include/linux/efi_embedded_fw.h b/include/linux/efi_embedded_fw.h new file mode 100644 index 000000000000..ac70ff146d58 --- /dev/null +++ b/include/linux/efi_embedded_fw.h @@ -0,0 +1,25 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef _LINUX_EFI_EMBEDDED_FW_H +#define _LINUX_EFI_EMBEDDED_FW_H + +#include <linux/mod_devicetable.h> + +/** + * struct efi_embedded_fw_desc - This struct is used by the EFI embedded-fw + * code to search for embedded firmwares. + * + * @name: Name to register the firmware with if found + * @prefix: First 8 bytes of the firmware + * @length: Length of the firmware in bytes including prefix + * @sha256: SHA256 of the firmware + */ +struct efi_embedded_fw_desc { + const char *name; + u8 prefix[8]; + u32 length; + u8 sha256[32]; +}; + +int efi_get_embedded_fw(const char *name, void **dat, size_t *sz); + +#endif