Proposal: EFI boot stub configuration file
Hello,
In some EFI boot environments (e.g. booting from an external medium or non-standard systems where tools like efibootmgr don't work), it is currently impossible to pass the right arguments to the kernel unless an EFI shell is launched. To ameliorate this, I propose that if image->load_options_size is 0 (indicating no arguments were passed) AND image->parent_handle is NULL (indicating that the image was loaded automatically by the firmware), then the kernel looks for a file in some fixed, possibly configurable place (e.g. \efi\linux\params), sets image->load_options_size to its size, and sets image->load_options to its contents. On any error whatsoever (finding the file, reading it, getting its size, whatever), any allocated memory would be freed and load_options_size would be set back to 0. Since the arguments are already converted to ASCII and parsed during the boot process, the file would be expected to be in UCS-2 format and no validation would be done in the configuration loading code. I'll write something up over the next week or so and submit it as an RFC patch series, but I thought I'd post this here first in case anyone has immediate feedback based on this description.
Cheers,
Shea Levy
Quoted 12 lines · Shea Levy
Hello,
In some EFI boot environments (e.g. booting from an external medium or non-standard systems where tools like efibootmgr don't work), it is currently impossible to pass the right arguments to the kernel unless an EFI shell is launched. To ameliorate this, I propose that if
image->load_options_sizeis 0 (indicating no arguments were passed) ANDimage->parent_handleis NULL (indicating that the image was loaded automatically by the firmware), then the kernel looks for a file in some fixed, possibly configurable place (e.g. \efi\linux\params), setsimage->load_options_sizeto its size, and setsimage->load_optionsto its contents. On any error whatsoever (finding the file, reading it,
Quoted 9 lines
getting its size, whatever), any allocated memory would be freed and
load_options_sizewould be set back to 0. Since the arguments are already converted to ASCII and parsed during the boot process, the file would be expected to be in UCS-2 format and no validation would be done in the configuration loading code. I'll write something up over the next week or so and submit it as an RFC patch series, but I thought I'd post this here first in case anyone has immediate feedback based on this description.
A file in UCS-2 seems messed up.
Otherwise, seems like a reasonable idea, with a major caveat... since the whole point of this is to do something when it isn't possible to set NVRAM variables, it would make most sense to me if the configuration file could be founin a specific location relative to the kernel image itself.
-hpa
Quoted 1 line · H. Peter Anvin
A file in UCS-2 seems messed up.
Yeah, it seemed like a good way to let the code be dumb but upon reflection it'd just be a confusing inefficiency.
Quoted 1 line
Otherwise, seems like a reasonable idea, with a major caveat... since the whole point of this is to do something when it isn't possible to set NVRAM variables, it would make most sense to me if the configuration file could be founin a specific location relative to the kernel image itself.
OK. I'll try both approaches to see if the code complexity is greatly increased in the relative path case.
Cheers,
Shea
Quoted 1 line · Shea Levy
the file would be expected to be in UCS-2 format
Actually, on second thought I could just add a check to see if the parent handle is NULL in an else if after the already-existing check to see if the command line options are NULL. Then the file can be expected to be ASCII.