RFC: Delay before BS->StartImage()

[Earl Chew]

While debugging an issue, it was helpful to have a short delay before the StartImage() handoff in order to read/capture the efibootguard messages.

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?

Earl

[Jan Kiszka]

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

[Earl Chew]

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

[Jan Kiszka]

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...