From: sashiko-bot@kernel.org
To: "Breno Leitao" <leitao@debian.org>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH v5 7/7] x86/setup: prepend embedded bootconfig cmdline before parse_early_param
Date: Wed, 17 Jun 2026 11:43:07 +0000 [thread overview]
Message-ID: <20260617114308.08AA81F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260617-bootconfig_using_tools-v5-7-fd589a9cc5e3@debian.org>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Split-brain and silent loss of embedded bootconfig when an initrd bootconfig is present.
- [High] The check for 'bootconfig' in setup_arch() does not stop at the '--' separator, leading to a split-brain state if 'bootconfig' is passed strictly as an init argument.
--
commit 8df914967d65efb57f129f5003c1c8d584ad9df9
Author: Breno Leitao <leitao@debian.org>
x86/setup: prepend embedded bootconfig cmdline before parse_early_param
This patch modifies the x86 boot sequence to prepend embedded bootconfig
parameters to the kernel command line early in setup_arch(). It manually
checks for the "bootconfig" parameter before parse_early_param() runs,
and adjusts setup_boot_config() to avoid duplicating the command line
prepend later.
> The prepend necessarily runs before setup_boot_config() detects an
> initrd bootconfig, so an initrd cannot override the embedded "kernel"
> keys for early_param(). This is intentional: the embedded cmdline acts
> like a build-time CONFIG_CMDLINE. An initrd bootconfig's "kernel" keys
> never reached early_param() anyway (they apply late via
> extra_command_line), so nothing is lost -- the initrd keys still apply
> late, with last-wins keeping the embedded values in effect.
[Severity: High]
Does this accurately reflect the behavior when an initrd bootconfig is
present?
If both an embedded bootconfig and an initrd bootconfig are present,
setup_boot_config() handles it like this:
init/main.c:setup_boot_config() {
data = get_boot_config_from_initrd(&size);
if (!data) {
data = xbc_get_embedded_bootconfig(&size);
from_embedded = true;
}
...
}
This means the embedded bootconfig data is entirely ignored for the runtime
tree, silently discarding any tree-structured configuration (like ftrace or
IMA) from the embedded bootconfig.
Furthermore, extra_command_line from the initrd is placed before
boot_command_line in saved_command_line. Since the embedded keys were
already prepended to boot_command_line in setup_arch(), they appear
after the initrd keys.
With last-wins semantics, the embedded kernel parameters override the
initrd kernel parameters, while the tree data comes exclusively from the
initrd.
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 46882ce79c3a4..d69ba84c203f1 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
[ ... ]
> @@ -924,6 +926,31 @@ void __init setup_arch(char **cmdline_p)
> builtin_cmdline_added = true;
> #endif
>
> + /*
> + * Match the runtime bootconfig parser's opt-in: only fold the
> + * embedded kernel.* keys into the cmdline when "bootconfig" is
> + * present on the command line, or CONFIG_BOOT_CONFIG_FORCE is set.
> + * setup_boot_config()'s parse_args() loop treats any presence of
> + * the "bootconfig" key as opt-in (bare, =0, =1, ...), so check both
> + * forms here: cmdline_find_option_bool() matches the bare key,
> + * cmdline_find_option() matches "bootconfig=<anything>". Without
> + * the second check, "bootconfig=0" would skip the early prepend
> + * but still trigger the late runtime apply -- a split-brain state.
> + * CONFIG_BOOT_CONFIG_FORCE defaults to y when BOOT_CONFIG_EMBED is
> + * set, so on the default config the embedded keys are applied
> + * unconditionally.
> + */
> + {
> + char buf[8];
> +
> + if (IS_ENABLED(CONFIG_BOOT_CONFIG_FORCE) ||
> + cmdline_find_option_bool(boot_command_line, "bootconfig") ||
> + cmdline_find_option(boot_command_line, "bootconfig",
> + buf, sizeof(buf)) >= 0)
> + xbc_prepend_embedded_cmdline(boot_command_line,
> + COMMAND_LINE_SIZE);
> + }
[Severity: High]
Could this create a split-brain state if "bootconfig" is passed strictly as
an init argument (e.g., after the "--" separator)?
The cmdline_find_option_bool() and cmdline_find_option() functions search
the entire command-line string and do not stop at the "--" separator.
If a user passes "-- bootconfig", setup_arch() will detect it and
prematurely prepend the embedded kernel parameters to the command line.
Later, the runtime parser parse_args() in setup_boot_config() strictly
stops parsing at "--". It will fail to find "bootconfig" and exit early
without initializing the bootconfig subsystem.
This leaves the system in a state where the embedded kernel parameters are
fully applied, but the bootconfig tree itself remains completely
uninitialized.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260617-bootconfig_using_tools-v5-0-fd589a9cc5e3@debian.org?part=7
prev parent reply other threads:[~2026-06-17 11:43 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-17 11:23 [PATCH v5 0/7] bootconfig: embed kernel.* cmdline at build time Breno Leitao
2026-06-17 11:23 ` [PATCH v5 1/7] bootconfig: fix NULL-pointer arithmetic in xbc_snprint_cmdline() Breno Leitao
2026-06-17 11:23 ` [PATCH v5 2/7] bootconfig: render descendant keys when xbc_snprint_cmdline() root has a value Breno Leitao
2026-06-17 11:23 ` [PATCH v5 3/7] bootconfig: render embedded bootconfig as a kernel cmdline at build time Breno Leitao
2026-06-17 11:37 ` sashiko-bot
2026-06-17 13:30 ` Nicolas Schier
2026-06-17 11:23 ` [PATCH v5 4/7] bootconfig: clean build-time tools/bootconfig from make clean Breno Leitao
2026-06-17 13:45 ` Nicolas Schier
2026-06-17 11:23 ` [PATCH v5 5/7] bootconfig: add xbc_prepend_embedded_cmdline() helper Breno Leitao
2026-06-17 11:23 ` [PATCH v5 6/7] Documentation: bootconfig: document build-time cmdline rendering Breno Leitao
2026-06-17 11:23 ` [PATCH v5 7/7] x86/setup: prepend embedded bootconfig cmdline before parse_early_param Breno Leitao
2026-06-17 11:43 ` sashiko-bot [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260617114308.08AA81F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=leitao@debian.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox