On Thu, Jun 27, 2013 at 5:56 PM, Zeng, Star <star.z...@intel.com> wrote: > The purpose is to reduce the burden to merge the header > many times when there are many PeiGetVariable() or > PeiGetNextVariableName() calls.
About how many times would it need to be merged? 10? 1000? This boot path should only occur in rare circumstances, right? Is a HOB the best mechanism that we have for storing a global buffer for a PEI driver? I guess I could also see a PCD being used to store an allocated buffer pointer. Or, you could install a PPI to the allocated buffer. But, all of these (including HOBs) seem to be intended for different purposes than your usage model. -Jordan > -----Original Message----- > From: Jordan Justen [mailto:jljus...@gmail.com] > Sent: Friday, June 28, 2013 6:11 AM > To: Zeng, Star > Cc: edk2-devel@lists.sourceforge.net > 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 <star.z...@intel.com> 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 <star.z...@intel.com> >> >> ========== >> >> 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 <star.z...@intel.com> >> >> ========== >> >> >> >> [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 >> edk2-devel@lists.sourceforge.net >> 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 edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
