Length limitation for kernel parameters

[Mou, ChengShu(Ben)]

Hello all,

 

I’m sorry to trouble you. I met a problem when I use bg_setenv. I tried to specify kernel parameters but it failed with message “Error, kernel arguments string is too long. Maximum of 255 characters permitted.”

After checking the code, I found that a constant variable ENV_STRING_LENGTH limited the length of file names and kernel parameters. As we know, Linux has a length limitation(255) for file names. For kernel parameters, there is no limitation like this. If I use a customized Linux kernel with parameters more than 255 characters, it will fail.

So, can you provide a workaround for this? Thanks.

 

With best regards,
Cheng Shu Mou

Siemens Ltd., China
RC-CN DI FA BL IE
Tianyuan road No.99
611731 CHENGDU, China
mailto:chengs...@siemens.com
www.siemens.com

 

[Jan Kiszka]

On 07.06.22 07:58, Mou, ChengShu(Ben) wrote:
> Hello all,
>
> I’m sorry to trouble you. I met a problem when I use bg_setenv. I tried
> to specify kernel parameters but it failed with message “Error, kernel
> arguments string is too long. Maximum of 255 characters permitted.”
>
> After checking the code, I found that a constant variable
> ENV_STRING_LENGTH limited the length of file names and kernel
> parameters. As we know, Linux has a length limitation(255) for file
> names. For kernel parameters, there is no limitation like this. If I use
> a customized Linux kernel with parameters more than 255 characters, it
> will fail.
>
> So, can you provide a workaround for this? Thanks.
>

You are right, EFI Boot Guard has this unfortunate limitations. We
cannot easily overcome it for the existing versions because it would
break backward compatibility in the field. However, I'm planning to
renovate the config file with a "version 2" and enable EBG to read both
versions. No code written yet, though, just the intention.

Meanwhile, there might be ways for you to reduce your command line
length. Can you explain what makes it that long? E.g., we recently
dropped MTD layout parameters from an embedded board by moving it into
the device tree [1]. That wasn't hitting EBG's limits yet but was
getting close and also improved readability and maintanability.

Jan

[1]
https://github.com/siemens/meta-iot2050/commit/85040da46f6ec3009b96a934bc12fb6cb28de508

--
Siemens AG, Technology
Competence Center Embedded Linux

[Mou, ChengShu(Ben)]

Thanks for your reply. Unfortunately, the parameters can't be reduced. This kernel is well-tuned for special real time purpose. I think we should find another way to solve this issue.
After checking the code of tools, I found that struct BG_ENVDATA is used for recording environment variables. It will be written to(or read from) a specific file located in configuration partition by bg_setenv.
Reading or writing data with fixed size is more convenient than handling data with variable size. The field kernelparams is defined the same as field kernelfile with the length limitation of Linux file names.
I think we can add a new constant variable larger than 255(e.g. 1024) for field kernelparams and modify related logic code to avoid this limitation. This solution won't break the current mechanism of handling environment variables.
I don't know if I misunderstood something about this solution. Hope your suggestions.

With best regards,
Cheng Shu Mou

Siemens Ltd., China
RC-CN DI FA BL IE
Tianyuan road No.99
611731 CHENGDU, China
mailto:chengs...@siemens.com
www.siemens.com

[Jan Kiszka]

On 10.06.22 10:38, Mou, ChengShu(Ben) wrote:
> Thanks for your reply. Unfortunately, the parameters can't be reduced. This kernel is well-tuned for special real time purpose. I think we should find another way to solve this issue.

Henning, Adriaan, do we really have to create such long lines with
isolcpus, rcu_nocbs & Co. that would exceed 256 chars easily? If so,
this topic needs to be prioritized.

> After checking the code of tools, I found that struct BG_ENVDATA is used for recording environment variables. It will be written to(or read from) a specific file located in configuration partition by bg_setenv.
> Reading or writing data with fixed size is more convenient than handling data with variable size. The field kernelparams is defined the same as field kernelfile with the length limitation of Linux file names.
> I think we can add a new constant variable larger than 255(e.g. 1024) for field kernelparams and modify related logic code to avoid this limitation. This solution won't break the current mechanism of handling environment variables.
> I don't know if I misunderstood something about this solution. Hope your suggestions.

As I wrote, we can't change anything in the layout of EBGENV.DAT without
breaking existing solutions or future versions. The only way forward is
to carefully introduce a new version and add backward compatibility to
EBG to process both variants.

Jan

[Henning Schild]

Am Mon, 13 Jun 2022 09:24:52 +0200
schrieb Jan Kiszka <jan.k...@siemens.com>:

> On 10.06.22 10:38, Mou, ChengShu(Ben) wrote:
> > Thanks for your reply. Unfortunately, the parameters can't be
> > reduced. This kernel is well-tuned for special real time purpose. I
> > think we should find another way to solve this issue.
>
> Henning, Adriaan, do we really have to create such long lines with
> isolcpus, rcu_nocbs & Co. that would exceed 256 chars easily? If so,
> this topic needs to be prioritized.

I just checked one target booting with preempt and several tuning
params.

$ wc -c /proc/cmdline
424 /proc/cmdline

I bet one could drop or shorten some, but going up to 1k or simply 4k
might be a good idea. The number should probably be taken from what the
kernel has, or what other bootloaders might have hardcoded.

grub seems to take the value from a header of the kernel binary, for
recent kernels
https://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/loader/i386/linux.c#n715

Henning

[Jan Kiszka]

On 13.06.22 10:46, Henning Schild wrote:
> Am Mon, 13 Jun 2022 09:24:52 +0200
> schrieb Jan Kiszka <jan.k...@siemens.com>:
>
>> On 10.06.22 10:38, Mou, ChengShu(Ben) wrote:
>>> Thanks for your reply. Unfortunately, the parameters can't be
>>> reduced. This kernel is well-tuned for special real time purpose. I
>>> think we should find another way to solve this issue.
>>
>> Henning, Adriaan, do we really have to create such long lines with
>> isolcpus, rcu_nocbs & Co. that would exceed 256 chars easily? If so,
>> this topic needs to be prioritized.
>
> I just checked one target booting with preempt and several tuning
> params.
>
> $ wc -c /proc/cmdline
> 424 /proc/cmdline
>

OK - will likely only drop when deprecating isolcpus and related
boot-time configurations.

> I bet one could drop or shorten some, but going up to 1k or simply 4k
> might be a good idea. The number should probably be taken from what the
> kernel has, or what other bootloaders might have hardcoded.

For v2 of the file format, we will surely not go for any hard-coded
sizes anymore.

Jan

[Jan Kiszka]

Forgot to mention a workaround that is already available: unified kernel
image [1] (on x86, you could also use the unified kernel image stub and
tooling of systemd-boot). In that case, the command line is built into
that image, and that is not size-constrained. You can use that also for
non-secure boot - and you must use that anyway if you want to do secure
boot.

Jan

[1]
https://github.com/siemens/efibootguard/blob/master/docs/UNIFIED-KERNEL.md

[Mou, ChengShu(Ben)]

Yes, unified kernel image could be a workaround for this issue. However, we need to integrate swupdate, the root command will be specified in run time not in build time.
I don't know if there is a way that we can modify this command in swupdate. Adding a handler for it can be a way but it will need a big effort.

With best regards,
Cheng Shu Mou

Siemens Ltd., China
RC-CN DI FA BL IE
Tianyuan road No.99
611731 CHENGDU, China
mailto:chengs...@siemens.com
www.siemens.com


-----Original Message-----
From: Kiszka, Jan (T CED) <jan.k...@siemens.com>
Sent: Friday, June 17, 2022 4:12 PM
To: Mou, ChengShu(Ben) (DI FA CTR SVC CN) <Chengs...@siemens.com>
Cc: efibootg...@googlegroups.com; Schmidt, Adriaan (T CED SES-DE) <adriaan...@siemens.com>; Schild, Henning (T CED SES-DE) <henning...@siemens.com>
Subject: Re: Length limitation for kernel parameters

[Jan Kiszka]

On 20.06.22 11:17, Mou, ChengShu(Ben) (DI FA CTR SVC CN) wrote:
> Yes, unified kernel image could be a workaround for this issue. However, we need to integrate swupdate, the root command will be specified in run time not in build time.

You won't do secure boot then?

If you will, dynamic reconfiguration via cgroupv2 is long-term the only
option. The kernel command line is security relevant, thus can't be
generated on-the-fly but must be signed, and that can only happen offline.

Jan

[Chris Wyse]

Hi,

Has this issue been dropped?  I will need secure boot at some point (which apparently would resolve the issue), but for now I want to be able to pass more parameters.  My current parameters could probably be scaled back to be less than 255, but I change them quite a bit.  For example, if I want to enable dynamic debug messages at boot, the kernel parameters get large quickly - I need to set parameters for each of the files that I want to track.  

For my purposes, I have no need to be backward compatible.  I'm wondering if the patch is as simple as increasing ENV_STRING_LENGTH in envdata.h, or if there are other things that need to be considered.

Chris

[Jan Kiszka]

On 16.11.22 15:34, Chris Wyse wrote:
> Hi,
> Has this issue been dropped?  I will need secure boot at some point
> (which apparently would resolve the issue), but for now I want to be
> able to pass more parameters.  My current parameters could probably be
> scaled back to be less than 255, but I change them quite a bit.  For
> example, if I want to enable dynamic debug messages at boot, the kernel
> parameters get large quickly - I need to set parameters for each of the
> files that I want to track.  

The issue as not been dropped, just pushed a bit to the back. It depends
on a new file format for which we have first experiments. But that also
revealed that we need some internal refactoring first to avoid existing
duplications. So, this is now next on the agenda.

>
> For my purposes, I have no need to be backward compatible.  I'm
> wondering if the patch is as simple as increasing ENV_STRING_LENGTH in
> envdata.h, or if there are other things that need to be considered.

You can locally patch, of course, but that is then at your own risk.
Once you have your custom version in field, you will be stuck with
patching until those devices have been otherwise migrated on the
mainline again (e.g. a new config file format).

Jan

>
> Chris
>
> On Monday, June 20, 2022 at 5:38:29 AM UTC-4 Jan Kiszka wrote:
>
> On 20.06.22 11:17, Mou, ChengShu(Ben) (DI FA CTR SVC CN) wrote:
> > Yes, unified kernel image could be a workaround for this issue.
> However, we need to integrate swupdate, the root command will be
> specified in run time not in build time.
>
> You won't do secure boot then?
>
> If you will, dynamic reconfiguration via cgroupv2 is long-term the only
> option. The kernel command line is security relevant, thus can't be
> generated on-the-fly but must be signed, and that can only happen
> offline.
>
> Jan
>
> > I don't know if there is a way that we can modify this command in
> swupdate. Adding a handler for it can be a way but it will need a
> big effort.
> >
> > With best regards,
> > Cheng Shu Mou
> >
> > Siemens Ltd., China
> > RC-CN DI FA BL IE
> > Tianyuan road No.99
> > 611731 CHENGDU, China
> > mailto:chengs...@siemens.com

> > www.siemens.com <http://www.siemens.com>

> https://github.com/siemens/efibootguard/blob/master/docs/UNIFIED-KERNEL.md <https://github.com/siemens/efibootguard/blob/master/docs/UNIFIED-KERNEL.md>

> >
> > --
> > Siemens AG, Technology
> > Competence Center Embedded Linux
>
> --
> Siemens AG, Technology
> Competence Center Embedded Linux
>

> --
> You received this message because you are subscribed to the Google
> Groups "EFI Boot Guard" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to efibootguard-d...@googlegroups.com
> <mailto:efibootguard-d...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/efibootguard-dev/5ff18408-5d76-4a7a-8d31-232c0f9c266bn%40googlegroups.com <https://groups.google.com/d/msgid/efibootguard-dev/5ff18408-5d76-4a7a-8d31-232c0f9c266bn%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Chris Wyse]

Thanks for the info.

I have a local copy of the repository (https://github.com/siemens/efibootguard.git), and I didn't see any commits related to this change.  Is the development work being done in a different repository?

[Jan Kiszka]

On 16.11.22 17:19, Chris Wyse wrote:
> Thanks for the info.
>
> I have a local copy of the repository
> (https://github.com/siemens/efibootguard.git), and I didn't see any
> commits related to this change.  Is the development work being done in a
> different repository?
>

There is nothing related merged yet. Traces are RFC patches on the list,
discussions. And then there were some direct discussions, primarily
between Christian (on CC) and me.

Jan

> > > www.siemens.com <http://www.siemens.com> <http://www.siemens.com

> https://github.com/siemens/efibootguard/blob/master/docs/UNIFIED-KERNEL.md <https://github.com/siemens/efibootguard/blob/master/docs/UNIFIED-KERNEL.md> <https://github.com/siemens/efibootguard/blob/master/docs/UNIFIED-KERNEL.md <https://github.com/siemens/efibootguard/blob/master/docs/UNIFIED-KERNEL.md>>

> > >
> > > --
> > > Siemens AG, Technology
> > > Competence Center Embedded Linux
> >
> > --
> > Siemens AG, Technology
> > Competence Center Embedded Linux
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "EFI Boot Guard" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send
> > an email to efibootguard-d...@googlegroups.com
> > <mailto:efibootguard-d...@googlegroups.com>.
> > To view this discussion on the web visit
> >

> https://groups.google.com/d/msgid/efibootguard-dev/5ff18408-5d76-4a7a-8d31-232c0f9c266bn%40googlegroups.com <https://groups.google.com/d/msgid/efibootguard-dev/5ff18408-5d76-4a7a-8d31-232c0f9c266bn%40googlegroups.com> <https://groups.google.com/d/msgid/efibootguard-dev/5ff18408-5d76-4a7a-8d31-232c0f9c266bn%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/efibootguard-dev/5ff18408-5d76-4a7a-8d31-232c0f9c266bn%40googlegroups.com?utm_medium=email&utm_source=footer>>.

>
> --
> Siemens AG, Technology
> Competence Center Embedded Linux
>

> --
> You received this message because you are subscribed to the Google
> Groups "EFI Boot Guard" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to efibootguard-d...@googlegroups.com
> <mailto:efibootguard-d...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/efibootguard-dev/3c7b6ce8-78ec-4bc0-a657-7259883f7a26n%40googlegroups.com <https://groups.google.com/d/msgid/efibootguard-dev/3c7b6ce8-78ec-4bc0-a657-7259883f7a26n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Christian Storm]

Hi,

> > > [...] I will need secure boot at some point (which apparently
> > > would resolve the issue) [...]

It does, to some extent, namely that you're not using EFI Boot Guard
mechanisms anymore to convey kernel parameters but instead use Unified
Kernel Images (UKI) in which these parameters are embedded. The stub
loader hands them over to the kernel. With Secure Boot, the parameters
are immutable build-time defined as the whole UKI is signed (there's
a way around this but you're deliberately jeopardizing integrity then,
defeating the whole purpose). While not using Secure Boot, you can
however modify the stub loader to do whatever you want with kernel
parameters, e.g., setting them based on some condition or even loading
them from VFAT disk... As you will make the transition anyway, you may
be able to do it a bit sooner and don't need to ship a tainted EFI Boot
Guard ;)

> > I have a local copy of the repository
> > (https://github.com/siemens/efibootguard.git), and I didn't see any
> > commits related to this change.  Is the development work being done in a
> > different repository?
>
> There is nothing related merged yet. Traces are RFC patches on the list,
> discussions. And then there were some direct discussions, primarily
> between Christian (on CC) and me.

EFI Boot Guard is upstream first and anything happens in this repository
and its Mailing List. That doesn't include coffee bar talks though to
which Jan is referring to. So yes, we do have some ideas (and even RFC
patches on the list) but we're not truly happy with the results yet. As
you don't change config file formats like your clothes we're still
investigating this. So, it's not dead, quite the contrary, but the
change must be well-defined, future-proof, and backwards-compatible
(for some time being at least). You see, this is not an easy task ;)


Kind regards,
Christian

--
Dr. Christian Storm
Siemens AG, Technology, T CED SES-DE
Otto-Hahn-Ring 6, 81739 München, Germany