Current GetVariable implementation will return the first variable for
empty str VariableName, it is because GetVariable and GetNextVariablename
are sharing same function FindVariable.
But UEFI sepc defines SetVariable that If VariableName is an empty string,
then EFI_INVALID_PARAMETER is returned, that means an empty string variable
could never be set successfully, so GetVariable should return error for
empty string VariableName.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
What to do:
1. Merge from VariablePei in SecurityPkg to VariablePei in MdeModulePkg.
Why to do:
1. Remove code duplication and reduce maintenance effort.
The code logic of VariablePei in SecurityPkg is same with VariablePei
in MdeModulePkg.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17756 6f19259b-4bc3-4df7-8a09-765794883524
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.zeng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14454 6f19259b-4bc3-4df7-8a09-765794883524
The Variable PEI and RuntimeDxe drivers were using the attribute 'HeaderLength' of
EFI_FIRMWARE_VOLUME_HEADER without checking if a Firmware Volume Header was existing at
the base address.
In case the Firmware Volume Header does not exist or is corrupted, the attribute 'HeaderLength'
is a non valid value that can lead to a non valid physical address when accessing produces an
access error.
Signed-off-by: oliviermartin
Reviewed-by: niruiyu
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@12836 6f19259b-4bc3-4df7-8a09-765794883524
1. Rename EFI_PEI_NEXT_VARIABLE_NAME2 to EFI_PEI_GET_NEXT_VARIABLE_NAME2, as PI 1.2 specifies.
2. Add return status description for PEI Service FfsGetVolumeInfo.
3. Update parameter description for EFI_PEI_READ_ONLY_VARIABLE2_PPI.NextVariableName().
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@9438 6f19259b-4bc3-4df7-8a09-765794883524
1. record the distance of two neighboring VAR_ADDED type variables rather than the offset of each variable. As the field recording this info is UINT16 width, the latter causes in IA32/X64 platform, it can only cache those variables from offset 0 to offset 2^16; in IPF platform, from offset 0 to offset 2^18(extend the scope by left-shift the offset two bits).
when taking the former algorithm, the max range of caching variable is from offset 0 to offset 122*(2^16)
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@8625 6f19259b-4bc3-4df7-8a09-765794883524
[Root Cause]
The root cause is that in FindVariable function, original code logic will traverse all variable stored in variable volatile/non-volatile area. If the non-variable area is full and Linux sets a new variable, the caller of GetNextVariablePtr will get the address of next memory block, but this block doesn't be reserved as RUNTIME attribute. Therefore its corresponding page translation table doesn't exist and causes linux kernel panic.
Note that, Variable Pei driver has not such issue as the flash area is accessed in pre-os environment.All page table entries are filled. The access to next memory block will not cause such issue.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@7910 6f19259b-4bc3-4df7-8a09-765794883524
2. move VariableFormat.h into GUID directory and change the “Signature” field of the VARIABLE_STORE_HEADER to gEfiVariableGuid value.
3. merging VARIABLE_INFO_ENTRY structure into the new Include/Guid/VariableFormat.h
4. change gEfiVariableInfoGuid into gEfiVariableGuid.
5. modify FDF files to use new guid value instead of the original signature.
6. all code related to signature is changed to use guid value.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@7728 6f19259b-4bc3-4df7-8a09-765794883524
PeiGetVariable() and PeiGetNextVariableName() do not check NULL pointer access, not follow spec
[Impaction]
modify the Variable.c file in MdeModulePkg/Universal/Variable/Pei
[Reference Info]
PeiGetVariable() and PeiGetVariableName() do not follow spec
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@4899 6f19259b-4bc3-4df7-8a09-765794883524
2) Add HEADER_VALID_ONLY state of variable, which represents only the header is valid and the data/name is stale. This may be caused by incomplete data updating. Adding the state helps to check whether the header is valid. If variable header is valid, then we must skip the data of variable with the valid size. If the header is invalid, we should only skip the header of variable.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@4555 6f19259b-4bc3-4df7-8a09-765794883524
First round of PI enabling work:
1) PiPeiCis changes (CONST, EFI_PEI_FILE_HANDLE.. etc)
2) Make use of FirmwareVolume 2 protocol.
3) Verified for Nt32Pkg and real platform for S3.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@3773 6f19259b-4bc3-4df7-8a09-765794883524
Star Zeng
lzeng14
oliviermartin
niruiyu
sfu5
erictian
andrewfish
hhtian
xli24
rsun3
eric_tian
qhuang8
jji4
qwang12
lgao4
gtian
yshang1
klu2