On Jun 28, 2013, at 11:16 AM, Jordan Justen <[email protected]> wrote:
> On Thu, Jun 27, 2013 at 5:56 PM, Zeng, Star <[email protected]> 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,
The basic problem in early PEI is you are running from FLASH so global
variables do not work. Most PPIs are registered from a template that is in ROM
too, so it is hard to play the Protocol game where you hide state behind the
This pointer with the CR macro. So a GUIDed HOB is a way to emulate a global
variable in PEI.
Thanks,
Andrew Fish
> -Jordan
>
>> -----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
------------------------------------------------------------------------------
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
