efi: disentangle the generic EFI stub from FDT
Subsystems (4)
Ard Biesheuvel
maintainerv2 cover efi: disentangle the generic EFI stub from FDT
EFI architectures other than x86 rely on FDT to pass information between the stub and the core kernel. In hindsight, this is probably a mistake, given the issues around abuse of the internal ABI, and potential inconsistencies between two sources of information that both originate in the firmware (memory map, command line, etc)
Another reason for avoiding updates to the DT is the fact that it interferes with secure boot and measured boot. Even if we measure the original firmware provided DT into the TPM, the DT that the kernel receives is a completely different blob, and verifying it against the TPM event log is currently impossible.
So let's start hacking away at this, and refactor the generic stub so that all the FDT pieces are isolated in a singe source file, and rely on generic EFI config tables for passing the initrd base and size. Ultimately, this should permit all EFI architectures doing DT boot to perform the handover to the core kernel in a different way, and pass on the firmware provided DT unmodified, but this requires some future work for ARM/arm64 and RISC-V.
However, we can easily convert the newly added LoongArch code to adopt this approach, and to consume the DT strictly for hardware descriptions (if not doing ACPI boot), and pass the initrd, memory map and everything else via EFI config tables. Generating empty DTBs on ACPI platforms will no longer be needed.
The first six patches as well as patch #10 are general cleanup, and can be merged separately. The remaining patches refactor the FDT code in the EFI stub so that we can avoid it on platforms that don't need it for other reasons. Finally, LoongArch is updated to use DT only for hardware descriptions when doing EFI boot.
Changes since v1:
- to ease merging this with the loongarch tree, drop unrelated cleanup changes, which will be merged separately;
- drop the patch to enable DT for hw descriptions - it will be picked up again later
- avoid creating the INITRD table if no initrd was actually loaded;
- incorporate feedback from Huacai on the arch/loongarch changes;
- other minor tweaks.
Ard Biesheuvel (8):
efi: libstub: drop pointless get_memory_map() call
efi: libstub: avoid efi_get_memory_map() for allocating the virt map
efi: libstub: simplify efi_get_memory_map() and struct efi_boot_memmap
efi: libstub: remove pointless goto kludge
efi: libstub: unify initrd loading between architectures
efi: libstub: remove DT dependency from generic stub
efi: libstub: install boot-time memory map as config table efi/loongarch: libstub: remove dependency on flattened DT
Documentation/arm/uefi.rst | 4 - arch/loongarch/Kconfig | 3 - arch/loongarch/include/asm/bootinfo.h | 2 +- arch/loongarch/kernel/efi.c | 30 +++- arch/loongarch/kernel/env.c | 13 +- arch/loongarch/kernel/head.S | 2 + arch/loongarch/kernel/setup.c | 4 +- drivers/firmware/efi/efi.c | 15 ++ drivers/firmware/efi/libstub/Makefile | 13 +- drivers/firmware/efi/libstub/arm64-stub.c | 19 +-- drivers/firmware/efi/libstub/efi-stub-helper.c | 139 ++++++++-------- drivers/firmware/efi/libstub/efi-stub.c | 90 ++++------ drivers/firmware/efi/libstub/efistub.h | 28 +--- drivers/firmware/efi/libstub/fdt.c | 176 +++++++++++--------- drivers/firmware/efi/libstub/loongarch-stub.c | 56 ++++++- drivers/firmware/efi/libstub/mem.c | 93 +++++------ drivers/firmware/efi/libstub/randomalloc.c | 25 +-- drivers/firmware/efi/libstub/relocate.c | 21 +-- drivers/firmware/efi/libstub/x86-stub.c | 30 +--- include/linux/efi.h | 15 ++ 20 files changed, 395 insertions(+), 383 deletions(-)
Signature · 1 line
2.35.1
Ard Biesheuvel
maintainerPATCH v2 1/8 efi: libstub: drop pointless get_memory_map() call
Currently, the non-x86 stub code calls get_memory_map() redundantly, given that the data it returns is never used anywhere. So drop the call.
--- drivers/firmware/efi/libstub/fdt.c | 8 -------- 1 file changed, 8 deletions(-)
drivers/firmware/efi/libstub/fdt.c +0 -8
@@ -280,14 +280,6 @@ efi_status_t allocate_new_fdt_and_exit_boot(void *handle, goto fail; } -/* -* Now that we have done our final memory allocation (and free) -* we can get the memory map key needed for exit_boot_services(). -*/ - status =efi_get_memory_map (&map); -if (status !=EFI_SUCCESS ) - goto fail_free_new_fdt; - status =update_fdt ((void *)fdt_addr, fdt_size, (void *)*new_fdt_addr,MAX_FDT_SIZE , cmdline_ptr, initrd_addr, initrd_size);
Signature · 1 line
2.35.1
Ard Biesheuvel
maintainerPATCH v2 2/8 efi: libstub: avoid efi_get_memory_map() for allocating the virt map
In reply to Ard BiesheuvelThe virt map is a set of efi_memory_desc_t descriptors that are passed to SetVirtualAddressMap() to inform the firmware about the desired virtual mapping of the regions marked as EFI_MEMORY_RUNTIME. The only reason we currently call the efi_get_memory_map() helper is that it gives us an allocation that is guaranteed to be of sufficient size. However, efi_get_memory_map() has grown some additional complexity over the years, and today, we're actually better off calling the EFI boot service directly with a zero size, which tells us how much memory should be enough for the virt map.
While at it, avoid fiddling with the VA map allocation if we will not be using it anyway, i.e., if efi_novamap is true.
--- drivers/firmware/efi/libstub/efi-stub.c | 31 ++++++++++++++++ drivers/firmware/efi/libstub/efistub.h | 2 + drivers/firmware/efi/libstub/fdt.c | 39 ++++++++------------ 3 files changed, 49 insertions(+), 23 deletions(-)
drivers/firmware/efi/libstub/efi-stub.c +31 -0
@@ -321,6 +321,35 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,return status; } +/* +* efi_allocate_virtmap() - create a pool allocation for the virtmap +* +* Create an allocation that is of sufficient size to hold all the memory +* descriptors that will be passed to SetVirtualAddressMap() to inform the +* firmware about the virtual mapping that will be used under the OS to call +* into the firmware. +*/ +efi_status_t efi_alloc_virtmap (efi_memory_desc_t **virtmap, +unsigned long *desc_size,u32 *desc_ver) +{ +unsigned long size, mmap_key; +efi_status_t status; + +/* +* Use the size of the current memory map as an upper bound for the +* size of the buffer we need to pass to SetVirtualAddressMap() to +* cover all EFI_MEMORY_RUNTIME regions. +*/ + size =0 ; + status =efi_bs_call (get_memory_map, &size,NULL , &mmap_key, desc_size, + desc_ver); +if (status !=EFI_BUFFER_TOO_SMALL ) +return EFI_LOAD_ERROR ; + +return efi_bs_call (allocate_pool,EFI_LOADER_DATA , size, + (void **)virtmap); +} +/* * efi_get_virtmap() - create a virtual mapping for the EFI memory map *
@@ -336,6 +365,8 @@ void efi_get_virtmap(efi_memory_desc_t *memory_map, unsigned long map_size,efi_memory_desc_t *in, *out = runtime_map;int l; + *count =0 ; +for (l =0 ; l < map_size; l += desc_size) {u64 paddr, size;
drivers/firmware/efi/libstub/efistub.h +2 -0
@@ -864,6 +864,8 @@ efi_status_t allocate_new_fdt_and_exit_boot(void *handle,void *get_fdt (unsigned long *fdt_size); +efi_status_t efi_alloc_virtmap (efi_memory_desc_t **virtmap, +unsigned long *desc_size,u32 *desc_ver);void efi_get_virtmap (efi_memory_desc_t *memory_map,unsigned long map_size,unsigned long desc_size,efi_memory_desc_t *runtime_map,int *count);
drivers/firmware/efi/libstub/fdt.c +16 -23
@@ -199,7 +199,7 @@ static efi_status_t update_fdt_memmap(void *fdt, struct efi_boot_memmap *map)struct exit_boot_struct {efi_memory_desc_t *runtime_map; -int *runtime_entry_count; +int runtime_entry_count;void *new_fdt_addr; };
@@ -212,8 +212,9 @@ static efi_status_t exit_boot_func(struct efi_boot_memmap *map,* populate @runtime_map with copies of just the EFI_MEMORY_RUNTIME * entries so that we can pass it straight to SetVirtualAddressMap() */ -efi_get_virtmap (*map->map, *map->map_size, *map->desc_size, - p->runtime_map, p->runtime_entry_count); +if (!efi_novamap) +efi_get_virtmap (*map->map, *map->map_size, *map->desc_size, + p->runtime_map, &p->runtime_entry_count);return update_fdt_memmap (p->new_fdt_addr, map); }
@@ -246,29 +247,24 @@ efi_status_t allocate_new_fdt_and_exit_boot(void *handle,unsigned long map_size, desc_size, buff_size;u32 desc_ver;unsigned long mmap_key; -efi_memory_desc_t *memory_map, *runtime_map; +efi_memory_desc_t *memory_map;efi_status_t status; -int runtime_entry_count;struct efi_boot_memmap map;struct exit_boot_struct priv; - map.map = &runtime_map; map.map_size = &map_size; map.desc_size = &desc_size; map.desc_ver = &desc_ver; map.key_ptr = &mmap_key; map.buff_size = &buff_size; -/* -* Get a copy of the current memory map that we will use to prepare -* the input for SetVirtualAddressMap(). We don't have to worry about -* subsequent allocations adding entries, since they could not affect -* the number of EFI_MEMORY_RUNTIME regions. -*/ - status =efi_get_memory_map (&map); -if (status !=EFI_SUCCESS ) { -efi_err ("Unable to retrieve UEFI memory map.\n" ); -return status; +if (!efi_novamap) { + status =efi_alloc_virtmap (&priv.runtime_map, &desc_size, + &desc_ver); +if (status !=EFI_SUCCESS ) { +efi_err ("Unable to retrieve UEFI memory map.\n" ); +return status; + } }efi_info ("Exiting boot services...\n" );
@@ -289,10 +285,7 @@ efi_status_t allocate_new_fdt_and_exit_boot(void *handle, goto fail_free_new_fdt; } - runtime_entry_count =0 ; - priv.runtime_map = runtime_map; - priv.runtime_entry_count = &runtime_entry_count; - priv.new_fdt_addr = (void *)*new_fdt_addr; + priv.new_fdt_addr = (void *)*new_fdt_addr; status =efi_exit_boot_services (handle, &map, &priv, exit_boot_func);
@@ -304,8 +297,8 @@ efi_status_t allocate_new_fdt_and_exit_boot(void *handle,/* Install the new virtual address map */ svam = efi_system_table->runtime->set_virtual_address_map; - status =svam (runtime_entry_count * desc_size, desc_size, - desc_ver, runtime_map); + status =svam (priv.runtime_entry_count * desc_size, desc_size, + desc_ver, priv.runtime_map);/* * We are beyond the point of no return here, so if the call to
@@ -337,7 +330,7 @@ efi_status_t allocate_new_fdt_and_exit_boot(void *handle,efi_free (MAX_FDT_SIZE , *new_fdt_addr); fail: - efi_system_table->boottime->free_pool (runtime_map); +efi_bs_call (free_pool, priv.runtime_map);return EFI_LOAD_ERROR ; }
Signature · 1 line
2.35.1
Ard Biesheuvel
maintainerPATCH v2 3/8 efi: libstub: simplify efi_get_memory_map() and struct efi_boot_memmap
In reply to Ard BiesheuvelCurrently, struct efi_boot_memmap is a struct that is passed around between callers of efi_get_memory_map() and the users of the resulting data, and which carries pointers to various variables whose values are provided by the EFI GetMemoryMap() boot service.
This is overly complex, and it is much easier to carry these values in the struct itself. So turn the struct into one that carries these data items directly, including a flex array for the variable number of EFI memory descriptors that the boot service may return.
--- drivers/firmware/efi/libstub/arm64-stub.c | 17 ++--- drivers/firmware/efi/libstub/efi-stub-helper.c | 26 ++++--- drivers/firmware/efi/libstub/efistub.h | 15 +--- drivers/firmware/efi/libstub/fdt.c | 37 +++++----- drivers/firmware/efi/libstub/mem.c | 74 +++++++------------- drivers/firmware/efi/libstub/randomalloc.c | 23 ++---- drivers/firmware/efi/libstub/relocate.c | 21 ++---- drivers/firmware/efi/libstub/x86-stub.c | 20 ++---- include/linux/efi.h | 9 +++ 9 files changed, 85 insertions(+), 157 deletions(-)
drivers/firmware/efi/libstub/arm64-stub.c +4 -13
@@ -42,26 +42,17 @@ efi_status_t check_platform_features(void)*/ static bool check_image_region (u64 base,u64 size) { -unsigned long map_size, desc_size, buff_size; -efi_memory_desc_t *memory_map; -struct efi_boot_memmap map; +struct efi_boot_memmap *map;efi_status_t status;bool ret = false;int map_offset; - map.map = &memory_map; - map.map_size = &map_size; - map.desc_size = &desc_size; - map.desc_ver =NULL ; - map.key_ptr =NULL ; - map.buff_size = &buff_size; - status =efi_get_memory_map (&map);if (status !=EFI_SUCCESS )return false; -for (map_offset =0 ; map_offset < map_size; map_offset += desc_size) { -efi_memory_desc_t *md = (void *)memory_map + map_offset; +for (map_offset =0 ; map_offset < map->map_size; map_offset += map->desc_size) { +efi_memory_desc_t *md = (void *)map->map + map_offset;u64 end = md->phys_addr + md->num_pages *EFI_PAGE_SIZE ;/*
@@ -74,7 +65,7 @@ static bool check_image_region(u64 base, u64 size) } } -efi_bs_call (free_pool, memory_map); +efi_bs_call (free_pool, map);return ret; }
drivers/firmware/efi/libstub/efi-stub-helper.c +12 -14
@@ -419,7 +419,6 @@ char *efi_convert_cmdline(efi_loaded_image_t *image, int *cmd_line_len)/** * efi_exit_boot_services() - Exit boot services * @handle: handle of the exiting image -* @map: pointer to receive the memory map * @priv: argument to be passed to @priv_func * @priv_func: function to process the memory map before exiting boot services *
@@ -432,14 +431,13 @@ char *efi_convert_cmdline(efi_loaded_image_t *image, int *cmd_line_len)* * Return: status code */ -efi_status_t efi_exit_boot_services (void *handle, -struct efi_boot_memmap *map, -void *priv, +efi_status_t efi_exit_boot_services (void *handle,void *priv,efi_exit_boot_map_processing priv_func) { +struct efi_boot_memmap *map;efi_status_t status; - status =efi_get_memory_map (map); + status =efi_get_memory_map (&map);if (status !=EFI_SUCCESS ) goto fail;
@@ -451,7 +449,7 @@ efi_status_t efi_exit_boot_services(void *handle,if (efi_disable_pci_dma)efi_pci_disable_bridge_busmaster (); - status =efi_bs_call (exit_boot_services, handle, *map->key_ptr); + status =efi_bs_call (exit_boot_services, handle, map->map_key);if (status ==EFI_INVALID_PARAMETER ) {/*
@@ -467,13 +465,13 @@ efi_status_t efi_exit_boot_services(void *handle,* buffer should account for any changes in the map so the call * to get_memory_map() is expected to succeed here. */ - *map->map_size = *map->buff_size; + map->map_size = map->buff_size; status =efi_bs_call (get_memory_map, - map->map_size, - *map->map, - map->key_ptr, - map->desc_size, - map->desc_ver); + &map->map_size, + &map->map, + &map->map_key, + &map->desc_size, + &map->desc_ver);/* exit_boot_services() was called, thus cannot free */ if (status !=EFI_SUCCESS )
@@ -484,7 +482,7 @@ efi_status_t efi_exit_boot_services(void *handle,if (status !=EFI_SUCCESS ) goto fail; - status =efi_bs_call (exit_boot_services, handle, *map->key_ptr); + status =efi_bs_call (exit_boot_services, handle, map->map_key); }/* exit_boot_services() was called, thus cannot free */
@@ -494,7 +492,7 @@ efi_status_t efi_exit_boot_services(void *handle,return EFI_SUCCESS ; free_map: -efi_bs_call (free_pool, *map->map); +efi_bs_call (free_pool, map); fail:return status; }
drivers/firmware/efi/libstub/efistub.h +2 -13
@@ -160,15 +160,6 @@ void efi_set_u64_split(u64 data, u32 *lo, u32 *hi)*/ #define EFI_MMAP_NR_SLACK_SLOTS 8 -struct efi_boot_memmap { -efi_memory_desc_t **map; -unsigned long *map_size; -unsigned long *desc_size; -u32 *desc_ver; -unsigned long *key_ptr; -unsigned long *buff_size; -}; -typedef struct efi_generic_dev_path efi_device_path_protocol_t ;typedef void *efi_event_t ;
@@ -850,9 +841,7 @@ typedef efi_status_t (*efi_exit_boot_map_processing)(struct efi_boot_memmap *map, void *priv); -efi_status_t efi_exit_boot_services (void *handle, -struct efi_boot_memmap *map, -void *priv, +efi_status_t efi_exit_boot_services (void *handle,void *priv,efi_exit_boot_map_processing priv_func); efi_status_t allocate_new_fdt_and_exit_boot(void *handle,
@@ -891,7 +880,7 @@ void efi_apply_loadoptions_quirk(const void **load_options, int *load_options_sichar *efi_convert_cmdline (efi_loaded_image_t *image,int *cmd_line_len); -efi_status_t efi_get_memory_map (struct efi_boot_memmap *map); +efi_status_t efi_get_memory_map (struct efi_boot_memmap **map);efi_status_t efi_allocate_pages (unsigned long size,unsigned long *addr,unsigned long max);
drivers/firmware/efi/libstub/fdt.c +16 -21
@@ -170,25 +170,25 @@ static efi_status_t update_fdt_memmap(void *fdt, struct efi_boot_memmap *map)if (node <0 )return EFI_LOAD_ERROR ; - fdt_val64 =cpu_to_fdt64 ((unsigned long )*map->map); + fdt_val64 =cpu_to_fdt64 ((unsigned long )map->map); err =fdt_setprop_inplace_var (fdt, node,"linux,uefi-mmap-start" , fdt_val64);if (err)return EFI_LOAD_ERROR ; - fdt_val32 =cpu_to_fdt32 (*map->map_size); + fdt_val32 =cpu_to_fdt32 (map->map_size); err =fdt_setprop_inplace_var (fdt, node,"linux,uefi-mmap-size" , fdt_val32);if (err)return EFI_LOAD_ERROR ; - fdt_val32 =cpu_to_fdt32 (*map->desc_size); + fdt_val32 =cpu_to_fdt32 (map->desc_size); err =fdt_setprop_inplace_var (fdt, node,"linux,uefi-mmap-desc-size" , fdt_val32);if (err)return EFI_LOAD_ERROR ; - fdt_val32 =cpu_to_fdt32 (*map->desc_ver); + fdt_val32 =cpu_to_fdt32 (map->desc_ver); err =fdt_setprop_inplace_var (fdt, node,"linux,uefi-mmap-desc-ver" , fdt_val32);if (err)
@@ -198,22 +198,25 @@ static efi_status_t update_fdt_memmap(void *fdt, struct efi_boot_memmap *map) }struct exit_boot_struct { +struct efi_boot_memmap *boot_memmap;efi_memory_desc_t *runtime_map;int runtime_entry_count;void *new_fdt_addr; }; -static efi_status_t exit_boot_func (struct efi_boot_memmap *map, -void *priv) +static efi_status_t exit_boot_func (struct efi_boot_memmap *map,void *priv) {struct exit_boot_struct *p = priv; + + p->boot_memmap = map; +/* * Update the memory map with virtual addresses. The function will also * populate @runtime_map with copies of just the EFI_MEMORY_RUNTIME * entries so that we can pass it straight to SetVirtualAddressMap() */ if (!efi_novamap) -efi_get_virtmap (*map->map, *map->map_size, *map->desc_size, +efi_get_virtmap (map->map, map->map_size, map->desc_size, p->runtime_map, &p->runtime_entry_count);return update_fdt_memmap (p->new_fdt_addr, map);
@@ -244,20 +247,11 @@ efi_status_t allocate_new_fdt_and_exit_boot(void *handle, unsigned long fdt_addr, unsigned long fdt_size) { -unsigned long map_size, desc_size, buff_size; +unsigned long desc_size;u32 desc_ver; -unsigned long mmap_key; -efi_memory_desc_t *memory_map;efi_status_t status; -struct efi_boot_memmap map;struct exit_boot_struct priv; - map.map_size = &map_size; - map.desc_size = &desc_size; - map.desc_ver = &desc_ver; - map.key_ptr = &mmap_key; - map.buff_size = &buff_size; -if (!efi_novamap) { status =efi_alloc_virtmap (&priv.runtime_map, &desc_size, &desc_ver);
@@ -269,7 +263,6 @@ efi_status_t allocate_new_fdt_and_exit_boot(void *handle,efi_info ("Exiting boot services...\n" ); - map.map = &memory_map; status =efi_allocate_pages (MAX_FDT_SIZE , new_fdt_addr,ULONG_MAX );if (status !=EFI_SUCCESS ) {efi_err ("Unable to allocate memory for new device tree.\n" );
@@ -287,7 +280,7 @@ efi_status_t allocate_new_fdt_and_exit_boot(void *handle, priv.new_fdt_addr = (void *)*new_fdt_addr; - status =efi_exit_boot_services (handle, &map, &priv, exit_boot_func); + status =efi_exit_boot_services (handle, &priv, exit_boot_func);if (status ==EFI_SUCCESS ) {efi_set_virtual_address_map_t *svam;
@@ -306,6 +299,7 @@ efi_status_t allocate_new_fdt_and_exit_boot(void *handle,* incoming kernel but proceed normally otherwise. */ if (status !=EFI_SUCCESS ) { +efi_memory_desc_t *p;int l;/*
@@ -314,8 +308,9 @@ efi_status_t allocate_new_fdt_and_exit_boot(void *handle,* the incoming kernel that no virtual translation has * been installed. */ -for (l =0 ; l < map_size; l += desc_size) { -efi_memory_desc_t *p = (void *)memory_map + l; +for (l =0 ; l < priv.boot_memmap->map_size; + l += priv.boot_memmap->desc_size) { + p = (void *)priv.boot_memmap->map + l;if (p->attribute &EFI_MEMORY_RUNTIME ) p->virt_addr =0 ;
drivers/firmware/efi/libstub/mem.c +24 -50
95 lines not on this page · raw message
drivers/firmware/efi/libstub/randomalloc.c +7 -16
@@ -55,20 +55,11 @@ efi_status_t efi_random_alloc(unsigned long size,unsigned long *addr, unsigned long random_seed) { - unsigned long map_size, desc_size, total_slots = 0, target_slot; + unsigned long total_slots = 0, target_slot;unsigned long total_mirrored_slots =0 ; -unsigned long buff_size; +struct efi_boot_memmap *map;efi_status_t status; -efi_memory_desc_t *memory_map;int map_offset; -struct efi_boot_memmap map; - - map.map = &memory_map; - map.map_size = &map_size; - map.desc_size = &desc_size; - map.desc_ver =NULL ; - map.key_ptr =NULL ; - map.buff_size = &buff_size; status =efi_get_memory_map (&map);if (status !=EFI_SUCCESS )
@@ -80,8 +71,8 @@ efi_status_t efi_random_alloc(unsigned long size, size =round_up (size,EFI_ALLOC_ALIGN );/* count the suitable slots in each memory map entry */ -for (map_offset =0 ; map_offset < map_size; map_offset += desc_size) { -efi_memory_desc_t *md = (void *)memory_map + map_offset; +for (map_offset =0 ; map_offset < map->map_size; map_offset += map->desc_size) { +efi_memory_desc_t *md = (void *)map->map + map_offset;unsigned long slots; slots =get_entry_num_slots (md, size,ilog2 (align));
@@ -109,8 +100,8 @@ efi_status_t efi_random_alloc(unsigned long size,* to calculate the randomly chosen address, and allocate it directly * using EFI_ALLOCATE_ADDRESS. */ -for (map_offset =0 ; map_offset < map_size; map_offset += desc_size) { -efi_memory_desc_t *md = (void *)memory_map + map_offset; +for (map_offset =0 ; map_offset < map->map_size; map_offset += map->desc_size) { +efi_memory_desc_t *md = (void *)map->map + map_offset;efi_physical_addr_t target;unsigned long pages;
@@ -133,7 +124,7 @@ efi_status_t efi_random_alloc(unsigned long size,break ; } -efi_bs_call (free_pool, memory_map); +efi_bs_call (free_pool, map);return status; }
drivers/firmware/efi/libstub/relocate.c +6 -15
@@ -23,21 +23,12 @@efi_status_t efi_low_alloc_above (unsigned long size,unsigned long align,unsigned long *addr,unsigned long min) { -unsigned long map_size, desc_size, buff_size; -efi_memory_desc_t *map; +struct efi_boot_memmap *map;efi_status_t status;unsigned long nr_pages;int i; -struct efi_boot_memmap boot_map; - boot_map.map = ↦ - boot_map.map_size = &map_size; - boot_map.desc_size = &desc_size; - boot_map.desc_ver =NULL ; - boot_map.key_ptr =NULL ; - boot_map.buff_size = &buff_size; - - status =efi_get_memory_map (&boot_map); + status =efi_get_memory_map (&map);if (status !=EFI_SUCCESS ) goto fail;
@@ -52,12 +43,12 @@ efi_status_t efi_low_alloc_above(unsigned long size, unsigned long align, size =round_up (size,EFI_ALLOC_ALIGN ); nr_pages = size /EFI_PAGE_SIZE ; -for (i =0 ; i < map_size / desc_size; i++) { +for (i =0 ; i < map->map_size / map->desc_size; i++) {efi_memory_desc_t *desc; -unsigned long m = (unsigned long )map; +unsigned long m = (unsigned long )map->map;u64 start, end; - desc =efi_early_memdesc_ptr (m, desc_size, i); + desc =efi_early_memdesc_ptr (m, map->desc_size, i);if (desc->type !=EFI_CONVENTIONAL_MEMORY )continue ;
@@ -87,7 +78,7 @@ efi_status_t efi_low_alloc_above(unsigned long size, unsigned long align, } } -if (i == map_size / desc_size) +if (i == map->map_size / map->desc_size) status =EFI_NOT_FOUND ;efi_bs_call (free_pool, map);
drivers/firmware/efi/libstub/x86-stub.c +5 -15
@@ -716,32 +716,22 @@ static efi_status_t exit_boot_func(struct efi_boot_memmap *map,efi_set_u64_split ((unsigned long )efi_system_table, &p->efi->efi_systab, &p->efi->efi_systab_hi); - p->efi->efi_memdesc_size = *map->desc_size; - p->efi->efi_memdesc_version = *map->desc_ver; -efi_set_u64_split ((unsigned long )*map->map, + p->efi->efi_memdesc_size = map->desc_size; + p->efi->efi_memdesc_version = map->desc_ver; +efi_set_u64_split ((unsigned long )map->map, &p->efi->efi_memmap, &p->efi->efi_memmap_hi); - p->efi->efi_memmap_size = *map->map_size; + p->efi->efi_memmap_size = map->map_size;return EFI_SUCCESS ; }static efi_status_t exit_boot (struct boot_params *boot_params,void *handle) { -unsigned long map_sz, key, desc_size, buff_size; -efi_memory_desc_t *mem_map;struct setup_data *e820ext =NULL ;__u32 e820ext_size =0 ;efi_status_t status; -__u32 desc_version; -struct efi_boot_memmap map;struct exit_boot_struct priv; - map.map = &mem_map; - map.map_size = &map_sz; - map.desc_size = &desc_size; - map.desc_ver = &desc_version; - map.key_ptr = &key; - map.buff_size = &buff_size; priv.boot_params = boot_params; priv.efi = &boot_params->efi_info;
@@ -750,7 +740,7 @@ static efi_status_t exit_boot(struct boot_params *boot_params, void *handle)return status;/* Might as well exit boot services now */ - status =efi_exit_boot_services (handle, &map, &priv, exit_boot_func); + status =efi_exit_boot_services (handle, &priv, exit_boot_func);if (status !=EFI_SUCCESS )return status;
include/linux/efi.h +9 -0
@@ -518,6 +518,15 @@ typedef union {efi_system_table_32_t mixed_mode; } efi_system_table_t; +struct efi_boot_memmap { +unsigned long map_size; +unsigned long desc_size; +u32 desc_ver; +unsigned long map_key; +unsigned long buff_size; +efi_memory_desc_t map[]; +}; +/* * Architecture independent structure for describing a memory map for the * benefit of efi_memmap_init_early(), and for passing context between
Signature · 1 line
2.35.1
Ard Biesheuvel
maintainerPATCH v2 4/8 efi: libstub: remove pointless goto kludge
In reply to Ard BiesheuvelRemove some goto cruft that serves no purpose and obfuscates the code.
--- drivers/firmware/efi/libstub/efi-stub-helper.c | 22 +++++++------------- 1 file changed, 7 insertions(+), 15 deletions(-)
drivers/firmware/efi/libstub/efi-stub-helper.c +7 -15
@@ -438,13 +438,14 @@ efi_status_t efi_exit_boot_services(void *handle, void *priv,efi_status_t status; status =efi_get_memory_map (&map); -if (status !=EFI_SUCCESS ) - goto fail; +return status; status =priv_func (map, priv); -if (status !=EFI_SUCCESS ) - goto free_map; +if (status !=EFI_SUCCESS ) { +efi_bs_call (free_pool, map); +return status; + }if (efi_disable_pci_dma)efi_pci_disable_bridge_busmaster ();
@@ -475,25 +476,16 @@ efi_status_t efi_exit_boot_services(void *handle, void *priv,/* exit_boot_services() was called, thus cannot free */ if (status !=EFI_SUCCESS ) - goto fail; +return status; status =priv_func (map, priv);/* exit_boot_services() was called, thus cannot free */ if (status !=EFI_SUCCESS ) - goto fail; +return status; status =efi_bs_call (exit_boot_services, handle, map->map_key); } -/* exit_boot_services() was called, thus cannot free */ -if (status !=EFI_SUCCESS ) - goto fail; - -return EFI_SUCCESS ; - -free_map: -efi_bs_call (free_pool, map); -fail:return status; }
Signature · 1 line
2.35.1
Ard Biesheuvel
maintainerPATCH v2 5/8 efi: libstub: unify initrd loading between architectures
In reply to Ard BiesheuvelUse a EFI configuration table to pass the initrd to the core kernel, instead of per-arch methods. This cleans up the code considerably, and should make it easier for architectures to get rid of their reliance on DT for doing EFI boot in the future.
--- Documentation/arm/uefi.rst | 4 - drivers/firmware/efi/efi.c | 15 ++++ drivers/firmware/efi/libstub/efi-stub-helper.c | 93 +++++++++++--------- drivers/firmware/efi/libstub/efi-stub.c | 14 ++- drivers/firmware/efi/libstub/efistub.h | 3 - drivers/firmware/efi/libstub/fdt.c | 41 +++------ drivers/firmware/efi/libstub/x86-stub.c | 10 +-- include/linux/efi.h | 5 ++ 8 files changed, 85 insertions(+), 100 deletions(-)
Documentation/arm/uefi.rst +0 -4
@@ -65,10 +65,6 @@ linux,uefi-mmap-desc-size 32-bit Size in bytes of each entry in the UEFI linux,uefi-mmap-desc-ver 32-bit Version of the mmap descriptor format. -linux,initrd-start 64-bit Physical start address of an initrd - -linux,initrd-end 64-bit Physical end address of an initrd - kaslr-seed 64-bit Entropy used to randomize the kernel image base address location. ========================== ====== ===========================================
drivers/firmware/efi/efi.c +15 -0
@@ -21,6 +21,7 @@#include <linux/device.h> #include <linux/efi.h> #include <linux/of.h> +#include <linux/initrd.h> #include <linux/io.h> #include <linux/kexec.h> #include <linux/platform_device.h>
@@ -55,6 +56,7 @@ EXPORT_SYMBOL(efi);unsigned long __ro_after_init efi_rng_seed =EFI_INVALID_TABLE_ADDR ;static unsigned long __initdata mem_reserve =EFI_INVALID_TABLE_ADDR ;static unsigned long __initdata rt_prop =EFI_INVALID_TABLE_ADDR ; +static unsigned long __initdata initrd =EFI_INVALID_TABLE_ADDR ;struct mm_struct efi_mm = { .mm_rb =RB_ROOT ,
@@ -532,6 +534,7 @@ static const efi_config_table_type_t common_tables[] __initconst = { {LINUX_EFI_TPM_EVENT_LOG_GUID, &efi.tpm_log, "TPMEventLog" }, {LINUX_EFI_TPM_FINAL_LOG_GUID, &efi.tpm_final_log, "TPMFinalLog" }, {LINUX_EFI_MEMRESERVE_TABLE_GUID, &mem_reserve, "MEMRESERVE" }, + {LINUX_EFI_INITRD_MEDIA_GUID, &initrd, "INITRD" }, {EFI_RT_PROPERTIES_TABLE_GUID, &rt_prop, "RTPROP" }, #ifdef CONFIG_EFI_RCI2_TABLE {DELLEMC_EFI_RCI2_TABLE_GUID, &rci2_table_phys },
@@ -674,6 +677,18 @@ int __init efi_config_parse_tables(const efi_config_table_t *config_tables, } } +if (IS_ENABLED (CONFIG_BLK_DEV_INITRD ) && + initrd !=EFI_INVALID_TABLE_ADDR ) { +struct linux_efi_initrd *tbl; + + tbl =early_memremap (initrd,sizeof (*tbl)); +if (tbl) { + phys_initrd_start = tbl->base; + phys_initrd_size = tbl->size; +early_memunmap (tbl,sizeof (*tbl)); + } + } +return 0 ; }
drivers/firmware/efi/libstub/efi-stub-helper.c +49 -44
153 lines not on this page · raw message
drivers/firmware/efi/libstub/efi-stub.c +5 -9
@@ -132,8 +132,6 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,unsigned long image_addr;unsigned long image_size =0 ;/* addr/point and size pairs for memory management*/ -unsigned long initrd_addr =0 ; -unsigned long initrd_size =0 ;unsigned long fdt_addr =0 ;/* Original DTB */ unsigned long fdt_size =0 ;char *cmdline_ptr =NULL ;
@@ -249,7 +247,7 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,if (!fdt_addr)efi_info ("Generating empty DTB\n" ); -efi_load_initrd (image, &initrd_addr, &initrd_size,ULONG_MAX , +efi_load_initrd (image,ULONG_MAX ,efi_get_max_initrd_addr (image_addr));efi_random_get_seed ();
@@ -292,11 +290,10 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,install_memreserve_table (); - status =allocate_new_fdt_and_exit_boot (handle, &fdt_addr, - initrd_addr, initrd_size, - cmdline_ptr, fdt_addr, fdt_size); + status =allocate_new_fdt_and_exit_boot (handle, &fdt_addr, cmdline_ptr, + fdt_addr, fdt_size);if (status !=EFI_SUCCESS ) - goto fail_free_initrd; + goto fail_free_fdt;if (IS_ENABLED (CONFIG_ARM ))efi_handle_post_ebs_state ();
@@ -304,10 +301,9 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,efi_enter_kernel (image_addr, fdt_addr,fdt_totalsize ((void *)fdt_addr));/* not reached */ -fail_free_initrd: +fail_free_fdt:efi_err ("Failed to update FDT and exit boot services\n" ); -efi_free (initrd_size, initrd_addr);efi_free (fdt_size, fdt_addr); fail_free_image:
drivers/firmware/efi/libstub/efistub.h +0 -3
@@ -846,7 +846,6 @@ efi_status_t efi_exit_boot_services(void *handle, void *priv,efi_status_t allocate_new_fdt_and_exit_boot (void *handle,unsigned long *new_fdt_addr, -u64 initrd_addr,u64 initrd_size,char *cmdline_ptr,unsigned long fdt_addr,unsigned long fdt_size);
@@ -923,8 +922,6 @@ static inline efi_status_t efi_load_dtb(efi_loaded_image_t *image, }efi_status_t efi_load_initrd (efi_loaded_image_t *image, -unsigned long *load_addr, -unsigned long *load_size,unsigned long soft_limit,unsigned long hard_limit);/*
drivers/firmware/efi/libstub/fdt.c +10 -31
69 lines not on this page · raw message
drivers/firmware/efi/libstub/x86-stub.c +1 -9
@@ -766,7 +766,6 @@ unsigned long efi_main(efi_handle_t handle,unsigned long bzimage_addr = (unsigned long )startup_32;unsigned long buffer_start, buffer_end;struct setup_header *hdr = &boot_params->hdr; -unsigned long addr, size;efi_status_t status; efi_system_table = sys_table_arg;
@@ -861,16 +860,9 @@ unsigned long efi_main(efi_handle_t handle,* arguments will be processed only if image is not NULL, which will be * the case only if we were loaded via the PE entry point. */ - status =efi_load_initrd (image, &addr, &size, hdr->initrd_addr_max, -ULONG_MAX ); + status =efi_load_initrd (image, hdr->initrd_addr_max,ULONG_MAX );if (status !=EFI_SUCCESS ) goto fail; -if (size >0 ) { -efi_set_u64_split (addr, &hdr->ramdisk_image, - &boot_params->ext_ramdisk_image); -efi_set_u64_split (size, &hdr->ramdisk_size, - &boot_params->ext_ramdisk_size); - }/* * If the boot loader gave us a value for secure_boot then we use that,
include/linux/efi.h +5 -0
@@ -1330,6 +1330,11 @@ struct linux_efi_coco_secret_area {u64 size; }; +struct linux_efi_initrd { +unsigned long base; +unsigned long size; +}; +/* Header of a populated EFI secret area */ #define EFI_SECRET_TABLE_HEADER_GUID EFI_GUID(0x1e74f542, 0x71dd, 0x4d66, 0x96, 0x3e, 0xef, 0x42, 0x87, 0xff, 0x17, 0x3b)
Signature · 1 line
2.35.1
Ard Biesheuvel
maintainerPATCH v2 6/8 efi: libstub: remove DT dependency from generic stub
In reply to Ard BiesheuvelRefactor the generic EFI stub entry code so that all the dependencies on device tree are abstracted and hidden behind a generic efi_boot_kernel() routine that can also be implemented in other ways. This allows users of the generic stub to avoid using FDT for passing information to the core kernel.
--- drivers/firmware/efi/libstub/efi-stub.c | 53 +---------------- drivers/firmware/efi/libstub/efistub.h | 7 +-- drivers/firmware/efi/libstub/fdt.c | 61 ++++++++++++++++++-- 3 files changed, 60 insertions(+), 61 deletions(-)
drivers/firmware/efi/libstub/efi-stub.c +1 -52
@@ -10,7 +10,6 @@*/ #include <linux/efi.h> -#include <linux/libfdt.h> #include <asm/efi.h> #include "efistub.h"
@@ -132,14 +131,11 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,unsigned long image_addr;unsigned long image_size =0 ;/* addr/point and size pairs for memory management*/ -unsigned long fdt_addr =0 ;/* Original DTB */ -unsigned long fdt_size =0 ;char *cmdline_ptr =NULL ;int cmdline_size =0 ;efi_guid_t loaded_image_proto =LOADED_IMAGE_PROTOCOL_GUID ;unsigned long reserve_addr =0 ;unsigned long reserve_size =0 ; -enum efi_secureboot_mode secure_boot;struct screen_info *si;efi_properties_table_t *prop_tbl;
@@ -215,38 +211,6 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,/* Ask the firmware to clear memory on unclean shutdown */ efi_enable_reset_attack_mitigation (); - secure_boot =efi_get_secureboot (); - -/* -* Unauthenticated device tree data is a security hazard, so ignore -* 'dtb=' unless UEFI Secure Boot is disabled. We assume that secure -* boot is enabled if we can't determine its state. -*/ -if (!IS_ENABLED (CONFIG_EFI_ARMSTUB_DTB_LOADER ) || - secure_boot != efi_secureboot_mode_disabled) { -if (strstr (cmdline_ptr,"dtb=" )) -efi_err ("Ignoring DTB from command line.\n" ); - }else { - status =efi_load_dtb (image, &fdt_addr, &fdt_size); - -if (status !=EFI_SUCCESS ) { -efi_err ("Failed to load device tree!\n" ); - goto fail_free_image; - } - } - -if (fdt_addr) { -efi_info ("Using DTB from command line\n" ); - }else { -/* Look for a device tree configuration table entry. */ - fdt_addr = (uintptr_t )get_fdt (&fdt_size); -if (fdt_addr) -efi_info ("Using DTB from configuration table\n" ); - } - -if (!fdt_addr) -efi_info ("Generating empty DTB\n" ); -efi_load_initrd (image,ULONG_MAX ,efi_get_max_initrd_addr (image_addr));
@@ -290,23 +254,8 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,install_memreserve_table (); - status =allocate_new_fdt_and_exit_boot (handle, &fdt_addr, cmdline_ptr, - fdt_addr, fdt_size); -if (status !=EFI_SUCCESS ) - goto fail_free_fdt; - -if (IS_ENABLED (CONFIG_ARM )) -efi_handle_post_ebs_state (); - -efi_enter_kernel (image_addr, fdt_addr,fdt_totalsize ((void *)fdt_addr)); -/* not reached */ - -fail_free_fdt: -efi_err ("Failed to update FDT and exit boot services\n" ); - -efi_free (fdt_size, fdt_addr); + status =efi_boot_kernel (handle, image, image_addr, cmdline_ptr); -fail_free_image:efi_free (image_size, image_addr);efi_free (reserve_size, reserve_addr); fail_free_screeninfo:
drivers/firmware/efi/libstub/efistub.h +2 -5
@@ -844,11 +844,8 @@ typedef efi_status_t (*efi_exit_boot_map_processing)(efi_status_t efi_exit_boot_services (void *handle,void *priv,efi_exit_boot_map_processing priv_func); -efi_status_t allocate_new_fdt_and_exit_boot (void *handle, -unsigned long *new_fdt_addr, -char *cmdline_ptr, -unsigned long fdt_addr, -unsigned long fdt_size); +efi_status_t efi_boot_kernel (void *handle,efi_loaded_image_t *image, +unsigned long kernel_addr,char *cmdline_ptr);void *get_fdt (unsigned long *fdt_size);
drivers/firmware/efi/libstub/fdt.c +57 -4
91 lines not on this page · raw message
Signature · 1 line
2.35.1
Ard Biesheuvel
maintainerPATCH v2 7/8 efi: libstub: install boot-time memory map as config table
In reply to Ard BiesheuvelExpose the EFI boot time memory map to the kernel via a configuration table. This is arch agnostic and enables future changes that remove the dependency on DT on architectures that don't otherwise rely on it.
--- drivers/firmware/efi/libstub/arm64-stub.c | 2 +- drivers/firmware/efi/libstub/efi-stub-helper.c | 2 +- drivers/firmware/efi/libstub/efistub.h | 3 ++- drivers/firmware/efi/libstub/mem.c | 27 +++++++++++++++++--- drivers/firmware/efi/libstub/randomalloc.c | 2 +- drivers/firmware/efi/libstub/relocate.c | 2 +- include/linux/efi.h | 1 + 7 files changed, 31 insertions(+), 8 deletions(-)
drivers/firmware/efi/libstub/arm64-stub.c +1 -1
@@ -47,7 +47,7 @@ static bool check_image_region(u64 base, u64 size)bool ret = false;int map_offset; - status =efi_get_memory_map (&map); + status =efi_get_memory_map (&map, false);if (status !=EFI_SUCCESS )return false;
drivers/firmware/efi/libstub/efi-stub-helper.c +1 -1
@@ -437,7 +437,7 @@ efi_status_t efi_exit_boot_services(void *handle, void *priv,struct efi_boot_memmap *map;efi_status_t status; - status =efi_get_memory_map (&map); + status =efi_get_memory_map (&map, true);if (status !=EFI_SUCCESS )return status;
drivers/firmware/efi/libstub/efistub.h +2 -1
@@ -876,7 +876,8 @@ void efi_apply_loadoptions_quirk(const void **load_options, int *load_options_sichar *efi_convert_cmdline (efi_loaded_image_t *image,int *cmd_line_len); -efi_status_t efi_get_memory_map (struct efi_boot_memmap **map); +efi_status_t efi_get_memory_map (struct efi_boot_memmap **map, +bool install_cfg_tbl);efi_status_t efi_allocate_pages (unsigned long size,unsigned long *addr,unsigned long max);
drivers/firmware/efi/libstub/mem.c +24 -3
@@ -9,14 +9,20 @@* efi_get_memory_map() - get memory map * @map: pointer to memory map pointer to which to assign the * newly allocated memory map +* @install_cfg_tbl: whether or not to install the boot memory map as a +* configuration table * * Retrieve the UEFI memory map. The allocated memory leaves room for * up to EFI_MMAP_NR_SLACK_SLOTS additional memory map entries. * * Return: status code */ -efi_status_t efi_get_memory_map (struct efi_boot_memmap **map) +efi_status_t efi_get_memory_map (struct efi_boot_memmap **map, +bool install_cfg_tbl) { +int memtype = install_cfg_tbl ?EFI_ACPI_RECLAIM_MEMORY + :EFI_LOADER_DATA ; +efi_guid_t tbl_guid =LINUX_EFI_BOOT_MEMMAP_GUID ;struct efi_boot_memmap *m, tmp;efi_status_t status;unsigned long size;
@@ -28,20 +34,35 @@ efi_status_t efi_get_memory_map(struct efi_boot_memmap **map)return EFI_LOAD_ERROR ; size = tmp.map_size + tmp.desc_size *EFI_MMAP_NR_SLACK_SLOTS ; - status =efi_bs_call (allocate_pool,EFI_LOADER_DATA ,sizeof (*m) + size, + status =efi_bs_call (allocate_pool, memtype,sizeof (*m) + size, (void **)&m);if (status !=EFI_SUCCESS )return status; +if (install_cfg_tbl) { +/* +* Installing a configuration table might allocate memory, and +* this may modify the memory map. This means we should install +* the configuration table first, and re-install or delete it +* as needed. +*/ + status =efi_bs_call (install_configuration_table, &tbl_guid, m); +if (status !=EFI_SUCCESS ) + goto free_map; + } + m->buff_size = m->map_size = size; status =efi_bs_call (get_memory_map, &m->map_size, m->map, &m->map_key, &m->desc_size, &m->desc_ver);if (status !=EFI_SUCCESS ) - goto free_map; + goto uninstall_table; *map = m;return EFI_SUCCESS ; +uninstall_table: +if (install_cfg_tbl) +efi_bs_call (install_configuration_table, &tbl_guid,NULL ); free_map:efi_bs_call (free_pool, m);return status;
drivers/firmware/efi/libstub/randomalloc.c +1 -1
@@ -61,7 +61,7 @@ efi_status_t efi_random_alloc(unsigned long size,efi_status_t status;int map_offset; - status =efi_get_memory_map (&map); + status =efi_get_memory_map (&map, false);if (status !=EFI_SUCCESS )return status;
drivers/firmware/efi/libstub/relocate.c +1 -1
@@ -28,7 +28,7 @@ efi_status_t efi_low_alloc_above(unsigned long size, unsigned long align,unsigned long nr_pages;int i; - status =efi_get_memory_map (&map); + status =efi_get_memory_map (&map, false);if (status !=EFI_SUCCESS ) goto fail;
include/linux/efi.h +1 -0
@@ -410,6 +410,7 @@ void efi_native_runtime_setup(void);#define LINUX_EFI_INITRD_MEDIA_GUID EFI_GUID(0x5568e427, 0x68fc, 0x4f3d, 0xac, 0x74, 0xca, 0x55, 0x52, 0x31, 0xcc, 0x68)#define LINUX_EFI_MOK_VARIABLE_TABLE_GUID EFI_GUID(0xc451ed2b, 0x9694, 0x45d3, 0xba, 0xba, 0xed, 0x9f, 0x89, 0x88, 0xa3, 0x89)#define LINUX_EFI_COCO_SECRET_AREA_GUID EFI_GUID(0xadf956ad, 0xe98c, 0x484c, 0xae, 0x11, 0xb5, 0x1c, 0x7d, 0x33, 0x64, 0x47) +#define LINUX_EFI_BOOT_MEMMAP_GUID EFI_GUID(0x800f683f, 0xd08b, 0x423a, 0xa2, 0x93, 0x96, 0x5c, 0x3c, 0x6f, 0xe2, 0xb4)#define RISCV_EFI_BOOT_PROTOCOL_GUID EFI_GUID(0xccd15fec, 0x6f73, 0x4eec, 0x83, 0x95, 0x3e, 0x69, 0xe4, 0xb9, 0x40, 0xbf)
Signature · 1 line
2.35.1
Ard Biesheuvel
maintainerPATCH v2 8/8 efi/loongarch: libstub: remove dependency on flattened DT
In reply to Ard BiesheuvelLoongArch does not use FDT or DT natively [yet], and the only reason it currently uses it is so that it can reuse the existing EFI stub code.
Overloading the DT with data passed between the EFI stub and the core kernel has been a source of problems: there is the overlap between information provided by EFI which DT can also provide (initrd base/size, command line, memory descriptions), requiring us to reason about which is which and what to prioritize. It has also resulted in ABI leaks, i.e., internal ABI being promoted to external ABI inadvertently because the bootloader can set the EFI stub's DT properties as well (e.g., "kaslr-seed"). This has become especially problematic with boot environments that want to pretend that EFI boot is being done (to access ACPI and SMBIOS tables, for instance) but have no ability to execute the EFI stub, and so the environment that the EFI stub creates is emulated [poorly, in some cases].
Another downside of treating DT like this is that the DT binary that the kernel receives is different from the one created by the firmware, which is undesirable in the context of secure and measured boot.
Given that LoongArch support in Linux is brand new, we can avoid these pitfalls, and treat the DT strictly as a hardware description, and use a separate handover method between the EFI stub and the kernel. Now that initrd loading and passing the EFI memory map have been refactored into pure EFI routines that use EFI configuration tables, the only thing we need to pass directly is the kernel command line (even if we could pass this via a config table as well, it is used extremely early, so passing it directly is preferred in this case.)
--- arch/loongarch/Kconfig | 3 -- arch/loongarch/include/asm/bootinfo.h | 2 +- arch/loongarch/kernel/efi.c | 30 ++++++++++- arch/loongarch/kernel/env.c | 13 ++--- arch/loongarch/kernel/head.S | 2 + arch/loongarch/kernel/setup.c | 4 +- drivers/firmware/efi/libstub/Makefile | 13 +++-- drivers/firmware/efi/libstub/loongarch-stub.c | 56 +++++++++++++++++--- 8 files changed, 95 insertions(+), 28 deletions(-)
arch/loongarch/Kconfig +0 -3
@@ -104,8 +104,6 @@ config LOONGARCH select MODULES_USE_ELF_RELA if MODULES select NEED_PER_CPU_EMBED_FIRST_CHUNK select NEED_PER_CPU_PAGE_FIRST_CHUNK - select OF - select OF_EARLY_FLATTREE select PCI select PCI_DOMAINS_GENERIC select PCI_ECAM if ACPI
@@ -311,7 +309,6 @@ config DMI config EFI bool "EFI runtime service support" select UCS2_STRING - select EFI_PARAMS_FROM_FDT select EFI_RUNTIME_WRAPPERS help This enables the kernel to use EFI runtime services that are
arch/loongarch/include/asm/bootinfo.h +1 -1
@@ -36,7 +36,7 @@ struct loongson_system_configuration { };extern u64 efi_system_table; -extern unsigned long fw_arg0, fw_arg1; +extern unsigned long fw_arg0, fw_arg1, fw_arg2;extern struct loongson_board_info b_info;extern struct loongson_system_configuration loongson_sysconf;
arch/loongarch/kernel/efi.c +29 -1
@@ -27,8 +27,13 @@static unsigned long efi_nr_tables;static unsigned long efi_config_table; +static unsigned long __initdata boot_memmap =EFI_INVALID_TABLE_ADDR ; +static efi_system_table_t *efi_systab; -static efi_config_table_type_t arch_tables[]__initdata = {{},}; +static efi_config_table_type_t arch_tables[]__initdata = { + {LINUX_EFI_BOOT_MEMMAP_GUID , &boot_memmap,"MEMMAP" }, + {}, +};void __init efi_runtime_init (void ) {
@@ -51,6 +56,7 @@ void __init efi_init(void) {int size;void *config_tables; +struct efi_boot_memmap *tbl;if (!efi_system_table)return ;
@@ -61,6 +67,8 @@ void __init efi_init(void)return ; } +efi_systab_report_header (&efi_systab->hdr, efi_systab->fw_vendor); +set_bit (EFI_64BIT , &efi.flags); efi_nr_tables = efi_systab->nr_tables; efi_config_table = (unsigned long )efi_systab->tables;
@@ -70,6 +78,26 @@ void __init efi_init(void)efi_config_parse_tables (config_tables, efi_systab->nr_tables, arch_tables);early_memunmap (config_tables, efi_nr_tables * size); +set_bit (EFI_CONFIG_TABLES , &efi.flags); +if (screen_info.orig_video_isVGA ==VIDEO_TYPE_EFI )memblock_reserve (screen_info.lfb_base, screen_info.lfb_size); + +if (boot_memmap ==EFI_INVALID_TABLE_ADDR ) +return ; + + tbl =early_memremap_ro (boot_memmap,sizeof (*tbl)); +if (tbl) { +struct efi_memory_map_data data; + + data.phys_map = boot_memmap +sizeof (*tbl); + data.size = tbl->map_size; + data.desc_size = tbl->desc_size; + data.desc_version = tbl->desc_ver; + +if (efi_memmap_init_early (&data) <0 ) +panic ("Unable to map EFI memory map.\n" ); + +early_memunmap (tbl,sizeof (*tbl)); + } }
arch/loongarch/kernel/env.c +4 -9
@@ -8,7 +8,6 @@#include <linux/efi.h> #include <linux/export.h> #include <linux/memblock.h> -#include <linux/of_fdt.h> #include <asm/early_ioremap.h> #include <asm/bootinfo.h> #include <asm/loongson.h>
@@ -20,21 +19,17 @@ EXPORT_SYMBOL(loongson_sysconf);void __init init_environ (void ) {int efi_boot = fw_arg0; -struct efi_memory_map_data data; -void *fdt_ptr =early_memremap_ro (fw_arg1,SZ_64K ); +char *cmdline =early_memremap_ro (fw_arg1,COMMAND_LINE_SIZE );if (efi_boot)set_bit (EFI_BOOT , &efi.flags);else clear_bit (EFI_BOOT , &efi.flags); -early_init_dt_scan (fdt_ptr); -early_init_fdt_reserve_self (); - efi_system_table =efi_get_fdt_params (&data); +strscpy (boot_command_line, cmdline,COMMAND_LINE_SIZE ); +early_memunmap (cmdline,COMMAND_LINE_SIZE ); -efi_memmap_init_early (&data); -memblock_reserve (data.phys_map &PAGE_MASK , -PAGE_ALIGN (data.size + (data.phys_map & ~PAGE_MASK ))); + efi_system_table = fw_arg2; }static int __init init_cpu_fullname (void )
arch/loongarch/kernel/head.S +2 -0
@@ -67,6 +67,8 @@ SYM_CODE_START(kernel_entry) # kernel entry point st.d a0, t0, 0 # firmware arguments la t0, fw_arg1 st.d a1, t0, 0 + la t0, fw_arg2 + st.d a2, t0, 0 /* KSave3 used for percpu base, initialized as 0 */ csrwr zero, PERCPU_BASE_KS
arch/loongarch/kernel/setup.c +2 -2
@@ -51,7 +51,7 @@ struct screen_info screen_info __section(".data"); -unsigned long fw_arg0, fw_arg1; +unsigned long fw_arg0, fw_arg1, fw_arg2; DEFINE_PER_CPU(unsigned long, kernelsp);struct cpuinfo_loongarch cpu_data[NR_CPUS ]__read_mostly ;
@@ -187,7 +187,6 @@ early_param("mem", early_parse_mem);void __init platform_init (void ) { -efi_init ();#ifdef CONFIG_ACPI_TABLE_UPGRADE acpi_table_upgrade ();#endif
@@ -347,6 +346,7 @@ void __init setup_arch(char **cmdline_p) *cmdline_p = boot_command_line;init_environ (); +efi_init ();memblock_init ();parse_early_param ();
drivers/firmware/efi/libstub/Makefile +8 -5
@@ -29,7 +29,7 @@ cflags-$(CONFIG_RISCV) := $(subst $(CC_FLAGS_FTRACE),,$(KBUILD_CFLAGS)) \ cflags-$(CONFIG_LOONGARCH) := $(subst $(CC_FLAGS_FTRACE),,$(KBUILD_CFLAGS)) \ -fpie -cflags-$(CONFIG_EFI_GENERIC_STUB) += -I$(srctree)/scripts/dtc/libfdt +cflags-$(CONFIG_EFI_PARAMS_FROM_FDT) += -I$(srctree)/scripts/dtc/libfdt KBUILD_CFLAGS := $(cflags-y) -Os -DDISABLE_BRANCH_PROFILING \ -include $(srctree)/include/linux/hidden.h \
@@ -59,14 +59,17 @@ lib-y := efi-stub-helper.o gop.o secureboot.o tpm.o \ skip_spaces.o lib-cmdline.o lib-ctype.o \ alignedmem.o relocate.o vsprintf.o -# include the stub's generic dependencies from lib/ when building for ARM/arm64 -efi-deps-y := fdt_rw.c fdt_ro.c fdt_wip.c fdt.c fdt_empty_tree.c fdt_sw.c +# include the stub's libfdt dependencies from lib/ when needed +libfdt-deps := fdt_rw.c fdt_ro.c fdt_wip.c fdt.c \ + fdt_empty_tree.c fdt_sw.c + +lib-$(CONFIG_EFI_PARAMS_FROM_FDT) += fdt.o \ + $(patsubst %.c,lib-%.o,$(libfdt-deps)) $(obj)/lib-%.o: $(srctree)/lib/%.c FORCE $(call if_changed_rule,cc_o_c) -lib-$(CONFIG_EFI_GENERIC_STUB) += efi-stub.o fdt.o string.o \ - $(patsubst %.c,lib-%.o,$(efi-deps-y)) +lib-$(CONFIG_EFI_GENERIC_STUB) += efi-stub.o string.o lib-$(CONFIG_ARM) += arm32-stub.o lib-$(CONFIG_ARM64) += arm64-stub.o
drivers/firmware/efi/libstub/loongarch-stub.c +49 -7
75 lines not on this page · raw message
Signature · 1 line
2.35.1
Re: [PATCH v2 8/8] efi/loongarch: libstub: remove dependency on flattened DT
Quoted 339 lines · Ard Biesheuvel
LoongArch does not use FDT or DT natively [yet], and the only reason it currently uses it is so that it can reuse the existing EFI stub code.
Overloading the DT with data passed between the EFI stub and the core kernel has been a source of problems: there is the overlap between information provided by EFI which DT can also provide (initrd base/size, command line, memory descriptions), requiring us to reason about which is which and what to prioritize. It has also resulted in ABI leaks, i.e., internal ABI being promoted to external ABI inadvertently because the bootloader can set the EFI stub's DT properties as well (e.g., "kaslr-seed"). This has become especially problematic with boot environments that want to pretend that EFI boot is being done (to access ACPI and SMBIOS tables, for instance) but have no ability to execute the EFI stub, and so the environment that the EFI stub creates is emulated [poorly, in some cases].
Another downside of treating DT like this is that the DT binary that the kernel receives is different from the one created by the firmware, which is undesirable in the context of secure and measured boot.
Given that LoongArch support in Linux is brand new, we can avoid these pitfalls, and treat the DT strictly as a hardware description, and use a separate handover method between the EFI stub and the kernel. Now that initrd loading and passing the EFI memory map have been refactored into pure EFI routines that use EFI configuration tables, the only thing we need to pass directly is the kernel command line (even if we could pass this via a config table as well, it is used extremely early, so passing it directly is preferred in this case.)
Signed-off-by Ard Biesheuvel <[email protected]>--- arch/loongarch/Kconfig | 3 -- arch/loongarch/include/asm/bootinfo.h | 2 +- arch/loongarch/kernel/efi.c | 30 ++++++++++- arch/loongarch/kernel/env.c | 13 ++--- arch/loongarch/kernel/head.S | 2 + arch/loongarch/kernel/setup.c | 4 +- drivers/firmware/efi/libstub/Makefile | 13 +++-- drivers/firmware/efi/libstub/loongarch-stub.c | 56 +++++++++++++++++--- 8 files changed, 95 insertions(+), 28 deletions(-)arch/loongarch/Kconfig +0
-3@@ -104,8 +104,6 @@ config LOONGARCH select MODULES_USE_ELF_RELA if MODULES select NEED_PER_CPU_EMBED_FIRST_CHUNK select NEED_PER_CPU_PAGE_FIRST_CHUNK - select OF - select OF_EARLY_FLATTREE select PCI select PCI_DOMAINS_GENERIC select PCI_ECAM if ACPI@@ -311,7 +309,6 @@ config DMI config EFI bool "EFI runtime service support" select UCS2_STRING - select EFI_PARAMS_FROM_FDT select EFI_RUNTIME_WRAPPERS help This enables the kernel to use EFI runtime services that arearch/loongarch/include/asm/bootinfo.h +1
-1@@ -36,7 +36,7 @@ struct loongson_system_configuration { };extern u64 efi_system_table; -extern unsigned long fw_arg0, fw_arg1; +extern unsigned long fw_arg0, fw_arg1, fw_arg2;extern struct loongson_board_info b_info;extern struct loongson_system_configuration loongson_sysconf;arch/loongarch/kernel/efi.c +29
-1@@ -27,8 +27,13 @@static unsigned long efi_nr_tables;static unsigned long efi_config_table; +static unsigned long __initdata boot_memmap =EFI_INVALID_TABLE_ADDR ; +static efi_system_table_t *efi_systab; -static efi_config_table_type_t arch_tables[]__initdata = {{},}; +static efi_config_table_type_t arch_tables[]__initdata = { + {LINUX_EFI_BOOT_MEMMAP_GUID , &boot_memmap,"MEMMAP" }, + {}, +};void __init efi_runtime_init (void ) {@@ -51,6 +56,7 @@ void __init efi_init(void) {int size;void *config_tables; +struct efi_boot_memmap *tbl;if (!efi_system_table)return ;@@ -61,6 +67,8 @@ void __init efi_init(void)return ; } +efi_systab_report_header (&efi_systab->hdr, efi_systab->fw_vendor); +set_bit (EFI_64BIT , &efi.flags); efi_nr_tables = efi_systab->nr_tables; efi_config_table = (unsigned long )efi_systab->tables;@@ -70,6 +78,26 @@ void __init efi_init(void)efi_config_parse_tables (config_tables, efi_systab->nr_tables, arch_tables);early_memunmap (config_tables, efi_nr_tables * size); +set_bit (EFI_CONFIG_TABLES , &efi.flags); +if (screen_info.orig_video_isVGA ==VIDEO_TYPE_EFI )memblock_reserve (screen_info.lfb_base, screen_info.lfb_size); + +if (boot_memmap ==EFI_INVALID_TABLE_ADDR ) +return ; + + tbl =early_memremap_ro (boot_memmap,sizeof (*tbl)); +if (tbl) { +struct efi_memory_map_data data; + + data.phys_map = boot_memmap +sizeof (*tbl); + data.size = tbl->map_size; + data.desc_size = tbl->desc_size; + data.desc_version = tbl->desc_ver; + +if (efi_memmap_init_early (&data) <0 ) +panic ("Unable to map EFI memory map.\n" ); + +early_memunmap (tbl,sizeof (*tbl)); + } }arch/loongarch/kernel/env.c +4
-9@@ -8,7 +8,6 @@#include <linux/efi.h> #include <linux/export.h> #include <linux/memblock.h> -#include <linux/of_fdt.h> #include <asm/early_ioremap.h> #include <asm/bootinfo.h> #include <asm/loongson.h> @@ -20,21 +19,17 @@ EXPORT_SYMBOL(loongson_sysconf);void __init init_environ (void ) {int efi_boot = fw_arg0; -struct efi_memory_map_data data; -void *fdt_ptr =early_memremap_ro (fw_arg1,SZ_64K ); +char *cmdline =early_memremap_ro (fw_arg1,COMMAND_LINE_SIZE );if (efi_boot)set_bit (EFI_BOOT , &efi.flags);else clear_bit (EFI_BOOT , &efi.flags); -early_init_dt_scan (fdt_ptr); -early_init_fdt_reserve_self (); - efi_system_table =efi_get_fdt_params (&data); +strscpy (boot_command_line, cmdline,COMMAND_LINE_SIZE ); +early_memunmap (cmdline,COMMAND_LINE_SIZE ); -efi_memmap_init_early (&data); -memblock_reserve (data.phys_map &PAGE_MASK , -PAGE_ALIGN (data.size + (data.phys_map & ~PAGE_MASK ))); + efi_system_table = fw_arg2; }static int __init init_cpu_fullname (void )arch/loongarch/kernel/head.S +2
-0@@ -67,6 +67,8 @@ SYM_CODE_START(kernel_entry) # kernel entry point st.d a0, t0, 0 # firmware arguments la t0, fw_arg1 st.d a1, t0, 0 + la t0, fw_arg2 + st.d a2, t0, 0 /* KSave3 used for percpu base, initialized as 0 */ csrwr zero, PERCPU_BASE_KSarch/loongarch/kernel/setup.c +2
-2@@ -51,7 +51,7 @@ struct screen_info screen_info __section(".data"); -unsigned long fw_arg0, fw_arg1; +unsigned long fw_arg0, fw_arg1, fw_arg2; DEFINE_PER_CPU(unsigned long, kernelsp);struct cpuinfo_loongarch cpu_data[NR_CPUS ]__read_mostly ;@@ -187,7 +187,6 @@ early_param("mem", early_parse_mem);void __init platform_init (void ) { -efi_init ();#ifdef CONFIG_ACPI_TABLE_UPGRADE acpi_table_upgrade ();#endif @@ -347,6 +346,7 @@ void __init setup_arch(char **cmdline_p) *cmdline_p = boot_command_line;init_environ (); +efi_init ();memblock_init ();parse_early_param ();drivers/firmware/efi/libstub/Makefile +8
-5@@ -29,7 +29,7 @@ cflags-$(CONFIG_RISCV) := $(subst $(CC_FLAGS_FTRACE),,$(KBUILD_CFLAGS)) \ cflags-$(CONFIG_LOONGARCH) := $(subst $(CC_FLAGS_FTRACE),,$(KBUILD_CFLAGS)) \ -fpie -cflags-$(CONFIG_EFI_GENERIC_STUB) += -I$(srctree)/scripts/dtc/libfdt +cflags-$(CONFIG_EFI_PARAMS_FROM_FDT) += -I$(srctree)/scripts/dtc/libfdt KBUILD_CFLAGS := $(cflags-y) -Os -DDISABLE_BRANCH_PROFILING \ -include $(srctree)/include/linux/hidden.h \@@ -59,14 +59,17 @@ lib-y := efi-stub-helper.o gop.o secureboot.o tpm.o \ skip_spaces.o lib-cmdline.o lib-ctype.o \ alignedmem.o relocate.o vsprintf.o -# include the stub's generic dependencies from lib/ when building for ARM/arm64 -efi-deps-y := fdt_rw.c fdt_ro.c fdt_wip.c fdt.c fdt_empty_tree.c fdt_sw.c +# include the stub's libfdt dependencies from lib/ when needed +libfdt-deps := fdt_rw.c fdt_ro.c fdt_wip.c fdt.c \ + fdt_empty_tree.c fdt_sw.c + +lib-$(CONFIG_EFI_PARAMS_FROM_FDT) += fdt.o \ + $(patsubst %.c,lib-%.o,$(libfdt-deps)) $(obj)/lib-%.o: $(srctree)/lib/%.c FORCE $(call if_changed_rule,cc_o_c) -lib-$(CONFIG_EFI_GENERIC_STUB) += efi-stub.o fdt.o string.o \ - $(patsubst %.c,lib-%.o,$(efi-deps-y)) +lib-$(CONFIG_EFI_GENERIC_STUB) += efi-stub.o string.o lib-$(CONFIG_ARM) += arm32-stub.o lib-$(CONFIG_ARM64) += arm64-stub.odrivers/firmware/efi/libstub/loongarch-stub.c +49
-8@@ -9,7 +9,8 @@#include <asm/addrspace.h> #include "efistub.h" -typedef void __noreturn (*kernel_entry_t )(bool efi,unsigned long fdt); +typedef void __noreturn (*kernel_entry_t )(bool efi,unsigned long cmdline, +unsigned long systab);extern int kernel_asize;extern int kernel_fsize;@@ -42,19 +43,60 @@ efi_status_t handle_kernel_image(unsigned long *image_addr,return status; } -void __noreturn efi_enter_kernel (unsigned long entrypoint,unsigned long fdt,unsigned long fdt_size) +struct exit_boot_struct { +efi_memory_desc_t *runtime_map; +int runtime_entry_count; +}; + +static efi_status_t exit_boot_func (struct efi_boot_memmap *map,void *priv) +{ +struct exit_boot_struct *p = priv; + +/* +* Update the memory map with virtual addresses. The function will also +* populate @runtime_map with copies of just the EFI_MEMORY_RUNTIME +* entries so that we can pass it straight to SetVirtualAddressMap() +*/ +efi_get_virtmap (map->map, map->map_size, map->desc_size, + p->runtime_map, &p->runtime_entry_count); + +return EFI_SUCCESS ; +} + +efi_status_t efi_boot_kernel (void *handle,efi_loaded_image_t *image, +unsigned long kernel_addr,char *cmdline_ptr) {kernel_entry_t real_kernel_entry; +struct exit_boot_struct priv; +unsigned long desc_size; +efi_status_t status; +u32 desc_ver; + + status =efi_alloc_virtmap (&priv.runtime_map, &desc_size, &desc_ver); +if (status !=EFI_SUCCESS ) { +efi_err ("Unable to retrieve UEFI memory map.\n" ); +return status; + } + +efi_info ("Exiting boot services\n" ); + + efi_novamap = false; + status =efi_exit_boot_services (handle, &priv, exit_boot_func); +if (status !=EFI_SUCCESS ) +return status; + +/* Install the new virtual address map */ +efi_rt_call (set_virtual_address_map, + priv.runtime_entry_count * desc_size, desc_size, + desc_ver, priv.runtime_map);/* Config Direct Mapping */ csr_write64 (CSR_DMW0_INIT ,LOONGARCH_CSR_DMWIN0 );csr_write64 (CSR_DMW1_INIT ,LOONGARCH_CSR_DMWIN1 ); real_kernel_entry = (kernel_entry_t) - ((unsigned long )&kernel_entry - entrypoint +VMLINUX_LOAD_ADDRESS ); + ((unsigned long )&kernel_entry - kernel_addr +VMLINUX_LOAD_ADDRESS ); -if (!efi_novamap) -real_kernel_entry (true, fdt); -else -real_kernel_entry (false, fdt); +real_kernel_entry (true, (unsigned long )cmdline_ptr, + (unsigned long )efi_system_table); } --2.35.1
Ard Biesheuvel
maintainerRe: [PATCH v2 8/8] efi/loongarch: libstub: remove dependency on flattened DT
Quoted 3 lines · Huacai Chen
Acked-by Huacai Chen <[email protected]>
Thank you Huacai
I have created a separate tag with these patches applied onto the first loongarch efi enablement patch (see below)
I would prefer to keep the loongarch trees separate for the next merge window, but if needed to avoid massive conflicts, you could merge the tag into the loongarch tree and rebase your changes on top. But please take care not to rebase those patches themselves: the commit SHAs need to remain the same.
However, if the conflicts are only minor, you can just explain in your PR to Linus what the resolution should look like.
The tag can be found here:
https://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git/tag/?h=efi-loongarch-for-v6.1-2
I have merged this into the EFI tree as well and pushed it out; it should appear in -next tomorrow.
b093dc55ba9a efi/loongarch: libstub: remove dependency on flattened DT 102faf0747c2 efi: libstub: install boot-time memory map as config table 7318926e7bc9 efi: libstub: remove DT dependency from generic stub 7cb6671e3caa efi: libstub: unify initrd loading between architectures 1add08ceb15b efi: libstub: remove pointless goto kludge d2130a9cf0f7 efi: libstub: simplify efi_get_memory_map() and struct efi_boot_memmapbc5853aa56de efi: libstub: avoid efi_get_memory_map() for allocating the virt mapd80ca810f096 efi: libstub: drop pointless get_memory_map() call ead384d95634 (tag: efi-loongarch-for-v6.1) efi/loongarch: Add efistub booting support568035b01cfb (tag: v6.0-rc1) Linux 6.0-rc1
Quoted 340 lines · Ard Biesheuvel
Quoted 339 lines
LoongArch does not use FDT or DT natively [yet], and the only reason it currently uses it is so that it can reuse the existing EFI stub code.
Overloading the DT with data passed between the EFI stub and the core kernel has been a source of problems: there is the overlap between information provided by EFI which DT can also provide (initrd base/size, command line, memory descriptions), requiring us to reason about which is which and what to prioritize. It has also resulted in ABI leaks, i.e., internal ABI being promoted to external ABI inadvertently because the bootloader can set the EFI stub's DT properties as well (e.g., "kaslr-seed"). This has become especially problematic with boot environments that want to pretend that EFI boot is being done (to access ACPI and SMBIOS tables, for instance) but have no ability to execute the EFI stub, and so the environment that the EFI stub creates is emulated [poorly, in some cases].
Another downside of treating DT like this is that the DT binary that the kernel receives is different from the one created by the firmware, which is undesirable in the context of secure and measured boot.
Given that LoongArch support in Linux is brand new, we can avoid these pitfalls, and treat the DT strictly as a hardware description, and use a separate handover method between the EFI stub and the kernel. Now that initrd loading and passing the EFI memory map have been refactored into pure EFI routines that use EFI configuration tables, the only thing we need to pass directly is the kernel command line (even if we could pass this via a config table as well, it is used extremely early, so passing it directly is preferred in this case.)
Signed-off-by Ard Biesheuvel <[email protected]>--- arch/loongarch/Kconfig | 3 -- arch/loongarch/include/asm/bootinfo.h | 2 +- arch/loongarch/kernel/efi.c | 30 ++++++++++- arch/loongarch/kernel/env.c | 13 ++--- arch/loongarch/kernel/head.S | 2 + arch/loongarch/kernel/setup.c | 4 +- drivers/firmware/efi/libstub/Makefile | 13 +++-- drivers/firmware/efi/libstub/loongarch-stub.c | 56 +++++++++++++++++--- 8 files changed, 95 insertions(+), 28 deletions(-)arch/loongarch/Kconfig +0
-3@@ -104,8 +104,6 @@ config LOONGARCH select MODULES_USE_ELF_RELA if MODULES select NEED_PER_CPU_EMBED_FIRST_CHUNK select NEED_PER_CPU_PAGE_FIRST_CHUNK - select OF - select OF_EARLY_FLATTREE select PCI select PCI_DOMAINS_GENERIC select PCI_ECAM if ACPI@@ -311,7 +309,6 @@ config DMI config EFI bool "EFI runtime service support" select UCS2_STRING - select EFI_PARAMS_FROM_FDT select EFI_RUNTIME_WRAPPERS help This enables the kernel to use EFI runtime services that arearch/loongarch/include/asm/bootinfo.h +1
-1@@ -36,7 +36,7 @@ struct loongson_system_configuration { };extern u64 efi_system_table; -extern unsigned long fw_arg0, fw_arg1; +extern unsigned long fw_arg0, fw_arg1, fw_arg2;extern struct loongson_board_info b_info;extern struct loongson_system_configuration loongson_sysconf;arch/loongarch/kernel/efi.c +29
-1@@ -27,8 +27,13 @@static unsigned long efi_nr_tables;static unsigned long efi_config_table; +static unsigned long __initdata boot_memmap =EFI_INVALID_TABLE_ADDR ; +static efi_system_table_t *efi_systab; -static efi_config_table_type_t arch_tables[]__initdata = {{},}; +static efi_config_table_type_t arch_tables[]__initdata = { + {LINUX_EFI_BOOT_MEMMAP_GUID , &boot_memmap,"MEMMAP" }, + {}, +};void __init efi_runtime_init (void ) {@@ -51,6 +56,7 @@ void __init efi_init(void) {int size;void *config_tables; +struct efi_boot_memmap *tbl;if (!efi_system_table)return ;@@ -61,6 +67,8 @@ void __init efi_init(void)return ; } +efi_systab_report_header (&efi_systab->hdr, efi_systab->fw_vendor); +set_bit (EFI_64BIT , &efi.flags); efi_nr_tables = efi_systab->nr_tables; efi_config_table = (unsigned long )efi_systab->tables;@@ -70,6 +78,26 @@ void __init efi_init(void)efi_config_parse_tables (config_tables, efi_systab->nr_tables, arch_tables);early_memunmap (config_tables, efi_nr_tables * size); +set_bit (EFI_CONFIG_TABLES , &efi.flags); +if (screen_info.orig_video_isVGA ==VIDEO_TYPE_EFI )memblock_reserve (screen_info.lfb_base, screen_info.lfb_size); + +if (boot_memmap ==EFI_INVALID_TABLE_ADDR ) +return ; + + tbl =early_memremap_ro (boot_memmap,sizeof (*tbl)); +if (tbl) { +struct efi_memory_map_data data; + + data.phys_map = boot_memmap +sizeof (*tbl); + data.size = tbl->map_size; + data.desc_size = tbl->desc_size; + data.desc_version = tbl->desc_ver; + +if (efi_memmap_init_early (&data) <0 ) +panic ("Unable to map EFI memory map.\n" ); + +early_memunmap (tbl,sizeof (*tbl)); + } }arch/loongarch/kernel/env.c +4
-9@@ -8,7 +8,6 @@#include <linux/efi.h> #include <linux/export.h> #include <linux/memblock.h> -#include <linux/of_fdt.h> #include <asm/early_ioremap.h> #include <asm/bootinfo.h> #include <asm/loongson.h> @@ -20,21 +19,17 @@ EXPORT_SYMBOL(loongson_sysconf);void __init init_environ (void ) {int efi_boot = fw_arg0; -struct efi_memory_map_data data; -void *fdt_ptr =early_memremap_ro (fw_arg1,SZ_64K ); +char *cmdline =early_memremap_ro (fw_arg1,COMMAND_LINE_SIZE );if (efi_boot)set_bit (EFI_BOOT , &efi.flags);else clear_bit (EFI_BOOT , &efi.flags); -early_init_dt_scan (fdt_ptr); -early_init_fdt_reserve_self (); - efi_system_table =efi_get_fdt_params (&data); +strscpy (boot_command_line, cmdline,COMMAND_LINE_SIZE ); +early_memunmap (cmdline,COMMAND_LINE_SIZE ); -efi_memmap_init_early (&data); -memblock_reserve (data.phys_map &PAGE_MASK , -PAGE_ALIGN (data.size + (data.phys_map & ~PAGE_MASK ))); + efi_system_table = fw_arg2; }static int __init init_cpu_fullname (void )arch/loongarch/kernel/head.S +2
-0@@ -67,6 +67,8 @@ SYM_CODE_START(kernel_entry) # kernel entry point st.d a0, t0, 0 # firmware arguments la t0, fw_arg1 st.d a1, t0, 0 + la t0, fw_arg2 + st.d a2, t0, 0 /* KSave3 used for percpu base, initialized as 0 */ csrwr zero, PERCPU_BASE_KSarch/loongarch/kernel/setup.c +2
-2@@ -51,7 +51,7 @@ struct screen_info screen_info __section(".data"); -unsigned long fw_arg0, fw_arg1; +unsigned long fw_arg0, fw_arg1, fw_arg2; DEFINE_PER_CPU(unsigned long, kernelsp);struct cpuinfo_loongarch cpu_data[NR_CPUS ]__read_mostly ;@@ -187,7 +187,6 @@ early_param("mem", early_parse_mem);void __init platform_init (void ) { -efi_init ();#ifdef CONFIG_ACPI_TABLE_UPGRADE acpi_table_upgrade ();#endif @@ -347,6 +346,7 @@ void __init setup_arch(char **cmdline_p) *cmdline_p = boot_command_line;init_environ (); +efi_init ();memblock_init ();parse_early_param ();drivers/firmware/efi/libstub/Makefile +8
-5@@ -29,7 +29,7 @@ cflags-$(CONFIG_RISCV) := $(subst $(CC_FLAGS_FTRACE),,$(KBUILD_CFLAGS)) \ cflags-$(CONFIG_LOONGARCH) := $(subst $(CC_FLAGS_FTRACE),,$(KBUILD_CFLAGS)) \ -fpie -cflags-$(CONFIG_EFI_GENERIC_STUB) += -I$(srctree)/scripts/dtc/libfdt +cflags-$(CONFIG_EFI_PARAMS_FROM_FDT) += -I$(srctree)/scripts/dtc/libfdt KBUILD_CFLAGS := $(cflags-y) -Os -DDISABLE_BRANCH_PROFILING \ -include $(srctree)/include/linux/hidden.h \@@ -59,14 +59,17 @@ lib-y := efi-stub-helper.o gop.o secureboot.o tpm.o \ skip_spaces.o lib-cmdline.o lib-ctype.o \ alignedmem.o relocate.o vsprintf.o -# include the stub's generic dependencies from lib/ when building for ARM/arm64 -efi-deps-y := fdt_rw.c fdt_ro.c fdt_wip.c fdt.c fdt_empty_tree.c fdt_sw.c +# include the stub's libfdt dependencies from lib/ when needed +libfdt-deps := fdt_rw.c fdt_ro.c fdt_wip.c fdt.c \ + fdt_empty_tree.c fdt_sw.c + +lib-$(CONFIG_EFI_PARAMS_FROM_FDT) += fdt.o \ + $(patsubst %.c,lib-%.o,$(libfdt-deps)) $(obj)/lib-%.o: $(srctree)/lib/%.c FORCE $(call if_changed_rule,cc_o_c) -lib-$(CONFIG_EFI_GENERIC_STUB) += efi-stub.o fdt.o string.o \ - $(patsubst %.c,lib-%.o,$(efi-deps-y)) +lib-$(CONFIG_EFI_GENERIC_STUB) += efi-stub.o string.o lib-$(CONFIG_ARM) += arm32-stub.o lib-$(CONFIG_ARM64) += arm64-stub.odrivers/firmware/efi/libstub/loongarch-stub.c +49
-8@@ -9,7 +9,8 @@#include <asm/addrspace.h> #include "efistub.h" -typedef void __noreturn (*kernel_entry_t )(bool efi,unsigned long fdt); +typedef void __noreturn (*kernel_entry_t )(bool efi,unsigned long cmdline, +unsigned long systab);extern int kernel_asize;extern int kernel_fsize;@@ -42,19 +43,60 @@ efi_status_t handle_kernel_image(unsigned long *image_addr,return status; } -void __noreturn efi_enter_kernel (unsigned long entrypoint,unsigned long fdt,unsigned long fdt_size) +struct exit_boot_struct { +efi_memory_desc_t *runtime_map; +int runtime_entry_count; +}; + +static efi_status_t exit_boot_func (struct efi_boot_memmap *map,void *priv) +{ +struct exit_boot_struct *p = priv; + +/* +* Update the memory map with virtual addresses. The function will also +* populate @runtime_map with copies of just the EFI_MEMORY_RUNTIME +* entries so that we can pass it straight to SetVirtualAddressMap() +*/ +efi_get_virtmap (map->map, map->map_size, map->desc_size, + p->runtime_map, &p->runtime_entry_count); + +return EFI_SUCCESS ; +} + +efi_status_t efi_boot_kernel (void *handle,efi_loaded_image_t *image, +unsigned long kernel_addr,char *cmdline_ptr) {kernel_entry_t real_kernel_entry; +struct exit_boot_struct priv; +unsigned long desc_size; +efi_status_t status; +u32 desc_ver; + + status =efi_alloc_virtmap (&priv.runtime_map, &desc_size, &desc_ver); +if (status !=EFI_SUCCESS ) { +efi_err ("Unable to retrieve UEFI memory map.\n" ); +return status; + } + +efi_info ("Exiting boot services\n" ); + + efi_novamap = false; + status =efi_exit_boot_services (handle, &priv, exit_boot_func); +if (status !=EFI_SUCCESS ) +return status; + +/* Install the new virtual address map */ +efi_rt_call (set_virtual_address_map, + priv.runtime_entry_count * desc_size, desc_size, + desc_ver, priv.runtime_map);/* Config Direct Mapping */ csr_write64 (CSR_DMW0_INIT ,LOONGARCH_CSR_DMWIN0 );csr_write64 (CSR_DMW1_INIT ,LOONGARCH_CSR_DMWIN1 ); real_kernel_entry = (kernel_entry_t) - ((unsigned long )&kernel_entry - entrypoint +VMLINUX_LOAD_ADDRESS ); + ((unsigned long )&kernel_entry - kernel_addr +VMLINUX_LOAD_ADDRESS ); -if (!efi_novamap) -real_kernel_entry (true, fdt); -else -real_kernel_entry (false, fdt); +real_kernel_entry (true, (unsigned long )cmdline_ptr, + (unsigned long )efi_system_table); } --2.35.1
Huacai Chen
maintainerRe: [PATCH v2 8/8] efi/loongarch: libstub: remove dependency on flattened DT
Quoted 28 lines · Ard Biesheuvel
Quoted 3 lines · Huacai Chen
Acked-by Huacai Chen <[email protected]>Thank you Huacai
I have created a separate tag with these patches applied onto the first loongarch efi enablement patch (see below)
I would prefer to keep the loongarch trees separate for the next merge window, but if needed to avoid massive conflicts, you could merge the tag into the loongarch tree and rebase your changes on top. But please take care not to rebase those patches themselves: the commit SHAs need to remain the same.
However, if the conflicts are only minor, you can just explain in your PR to Linus what the resolution should look like.
The tag can be found here:
https://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git/tag/?h=efi-loongarch-for-v6.1-2I have merged this into the EFI tree as well and pushed it out; it should appear in -next tomorrow.
Quoted 13 lines
b093dc55ba9aefi/loongarch: libstub: remove dependency on flattened DT102faf0747c2efi: libstub: install boot-time memory map as config table7318926e7bc9efi: libstub: remove DT dependency from generic stub7cb6671e3caaefi: libstub: unify initrd loading between architectures1add08ceb15befi: libstub: remove pointless goto kludged2130a9cf0f7efi: libstub: simplifyefi_get_memory_map()and structefi_boot_memmapbc5853aa56deefi: libstub: avoidefi_get_memory_map()for allocating the virt mapd80ca810f096efi: libstub: drop pointlessget_memory_map()callead384d95634(tag: efi-loongarch-for-v6.1) efi/loongarch: Add efistub booting support568035b01cfb(tag: v6.0-rc1) Linux 6.0-rc1
Hmmm, I want to also merge zboot support in the loongarch-next's base, is that possible?
Huacai
Quoted 343 lines
Quoted 343 lines · Ard Biesheuvel
Quoted 339 lines
LoongArch does not use FDT or DT natively [yet], and the only reason it currently uses it is so that it can reuse the existing EFI stub code.
Overloading the DT with data passed between the EFI stub and the core kernel has been a source of problems: there is the overlap between information provided by EFI which DT can also provide (initrd base/size, command line, memory descriptions), requiring us to reason about which is which and what to prioritize. It has also resulted in ABI leaks, i.e., internal ABI being promoted to external ABI inadvertently because the bootloader can set the EFI stub's DT properties as well (e.g., "kaslr-seed"). This has become especially problematic with boot environments that want to pretend that EFI boot is being done (to access ACPI and SMBIOS tables, for instance) but have no ability to execute the EFI stub, and so the environment that the EFI stub creates is emulated [poorly, in some cases].
Another downside of treating DT like this is that the DT binary that the kernel receives is different from the one created by the firmware, which is undesirable in the context of secure and measured boot.
Given that LoongArch support in Linux is brand new, we can avoid these pitfalls, and treat the DT strictly as a hardware description, and use a separate handover method between the EFI stub and the kernel. Now that initrd loading and passing the EFI memory map have been refactored into pure EFI routines that use EFI configuration tables, the only thing we need to pass directly is the kernel command line (even if we could pass this via a config table as well, it is used extremely early, so passing it directly is preferred in this case.)
Signed-off-by Ard Biesheuvel <[email protected]>--- arch/loongarch/Kconfig | 3 -- arch/loongarch/include/asm/bootinfo.h | 2 +- arch/loongarch/kernel/efi.c | 30 ++++++++++- arch/loongarch/kernel/env.c | 13 ++--- arch/loongarch/kernel/head.S | 2 + arch/loongarch/kernel/setup.c | 4 +- drivers/firmware/efi/libstub/Makefile | 13 +++-- drivers/firmware/efi/libstub/loongarch-stub.c | 56 +++++++++++++++++--- 8 files changed, 95 insertions(+), 28 deletions(-)arch/loongarch/Kconfig +0
-3@@ -104,8 +104,6 @@ config LOONGARCH select MODULES_USE_ELF_RELA if MODULES select NEED_PER_CPU_EMBED_FIRST_CHUNK select NEED_PER_CPU_PAGE_FIRST_CHUNK - select OF - select OF_EARLY_FLATTREE select PCI select PCI_DOMAINS_GENERIC select PCI_ECAM if ACPI@@ -311,7 +309,6 @@ config DMI config EFI bool "EFI runtime service support" select UCS2_STRING - select EFI_PARAMS_FROM_FDT select EFI_RUNTIME_WRAPPERS help This enables the kernel to use EFI runtime services that arearch/loongarch/include/asm/bootinfo.h +1
-1@@ -36,7 +36,7 @@ struct loongson_system_configuration { };extern u64 efi_system_table; -extern unsigned long fw_arg0, fw_arg1; +extern unsigned long fw_arg0, fw_arg1, fw_arg2;extern struct loongson_board_info b_info;extern struct loongson_system_configuration loongson_sysconf;arch/loongarch/kernel/efi.c +29
-1@@ -27,8 +27,13 @@static unsigned long efi_nr_tables;static unsigned long efi_config_table; +static unsigned long __initdata boot_memmap =EFI_INVALID_TABLE_ADDR ; +static efi_system_table_t *efi_systab; -static efi_config_table_type_t arch_tables[]__initdata = {{},}; +static efi_config_table_type_t arch_tables[]__initdata = { + {LINUX_EFI_BOOT_MEMMAP_GUID , &boot_memmap,"MEMMAP" }, + {}, +};void __init efi_runtime_init (void ) {@@ -51,6 +56,7 @@ void __init efi_init(void) {int size;void *config_tables; +struct efi_boot_memmap *tbl;if (!efi_system_table)return ;@@ -61,6 +67,8 @@ void __init efi_init(void)return ; } +efi_systab_report_header (&efi_systab->hdr, efi_systab->fw_vendor); +set_bit (EFI_64BIT , &efi.flags); efi_nr_tables = efi_systab->nr_tables; efi_config_table = (unsigned long )efi_systab->tables;@@ -70,6 +78,26 @@ void __init efi_init(void)efi_config_parse_tables (config_tables, efi_systab->nr_tables, arch_tables);early_memunmap (config_tables, efi_nr_tables * size); +set_bit (EFI_CONFIG_TABLES , &efi.flags); +if (screen_info.orig_video_isVGA ==VIDEO_TYPE_EFI )memblock_reserve (screen_info.lfb_base, screen_info.lfb_size); + +if (boot_memmap ==EFI_INVALID_TABLE_ADDR ) +return ; + + tbl =early_memremap_ro (boot_memmap,sizeof (*tbl)); +if (tbl) { +struct efi_memory_map_data data; + + data.phys_map = boot_memmap +sizeof (*tbl); + data.size = tbl->map_size; + data.desc_size = tbl->desc_size; + data.desc_version = tbl->desc_ver; + +if (efi_memmap_init_early (&data) <0 ) +panic ("Unable to map EFI memory map.\n" ); + +early_memunmap (tbl,sizeof (*tbl)); + } }arch/loongarch/kernel/env.c +4
-9@@ -8,7 +8,6 @@#include <linux/efi.h> #include <linux/export.h> #include <linux/memblock.h> -#include <linux/of_fdt.h> #include <asm/early_ioremap.h> #include <asm/bootinfo.h> #include <asm/loongson.h> @@ -20,21 +19,17 @@ EXPORT_SYMBOL(loongson_sysconf);void __init init_environ (void ) {int efi_boot = fw_arg0; -struct efi_memory_map_data data; -void *fdt_ptr =early_memremap_ro (fw_arg1,SZ_64K ); +char *cmdline =early_memremap_ro (fw_arg1,COMMAND_LINE_SIZE );if (efi_boot)set_bit (EFI_BOOT , &efi.flags);else clear_bit (EFI_BOOT , &efi.flags); -early_init_dt_scan (fdt_ptr); -early_init_fdt_reserve_self (); - efi_system_table =efi_get_fdt_params (&data); +strscpy (boot_command_line, cmdline,COMMAND_LINE_SIZE ); +early_memunmap (cmdline,COMMAND_LINE_SIZE ); -efi_memmap_init_early (&data); -memblock_reserve (data.phys_map &PAGE_MASK , -PAGE_ALIGN (data.size + (data.phys_map & ~PAGE_MASK ))); + efi_system_table = fw_arg2; }static int __init init_cpu_fullname (void )arch/loongarch/kernel/head.S +2
-0@@ -67,6 +67,8 @@ SYM_CODE_START(kernel_entry) # kernel entry point st.d a0, t0, 0 # firmware arguments la t0, fw_arg1 st.d a1, t0, 0 + la t0, fw_arg2 + st.d a2, t0, 0 /* KSave3 used for percpu base, initialized as 0 */ csrwr zero, PERCPU_BASE_KSarch/loongarch/kernel/setup.c +2
-2@@ -51,7 +51,7 @@ struct screen_info screen_info __section(".data"); -unsigned long fw_arg0, fw_arg1; +unsigned long fw_arg0, fw_arg1, fw_arg2; DEFINE_PER_CPU(unsigned long, kernelsp);struct cpuinfo_loongarch cpu_data[NR_CPUS ]__read_mostly ;@@ -187,7 +187,6 @@ early_param("mem", early_parse_mem);void __init platform_init (void ) { -efi_init ();#ifdef CONFIG_ACPI_TABLE_UPGRADE acpi_table_upgrade ();#endif @@ -347,6 +346,7 @@ void __init setup_arch(char **cmdline_p) *cmdline_p = boot_command_line;init_environ (); +efi_init ();memblock_init ();parse_early_param ();drivers/firmware/efi/libstub/Makefile +8
-5@@ -29,7 +29,7 @@ cflags-$(CONFIG_RISCV) := $(subst $(CC_FLAGS_FTRACE),,$(KBUILD_CFLAGS)) \ cflags-$(CONFIG_LOONGARCH) := $(subst $(CC_FLAGS_FTRACE),,$(KBUILD_CFLAGS)) \ -fpie -cflags-$(CONFIG_EFI_GENERIC_STUB) += -I$(srctree)/scripts/dtc/libfdt +cflags-$(CONFIG_EFI_PARAMS_FROM_FDT) += -I$(srctree)/scripts/dtc/libfdt KBUILD_CFLAGS := $(cflags-y) -Os -DDISABLE_BRANCH_PROFILING \ -include $(srctree)/include/linux/hidden.h \@@ -59,14 +59,17 @@ lib-y := efi-stub-helper.o gop.o secureboot.o tpm.o \ skip_spaces.o lib-cmdline.o lib-ctype.o \ alignedmem.o relocate.o vsprintf.o -# include the stub's generic dependencies from lib/ when building for ARM/arm64 -efi-deps-y := fdt_rw.c fdt_ro.c fdt_wip.c fdt.c fdt_empty_tree.c fdt_sw.c +# include the stub's libfdt dependencies from lib/ when needed +libfdt-deps := fdt_rw.c fdt_ro.c fdt_wip.c fdt.c \ + fdt_empty_tree.c fdt_sw.c + +lib-$(CONFIG_EFI_PARAMS_FROM_FDT) += fdt.o \ + $(patsubst %.c,lib-%.o,$(libfdt-deps)) $(obj)/lib-%.o: $(srctree)/lib/%.c FORCE $(call if_changed_rule,cc_o_c) -lib-$(CONFIG_EFI_GENERIC_STUB) += efi-stub.o fdt.o string.o \ - $(patsubst %.c,lib-%.o,$(efi-deps-y)) +lib-$(CONFIG_EFI_GENERIC_STUB) += efi-stub.o string.o lib-$(CONFIG_ARM) += arm32-stub.o lib-$(CONFIG_ARM64) += arm64-stub.odrivers/firmware/efi/libstub/loongarch-stub.c +49
-8@@ -9,7 +9,8 @@#include <asm/addrspace.h> #include "efistub.h" -typedef void __noreturn (*kernel_entry_t )(bool efi,unsigned long fdt); +typedef void __noreturn (*kernel_entry_t )(bool efi,unsigned long cmdline, +unsigned long systab);extern int kernel_asize;extern int kernel_fsize;@@ -42,19 +43,60 @@ efi_status_t handle_kernel_image(unsigned long *image_addr,return status; } -void __noreturn efi_enter_kernel (unsigned long entrypoint,unsigned long fdt,unsigned long fdt_size) +struct exit_boot_struct { +efi_memory_desc_t *runtime_map; +int runtime_entry_count; +}; + +static efi_status_t exit_boot_func (struct efi_boot_memmap *map,void *priv) +{ +struct exit_boot_struct *p = priv; + +/* +* Update the memory map with virtual addresses. The function will also +* populate @runtime_map with copies of just the EFI_MEMORY_RUNTIME +* entries so that we can pass it straight to SetVirtualAddressMap() +*/ +efi_get_virtmap (map->map, map->map_size, map->desc_size, + p->runtime_map, &p->runtime_entry_count); + +return EFI_SUCCESS ; +} + +efi_status_t efi_boot_kernel (void *handle,efi_loaded_image_t *image, +unsigned long kernel_addr,char *cmdline_ptr) {kernel_entry_t real_kernel_entry; +struct exit_boot_struct priv; +unsigned long desc_size; +efi_status_t status; +u32 desc_ver; + + status =efi_alloc_virtmap (&priv.runtime_map, &desc_size, &desc_ver); +if (status !=EFI_SUCCESS ) { +efi_err ("Unable to retrieve UEFI memory map.\n" ); +return status; + } + +efi_info ("Exiting boot services\n" ); + + efi_novamap = false; + status =efi_exit_boot_services (handle, &priv, exit_boot_func); +if (status !=EFI_SUCCESS ) +return status; + +/* Install the new virtual address map */ +efi_rt_call (set_virtual_address_map, + priv.runtime_entry_count * desc_size, desc_size, + desc_ver, priv.runtime_map);/* Config Direct Mapping */ csr_write64 (CSR_DMW0_INIT ,LOONGARCH_CSR_DMWIN0 );csr_write64 (CSR_DMW1_INIT ,LOONGARCH_CSR_DMWIN1 ); real_kernel_entry = (kernel_entry_t) - ((unsigned long )&kernel_entry - entrypoint +VMLINUX_LOAD_ADDRESS ); + ((unsigned long )&kernel_entry - kernel_addr +VMLINUX_LOAD_ADDRESS ); -if (!efi_novamap) -real_kernel_entry (true, fdt); -else -real_kernel_entry (false, fdt); +real_kernel_entry (true, (unsigned long )cmdline_ptr, + (unsigned long )efi_system_table); } --2.35.1
Ard Biesheuvel
maintainerRe: [PATCH v2 8/8] efi/loongarch: libstub: remove dependency on flattened DT
Quoted 30 lines · Huacai Chen
Quoted 28 lines · Ard Biesheuvel
Quoted 3 lines · Huacai Chen
Acked-by Huacai Chen <[email protected]>Thank you Huacai
I have created a separate tag with these patches applied onto the first loongarch efi enablement patch (see below)
I would prefer to keep the loongarch trees separate for the next merge window, but if needed to avoid massive conflicts, you could merge the tag into the loongarch tree and rebase your changes on top. But please take care not to rebase those patches themselves: the commit SHAs need to remain the same.
However, if the conflicts are only minor, you can just explain in your PR to Linus what the resolution should look like.
The tag can be found here:
https://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git/tag/?h=efi-loongarch-for-v6.1-2I have merged this into the EFI tree as well and pushed it out; it should appear in -next tomorrow.
Quoted 4 lines
Quoted 4 lines
b093dc55ba9aefi/loongarch: libstub: remove dependency on flattened DT102faf0747c2efi: libstub: install boot-time memory map as config table7318926e7bc9efi: libstub: remove DT dependency from generic stub7cb6671e3caaefi: libstub: unify initrd loading between architectures
I will have to respin the initrd patch, unfortunately, as it breaks x86. So the signed tag will be updated, and the SHAs above will change as well.
Quoted 9 lines
Quoted 9 lines
1add08ceb15befi: libstub: remove pointless goto kludged2130a9cf0f7efi: libstub: simplifyefi_get_memory_map()and structefi_boot_memmapbc5853aa56deefi: libstub: avoidefi_get_memory_map()for allocating the virt mapd80ca810f096efi: libstub: drop pointlessget_memory_map()callead384d95634(tag: efi-loongarch-for-v6.1) efi/loongarch: Add efistub booting support568035b01cfb(tag: v6.0-rc1) Linux 6.0-rc1
Quoted 3 lines
Hmmm, I want to also merge zboot support in the loongarch-next's base, is that possible?
No, let's keep that separate. LoongArch boots fine without it, so we can wait until it arrives via the EFI tree, no?
Huacai Chen
maintainerRe: [PATCH v2 8/8] efi/loongarch: libstub: remove dependency on flattened DT
Quoted 32 lines · Ard Biesheuvel
Quoted 30 lines · Huacai Chen
Quoted 28 lines · Ard Biesheuvel
Quoted 3 lines · Huacai Chen
Acked-by Huacai Chen <[email protected]>Thank you Huacai
I have created a separate tag with these patches applied onto the first loongarch efi enablement patch (see below)
I would prefer to keep the loongarch trees separate for the next merge window, but if needed to avoid massive conflicts, you could merge the tag into the loongarch tree and rebase your changes on top. But please take care not to rebase those patches themselves: the commit SHAs need to remain the same.
However, if the conflicts are only minor, you can just explain in your PR to Linus what the resolution should look like.
The tag can be found here:
https://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git/tag/?h=efi-loongarch-for-v6.1-2I have merged this into the EFI tree as well and pushed it out; it should appear in -next tomorrow.
Quoted 8 lines
Quoted 4 lines
Quoted 4 lines
b093dc55ba9aefi/loongarch: libstub: remove dependency on flattened DT102faf0747c2efi: libstub: install boot-time memory map as config table7318926e7bc9efi: libstub: remove DT dependency from generic stub7cb6671e3caaefi: libstub: unify initrd loading between architecturesI will have to respin the initrd patch, unfortunately, as it breaks x86. So the signed tag will be updated, and the SHAs above will change as well.
Emm, initrd is also broken on LoongArch, the core kernel gets an EFI_INVALID_TABLE_ADDR address.
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
1add08ceb15befi: libstub: remove pointless goto kludged2130a9cf0f7efi: libstub: simplifyefi_get_memory_map()and structefi_boot_memmapbc5853aa56deefi: libstub: avoidefi_get_memory_map()for allocating the virt mapd80ca810f096efi: libstub: drop pointlessget_memory_map()callead384d95634(tag: efi-loongarch-for-v6.1) efi/loongarch: Add efistub booting support568035b01cfb(tag: v6.0-rc1) Linux 6.0-rc1
Quoted 6 lines
Quoted 3 lines
Hmmm, I want to also merge zboot support in the loongarch-next's base, is that possible?
No, let's keep that separate. LoongArch boots fine without it, so we can wait until it arrives via the EFI tree, no?
Both OK but I prefer to use a compressed kernel in daily work.
Huacai
Ard Biesheuvel
maintainerRe: [PATCH v2 8/8] efi/loongarch: libstub: remove dependency on flattened DT
Quoted 39 lines · Huacai Chen
Quoted 37 lines · Ard Biesheuvel
Quoted 34 lines · Huacai Chen
Quoted 32 lines · Ard Biesheuvel
Quoted 3 lines · Huacai Chen
Acked-by Huacai Chen <[email protected]>Thank you Huacai
I have created a separate tag with these patches applied onto the first loongarch efi enablement patch (see below)
I would prefer to keep the loongarch trees separate for the next merge window, but if needed to avoid massive conflicts, you could merge the tag into the loongarch tree and rebase your changes on top. But please take care not to rebase those patches themselves: the commit SHAs need to remain the same.
However, if the conflicts are only minor, you can just explain in your PR to Linus what the resolution should look like.
The tag can be found here:
https://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git/tag/?h=efi-loongarch-for-v6.1-2I have merged this into the EFI tree as well and pushed it out; it should appear in -next tomorrow.
b093dc55ba9aefi/loongarch: libstub: remove dependency on flattened DT102faf0747c2efi: libstub: install boot-time memory map as config table7318926e7bc9efi: libstub: remove DT dependency from generic stub7cb6671e3caaefi: libstub: unify initrd loading between architectures
Quoted 6 lines
Quoted 3 lines
I will have to respin the initrd patch, unfortunately, as it breaks x86. So the signed tag will be updated, and the SHAs above will change as well.
Emm, initrd is also broken on LoongArch, the core kernel gets an
EFI_INVALID_TABLE_ADDRaddress.
OK, I will investigate. This was working fine before so I'm not sure what happened there.
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
1add08ceb15befi: libstub: remove pointless goto kludged2130a9cf0f7efi: libstub: simplifyefi_get_memory_map()and structefi_boot_memmapbc5853aa56deefi: libstub: avoidefi_get_memory_map()for allocating the virt mapd80ca810f096efi: libstub: drop pointlessget_memory_map()callead384d95634(tag: efi-loongarch-for-v6.1) efi/loongarch: Add efistub booting support568035b01cfb(tag: v6.0-rc1) Linux 6.0-rc1
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
Hmmm, I want to also merge zboot support in the loongarch-next's base, is that possible?
No, let's keep that separate. LoongArch boots fine without it, so we can wait until it arrives via the EFI tree, no?
Both OK but I prefer to use a compressed kernel in daily work.
I understand that. But what you use for daily work and what you send to Linus are two different things, no?
Huacai Chen
maintainerRe: [PATCH v2 8/8] efi/loongarch: libstub: remove dependency on flattened DT
Quoted 65 lines · Ard Biesheuvel
Quoted 39 lines · Huacai Chen
Quoted 37 lines · Ard Biesheuvel
Quoted 34 lines · Huacai Chen
Quoted 32 lines · Ard Biesheuvel
Quoted 3 lines · Huacai Chen
Acked-by Huacai Chen <[email protected]>Thank you Huacai
I have created a separate tag with these patches applied onto the first loongarch efi enablement patch (see below)
I would prefer to keep the loongarch trees separate for the next merge window, but if needed to avoid massive conflicts, you could merge the tag into the loongarch tree and rebase your changes on top. But please take care not to rebase those patches themselves: the commit SHAs need to remain the same.
However, if the conflicts are only minor, you can just explain in your PR to Linus what the resolution should look like.
The tag can be found here:
https://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git/tag/?h=efi-loongarch-for-v6.1-2I have merged this into the EFI tree as well and pushed it out; it should appear in -next tomorrow.
b093dc55ba9aefi/loongarch: libstub: remove dependency on flattened DT102faf0747c2efi: libstub: install boot-time memory map as config table7318926e7bc9efi: libstub: remove DT dependency from generic stub7cb6671e3caaefi: libstub: unify initrd loading between architecturesQuoted 6 lines
Quoted 3 lines
I will have to respin the initrd patch, unfortunately, as it breaks x86. So the signed tag will be updated, and the SHAs above will change as well.
Emm, initrd is also broken on LoongArch, the core kernel gets an
EFI_INVALID_TABLE_ADDRaddress.OK, I will investigate. This was working fine before so I'm not sure what happened there.
Quoted 14 lines
Quoted 14 lines
Quoted 13 lines
Quoted 10 lines
1add08ceb15befi: libstub: remove pointless goto kludged2130a9cf0f7efi: libstub: simplifyefi_get_memory_map()and structefi_boot_memmapbc5853aa56deefi: libstub: avoidefi_get_memory_map()for allocating the virt mapd80ca810f096efi: libstub: drop pointlessget_memory_map()callead384d95634(tag: efi-loongarch-for-v6.1) efi/loongarch: Add efistub booting support568035b01cfb(tag: v6.0-rc1) Linux 6.0-rc1Hmmm, I want to also merge zboot support in the loongarch-next's base, is that possible?
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
No, let's keep that separate. LoongArch boots fine without it, so we can wait until it arrives via the EFI tree, no?
Both OK but I prefer to use a compressed kernel in daily work.
I understand that. But what you use for daily work and what you send to Linus are two different things, no?
OK, then let's keep things as is, I'll apply zboot patches manually in my working tree.
Huacai
Ard Biesheuvel
maintainerRe: [PATCH v2 8/8] efi/loongarch: libstub: remove dependency on flattened DT
Quoted 46 lines · Huacai Chen
Quoted 44 lines · Ard Biesheuvel
Quoted 42 lines · Huacai Chen
Quoted 40 lines · Ard Biesheuvel
Quoted 30 lines · Huacai Chen
Quoted 28 lines · Ard Biesheuvel
Quoted 3 lines · Huacai Chen
Acked-by Huacai Chen <[email protected]>Thank you Huacai
I have created a separate tag with these patches applied onto the first loongarch efi enablement patch (see below)
I would prefer to keep the loongarch trees separate for the next merge window, but if needed to avoid massive conflicts, you could merge the tag into the loongarch tree and rebase your changes on top. But please take care not to rebase those patches themselves: the commit SHAs need to remain the same.
However, if the conflicts are only minor, you can just explain in your PR to Linus what the resolution should look like.
The tag can be found here:
https://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git/tag/?h=efi-loongarch-for-v6.1-2I have merged this into the EFI tree as well and pushed it out; it should appear in -next tomorrow.
Quoted 4 lines
Quoted 4 lines
b093dc55ba9aefi/loongarch: libstub: remove dependency on flattened DT102faf0747c2efi: libstub: install boot-time memory map as config table7318926e7bc9efi: libstub: remove DT dependency from generic stub7cb6671e3caaefi: libstub: unify initrd loading between architecturesI will have to respin the initrd patch, unfortunately, as it breaks x86. So the signed tag will be updated, and the SHAs above will change as well.
Quoted 7 lines
Quoted 7 lines
Quoted 3 lines
Emm, initrd is also broken on LoongArch, the core kernel gets an
EFI_INVALID_TABLE_ADDRaddress.OK, I will investigate. This was working fine before so I'm not sure what happened there.
I cannot reproduce this. Can you reproduce it with qemu? If so, can you share your command line and .config etc?
Huacai Chen
maintainerRe: [PATCH v2 8/8] efi/loongarch: libstub: remove dependency on flattened DT
Hi, Ard,
Quoted 52 lines · Ard Biesheuvel
Quoted 50 lines · Huacai Chen
Quoted 48 lines · Ard Biesheuvel
Quoted 45 lines · Huacai Chen
Quoted 32 lines · Ard Biesheuvel
Quoted 30 lines · Huacai Chen
Quoted 28 lines · Ard Biesheuvel
Quoted 3 lines · Huacai Chen
Acked-by Huacai Chen <[email protected]>Thank you Huacai
I have created a separate tag with these patches applied onto the first loongarch efi enablement patch (see below)
I would prefer to keep the loongarch trees separate for the next merge window, but if needed to avoid massive conflicts, you could merge the tag into the loongarch tree and rebase your changes on top. But please take care not to rebase those patches themselves: the commit SHAs need to remain the same.
However, if the conflicts are only minor, you can just explain in your PR to Linus what the resolution should look like.
The tag can be found here:
https://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git/tag/?h=efi-loongarch-for-v6.1-2I have merged this into the EFI tree as well and pushed it out; it should appear in -next tomorrow.
Quoted 8 lines
Quoted 4 lines
Quoted 4 lines
b093dc55ba9aefi/loongarch: libstub: remove dependency on flattened DT102faf0747c2efi: libstub: install boot-time memory map as config table7318926e7bc9efi: libstub: remove DT dependency from generic stub7cb6671e3caaefi: libstub: unify initrd loading between architecturesI will have to respin the initrd patch, unfortunately, as it breaks x86. So the signed tag will be updated, and the SHAs above will change as well.
Emm, initrd is also broken on LoongArch, the core kernel gets an
EFI_INVALID_TABLE_ADDRaddress.
Quoted 6 lines
Quoted 3 lines
Quoted 3 lines
OK, I will investigate. This was working fine before so I'm not sure what happened there.
I cannot reproduce this. Can you reproduce it with qemu? If so, can you share your command line and .config etc?
In qemu we also OK, but on a real machine efistub fails at efi_bs_call(locate_device_path, &lf2_proto_guid, &dp, &handle), maybe our UEFI BIOS has some problems? On a real machine we use grub and there is no "initrd" command in UEFI shell.
Huacai
Ard Biesheuvel
maintainerRe: [PATCH v2 8/8] efi/loongarch: libstub: remove dependency on flattened DT
Quoted 60 lines · Huacai Chen
Hi, Ard,
Quoted 56 lines · Ard Biesheuvel
Quoted 53 lines · Huacai Chen
Quoted 51 lines · Ard Biesheuvel
Quoted 39 lines · Huacai Chen
Quoted 37 lines · Ard Biesheuvel
Quoted 34 lines · Huacai Chen
Quoted 32 lines · Ard Biesheuvel
Quoted 3 lines · Huacai Chen
Acked-by Huacai Chen <[email protected]>Thank you Huacai
I have created a separate tag with these patches applied onto the first loongarch efi enablement patch (see below)
I would prefer to keep the loongarch trees separate for the next merge window, but if needed to avoid massive conflicts, you could merge the tag into the loongarch tree and rebase your changes on top. But please take care not to rebase those patches themselves: the commit SHAs need to remain the same.
However, if the conflicts are only minor, you can just explain in your PR to Linus what the resolution should look like.
The tag can be found here:
https://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git/tag/?h=efi-loongarch-for-v6.1-2I have merged this into the EFI tree as well and pushed it out; it should appear in -next tomorrow.
b093dc55ba9aefi/loongarch: libstub: remove dependency on flattened DT102faf0747c2efi: libstub: install boot-time memory map as config table7318926e7bc9efi: libstub: remove DT dependency from generic stub7cb6671e3caaefi: libstub: unify initrd loading between architecturesQuoted 6 lines
Quoted 3 lines
I will have to respin the initrd patch, unfortunately, as it breaks x86. So the signed tag will be updated, and the SHAs above will change as well.
Emm, initrd is also broken on LoongArch, the core kernel gets an
EFI_INVALID_TABLE_ADDRaddress.OK, I will investigate. This was working fine before so I'm not sure what happened there.
Quoted 7 lines
Quoted 2 lines
I cannot reproduce this. Can you reproduce it with qemu? If so, can you share your command line and .config etc?
In qemu we also OK, but on a real machine efistub fails at
efi_bs_call(locate_device_path, &lf2_proto_guid, &dp, &handle), maybe our UEFI BIOS has some problems? On a real machine we use grub and there is no "initrd" command in UEFI shell.
Ah ok, so i guess your GRUB lacks the LoadFile2 patches?
https://lists.gnu.org/archive/html/grub-devel/2022-09/msg00057.html
Those have been blocked in review for almost 2 years. I cc'ed you on the latest version. Without those patches, GRUB will generate a DT to pass the initrd information.
I understand this is annoying right now, but I strongly suggest to implement only a single method of loading the INITRD for EFI boot - it is much easier to reason about when things like secure boot and measured boot become relevant on your architecture.
In any case, you can build your UEFI shell with the following dynamic command from EDK2:
OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.inf
This add a 'initrd' command to the UEFI shell
(it will also work for bare metal platforms not only for virtual machines)
If this is a deal breaker for you, one workaround we might consider is to parse /chosen/linux,initrd-* in the LoongArch stub (but nothing else) if locating the LoadFile2 protocol fails and a DTB exists in the config table array. I'd prefer to avoid that if we can, but at least the initrd is always visible to the stub, for measurement etc.
Ard Biesheuvel
maintainerRe: [PATCH v2 8/8] efi/loongarch: libstub: remove dependency on flattened DT
Quoted 90 lines · Ard Biesheuvel
Quoted 60 lines · Huacai Chen
Hi, Ard,
Quoted 56 lines · Ard Biesheuvel
Quoted 53 lines · Huacai Chen
Quoted 51 lines · Ard Biesheuvel
Quoted 39 lines · Huacai Chen
Quoted 37 lines · Ard Biesheuvel
Quoted 34 lines · Huacai Chen
Quoted 32 lines · Ard Biesheuvel
Quoted 3 lines · Huacai Chen
Acked-by Huacai Chen <[email protected]>Thank you Huacai
I have created a separate tag with these patches applied onto the first loongarch efi enablement patch (see below)
I would prefer to keep the loongarch trees separate for the next merge window, but if needed to avoid massive conflicts, you could merge the tag into the loongarch tree and rebase your changes on top. But please take care not to rebase those patches themselves: the commit SHAs need to remain the same.
However, if the conflicts are only minor, you can just explain in your PR to Linus what the resolution should look like.
The tag can be found here:
https://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git/tag/?h=efi-loongarch-for-v6.1-2I have merged this into the EFI tree as well and pushed it out; it should appear in -next tomorrow.
b093dc55ba9aefi/loongarch: libstub: remove dependency on flattened DT102faf0747c2efi: libstub: install boot-time memory map as config table7318926e7bc9efi: libstub: remove DT dependency from generic stub7cb6671e3caaefi: libstub: unify initrd loading between architecturesQuoted 6 lines
Quoted 3 lines
I will have to respin the initrd patch, unfortunately, as it breaks x86. So the signed tag will be updated, and the SHAs above will change as well.
Emm, initrd is also broken on LoongArch, the core kernel gets an
EFI_INVALID_TABLE_ADDRaddress.OK, I will investigate. This was working fine before so I'm not sure what happened there.
Quoted 7 lines
Quoted 2 lines
I cannot reproduce this. Can you reproduce it with qemu? If so, can you share your command line and .config etc?
In qemu we also OK, but on a real machine efistub fails at
efi_bs_call(locate_device_path, &lf2_proto_guid, &dp, &handle), maybe our UEFI BIOS has some problems? On a real machine we use grub and there is no "initrd" command in UEFI shell.Ah ok, so i guess your GRUB lacks the LoadFile2 patches?
https://lists.gnu.org/archive/html/grub-devel/2022-09/msg00057.html
Those have been blocked in review for almost 2 years. I cc'ed you on the latest version. Without those patches, GRUB will generate a DT to pass the initrd information.
I understand this is annoying right now, but I strongly suggest to implement only a single method of loading the INITRD for EFI boot - it is much easier to reason about when things like secure boot and measured boot become relevant on your architecture.
In any case, you can build your UEFI shell with the following dynamic command from EDK2:
OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.inf
This add a 'initrd' command to the UEFI shell
Quoted 8 lines
(it will also work for bare metal platforms not only for virtual machines)
If this is a deal breaker for you, one workaround we might consider is to parse /chosen/linux,initrd-* in the LoongArch stub (but nothing else) if locating the LoadFile2 protocol fails and a DTB exists in the config table array. I'd prefer to avoid that if we can, but at least the initrd is always visible to the stub, for measurement etc.
Are all DT properties you need for kexec/kdump under the /chosen node?
Huacai Chen
maintainerRe: [PATCH v2 8/8] efi/loongarch: libstub: remove dependency on flattened DT
In reply to Ard BiesheuvelQuoted 70 lines · Ard Biesheuvel
Quoted 60 lines · Huacai Chen
Hi, Ard,
Quoted 56 lines · Ard Biesheuvel
Quoted 53 lines · Huacai Chen
Quoted 51 lines · Ard Biesheuvel
Quoted 39 lines · Huacai Chen
Quoted 37 lines · Ard Biesheuvel
Quoted 34 lines · Huacai Chen
Quoted 32 lines · Ard Biesheuvel
Quoted 3 lines · Huacai Chen
Acked-by Huacai Chen <[email protected]>Thank you Huacai
I have created a separate tag with these patches applied onto the first loongarch efi enablement patch (see below)
I would prefer to keep the loongarch trees separate for the next merge window, but if needed to avoid massive conflicts, you could merge the tag into the loongarch tree and rebase your changes on top. But please take care not to rebase those patches themselves: the commit SHAs need to remain the same.
However, if the conflicts are only minor, you can just explain in your PR to Linus what the resolution should look like.
The tag can be found here:
https://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git/tag/?h=efi-loongarch-for-v6.1-2I have merged this into the EFI tree as well and pushed it out; it should appear in -next tomorrow.
b093dc55ba9aefi/loongarch: libstub: remove dependency on flattened DT102faf0747c2efi: libstub: install boot-time memory map as config table7318926e7bc9efi: libstub: remove DT dependency from generic stub7cb6671e3caaefi: libstub: unify initrd loading between architecturesQuoted 6 lines
Quoted 3 lines
I will have to respin the initrd patch, unfortunately, as it breaks x86. So the signed tag will be updated, and the SHAs above will change as well.
Emm, initrd is also broken on LoongArch, the core kernel gets an
EFI_INVALID_TABLE_ADDRaddress.OK, I will investigate. This was working fine before so I'm not sure what happened there.
Quoted 7 lines
Quoted 2 lines
I cannot reproduce this. Can you reproduce it with qemu? If so, can you share your command line and .config etc?
In qemu we also OK, but on a real machine efistub fails at
efi_bs_call(locate_device_path, &lf2_proto_guid, &dp, &handle), maybe our UEFI BIOS has some problems? On a real machine we use grub and there is no "initrd" command in UEFI shell.
Quoted 3 lines
Ah ok, so i guess your GRUB lacks the LoadFile2 patches?
https://lists.gnu.org/archive/html/grub-devel/2022-09/msg00057.html
Maybe it is a GRUB problem (I'll discuss with GRUB team), but why without this series the GRUB can load initrd? Because in the old way UEFI BIOS fill initrd information to FDT?
Huacai
Quoted 25 lines
Those have been blocked in review for almost 2 years. I cc'ed you on the latest version. Without those patches, GRUB will generate a DT to pass the initrd information.
I understand this is annoying right now, but I strongly suggest to implement only a single method of loading the INITRD for EFI boot - it is much easier to reason about when things like secure boot and measured boot become relevant on your architecture.
In any case, you can build your UEFI shell with the following dynamic command from EDK2:
OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.inf
This add a 'initrd' command to the UEFI shell
(it will also work for bare metal platforms not only for virtual machines)
If this is a deal breaker for you, one workaround we might consider is to parse /chosen/linux,initrd-* in the LoongArch stub (but nothing else) if locating the LoadFile2 protocol fails and a DTB exists in the config table array. I'd prefer to avoid that if we can, but at least the initrd is always visible to the stub, for measurement etc.
Ard Biesheuvel
maintainerRe: [PATCH v2 8/8] efi/loongarch: libstub: remove dependency on flattened DT
Quoted 72 lines · Huacai Chen
Quoted 70 lines · Ard Biesheuvel
Quoted 67 lines · Huacai Chen
Hi, Ard,
Quoted 52 lines · Ard Biesheuvel
Quoted 50 lines · Huacai Chen
Quoted 48 lines · Ard Biesheuvel
Quoted 45 lines · Huacai Chen
Quoted 32 lines · Ard Biesheuvel
Quoted 30 lines · Huacai Chen
Quoted 28 lines · Ard Biesheuvel
Quoted 3 lines · Huacai Chen
Acked-by Huacai Chen <[email protected]>Thank you Huacai
I have created a separate tag with these patches applied onto the first loongarch efi enablement patch (see below)
I would prefer to keep the loongarch trees separate for the next merge window, but if needed to avoid massive conflicts, you could merge the tag into the loongarch tree and rebase your changes on top. But please take care not to rebase those patches themselves: the commit SHAs need to remain the same.
However, if the conflicts are only minor, you can just explain in your PR to Linus what the resolution should look like.
The tag can be found here:
https://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git/tag/?h=efi-loongarch-for-v6.1-2I have merged this into the EFI tree as well and pushed it out; it should appear in -next tomorrow.
Quoted 8 lines
Quoted 4 lines
Quoted 4 lines
b093dc55ba9aefi/loongarch: libstub: remove dependency on flattened DT102faf0747c2efi: libstub: install boot-time memory map as config table7318926e7bc9efi: libstub: remove DT dependency from generic stub7cb6671e3caaefi: libstub: unify initrd loading between architecturesI will have to respin the initrd patch, unfortunately, as it breaks x86. So the signed tag will be updated, and the SHAs above will change as well.
Emm, initrd is also broken on LoongArch, the core kernel gets an
EFI_INVALID_TABLE_ADDRaddress.Quoted 6 lines
Quoted 3 lines
Quoted 3 lines
OK, I will investigate. This was working fine before so I'm not sure what happened there.
I cannot reproduce this. Can you reproduce it with qemu? If so, can you share your command line and .config etc?
In qemu we also OK, but on a real machine efistub fails at
efi_bs_call(locate_device_path, &lf2_proto_guid, &dp, &handle), maybe our UEFI BIOS has some problems? On a real machine we use grub and there is no "initrd" command in UEFI shell.
Quoted 7 lines
Quoted 3 lines
Ah ok, so i guess your GRUB lacks the LoadFile2 patches?
https://lists.gnu.org/archive/html/grub-devel/2022-09/msg00057.html
Maybe it is a GRUB problem (I'll discuss with GRUB team), but why without this series the GRUB can load initrd? Because in the old way UEFI BIOS fill initrd information to FDT?
No GRUB loads the initrd and creates a DT with a /chosen node to record the initrd base and size.
Huacai Chen
maintainerRe: [PATCH v2 8/8] efi/loongarch: libstub: remove dependency on flattened DT
Quoted 76 lines · Ard Biesheuvel
Quoted 74 lines · Huacai Chen
Quoted 72 lines · Ard Biesheuvel
Quoted 60 lines · Huacai Chen
Hi, Ard,
Quoted 56 lines · Ard Biesheuvel
Quoted 53 lines · Huacai Chen
Quoted 51 lines · Ard Biesheuvel
Quoted 39 lines · Huacai Chen
Quoted 37 lines · Ard Biesheuvel
Quoted 34 lines · Huacai Chen
Quoted 32 lines · Ard Biesheuvel
Quoted 3 lines · Huacai Chen
Acked-by Huacai Chen <[email protected]>Thank you Huacai
I have created a separate tag with these patches applied onto the first loongarch efi enablement patch (see below)
I would prefer to keep the loongarch trees separate for the next merge window, but if needed to avoid massive conflicts, you could merge the tag into the loongarch tree and rebase your changes on top. But please take care not to rebase those patches themselves: the commit SHAs need to remain the same.
However, if the conflicts are only minor, you can just explain in your PR to Linus what the resolution should look like.
The tag can be found here:
https://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git/tag/?h=efi-loongarch-for-v6.1-2I have merged this into the EFI tree as well and pushed it out; it should appear in -next tomorrow.
b093dc55ba9aefi/loongarch: libstub: remove dependency on flattened DT102faf0747c2efi: libstub: install boot-time memory map as config table7318926e7bc9efi: libstub: remove DT dependency from generic stub7cb6671e3caaefi: libstub: unify initrd loading between architecturesQuoted 6 lines
Quoted 3 lines
I will have to respin the initrd patch, unfortunately, as it breaks x86. So the signed tag will be updated, and the SHAs above will change as well.
Emm, initrd is also broken on LoongArch, the core kernel gets an
EFI_INVALID_TABLE_ADDRaddress.OK, I will investigate. This was working fine before so I'm not sure what happened there.
Quoted 7 lines
Quoted 2 lines
I cannot reproduce this. Can you reproduce it with qemu? If so, can you share your command line and .config etc?
In qemu we also OK, but on a real machine efistub fails at
efi_bs_call(locate_device_path, &lf2_proto_guid, &dp, &handle), maybe our UEFI BIOS has some problems? On a real machine we use grub and there is no "initrd" command in UEFI shell.Ah ok, so i guess your GRUB lacks the LoadFile2 patches?
Quoted 8 lines
Quoted 5 lines
Maybe it is a GRUB problem (I'll discuss with GRUB team), but why without this series the GRUB can load initrd? Because in the old way UEFI BIOS fill initrd information to FDT?
No GRUB loads the initrd and creates a DT with a /chosen node to record the initrd base and size.
Without this series, efistub also fails at efi_bs_call(locate_device_path, &lf2_proto_guid, &dp, &handle), but initrd works well, this makes me puzzled.
Huacai
Ard Biesheuvel
maintainerRe: [PATCH v2 8/8] efi/loongarch: libstub: remove dependency on flattened DT
Quoted 84 lines · Huacai Chen
Quoted 82 lines · Ard Biesheuvel
Quoted 79 lines · Huacai Chen
Quoted 70 lines · Ard Biesheuvel
Quoted 60 lines · Huacai Chen
Hi, Ard,
Quoted 56 lines · Ard Biesheuvel
Quoted 53 lines · Huacai Chen
Quoted 51 lines · Ard Biesheuvel
Quoted 39 lines · Huacai Chen
Quoted 37 lines · Ard Biesheuvel
Quoted 34 lines · Huacai Chen
Quoted 32 lines · Ard Biesheuvel
Quoted 3 lines · Huacai Chen
Acked-by: Huacai Chen <[email protected]>
Thank you Huacai
I have created a separate tag with these patches applied onto the first loongarch efi enablement patch (see below)
I would prefer to keep the loongarch trees separate for the next merge window, but if needed to avoid massive conflicts, you could merge the tag into the loongarch tree and rebase your changes on top. But please take care not to rebase those patches themselves: the commit SHAs need to remain the same.
However, if the conflicts are only minor, you can just explain in your PR to Linus what the resolution should look like.
The tag can be found here:
https://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git/tag/?h=efi-loongarch-for-v6.1-2I have merged this into the EFI tree as well and pushed it out; it should appear in -next tomorrow.
b093dc55ba9aefi/loongarch: libstub: remove dependency on flattened DT102faf0747c2efi: libstub: install boot-time memory map as config table7318926e7bc9efi: libstub: remove DT dependency from generic stub7cb6671e3caaefi: libstub: unify initrd loading between architecturesQuoted 6 lines
Quoted 3 lines
I will have to respin the initrd patch, unfortunately, as it breaks x86. So the signed tag will be updated, and the SHAs above will change as well.
Emm, initrd is also broken on LoongArch, the core kernel gets an
EFI_INVALID_TABLE_ADDRaddress.OK, I will investigate. This was working fine before so I'm not sure what happened there.
Quoted 7 lines
Quoted 2 lines
I cannot reproduce this. Can you reproduce it with qemu? If so, can you share your command line and .config etc?
In qemu we also OK, but on a real machine efistub fails at
efi_bs_call(locate_device_path, &lf2_proto_guid, &dp, &handle), maybe our UEFI BIOS has some problems? On a real machine we use grub and there is no "initrd" command in UEFI shell.Quoted 3 lines
Ah ok, so i guess your GRUB lacks the LoadFile2 patches?
https://lists.gnu.org/archive/html/grub-devel/2022-09/msg00057.html
Maybe it is a GRUB problem (I'll discuss with GRUB team), but why without this series the GRUB can load initrd? Because in the old way UEFI BIOS fill initrd information to FDT?
Quoted 6 lines
Quoted 2 lines
No GRUB loads the initrd and creates a DT with a /chosen node to record the initrd base and size.
Without this series, efistub also fails at
efi_bs_call(locate_device_path, &lf2_proto_guid, &dp, &handle), but initrd works well, this makes me puzzled.
That is because you don't have DTB support in the core kernel yet right?
Ard Biesheuvel
maintainerRe: [PATCH v2 8/8] efi/loongarch: libstub: remove dependency on flattened DT
Quoted 86 lines · Ard Biesheuvel
Quoted 84 lines · Huacai Chen
Quoted 82 lines · Ard Biesheuvel
Quoted 79 lines · Huacai Chen
Quoted 70 lines · Ard Biesheuvel
Quoted 60 lines · Huacai Chen
Hi, Ard,
Quoted 56 lines · Ard Biesheuvel
Quoted 53 lines · Huacai Chen
Quoted 51 lines · Ard Biesheuvel
Quoted 39 lines · Huacai Chen
Quoted 37 lines · Ard Biesheuvel
Quoted 34 lines · Huacai Chen
Quoted 32 lines · Ard Biesheuvel
On Wed, 21 Sept 2022 at 06:02, Huacai Chen <[email protected]> wrote:
Acked-by: Huacai Chen <[email protected]>
Thank you Huacai
I have created a separate tag with these patches applied onto the
first loongarch efi enablement patch (see below)I would prefer to keep the loongarch trees separate for the next merge
window, but if needed to avoid massive conflicts, you could merge the
tag into the loongarch tree and rebase your changes on top. But please
take care not to rebase those patches themselves: the commit SHAs need
to remain the same.However, if the conflicts are only minor, you can just explain in your
PR to Linus what the resolution should look like.The tag can be found here:
https://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git/tag/?h=efi-loongarch-for-v6.1-2I have merged this into the EFI tree as well and pushed it out; it
should appear in -next tomorrow.b093dc55ba9a efi/loongarch: libstub: remove dependency on flattened DT
102faf0747c2 efi: libstub: install boot-time memory map as config table
7318926e7bc9 efi: libstub: remove DT dependency from generic stub
7cb6671e3caa efi: libstub: unify initrd loading between architecturesQuoted 6 lines
Quoted 3 lines
I will have to respin the initrd patch, unfortunately, as it breaks x86. So the signed tag will be updated, and the SHAs above will change as well.
Emm, initrd is also broken on LoongArch, the core kernel gets an
EFI_INVALID_TABLE_ADDRaddress.OK, I will investigate. This was working fine before so I'm not sure what happened there.
Quoted 7 lines
Quoted 2 lines
I cannot reproduce this. Can you reproduce it with qemu? If so, can you share your command line and .config etc?
In qemu we also OK, but on a real machine efistub fails at
efi_bs_call(locate_device_path, &lf2_proto_guid, &dp, &handle), maybe our UEFI BIOS has some problems? On a real machine we use grub and there is no "initrd" command in UEFI shell.Quoted 3 lines
Ah ok, so i guess your GRUB lacks the LoadFile2 patches?
https://lists.gnu.org/archive/html/grub-devel/2022-09/msg00057.html
Maybe it is a GRUB problem (I'll discuss with GRUB team), but why without this series the GRUB can load initrd? Because in the old way UEFI BIOS fill initrd information to FDT?
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
No GRUB loads the initrd and creates a DT with a /chosen node to record the initrd base and size.
Without this series, efistub also fails at
efi_bs_call(locate_device_path, &lf2_proto_guid, &dp, &handle), but initrd works well, this makes me puzzled.That is because you don't have DTB support in the core kernel yet right?
Never mind - what exact commit are you testing this with?
Ard Biesheuvel
maintainerRe: [PATCH v2 8/8] efi/loongarch: libstub: remove dependency on flattened DT
Quoted 90 lines · Ard Biesheuvel
Quoted 88 lines · Ard Biesheuvel
Quoted 86 lines · Huacai Chen
Quoted 84 lines · Ard Biesheuvel
Quoted 72 lines · Huacai Chen
Quoted 70 lines · Ard Biesheuvel
Quoted 67 lines · Huacai Chen
Hi, Ard,
Quoted 52 lines · Ard Biesheuvel
Quoted 50 lines · Huacai Chen
Quoted 48 lines · Ard Biesheuvel
Quoted 45 lines · Huacai Chen
Quoted 32 lines · Ard Biesheuvel
Quoted 30 lines · Huacai Chen
On Wed, Sep 21, 2022 at 4:15 PM Ard Biesheuvel <[email protected]> wrote:
On Wed, 21 Sept 2022 at 06:02, Huacai Chen <[email protected]> wrote:
Acked-by: Huacai Chen <[email protected]>
Thank you Huacai
I have created a separate tag with these patches applied onto the
first loongarch efi enablement patch (see below)I would prefer to keep the loongarch trees separate for the next merge
window, but if needed to avoid massive conflicts, you could merge the
tag into the loongarch tree and rebase your changes on top. But please
take care not to rebase those patches themselves: the commit SHAs need
to remain the same.However, if the conflicts are only minor, you can just explain in your
PR to Linus what the resolution should look like.The tag can be found here:
https://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git/tag/?h=efi-loongarch-for-v6.1-2I have merged this into the EFI tree as well and pushed it out; it
should appear in -next tomorrow.Quoted 8 lines
Quoted 4 lines
b093dc55ba9a efi/loongarch: libstub: remove dependency on flattened DT
102faf0747c2 efi: libstub: install boot-time memory map as config table
7318926e7bc9 efi: libstub: remove DT dependency from generic stub
7cb6671e3caa efi: libstub: unify initrd loading between architecturesI will have to respin the initrd patch, unfortunately, as it breaks x86. So the signed tag will be updated, and the SHAs above will change as well.
Emm, initrd is also broken on LoongArch, the core kernel gets an
EFI_INVALID_TABLE_ADDRaddress.Quoted 6 lines
Quoted 3 lines
Quoted 3 lines
OK, I will investigate. This was working fine before so I'm not sure what happened there.
I cannot reproduce this. Can you reproduce it with qemu? If so, can you share your command line and .config etc?
In qemu we also OK, but on a real machine efistub fails at
efi_bs_call(locate_device_path, &lf2_proto_guid, &dp, &handle), maybe our UEFI BIOS has some problems? On a real machine we use grub and there is no "initrd" command in UEFI shell.Quoted 7 lines
Quoted 3 lines
Ah ok, so i guess your GRUB lacks the LoadFile2 patches?
https://lists.gnu.org/archive/html/grub-devel/2022-09/msg00057.html
Maybe it is a GRUB problem (I'll discuss with GRUB team), but why without this series the GRUB can load initrd? Because in the old way UEFI BIOS fill initrd information to FDT?
No GRUB loads the initrd and creates a DT with a /chosen node to record the initrd base and size.
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
Without this series, efistub also fails at
efi_bs_call(locate_device_path, &lf2_proto_guid, &dp, &handle), but initrd works well, this makes me puzzled.That is because you don't have DTB support in the core kernel yet right?
Never mind - what exact commit are you testing this with?
OK, so the existing code only does
early_init_dt_scan(fdt_ptr);early_init_fdt_reserve_self();efi_system_table = efi_get_fdt_params(&data);
so it never parses the /chosen node, and therefore does not discover the initrd.
I suppose you may have been running with the loongson-2k patches?
But actually, this describes exactly the problem that I am addressing with this series: you have been inadvertently relying on DT hardware support for initrd functionality ...
Huacai Chen
maintainerRe: [PATCH v2 8/8] efi/loongarch: libstub: remove dependency on flattened DT
Quoted 107 lines · Ard Biesheuvel
Quoted 90 lines · Ard Biesheuvel
Quoted 88 lines · Ard Biesheuvel
Quoted 86 lines · Huacai Chen
Quoted 84 lines · Ard Biesheuvel
Quoted 72 lines · Huacai Chen
Quoted 70 lines · Ard Biesheuvel
Quoted 67 lines · Huacai Chen
Hi, Ard,
Quoted 52 lines · Ard Biesheuvel
Quoted 50 lines · Huacai Chen
Quoted 48 lines · Ard Biesheuvel
Quoted 45 lines · Huacai Chen
Quoted 40 lines · Ard Biesheuvel
On Thu, 22 Sept 2022 at 04:15, Huacai Chen <[email protected]> wrote:
On Wed, Sep 21, 2022 at 4:15 PM Ard Biesheuvel <[email protected]> wrote:
On Wed, 21 Sept 2022 at 06:02, Huacai Chen <[email protected]> wrote:
Acked-by: Huacai Chen <[email protected]>
Thank you Huacai
I have created a separate tag with these patches applied onto the
first loongarch efi enablement patch (see below)I would prefer to keep the loongarch trees separate for the next merge
window, but if needed to avoid massive conflicts, you could merge the
tag into the loongarch tree and rebase your changes on top. But please
take care not to rebase those patches themselves: the commit SHAs need
to remain the same.However, if the conflicts are only minor, you can just explain in your
PR to Linus what the resolution should look like.The tag can be found here:
https://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git/tag/?h=efi-loongarch-for-v6.1-2I have merged this into the EFI tree as well and pushed it out; it
should appear in -next tomorrow.b093dc55ba9a efi/loongarch: libstub: remove dependency on flattened DT
102faf0747c2 efi: libstub: install boot-time memory map as config table
7318926e7bc9 efi: libstub: remove DT dependency from generic stub
7cb6671e3caa efi: libstub: unify initrd loading between architecturesI will have to respin the initrd patch, unfortunately, as it breaks
x86. So the signed tag will be updated, and the SHAs above will change
as well.Emm, initrd is also broken on LoongArch, the core kernel gets an
EFI_INVALID_TABLE_ADDRaddress.Quoted 6 lines
Quoted 3 lines
Quoted 3 lines
OK, I will investigate. This was working fine before so I'm not sure what happened there.
I cannot reproduce this. Can you reproduce it with qemu? If so, can you share your command line and .config etc?
In qemu we also OK, but on a real machine efistub fails at
efi_bs_call(locate_device_path, &lf2_proto_guid, &dp, &handle), maybe our UEFI BIOS has some problems? On a real machine we use grub and there is no "initrd" command in UEFI shell.Quoted 7 lines
Quoted 3 lines
Ah ok, so i guess your GRUB lacks the LoadFile2 patches?
https://lists.gnu.org/archive/html/grub-devel/2022-09/msg00057.html
Maybe it is a GRUB problem (I'll discuss with GRUB team), but why without this series the GRUB can load initrd? Because in the old way UEFI BIOS fill initrd information to FDT?
No GRUB loads the initrd and creates a DT with a /chosen node to record the initrd base and size.
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
Without this series, efistub also fails at
efi_bs_call(locate_device_path, &lf2_proto_guid, &dp, &handle), but initrd works well, this makes me puzzled.That is because you don't have DTB support in the core kernel yet right?
Never mind - what exact commit are you testing this with?
OK, so the existing code only does
early_init_dt_scan(fdt_ptr);early_init_fdt_reserve_self();efi_system_table=efi_get_fdt_params(&data);
Quoted 7 lines
so it never parses the /chosen node, and therefore does not discover the initrd.
I suppose you may have been running with the loongson-2k patches?
But actually, this describes exactly the problem that I am addressing with this series: you have been inadvertently relying on DT hardware support for initrd functionality ...
Yes, the correct way is to update our grub. But for kexec, seems initrd over cmdline is the only way because we don't know how to handle systemtable and don't know how to work together with both ACPI/DT systems after efistub refactoring.
Huacai