Re: Transfering Data from GRUB to userspace?

[Max Tottenham]

On 10/28, Daniel Kiper wrote:
> Hi Max,

...

> Yeah, I think you are right. Additionally, please take a look at [1] and
> especially at [2]. The series is about to commit and setup_indirect part
> can be very useful for you. And I would like to see similar feature in the
> Multiboot2 protocol [3].

So it looks to me like setup_data is linux specific, which is fine for
me, but would mean that the BSDs wouldn't be able to take advantage of
some more generic bootloader <-> userspace interface (like a file in a
ramdisk).

I suppose for adding support to [3] the idea would be to define a new
generic boot information structure.

Maybe something like:

Generic 64bit data blob:
    +----------------------------------------------------+
u32 | type = 22                                          |
u32 | size = 28                                          |
u64 | data_load_addr = <paddr of loaded data>            |
u64 | data_len = <length of loaded data>                 |
u32 | data_type = <Some ENUM>                            |
    +----------------------------------------------------+

>From reading the multiboot spec it doesn't sound like there is a
requirement that the boot information data-structure have all it's
associated structures be located in a contiguous region (unlike linux's
setup_data).

I think given the different possible approaches, I'll come up with
a formal API that could have several providers (setup_indirect v.s. initramfs
files, v.s. multiboot boot information structs), and provide an
implementation based on setup_indirect.

I think something like:

struct grub_boot_data_t;

struct grub_boot_data_t {
    grub_addr_t addr;
    uint64_t len;
    grub_uint32_t type;
    struct grub_boot_data_t* next;
};

struct grub_boot_data_provider_t {
 int (*supports) (void*);
 int (*setup) (void*, grub_boot_data_t*);
 struct grub_boot_data_provider_t *next;   
}

struct grub_boot_data_t* addl_data_head;
struct grub_boot_data_provider *boot_data_providers;

grub_boot_data_setup(void* ctx)  {
    for (p: boot_data_providers) {
        if (p->supports(ctx))
            p->setup(ctx, addl_data_head);
    }
}

grub_boot_data_register_provider() {

}

Where each backend would register a 'boot_data_provider', ctx would
contain either a pointer to the kernel setup header/multiboot header,
supports() would indicate whether this backend supports the loader used in
ctx, and setup() would perform the actual business of setting up the
correct structures etc.

> Additionally, I think you can take a look at ACPI ERST and UEFI variables.
> Both can be interesting for you and are used in Linux kernel by something
> called pstore (in general "grep -Ir pstore Documentation" will show you
> some interesting things, e.g. ramoops). Though this stuff is limited in size.

I'm weary of this approach, at least in the UEFI case I'd be weary of
writing to NVRAM backed EFI variables, as I'm pretty sure these NVRAM
chips have pretty low write limits (1-10k write cycles) and are meant to
be updated pretty infrequently. 

I wouldn't want to create an interface that developers might use
thinking that it's fine to stick stuff in there on every boot, only to
find out their NVRAM becomes a ROM after a couple of years.

> 
> Daniel
> 
> [1] https://lkml.org/lkml/2019/10/24/378
> [2] https://lkml.org/lkml/2019/10/24/387
> [3] https://www.gnu.org/software/grub/manual/multiboot2/

-- 
Max Tottenham       | address@hidden
Senior Software Engineer, Server Platform Engineering
/(* Akamai Technologies