[PATCH 0/2] Import environment variables from FIT configuration
Lukas Funke
lukas.funke-oss at weidmueller.com
Tue Jul 2 14:58:55 CEST 2024
Hi Quentin,
On 02.07.2024 13:37, Quentin Schulz wrote:
> Hi Lukas,
>
> On 7/2/24 1:01 PM, Lukas Funke wrote:
>> Hi Quentin,
>>
>> On 02.07.2024 11:16, Quentin Schulz wrote:
>>> Hi Lukas,
>>>
>>> On 7/2/24 8:48 AM, lukas.funke-oss at weidmueller.com wrote:
>>>> From: Lukas Funke <lukas.funke at weidmueller.com>
>>>>
>>>>
>>>> This series enables U-Boot to import environment variables from the
>>>> selectd FIT configuration. One use-case is that the overall build
>>>> process
>>>> enriches the FIT configuration node with dm-verity information which
>>>> should be injected into the kernel commandline. U-Boot will then read
>>>> these (possibly signed) environment variables and put them into the
>>>> actual Kernel commandline using variable replacement
>>>> (see CONFIG_BOOTARGS_SUBST).
>>>>
>>>> Example:
>>>>
>>>> Config:
>>>> CONFIG_BOOTARGS_SUBST=y
>>>> CONFIG_ENV_IMPORT_FIT_CONF=y
>>>>
>>>> FIT:
>>>> configurations {
>>>> default = "conf-1";
>>>> conf-1 {
>>>> kernel = "kernel-1";
>>>> fdt = "fdt-1";
>>>> env,dm-verity-args = "dm-mod.create=...";
>>>> env,bar = "someothervalue";
>>>> };
>>>> };
>>>>
>>>> U-Boot cmdline:
>>>> => env set bootargs="rootfstype=squashfs root=/dev/xyz
>>>> ${dm-verity-args} ro"
>>>> => boot
>>>>
>>>> Kernel cmdline:
>>>> Kernel command line: rootfstype=squashfs ... dm-mod.create= ...
>>>>
>>>>
>>>
>>> I think FIT supports storing U-Boot scripts and running those via
>>> `source` command (usually the file extension is .scr).
>>>
>>> I do not know if there's support for automatically loading this .scr
>>> as part of a config node though, but if there isn't I guess it'd make
>>> more sense to support this case than to come up with yet another
>>> implementation?
>>>
>>> What do you think?
>>
>> I wasn't aware of this, thanks for pointing it out!
>>
>> This patch was mainly inspired by the dm-vertiy use-case which
>> requires just env-variables and no (complex) scripts.
>>
>> There is currently no mechanism to source/run such scripts automatically.
>>
>> How would you distinguish between scripts that should run
>> automatically und scripts which are sourced by a specific
>> board/shell-script implementation? I guess there are good reasons to
>> not run such scripts
>
> Scripts in conf would be automatically run? Scripts not in conf needs to
> be executed via `source` command for example?
>
> Not sure what to do if you want a script linked to a conf but not run
> automatically though (and what would be the use-case?). I guess you
> could have a script automatically run (so in conf node) that sets a
> variable to know where to look for the other script that isn't
> automatically executed?
Sounds like yet another level of indirection. Not sure if this a good or
a bad thing, but makes things definitely more complicated.
>
>> per default. I would also change current behaviour. For env variables
>> I see no harm.
>>
>
> If the env properties in the FIT image are part of the checksum and
> signature of the conf node, which is necessary for secure boot, I guess
> "no harm" fits the bill.
To my current knowledge the configuration node itself is signed. Thus,
all env-properties are signed. Please correct me if I'm wrong.
>
> Cheers,
> Quentin
More information about the U-Boot
mailing list