On Thu, Nov 16, 2017 at 06:36:44PM +0100, Jan Kiszka wrote: > 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? >
I see your point. There is always a non-vanishing chance to corrupt data if writing to it. By implementing the global recovery state for SWUpdate the idea was to edit all user variable spaces of all environments. However, as you state, there is a chance that there is a power loss between the sync system call and the controller writing the actual data. Although this is very small, as the environment is written within micro seconds, it should not be disregarded. Also, when chosing a separate region within the same environment file, with a separate CRC, the complete file may be corrupted. The same is true if writing to an adjacent block by not using the file system, since the controller could write the whole track internally instead of just the block. The best way i.m.o. to increase security on this is to create a second area for user variables, for the global ones, which is far enough away from the sensitive evironment, i.e. a reserved block of the FAT file system. Then local user variables are stored into the same environment as before and global user variables are stored directly to disk away from the BGENV.DAT file. The only remaining chance of corruption is due to the write-access to the disk itself. One might also consider using UEFI variables for storing the state. However, due to the fragile implementation on some systems and even accessing them from kernel user space requiring specific kernel configuration settings, I would skip UEFI variables as a solution. Andreas > Jan > > -- > Siemens AG, Corporate Technology, CT RDA ITP SES-DE > Corporate Competence Center Embedded Linux -- Andreas Reichel Dipl.-Phys. (Univ.) Software Consultant [email protected], +49-174-3180074 TNG Technology Consulting GmbH, Betastr. 13a, 85774 Unterfoehring Geschaeftsfuehrer: Henrik Klagges, Dr. Robert Dahlke, Gerhard Mueller Sitz: Unterfoehring * Amtsgericht Muenchen * HRB 135082 -- 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/20171117094813.GB24919%40iiotirae. For more options, visit https://groups.google.com/d/optout.
