On 2017-11-14 14:20, [ext] Andreas J. Reichel wrote: > A new FLAG "USERVAR_TYPE_GLOBAL" is introduced, which gives a variable > the property "global" such that it is saved into all environment > copies. This implements a feature needed by swupdate, which wants to > store a temporary state which must not alter in failure cases or > rollback scenarios.
Hopefully, you can resolve this concern quickly: Setting a global variable during each update process (this is my understanding of this swupdate desire) now means not only changing the config partition of the upcoming version but also modifying the existing, working one. Which measures ensure that we never corrupt the current config, e.g. due to a power loss in the middle of a write? So far, we only modified the upcoming version (config and data), which even put us ahead of U-boot-based switch-over implementations. It now appears to me that we are regressing here, no? If so, could we address this be protecting user variables separately from the critical EFI boot guard state? Jan -- Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate 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 post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/efibootguard-dev/087d5f75-328a-af2f-d0b8-7a4e4d004b2f%40siemens.com. For more options, visit https://groups.google.com/d/optout.
