On Wed, Apr 01, 2026 at 10:02:37AM +0900, Masami Hiramatsu wrote: > On Tue, 31 Mar 2026 11:18:33 +0100 > Kiryl Shutsemau <[email protected]> wrote: > > > On Wed, Mar 25, 2026 at 11:22:04PM +0900, Masami Hiramatsu wrote: > > > > diff --git a/init/main.c b/init/main.c > > > > index 453ac9dff2da0..14a04c283fa48 100644 > > > > --- a/init/main.c > > > > +++ b/init/main.c > > > > @@ -416,9 +416,64 @@ static int __init warn_bootconfig(char *str) > > > > return 0; > > > > } > > > > > > > > +/* > > > > + * do_early_param() is defined later in this file but called from > > > > + * bootconfig_apply_early_params() below, so we need a forward > > > > declaration. > > > > + */ > > > > +static int __init do_early_param(char *param, char *val, > > > > + const char *unused, void *arg); > > > > + > > > > +/* > > > > + * bootconfig_apply_early_params - dispatch kernel.* keys from the > > > > embedded > > > > + * bootconfig as early_param() calls. > > > > + * > > > > + * early_param() handlers must run before most of the kernel > > > > initialises > > > > + * (e.g. before the GIC driver reads irqchip.gicv3_pseudo_nmi). A > > > > bootconfig > > > > + * attached to the initrd arrives too late for this because the initrd > > > > is not > > > > + * mapped yet when early params are processed. The embedded > > > > bootconfig lives > > > > + * in the kernel image itself (.init.data), so it is always reachable. > > > > + * > > > > + * This function is called from setup_boot_config() which runs in > > > > + * start_kernel() before parse_early_param(), making the timing > > > > correct. > > > > + */ > > > > +static void __init bootconfig_apply_early_params(void) > > > > > > [sashiko comment] > > > | Does this run early enough for architectural parameters? > > > | While setup_boot_config() runs before parse_early_param() in > > > start_kernel(), > > > | it runs after setup_arch(). setup_boot_config() relies on xbc_init() > > > which > > > | uses the memblock allocator, requiring setup_arch() to have already > > > | initialized it. > > > | However, the kernel expects many early parameters (like mem=, earlycon, > > > | noapic, and iommu) to be parsed during setup_arch() via the > > > architecture's > > > | call to parse_early_param(). Since setup_arch() completes before > > > | setup_boot_config() runs, will these architectural early parameters be > > > | silently ignored because the decisions they influence were already > > > | finalized? > > > > > > This is the major reason that I did not support early parameter > > > in bootconfig. Some archs initialize kernel_cmdline in setup_arch() > > > and setup early parameters in it. > > > To fix this, we need to change setup_arch() for each architecture so > > > that it calls this bootconfig_apply_early_params(). > > > > Hi Masami, > > > > I have a question about bootconfig design. Is it necessary to parse the > > bootconfig at boot time? > > > > We could avoid a lot of complexity if we flattened the bootconfig into a > > simple key-value list before embedding it in the kernel image or > > attaching it to the initrd. That would eliminate the need for memory > > allocations and allow the config to be used earlier during boot. > > Hi Kiryl, > > Thanks for a good question. > > If it is embedded in the kernel, yes, we can compile it. But if it is > attached to initrd, the kernel needs to verify it. So anyway we have to > parse the key-value. Of course we can make it a binary data structure, > but it still needs verification. Moreover, memory allocation is not > required by design (the first design uses a statically allocated data). > > Even if it is normalized as key-value, we can not trust the contents > without outer verification system, like verified boot. Therefore, our > basic strategy is to parse the text.
Hm. I am not sure what issues verification aims to solve. Could you elaborate. With normalized key-value structure, we should be able to extract the needed value in the same way as with normal kernel command line, no? -- Kiryl Shutsemau / Kirill A. Shutemov
