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 > On Wednesday, November 16, 2022 at 10:50:04 AM UTC-5 Jan Kiszka wrote: > > 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:[email protected] > > > www.siemens.com <http://www.siemens.com> <http://www.siemens.com > <http://www.siemens.com>> > > > > > > > > > -----Original Message----- > > > From: Kiszka, Jan (T CED) <[email protected]> > > > Sent: Friday, June 17, 2022 4:12 PM > > > To: Mou, ChengShu(Ben) (DI FA CTR SVC CN) <[email protected]> > > > Cc: [email protected]; Schmidt, Adriaan (T CED SES-DE) > > <[email protected]>; Schild, Henning (T CED SES-DE) > > <[email protected]> > > > Subject: Re: Length limitation for kernel parameters > > > > > > On 13.06.22 11:27, Jan Kiszka wrote: > > >> On 13.06.22 10:46, Henning Schild wrote: > > >>> Am Mon, 13 Jun 2022 09:24:52 +0200 > > >>> schrieb Jan Kiszka <[email protected]>: > > >>> > > >>>> 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. > > >> > > > > > > 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 > <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 [email protected] > > <mailto:[email protected]>. > > 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 [email protected] > <mailto:[email protected]>. > 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>. -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/efibootguard-dev/d844ce04-f292-1d40-0b9d-3c4915fbf044%40siemens.com.
