On 19.02.25 16:34, 'Storm, Christian' via EFI Boot Guard wrote: > Hi Bjoern, > >> Package: libefibootguard >> Version: 0.15-1 > > This is a rather old version of EFI Boot Guard... but upgrading won't help > you here, see below reasoning. > > >> When opening and closing a context within libefibootguard, the bootloader >> config gets corrupted, inhibiting further boots of the system. > > Whether or not they get "corrupted" depends on what you do (or rather not do) > with a once opened environment. The problem is that, in the current > implementation and semantics of libebgenv, `env_close()` first *writes* to > the current environment and then closes it. If you happen to write the > information you read, there's no corruption. However, you're writing to the > environment for no good reason which one shouldn't do. This is why the > SWUpdate binding to EFI Boot Guard > (https://github.com/sbabic/swupdate/blob/master/bootloader/ebg.c#L89-L91) > goes to great lengths to avoid this behavior... > > >> Context: >> We are using efibootguard in context of isar-cip-core with A/B partitioning >> scheme: >> Partition 1 - efibootguard >> Partition 2 - efibootguard config A >> Partition 3 - efibootguard config B >> >> After software update, we need to know if the bootloader is in testing mode >> so that we can trigger a rollback. For this, we need to call >> ebg_env_getglobalstate which is taking a pointer provided by >> ebg_env_open_current. >> >> Code: >> ebgenv_t e; >> ebg_env_open_current(&e); // seems that closing is not really needed, no >> leaks found. >> uint16_t ustate = ebg_env_getglobalstate(NULL); >> //ebg_env_close(&e); not closing it beacuse it writes & breaks >> >> printf("obtained ustate is %u\n", ustate); >> >> if (ustate == 2 /*testing mode */) { >> return 0; >> } >> else { >> return -1; >> } >> >> Expected Behaviour: >> efibootguad configs (on partition 2 and 3) should not get corrupted. >> >> Possible Solution/Workaround: >> We are now calling ebg_env_getglobalstate with NULL as a parameter as, >> looking at the code, it is not used anyway. So we don't need to do >> open/close. >> >> Steps to reproduce: >> >> 1. Do ebg_env_open_current and ebg_env_close in a loop and interrupt it with >> CTRL-C >> 2. check config with bg_printenv >> 3. one config is set to all (most) zeros. Works mostly on first attempt, >> retry loop if needed. >> >> >> We can work for now, but this should be fixed in the future. > > Yes, this will definitely need to be addressed in a libebgenv version 2.0. >
We can simply make that usage of ebg_env_getglobalstate with NULL as parameter official. It was and it will be never used because that "global" in this function implies that a single, externally managed env cannot contribute anything to the call. Another way, but that implies calling a process and parsing output: bg_printenv -c -r -o ustate Jan -- Siemens AG, Foundational Technologies 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/efibootguard-dev/1d2d633c-b2d6-4c43-a28b-7b8913c6b22f%40siemens.com.
