Re: RFC: Delay before BS->StartImage()
On 15.01.24 15:50, Earl Chew wrote: > Jan, > >> Are you trying to catch the messages from a screen, or are they >> overwritten on a UART by the succeeding EFI app? > > Yes, in my case, cleared/overwritten by the next EFI app. > EFI provider is U-Boot or a PC firmware? The former has now CONFIG_EFI_SCROLL_ON_CLEAR_SCREEN to prevent that overwriting. >> The problem is that BG_ENVDATA is fully packed and has no extension >> space (yeah...). > > Another direction could be to make this a configuration time option, > but that would get in the way of being able to turn on this behaviour > in a deployed system. > > Hmm ... what do you think about leveraging the user variable space > by reserving some namespace (eg names starting with "ebg_") ? > > https://github.com/siemens/efibootguard/blob/master/docs/API.md#example-on-user-variable-usage > > For example: > > ebg_env_set(&e, "ebg_start_delay_ms", "3000"); > Yes, that would solve the missing-space issue. But this would force to bootloader to start parsing that region, something we avoided so far (and something that likely helped confining our CVE to the library bits). No free lunch... Jan -- Siemens AG, Technology Linux Expert Center -- 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-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/efibootguard-dev/25b4415d-37bb-47d5-af1d-5e8773a9ccd2%40siemens.com.
Re: RFC: Delay before BS->StartImage()
Jan, Are you trying to catch the messages from a screen, or are they overwritten on a UART by the succeeding EFI app? Yes, in my case, cleared/overwritten by the next EFI app. The problem is that BG_ENVDATA is fully packed and has no extension space (yeah...). Another direction could be to make this a configuration time option, but that would get in the way of being able to turn on this behaviour in a deployed system. Hmm ... what do you think about leveraging the user variable space by reserving some namespace (eg names starting with "ebg_") ? https://github.com/siemens/efibootguard/blob/master/docs/API.md#example-on-user-variable-usage For example: ebg_env_set(&e, "ebg_start_delay_ms", "3000"); Earl On 2024-01-14 23:37, Jan Kiszka wrote: On 15.01.24 00:20, 'Earl Chew' via EFI Boot Guard wrote: While debugging an issue, it was helpful to have a short delay before the StartImage() handoff in order to read/capture the efibootguard messages. Are you trying to catch the messages from a screen, or are they overwritten on a UART by the succeeding EFI app? For now, I used a 3 second BS->Stall() before invoking StartImage(). While this seems useful and unobtrusive enough to me, upstream users are probably used to the existing behaviour. What does the team think about another environment key (watchdog_timeout_sec vs start_delay_sec) to achieve this? The problem is that BG_ENVDATA is fully packed and has no extension space (yeah...). We ran into that issue before, and the long-term plan is to have a new configuration format, plus a clear migration path. Short-term, not much is possible without breaking existing deployments. Jan -- 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-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/efibootguard-dev/4e7dea5d-3ebe-425f-827b-375c564de18a%40yahoo.com.
Re: RFC: Delay before BS->StartImage()
On 15.01.24 00:20, 'Earl Chew' via EFI Boot Guard wrote: > While debugging an issue, it was helpful to have a short delay before > the StartImage() handoff in order to read/capture the efibootguard > messages. > Are you trying to catch the messages from a screen, or are they overwritten on a UART by the succeeding EFI app? > For now, I used a 3 second BS->Stall() before invoking StartImage(). > > While this seems useful and unobtrusive enough to me, upstream users are > probably used to the existing behaviour. > > What does the team think about another environment key > (watchdog_timeout_sec vs start_delay_sec) to achieve this? > The problem is that BG_ENVDATA is fully packed and has no extension space (yeah...). We ran into that issue before, and the long-term plan is to have a new configuration format, plus a clear migration path. Short-term, not much is possible without breaking existing deployments. Jan -- Siemens AG, Technology Linux Expert Center -- 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-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/efibootguard-dev/ccd42a74-b702-4f7b-a41b-5fb2394ea4c8%40siemens.com.
