The purpose is to reduce the burden to merge the header many times when there are many PeiGetVariable() or PeiGetNextVariableName() calls.
Thanks. Star -----Original Message----- From: Jordan Justen [mailto:[email protected]] Sent: Friday, June 28, 2013 6:11 AM To: Zeng, Star Cc: [email protected] Subject: Re: [edk2] [PATCH 1/2] MdeModulePkg and SecurityPkg: PEI variable does not robustly handle crashes during Reclaim(). In MdeModulePkg/Universal/Variable/Pei/Variable.c GetVariableHeader, why do you need to create the HOB? Could you have a VARIABLE_HEADER structure local variable (on the stack) in FindVariableEx, and merge the header into that variable instead? (Same question for SecurityPkg/VariableAuthenticated/Pei/Variable.c...) -Jordan On Mon, Jun 24, 2013 at 4:29 AM, Zeng, Star <[email protected]> wrote: > ========== > > MdeModulePkg: Variable drivers robustly handle crashes during Reclaim(). > > > > PEI variable implementation checks only the variable header signature > for validity. This does not seem robust if system crash occurred > during previous > Reclaim() operation. If the crash occurred while FTW was rewriting the > variable FV, the signature could be valid even though the rest of the > FV isn't valid. > > Solution: Add a FaultTolerantWritePei driver to check and provide the > FTW last write status, then PEI variable and early phase(before FTW > protocol > ready) of DXE variable can check the status and determine if all or > partial variable data has been backed up in spare block, and then use > the backed up data. > > > > Contributed-under: TianoCore Contribution Agreement 1.0 > > Signed-off-by: Star Zeng <[email protected]> > > ========== > > SecurityPkg: Variable drivers robustly handle crashes during Reclaim(). > > > > PEI variable implementation checks only the variable header signature > for validity. This does not seem robust if system crash occurred > during previous > Reclaim() operation. If the crash occurred while FTW was rewriting the > variable FV, the signature could be valid even though the rest of the > FV isn't valid. > > Solution: PEI variable and early phase(before FTW protocol ready) of > DXE variable can check the FTW last write status provided by > FaultTolerantWritePei and determine if all or partial variable data > has been backed up in spare block, and then use the backed up data. > > > > Contributed-under: TianoCore Contribution Agreement 1.0 > > Signed-off-by: Star Zeng <[email protected]> > > ========== > > > > [Impact] > > 1. If Platforms use VariablePei.inf now, they need to add > FaultTolerantWritePei.inf into the platform *.dsc and *.inf. Because > PEI variable will be updated to depend on the added FaultTolerantWritePei. > > 2. The signature of working block header needs to be updated to > gWorkingBlockSignatureGuid because FTW write header and record will be > updated and exposed to support crossing archs. Low impact to platform > because FaultTolerantWrite DXE driver can help correct or add the > working block header at the first boot if platform *.fdf uses the old > signature GUID or no working block header init data. > > > > > > Thanks! > > Star > > > ---------------------------------------------------------------------- > -------- This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/edk2-devel > ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
