[edk2] [Patch] BaseTools: report build time measured by module of EDKII Build

[Yonghong Zhu]

In the build report, we add AutoGen Phase, Make Phase and GenFds Phase
time duration in the Platform Summary section, and we also add a item
in Module section to display module and library's build time.

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yonghong Zhu 
---
 BaseTools/Source/Python/AutoGen/AutoGen.py   |  1 +
 BaseTools/Source/Python/build/BuildReport.py | 29 +--
 BaseTools/Source/Python/build/build.py   | 73 +---
 3 files changed, 92 insertions(+), 11 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py 
b/BaseTools/Source/Python/AutoGen/AutoGen.py
index 1a8c0d9..6bbfc87 100644
--- a/BaseTools/Source/Python/AutoGen/AutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
@@ -2693,10 +2693,11 @@ class ModuleAutoGen(AutoGen):
 self.IsAsBuiltInfCreated = False
 self.DepexGenerated = False
 
 self.BuildDatabase = self.Workspace.BuildDatabase
 self.BuildRuleOrder = None
+self.BuildTime  = 0
 
 self._Module  = None
 self._Name= None
 self._Guid= None
 self._Version = None
diff --git a/BaseTools/Source/Python/build/BuildReport.py 
b/BaseTools/Source/Python/build/BuildReport.py
index 38ee26d..f0e9093 100644
--- a/BaseTools/Source/Python/build/BuildReport.py
+++ b/BaseTools/Source/Python/build/BuildReport.py
@@ -305,11 +305,15 @@ class LibraryReport(object):
 LibInfPath = str(Lib)
 LibClassList = Lib.LibraryClass[0].LibraryClass
 LibConstructorList = Lib.ConstructorList
 LibDesstructorList = Lib.DestructorList
 LibDepexList = Lib.DepexExpression[M.Arch, M.ModuleType]
-self.LibraryList.append((LibInfPath, LibClassList, 
LibConstructorList, LibDesstructorList, LibDepexList))
+for LibAutoGen in M.LibraryAutoGenList:
+if LibInfPath == LibAutoGen.MetaFile.Path:
+LibTime = LibAutoGen.BuildTime
+break
+self.LibraryList.append((LibInfPath, LibClassList, 
LibConstructorList, LibDesstructorList, LibDepexList, LibTime))
 
 ##
 # Generate report for module library information
 #
 # This function generates report for the module library.
@@ -342,10 +346,12 @@ class LibraryReport(object):
 if LibDestructor:
 EdkIILibInfo += " D = " + LibDestructor
 LibDepex = " ".join(LibraryItem[4])
 if LibDepex:
 EdkIILibInfo += " Depex = " + LibDepex
+if LibraryItem[5]:
+EdkIILibInfo += " Time = " + LibraryItem[5]
 if EdkIILibInfo:
 FileWrite(File, "{%s: %s}" % (LibClass, EdkIILibInfo))
 else:
 FileWrite(File, "{%s}" % LibClass)
 
@@ -551,10 +557,11 @@ class ModuleReport(object):
 self.UefiSpecVersion = 
M.Module.Specification.get("UEFI_SPECIFICATION_VERSION", "")
 self.PiSpecVersion = 
M.Module.Specification.get("PI_SPECIFICATION_VERSION", "")
 self.PciDeviceId = M.Module.Defines.get("PCI_DEVICE_ID", "")
 self.PciVendorId = M.Module.Defines.get("PCI_VENDOR_ID", "")
 self.PciClassCode = M.Module.Defines.get("PCI_CLASS_CODE", "")
+self.BuildTime = M.BuildTime
 
 self._BuildDir = M.BuildDir
 self.ModulePcdSet = {}
 if "PCD" in ReportType:
 #
@@ -646,10 +653,12 @@ class ModuleReport(object):
 FileWrite(File, "Size: 0x%X (%.2fK)" % (self.Size, 
self.Size / 1024.0))
 if self.Hash:
 FileWrite(File, "SHA1 HASH:%s *%s" % (self.Hash, 
self.ModuleName + ".efi"))
 if self.BuildTimeStamp:
 FileWrite(File, "Build Time Stamp: %s" % self.BuildTimeStamp)
+if self.BuildTime:
+FileWrite(File, "Module Build Time:%s" % self.BuildTime)
 if self.DriverType:
 FileWrite(File, "Driver Type:  %s" % self.DriverType)
 if self.UefiSpecVersion:
 FileWrite(File, "UEFI Spec Version:%s" % self.UefiSpecVersion)
 if self.PiSpecVersion:
@@ -1694,22 +1703,31 @@ class PlatformReport(object):
 # module list sections.
 #
 # @param selfThe object pointer
 # @param FileThe file object for report
 # @param BuildDuration   The total time to build the modules
+# @param AutoGenTime The total time of AutoGen Phase
+# @param MakeTimeThe total time of Make Phase
+# @param GenFdsTime  The total time of GenFds Phase
 # @param ReportType  The kind of report items in the final report file
 #
-def GenerateReport(self, File, BuildDuration, ReportType):
+def GenerateReport(self, File, 

Re: [edk2] [PATCH 4/6] MdeModulePkg/DxeNetLib: Fix negative value left shift

[Wu, Jiaxin]

Reviewed-by: Wu Jiaxin 


> -Original Message-
> From: Wu, Hao A
> Sent: Tuesday, September 19, 2017 7:44 PM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Shi, Steven ;
> Fu, Siyuan ; Ye, Ting ; Wu, Jiaxin
> ; Zeng, Star ; Dong, Eric
> 
> Subject: [PATCH 4/6] MdeModulePkg/DxeNetLib: Fix negative value left shift
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=698
> 
> Within function NetRandomInitSeed(), left shift a negative value is used
> in:
> "~Time.Hour << 24"
> 
> which involves undefined behavior.
> 
> Since Time.Hour is of type UINT8 (range from 0 to 23), hence ~Time.Hour
> will be a negative value (of type int, signed).
> 
> According to the C11 spec, Section 6.5.7:
> > 4 The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated
> >   bits are filled with zeros. If E1 has an unsigned type, the value
> >   of the result is E1 * 2^E2 , reduced modulo one more than the
> >   maximum value representable in the result type. If E1 has a signed
> >   type and nonnegative value, and E1 * 2^E2 is representable in the
> >   result type, then that is the resulting value; otherwise, the
> >   behavior is undefined.
> 
> This commit explicitly cast 'Time.Hour' with UINT32 to resolve this issue.
> 
> Cc: Steven Shi 
> Cc: Fu Siyuan 
> Cc: Ye Ting 
> Cc: Wu Jiaxin 
> Cc: Star Zeng 
> Cc: Eric Dong 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu 
> ---
>  MdeModulePkg/Library/DxeNetLib/DxeNetLib.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
> b/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
> index 7cd7e3aca0..ca5413edcc 100644
> --- a/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
> +++ b/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
> @@ -872,7 +872,7 @@ NetRandomInitSeed (
>UINT64MonotonicCount;
> 
>gRT->GetTime (, NULL);
> -  Seed = (~Time.Hour << 24 | Time.Day << 16 | Time.Minute << 8 |
> Time.Second);
> +  Seed = (~(UINT32)Time.Hour << 24 | Time.Day << 16 | Time.Minute << 8 |
> Time.Second);
>Seed ^= Time.Nanosecond;
>Seed ^= Time.Year << 7;
> 
> --
> 2.12.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ShellPkg/dmpstore: Show name of known variable vendor GUID

[Ni, Ruiyu]

"Variable %H%s%N '%H%g%N:%H%s%N' DataSize = 0x%02x\r\n"
"Variable %H%s%N '%H%s%N:%H%s%N' DataSize = 0x%02x\r\n"

HEADER_LINE dumps the GUID in hex format, using %g.
HEADER_LINE2 dumps the GUID name, using %s.

Thanks/Ray

> -Original Message-
> From: Carsey, Jaben
> Sent: Monday, September 18, 2017 11:24 PM
> To: Ni, Ruiyu ; edk2-devel@lists.01.org
> Cc: Li, Huajing 
> Subject: RE: [PATCH] ShellPkg/dmpstore: Show name of known variable
> vendor GUID
> 
> Whats the difference between HEADER_LINE and HEADER_LINE2?  They look
> the same to me...
> 
> > -Original Message-
> > From: Ni, Ruiyu
> > Sent: Sunday, September 17, 2017 11:42 PM
> > To: edk2-devel@lists.01.org
> > Cc: Li, Huajing ; Carsey, Jaben
> > 
> > Subject: [PATCH] ShellPkg/dmpstore: Show name of known variable
> vendor
> > GUID
> > Importance: High
> >
> > From: Huajing Li 
> >
> > Change "dmpstore" to show name of known variable vendor GUID.
> > The name is got from ShellProtocol.GetGuidName().
> >
> > Cc: Jaben Carsey 
> > Reviewed-by: Ruiyu Ni 
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Huajing Li 
> > ---
> >  ShellPkg/Library/UefiShellDebug1CommandsLib/DmpStore.c  | 17
> > +
> >  .../UefiShellDebug1CommandsLib.uni  |  1 +
> >  2 files changed, 14 insertions(+), 4 deletions(-)
> >
> > diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/DmpStore.c
> > b/ShellPkg/Library/UefiShellDebug1CommandsLib/DmpStore.c
> > index aeffc89b19..062ab5dc3a 100644
> > --- a/ShellPkg/Library/UefiShellDebug1CommandsLib/DmpStore.c
> > +++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/DmpStore.c
> > @@ -424,6 +424,7 @@ CascadeProcessVariables (
> >CHAR16*AttrString;
> >CHAR16*HexString;
> >EFI_STATUSSetStatus;
> > +  CHAR16*GuidName;
> >
> >if (ShellGetExecutionBreakFlag()) {
> >  return (SHELL_ABORTED);
> > @@ -521,10 +522,18 @@ CascadeProcessVariables (
> >  Status = EFI_OUT_OF_RESOURCES;
> >}
> >  } else {
> > -  ShellPrintHiiEx (
> > --1, -1, NULL, STRING_TOKEN (STR_DMPSTORE_HEADER_LINE),
> > gShellDebug1HiiHandle,
> > -AttrString, , FoundVarName, DataSize
> > -);
> > +  Status = gEfiShellProtocol->GetGuidName(,
> > );
> > +  if (EFI_ERROR (Status)) {
> > +ShellPrintHiiEx (
> > +  -1, -1, NULL, STRING_TOKEN (STR_DMPSTORE_HEADER_LINE),
> > gShellDebug1HiiHandle,
> > +  AttrString, , FoundVarName, DataSize
> > +  );
> > +  } else {
> > +ShellPrintHiiEx (
> > +  -1, -1, NULL, STRING_TOKEN (STR_DMPSTORE_HEADER_LINE2),
> > gShellDebug1HiiHandle,
> > +  AttrString, GuidName, FoundVarName, DataSize
> > +  );
> > +  }
> >DumpHex (2, 0, DataSize, DataBuffer);
> >  }
> >  SHELL_FREE_NON_NULL (AttrString); diff --git
> >
> a/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1Comman
> > dsLib.uni
> >
> b/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1Comman
> > dsLib.uni
> > index f733a67f0b..b6a133a454 100644
> > ---
> >
> a/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1Comman
> > dsLib.uni
> > +++
> >
> b/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1Comman
> > dsLib.uni
> > @@ -385,6 +385,7 @@
> >  #string STR_DMPSTORE_LOAD_GEN_FAIL #language en-US "%H%s%N:
> > Failed to set variable %H%s%N: %r.\r\n"
> >  #string STR_DMPSTORE_LOAD_BAD_FILE #language en-US "%H%s%N:
> > Incorrect file format.\r\n"
> >  #string STR_DMPSTORE_HEADER_LINE   #language en-US "Variable
> > %H%s%N '%H%g%N:%H%s%N' DataSize = 0x%02x\r\n"
> > +#string STR_DMPSTORE_HEADER_LINE2  #language en-US "Variable
> > %H%s%N '%H%s%N:%H%s%N' DataSize = 0x%02x\r\n"
> >  #string STR_DMPSTORE_DELETE_LINE   #language en-US "Delete variable
> > '%H%g%N:%H%s%N': %r\r\n"
> >  #string STR_DMPSTORE_NO_VAR_FOUND  #language en-US "%H%s%N:
> > No matching variables found.\r\n"
> >  #string STR_DMPSTORE_NO_VAR_FOUND_SFO  #language en-US
> > "VariableInfo,\"\",\"\",\"\",\"\",\"\"\r\n"
> > --
> > 2.12.2.windows.2

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2 5/6] IntelFrameworkModulePkg/Csm: Add code to bypass NULL pointer detection

[Jian J Wang]

Legacy has to access interrupt vector, BDA, etc. located in memory between
0-4095. To allow as much code as possible to be monitered by NULL pointer
detection, we add code to temporarily disable this feature right before
those memory access and enable it again afterwards.

Cc: Star Zeng 
Cc: Eric Dong 
Cc: Laszlo Ersek 
Cc: Jiewen Yao 
Cc: Michael Kinney 
Cc: Jordan Justen 
Cc: Ayellet Wolman 
Suggested-by: Ayellet Wolman 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 .../Csm/BiosThunk/KeyboardDxe/BiosKeyboard.c   | 13 
 .../Csm/BiosThunk/KeyboardDxe/BiosKeyboard.h   |  2 +
 .../Csm/BiosThunk/KeyboardDxe/KeyboardDxe.inf  |  2 +
 .../Csm/LegacyBiosDxe/LegacyBda.c  |  4 +
 .../Csm/LegacyBiosDxe/LegacyBios.c | 90 ++
 .../Csm/LegacyBiosDxe/LegacyBiosDxe.inf|  2 +
 .../Csm/LegacyBiosDxe/LegacyBiosInterface.h| 18 +
 .../Csm/LegacyBiosDxe/LegacyBootSupport.c  | 23 +-
 .../Csm/LegacyBiosDxe/LegacyPci.c  | 17 +++-
 IntelFrameworkModulePkg/Csm/LegacyBiosDxe/Thunk.c  | 27 +--
 10 files changed, 188 insertions(+), 10 deletions(-)

diff --git a/IntelFrameworkModulePkg/Csm/BiosThunk/KeyboardDxe/BiosKeyboard.c 
b/IntelFrameworkModulePkg/Csm/BiosThunk/KeyboardDxe/BiosKeyboard.c
index 7308523ad8..91e50405fc 100644
--- a/IntelFrameworkModulePkg/Csm/BiosThunk/KeyboardDxe/BiosKeyboard.c
+++ b/IntelFrameworkModulePkg/Csm/BiosThunk/KeyboardDxe/BiosKeyboard.c
@@ -1839,6 +1839,13 @@ BiosKeyboardTimerHandler (
   //   0 Right Shift pressed
 
 
+  //
+  // Disable NULL pointer detection temporarily
+  //
+  if ((PcdGet8 (PcdNullPointerDetectionPropertyMask) & BIT0) != 0) {
+gDS->SetMemorySpaceAttributes (0, EFI_PAGES_TO_SIZE(1), 0);
+  }
+
   //
   // Clear the CTRL and ALT BDA flag
   //
@@ -1916,6 +1923,12 @@ BiosKeyboardTimerHandler (
   KbFlag1 &= ~0x0C;  
   *((UINT8 *) (UINTN) 0x417) = KbFlag1; 
 
+  //
+  // Restore NULL pointer detection
+  //
+  if ((PcdGet8 (PcdNullPointerDetectionPropertyMask) & BIT0) != 0) {
+gDS->SetMemorySpaceAttributes (0, EFI_PAGES_TO_SIZE(1), EFI_MEMORY_RP);
+  }
   
   //
   // Output EFI input key and shift/toggle state
diff --git a/IntelFrameworkModulePkg/Csm/BiosThunk/KeyboardDxe/BiosKeyboard.h 
b/IntelFrameworkModulePkg/Csm/BiosThunk/KeyboardDxe/BiosKeyboard.h
index 0bf28ea140..c64ec0095e 100644
--- a/IntelFrameworkModulePkg/Csm/BiosThunk/KeyboardDxe/BiosKeyboard.h
+++ b/IntelFrameworkModulePkg/Csm/BiosThunk/KeyboardDxe/BiosKeyboard.h
@@ -18,6 +18,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 
 
 #include 
+#include 
 
 #include 
 #include 
@@ -33,6 +34,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/IntelFrameworkModulePkg/Csm/BiosThunk/KeyboardDxe/KeyboardDxe.inf 
b/IntelFrameworkModulePkg/Csm/BiosThunk/KeyboardDxe/KeyboardDxe.inf
index 4d4536466c..596f4ced44 100644
--- a/IntelFrameworkModulePkg/Csm/BiosThunk/KeyboardDxe/KeyboardDxe.inf
+++ b/IntelFrameworkModulePkg/Csm/BiosThunk/KeyboardDxe/KeyboardDxe.inf
@@ -60,6 +60,7 @@
   DebugLib
   BaseLib
   PcdLib
+  DxeServicesTableLib
 
 [Protocols]
   gEfiIsaIoProtocolGuid ## TO_START
@@ -73,6 +74,7 @@
 
 [Pcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdFastPS2Detection  ## 
SOMETIMES_CONSUMES
+  gEfiMdeModulePkgTokenSpaceGuid.PcdNullPointerDetectionPropertyMask  ## 
CONSUMES
 
 [UserExtensions.TianoCore."ExtraFiles"]
   KeyboardDxeExtra.uni
diff --git a/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBda.c 
b/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBda.c
index c45d5d4c3e..c6670febee 100644
--- a/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBda.c
+++ b/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBda.c
@@ -34,6 +34,8 @@ LegacyBiosInitBda (
   BDA_STRUC *Bda;
   UINT8 *Ebda;
 
+  DisableNullDetection ();
+
   Bda   = (BDA_STRUC *) ((UINTN) 0x400);
   Ebda  = (UINT8 *) ((UINTN) 0x9fc00);
 
@@ -62,5 +64,7 @@ LegacyBiosInitBda (
 
   *Ebda   = 0x01;
 
+  EnableNullDetection ();
+
   return EFI_SUCCESS;
 }
diff --git a/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBios.c 
b/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBios.c
index 3ead2d9828..e603f82d9e 100644
--- a/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBios.c
+++ b/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBios.c
@@ -40,6 +40,7 @@ VOID  *mRuntimeSmbiosEntryPoint = NULL;
 EFI_PHYSICAL_ADDRESS  mReserveSmbiosEntryPoint = 0;
 EFI_PHYSICAL_ADDRESS  mStructureTableAddress   = 0;
 UINTN mStructureTablePages = 0;
+BOOLEAN

[edk2] [PATCH v2 6/6] OvmfPkg/QemuVideoDxe: Bypass NULL pointer detection during VBE SHIM installing

[Jian J Wang]

QemuVideoDxe driver will install VBE SHIM into page 0. If NULL pointer
detection is enabled, this driver will fail to load. NULL pointer detection
bypassing code is added to prevent such problem during boot.

Please note that Windows 7 will try to access VBE SHIM during boot if it's
installed, and then cause boot failure. This can be fixed by setting BIT7
of PcdNullPointerDetectionPropertyMask to disable NULL pointer detection
after EndOfDxe. As far as we know, there's no other OSs has such issue.

Cc: Star Zeng 
Cc: Eric Dong 
Cc: Laszlo Ersek 
Cc: Jiewen Yao 
Cc: Michael Kinney 
Cc: Jordan Justen 
Cc: Ayellet Wolman 
Suggested-by: Ayellet Wolman 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf |  2 ++
 OvmfPkg/QemuVideoDxe/VbeShim.c| 22 ++
 2 files changed, 24 insertions(+)

diff --git a/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf 
b/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
index 577e07b0a8..8078232ded 100644
--- a/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
+++ b/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
@@ -67,6 +67,7 @@
   UefiBootServicesTableLib
   UefiDriverEntryPoint
   UefiLib
+  DxeServicesTableLib
 
 [Protocols]
   gEfiDriverSupportedEfiVersionProtocolGuid # PROTOCOL ALWAYS_PRODUCED
@@ -77,3 +78,4 @@
 [Pcd]
   gOptionRomPkgTokenSpaceGuid.PcdDriverSupportedEfiVersion
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId
+  gEfiMdeModulePkgTokenSpaceGuid.PcdNullPointerDetectionPropertyMask
diff --git a/OvmfPkg/QemuVideoDxe/VbeShim.c b/OvmfPkg/QemuVideoDxe/VbeShim.c
index e45a08e887..c3fb6d8d3c 100644
--- a/OvmfPkg/QemuVideoDxe/VbeShim.c
+++ b/OvmfPkg/QemuVideoDxe/VbeShim.c
@@ -21,10 +21,13 @@
   WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
 **/
 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
+
 #include 
 
 #include "Qemu.h"
@@ -74,11 +77,21 @@ InstallVbeShim (
   UINT8*Ptr;
   UINTNPrinted;
   VBE_MODE_INFO*VbeModeInfo;
+  EFI_STATUS   Status;
 
   Segment0 = 0x0;
   SegmentC = 0xC;
   SegmentF = 0xF;
 
+  //
+  // Disable NULL pointer detection temporarily. Otherwise the installation
+  // will fail due to the lack of memory access right.
+  //
+  if ((PcdGet8 (PcdNullPointerDetectionPropertyMask) & (BIT0|BIT7)) == BIT0) {
+Status = gDS->SetMemorySpaceAttributes (0, EFI_PAGES_TO_SIZE (1), 0);
+ASSERT_EFI_ERROR (Status);
+  }
+
   //
   // Attempt to cover the real mode IVT with an allocation. This is a UEFI
   // driver, hence the arch protocols have been installed previously. Among
@@ -304,5 +317,14 @@ InstallVbeShim (
   Int0x10->Segment = (UINT16) ((UINT32)SegmentC >> 4);
   Int0x10->Offset  = (UINT16) ((UINTN) (VbeModeInfo + 1) - SegmentC);
 
+  //
+  // Get NULL pointer detection back
+  //
+  if ((PcdGet8 (PcdNullPointerDetectionPropertyMask) & (BIT0|BIT7)) == BIT0) {
+Status = gDS->SetMemorySpaceAttributes (0, EFI_PAGES_TO_SIZE(1),
+EFI_MEMORY_RP);
+ASSERT_EFI_ERROR (Status);
+  }
+
   DEBUG ((EFI_D_INFO, "%a: VBE shim installed\n", __FUNCTION__));
 }
-- 
2.14.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2 4/6] MdeModulePkg/Core/Dxe: Add EndOfDxe workaround for NULL pointer detection

[Jian J Wang]

One of issue caused by enabling NULL pointer detection is that some PCI
device OptionROM, binary drivers and binary OS boot loaders may have NULL
pointer access bugs, which will prevent BIOS from booting and is almost
impossible to fix. BIT7 of PCD PcdNullPointerDetectionPropertyMask is used
as a workaround to indicate BIOS to disable NULL pointer detection right
after event gEfiEndOfDxeEventGroupGuid, and then let boot continue.

Cc: Star Zeng 
Cc: Eric Dong 
Cc: Laszlo Ersek 
Cc: Jiewen Yao 
Cc: Michael Kinney 
Cc: Jordan Justen 
Cc: Ayellet Wolman 
Suggested-by: Ayellet Wolman 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 MdeModulePkg/Core/Dxe/DxeMain.inf |  1 +
 MdeModulePkg/Core/Dxe/Mem/Page.c  |  4 ++-
 MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c | 48 +++
 3 files changed, 52 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Core/Dxe/DxeMain.inf 
b/MdeModulePkg/Core/Dxe/DxeMain.inf
index 30d5984f7c..0a161ffd71 100644
--- a/MdeModulePkg/Core/Dxe/DxeMain.inf
+++ b/MdeModulePkg/Core/Dxe/DxeMain.inf
@@ -192,6 +192,7 @@
   gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable   ## 
CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdImageProtectionPolicy   ## 
CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdDxeNxMemoryProtectionPolicy ## 
CONSUMES
+  gEfiMdeModulePkgTokenSpaceGuid.PcdNullPointerDetectionPropertyMask## 
CONSUMES
 
 # [Hob]
 # RESOURCE_DESCRIPTOR   ## CONSUMES
diff --git a/MdeModulePkg/Core/Dxe/Mem/Page.c b/MdeModulePkg/Core/Dxe/Mem/Page.c
index a142c79ee2..0468df3171 100644
--- a/MdeModulePkg/Core/Dxe/Mem/Page.c
+++ b/MdeModulePkg/Core/Dxe/Mem/Page.c
@@ -188,7 +188,9 @@ CoreAddRange (
   // used for other purposes.
   //  
   if (Type == EfiConventionalMemory && Start == 0 && (End >= EFI_PAGE_SIZE - 
1)) {
-SetMem ((VOID *)(UINTN)Start, EFI_PAGE_SIZE, 0);
+if ((PcdGet8 (PcdNullPointerDetectionPropertyMask) & BIT0) == 0) {
+  SetMem ((VOID *)(UINTN)Start, EFI_PAGE_SIZE, 0);
+}
   }
   
   //
diff --git a/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c 
b/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
index a73c4ccd64..73e3b269f3 100644
--- a/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
+++ b/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
@@ -995,6 +995,36 @@ MemoryProtectionExitBootServicesCallback (
   }
 }
 
+/**
+  Disable NULL pointer detection after EndOfDxe. This is a workaround resort in
+  order to skip unfixable NULL pointer access issues detected in OptionROM or
+  boot loaders.
+
+  @param[in]  Event The Event this notify function registered to.
+  @param[in]  Context   Pointer to the context data registered to the Event.
+**/
+VOID
+EFIAPI
+DisableNullDetectionAtTheEndOfDxe (
+  EFI_EVENT   Event,
+  VOID*Context
+  )
+{
+  EFI_STATUSStatus;
+
+  DEBUG ((DEBUG_INFO, "DisableNullDetectionAtTheEndOfDxe(): start\r\n"));
+  //
+  // Disable NULL pointer detection by enabling first 4K page
+  //
+  Status = gCpu->SetMemoryAttributes (gCpu, 0, EFI_PAGE_SIZE, 0);
+  ASSERT_EFI_ERROR (Status);
+
+  CoreCloseEvent (Event);
+  DEBUG ((DEBUG_INFO, "DisableNullDetectionAtTheEndOfDxe(): end\r\n"));
+
+  return;
+}
+
 /**
   Initialize Memory Protection support.
 **/
@@ -1006,6 +1036,7 @@ CoreInitializeMemoryProtection (
 {
   EFI_STATUS  Status;
   EFI_EVENT   Event;
+  EFI_EVENT   EndOfDxeEvent;
   VOID*Registration;
 
   mImageProtectionPolicy = PcdGet32(PcdImageProtectionPolicy);
@@ -1044,6 +1075,23 @@ CoreInitializeMemoryProtection (
);
 ASSERT_EFI_ERROR(Status);
   }
+
+  //
+  // Register a callback to disable NULL pointer detection at EndOfDxe
+  //
+  if ((PcdGet8 (PcdNullPointerDetectionPropertyMask) & (BIT0|BIT7))
+   == (BIT0|BIT7)) {
+Status = CoreCreateEventEx (
+EVT_NOTIFY_SIGNAL,
+TPL_NOTIFY,
+DisableNullDetectionAtTheEndOfDxe,
+NULL,
+,
+
+);
+ASSERT_EFI_ERROR (Status);
+  }
+
   return ;
 }
 
-- 
2.14.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2 2/6] MdeModulePkg/DxeIpl: Implement NULL pointer detection

[Jian J Wang]

NULL pointer detection is done by making use of paging mechanism of CPU.
During page table setup, if enabled, the first 4-K page (0-4095) will be
marked as NOT PRESENT. Any code which unintentionally access memory between
0-4095 will trigger a Page Fault exception which warns users that there's
potential illegal code in BIOS.

This also means that legacy code which has to access memory between 0-4095
should be cautious to temporarily disable this feature before the access
and re-enable it afterwards; or disalbe this feature at all.

Cc: Star Zeng 
Cc: Eric Dong 
Cc: Laszlo Ersek 
Cc: Jiewen Yao 
Cc: Michael Kinney 
Cc: Jordan Justen 
Cc: Ayellet Wolman 
Suggested-by: Ayellet Wolman 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 MdeModulePkg/Core/DxeIplPeim/DxeIpl.h| 25 +
 MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf  |  1 +
 MdeModulePkg/Core/DxeIplPeim/DxeLoad.c   | 65 
 MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c  | 11 +++-
 MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c   |  2 +
 MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 31 ---
 6 files changed, 126 insertions(+), 9 deletions(-)

diff --git a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h 
b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
index 72d2532f50..1654bcd2dc 100644
--- a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
+++ b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
@@ -240,4 +240,29 @@ Decompress (
   OUT   UINTN   *OutputSize
   );
 
+/**
+   Clear legacy memory located at the first 4K-page.
+
+   This function traverses the whole HOB list to check if memory from 0 to 4095
+   exists and has not been allocated, and then clear it if so.
+
+   @param HoStart The start of HobList passed to DxeCore.
+
+**/
+VOID
+ClearLegacyMemory (
+  IN  VOID *HobStart
+  );
+
+/**
+   Return configure status of NULL pointer detection feature
+
+   @return TRUE   NULL pointer detection feature is enabled
+   @return FALSE  NULL pointer detection feature is disabled
+**/
+BOOLEAN
+IsNullDetectionEnabled (
+  VOID
+  );
+
 #endif
diff --git a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf 
b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
index c54afe4aa6..9d0e76a293 100644
--- a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
+++ b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
@@ -115,6 +115,7 @@
 [Pcd.IA32,Pcd.X64]
   gEfiMdeModulePkgTokenSpaceGuid.PcdUse1GPageTable  ## 
SOMETIMES_CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask## 
CONSUMES
+  gEfiMdeModulePkgTokenSpaceGuid.PcdNullPointerDetectionPropertyMask## 
CONSUMES
 
 [Pcd.IA32,Pcd.X64,Pcd.ARM,Pcd.AARCH64]
   gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack   ## 
SOMETIMES_CONSUMES
diff --git a/MdeModulePkg/Core/DxeIplPeim/DxeLoad.c 
b/MdeModulePkg/Core/DxeIplPeim/DxeLoad.c
index 50b5440d15..0a71b1f3de 100644
--- a/MdeModulePkg/Core/DxeIplPeim/DxeLoad.c
+++ b/MdeModulePkg/Core/DxeIplPeim/DxeLoad.c
@@ -825,3 +825,68 @@ UpdateStackHob (
 Hob.Raw = GET_NEXT_HOB (Hob);
   }
 }
+
+/**
+   Clear legacy memory located at the first 4K-page, if available.
+
+   This function traverses the whole HOB list to check if memory from 0 to 4095
+   exists and has not been allocated, and then clear it if so.
+
+   @param HoStart   The start of HobList passed to DxeCore.
+
+**/
+VOID
+ClearLegacyMemory (
+  IN  VOID *HobStart
+  )
+{
+  EFI_PEI_HOB_POINTERS  RscHob;
+  EFI_PEI_HOB_POINTERS  MemHob;
+  BOOLEAN   DoClear;
+
+  RscHob.Raw = HobStart;
+  MemHob.Raw = HobStart;
+  DoClear = FALSE;
+
+  //
+  // Check if page 0 exists and free
+  //
+  while ((RscHob.Raw = GetNextHob (EFI_HOB_TYPE_RESOURCE_DESCRIPTOR,
+   RscHob.Raw)) != NULL) {
+if (RscHob.ResourceDescriptor->ResourceType == EFI_RESOURCE_SYSTEM_MEMORY 
&&
+RscHob.ResourceDescriptor->PhysicalStart == 0) {
+  DoClear = TRUE;
+  //
+  // Make sure memory at 0-4095 has not been allocated.
+  //
+  while ((MemHob.Raw = GetNextHob (EFI_HOB_TYPE_MEMORY_ALLOCATION,
+   MemHob.Raw)) != NULL) {
+if (MemHob.MemoryAllocation->AllocDescriptor.MemoryBaseAddress
+< EFI_PAGE_SIZE) {
+  DoClear = FALSE;
+  break;
+}
+MemHob.Raw = GET_NEXT_HOB (MemHob);
+  }
+  break;
+}
+RscHob.Raw = GET_NEXT_HOB (RscHob);
+  }
+
+  if (DoClear) {
+DEBUG ((DEBUG_INFO, "Clearing first 4K-page!\r\n"));
+SetMem (NULL, EFI_PAGE_SIZE, 0);
+  }
+
+  return;
+}
+
+BOOLEAN
+IsNullDetectionEnabled (
+  VOID
+  )
+{
+  return (((PcdGet8 (PcdNullPointerDetectionPropertyMask) & BIT0) != 0) ?
+  TRUE : FALSE);
+}

[edk2] [PATCH v2 3/6] UefiCpuPkg/PiSmmCpuDxeSmm: Implement NULL pointer detection for SMM code

[Jian J Wang]

The mechanism behind is the same as NULL pointer detection enabled in EDK-II
core. SMM has its own page table and we have to disable page 0 again in SMM
mode.

Cc: Star Zeng 
Cc: Eric Dong 
Cc: Laszlo Ersek 
Cc: Jiewen Yao 
Cc: Michael Kinney 
Cc: Jordan Justen 
Cc: Ayellet Wolman 
Suggested-by: Ayellet Wolman 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c | 12 
 UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c| 25 -
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf |  1 +
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c  | 12 
 4 files changed, 49 insertions(+), 1 deletion(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
index f295c2ebf2..1c9e239a34 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
@@ -155,6 +155,18 @@ SmiPFHandler (
 }
   }
 
+  //
+  // If NULL pointer was just accessed
+  //
+  if ((PcdGet8 (PcdNullPointerDetectionPropertyMask) & BIT1) != 0 &&
+  (PFAddress < EFI_PAGE_SIZE)) {
+DEBUG ((DEBUG_ERROR, "!!! NULL pointer access !!!\n"));
+DEBUG_CODE (
+  DumpModuleInfoByIp ((UINTN)SystemContext.SystemContextIa32->Rip);
+);
+CpuDeadLoop ();
+  }
+
   if (FeaturePcdGet (PcdCpuSmmProfileEnable)) {
 SmmProfilePFHandler (
   SystemContext.SystemContextIa32->Eip,
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
index f086b97c30..ed2afadb21 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
@@ -855,10 +855,10 @@ Gen4GPageTable (
 Pte[Index] = (Index << 21) | mAddressEncMask | IA32_PG_PS | 
PAGE_ATTRIBUTE_BITS;
   }
 
+  Pdpte = (UINT64*)PageTable;
   if (FeaturePcdGet (PcdCpuSmmStackGuard)) {
 Pages = (UINTN)PageTable + EFI_PAGES_TO_SIZE (5);
 GuardPage = mSmmStackArrayBase + EFI_PAGE_SIZE;
-Pdpte = (UINT64*)PageTable;
 for (PageIndex = Low2MBoundary; PageIndex <= High2MBoundary; PageIndex += 
SIZE_2MB) {
   Pte = (UINT64*)(UINTN)(Pdpte[BitFieldRead32 ((UINT32)PageIndex, 30, 31)] 
& ~mAddressEncMask & ~(EFI_PAGE_SIZE - 1));
   Pte[BitFieldRead32 ((UINT32)PageIndex, 21, 29)] = (UINT64)Pages | 
mAddressEncMask | PAGE_ATTRIBUTE_BITS;
@@ -886,6 +886,29 @@ Gen4GPageTable (
 }
   }
 
+  if ((PcdGet8 (PcdNullPointerDetectionPropertyMask) & BIT1) != 0) {
+Pte = (UINT64*)(UINTN)(Pdpte[0] & ~mAddressEncMask & ~(EFI_PAGE_SIZE - 1));
+if ((Pte[0] & IA32_PG_PS) == 0) {
+  // 4K-page entries are already mapped. Just hide the first one anyway.
+  Pte = (UINT64*)(UINTN)(Pte[0] & ~mAddressEncMask & ~(EFI_PAGE_SIZE - 1));
+  Pte[0] &= ~1; // Hide page 0
+} else {
+  // Create 4K-page entries
+  Pages = (UINTN)AllocatePageTableMemory (1);
+  ASSERT (Pages != 0);
+
+  Pte[0] = (UINT64)(Pages | mAddressEncMask | PAGE_ATTRIBUTE_BITS);
+
+  Pte = (UINT64*)Pages;
+  PageAddress = 0;
+  Pte[0] = PageAddress | mAddressEncMask; // Hide page 0 but present left
+  for (Index = 1; Index < EFI_PAGE_SIZE / sizeof (*Pte); Index++) {
+PageAddress += EFI_PAGE_SIZE;
+Pte[Index] = PageAddress | mAddressEncMask | PAGE_ATTRIBUTE_BITS;
+  }
+}
+  }
+
   return (UINT32)(UINTN)PageTable;
 }
 
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf 
b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf
index 099792e6ce..31cb215342 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf
@@ -159,6 +159,7 @@
   gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmStaticPageTable   ## CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiS3Enable   ## CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask## 
CONSUMES
+  gEfiMdeModulePkgTokenSpaceGuid.PcdNullPointerDetectionPropertyMask## 
CONSUMES
 
 [Depex]
   gEfiMpServiceProtocolGuid
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
index 3dde80f9ba..f3791ce897 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
@@ -872,6 +872,18 @@ SmiPFHandler (
 }
   }
 
+  //
+  // If NULL pointer was just accessed
+  //
+  if ((PcdGet8 (PcdNullPointerDetectionPropertyMask) & BIT1) != 0 &&
+  (PFAddress < EFI_PAGE_SIZE)) {
+DEBUG ((DEBUG_ERROR, "!!! NULL pointer access !!!\n"));
+DEBUG_CODE (
+  DumpModuleInfoByIp ((UINTN)SystemContext.SystemContextX64->Rip);
+);
+CpuDeadLoop ();
+  }
+
   if (FeaturePcdGet (PcdCpuSmmProfileEnable)) {
 SmmProfilePFHandler (
   SystemContext.SystemContextX64->Rip,
-- 
2.14.1.windows.1

[edk2] [PATCH v2 0/6] Add NULL pointer detection feature

[Jian J Wang]

The mechanism behind is to trigger a page fault exception at address 0.
This can be made by disabling page 0 (0-4095) during page table setup.
So this feature can only be available on platform with paging enabled.

Once this feature is enabled, any code, like CSM, which has to access
memory in page 0 needs to enable this page temporarily in advance and
disable it afterwards.

PcdNullPointerDetectionPropertyMask is used to control and elaborate
the use cases. For example, BIT7 of this PCD must be set for Windows 7
boot on Qemu if BIT0 set; or boot will fail.

Cc: Star Zeng 
Cc: Eric Dong 
Cc: Laszlo Ersek 
Cc: Jiewen Yao 
Cc: Michael Kinney 
Cc: Jordan Justen 
Cc: Ayellet Wolman 
Suggested-by: Ayellet Wolman 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 

Jian J Wang (5):
  MdeModulePkg/DxeIpl: Implement NULL pointer detection
  UefiCpuPkg/PiSmmCpuDxeSmm: Implement NULL pointer detection for SMM
code
  MdeModulePkg/Core/Dxe: Add EndOfDxe workaround for NULL pointer
detection
  IntelFrameworkModulePkg/Csm: Add code to bypass NULL pointer detection
  OvmfPkg/QemuVideoDxe: Bypass NULL pointer detection during VBE SHIM
installing

Wang, Jian J (1):
  MdeModulePkg/MdeModulePkg.dec: Add NULL pointer detection PCD

 .../Csm/BiosThunk/KeyboardDxe/BiosKeyboard.c   | 13 
 .../Csm/BiosThunk/KeyboardDxe/BiosKeyboard.h   |  2 +
 .../Csm/BiosThunk/KeyboardDxe/KeyboardDxe.inf  |  2 +
 .../Csm/LegacyBiosDxe/LegacyBda.c  |  4 +
 .../Csm/LegacyBiosDxe/LegacyBios.c | 90 ++
 .../Csm/LegacyBiosDxe/LegacyBiosDxe.inf|  2 +
 .../Csm/LegacyBiosDxe/LegacyBiosInterface.h| 18 +
 .../Csm/LegacyBiosDxe/LegacyBootSupport.c  | 23 +-
 .../Csm/LegacyBiosDxe/LegacyPci.c  | 17 +++-
 IntelFrameworkModulePkg/Csm/LegacyBiosDxe/Thunk.c  | 27 +--
 MdeModulePkg/Core/Dxe/DxeMain.inf  |  1 +
 MdeModulePkg/Core/Dxe/Mem/Page.c   |  4 +-
 MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c  | 48 
 MdeModulePkg/Core/DxeIplPeim/DxeIpl.h  | 25 ++
 MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf|  1 +
 MdeModulePkg/Core/DxeIplPeim/DxeLoad.c | 65 
 MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c| 11 ++-
 MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c |  2 +
 MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c   | 31 ++--
 MdeModulePkg/MdeModulePkg.dec  | 13 
 OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf  |  2 +
 OvmfPkg/QemuVideoDxe/VbeShim.c | 22 ++
 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c   | 12 +++
 UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c  | 25 +-
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf   |  1 +
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c| 12 +++
 26 files changed, 452 insertions(+), 21 deletions(-)

-- 
2.14.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2 1/6] MdeModulePkg/MdeModulePkg.dec: Add NULL pointer detection PCD

[Jian J Wang]

From: "Wang, Jian J" 

PCD PcdNullPointerDetectionPropertyMask is a bitmask used to control the
NULL address detection functionality in code for different phases.

If enabled, accessing NULL address in UEFI or SMM code can be caught
as a page fault exception.

BIT0- Enable NULL pointer detection for UEFI.
BIT1- Enable NULL pointer detection for SMM.
BIT2..6 - Reserved for future uses.
BIT7- Disable NULL pointer detection just after EndOfDxe. This is a
  workaround for those unsolvable NULL access issues in
  OptionROM, boot loader, etc. It can also help to avoid
  unnecessary exception caused by legacy memory (0-4095) access
  after EndOfDxe, such as Windows 7 boot on Qemu.

Cc: Star Zeng 
Cc: Eric Dong 
Cc: Laszlo Ersek 
Cc: Jiewen Yao 
Cc: Michael Kinney 
Cc: Jordan Justen 
Cc: Ayellet Wolman 
Suggested-by: Ayellet Wolman 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 MdeModulePkg/MdeModulePkg.dec | 13 +
 1 file changed, 13 insertions(+)

diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index 403a66a5ad..3f90b8d7e6 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -863,6 +863,19 @@
   # @ValidList  0x8006 | 0x03058002
   
gEfiMdeModulePkgTokenSpaceGuid.PcdErrorCodeSetVariable|0x03058002|UINT32|0x30001040
 
+  ## Mask to control the NULL address detection in code for different phases.
+  #  If enabled, accessing NULL address in UEFI or SMM code can be 
caught.
+  #BIT0- Enable NULL pointer detection for UEFI.
+  #BIT1- Enable NULL pointer detection for SMM.
+  #BIT2..6 - Reserved for future uses.
+  #BIT7- Disable NULL pointer detection just after EndOfDxe. 
+  #  This is a workaround for those unsolvable NULL access issues 
in
+  #  OptionROM, boot loader, etc. It can also help to avoid 
unnecessary
+  #  exception caused by legacy memory (0-4095) access after 
EndOfDxe,
+  #  such as Windows 7 boot on Qemu.
+  # @Prompt Enable NULL address detection.
+  
gEfiMdeModulePkgTokenSpaceGuid.PcdNullPointerDetectionPropertyMask|0x0|UINT8|0x30001050
+
 [PcdsFixedAtBuild, PcdsPatchableInModule]
   ## Dynamic type PCD can be registered callback function for Pcd setting 
action.
   #  PcdMaxPeiPcdCallBackNumberPerPcdEntry indicates the maximum number of 
callback function
-- 
2.14.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch][edk2-platforms/devel-MinnowBoard3-UDK2017 2/2] Update Minor Version of BIOS ID.

[zwei4]

Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: zwei4 
---
 Platform/BroxtonPlatformPkg/BiosId.env | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Platform/BroxtonPlatformPkg/BiosId.env 
b/Platform/BroxtonPlatformPkg/BiosId.env
index 3c1b1a489..8de9eb87f 100644
--- a/Platform/BroxtonPlatformPkg/BiosId.env
+++ b/Platform/BroxtonPlatformPkg/BiosId.env
@@ -31,5 +31,5 @@ BOARD_ID  = APLKRVP
 BOARD_REV = 3
 BUILD_TYPE= D
 VERSION_MAJOR = 0066
-VERSION_MINOR = 01
+VERSION_MINOR = 02
 BOARD_EXT = X64
-- 
2.14.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3] CryptoPkg: Add new API to retrieve commonName of X.509 certificate

[Ye, Ting]

Hi Qin,

I think we might add OPTIONAL attribute to CommonName, as NULL is an valid 
input for this API.
In function description, I think we need update below statement to "if *** and 
*CommonNameSize is 0."

 "If CommonName is not NULL and CommonNameSize is 0."

Others are good to me.

Reviewed-by: Ye Ting 

Best Regards,
Ting

-Original Message-
From: Long, Qin 
Sent: Thursday, September 21, 2017 10:48 AM
To: ler...@redhat.com; Ye, Ting ; Zhang, Chao B 

Cc: edk2-devel@lists.01.org
Subject: [PATCH v3] CryptoPkg: Add new API to retrieve commonName of X.509 
certificate

v3: Add extra CommonNameSize check since OpenSSL didn't check this
input parameter. (One openssl issue was filed to address this risk:
https://github.com/openssl/openssl/issues/4392)
v2: Update function interface to return RETURN_STATUS to represent
different error cases.

Add one new API (X509GetCommonName()) to retrieve the subject commonName string 
from one X.509 certificate.

Cc: Laszlo Ersek 
Cc: Ting Ye 
Cc: Chao Zhang 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qin Long 
---
 CryptoPkg/Application/Cryptest/RsaVerify2.c|  32 --
 CryptoPkg/Include/Library/BaseCryptLib.h   |  35 +++
 CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c  | 109 +
 CryptoPkg/Library/BaseCryptLib/Pk/CryptX509Null.c  |  32 ++
 .../Pk/CryptX509Null.c |  34 ++-
 5 files changed, 234 insertions(+), 8 deletions(-)

diff --git a/CryptoPkg/Application/Cryptest/RsaVerify2.c 
b/CryptoPkg/Application/Cryptest/RsaVerify2.c
index 98b5aad900..9db43d6eef 100644
--- a/CryptoPkg/Application/Cryptest/RsaVerify2.c
+++ b/CryptoPkg/Application/Cryptest/RsaVerify2.c
@@ -204,13 +204,17 @@ ValidateCryptRsa2 (
   VOID
   )
 {
-  BOOLEAN  Status;
-  VOID *RsaPrivKey;
-  VOID *RsaPubKey;
-  UINT8*Signature;
-  UINTNSigSize;
-  UINT8*Subject;
-  UINTNSubjectSize;
+  BOOLEANStatus;
+  VOID   *RsaPrivKey;
+  VOID   *RsaPubKey;
+  UINT8  *Signature;
+  UINTN  SigSize;
+  UINT8  *Subject;
+  UINTN  SubjectSize;
+  RETURN_STATUS  ReturnStatus;
+  CHAR8  CommonName[64];
+  CHAR16 CommonNameUnicode[64];
+  UINTN  CommonNameSize;
 
   Print (L"\nUEFI-OpenSSL RSA Key Retrieving Testing: ");
 
@@ -286,6 +290,20 @@ ValidateCryptRsa2 (
 Print (L"[Pass]");
   }
 
+  //
+  // Get CommonName from X509 Certificate Subject  //  CommonNameSize = 
+ 64;  ZeroMem (CommonName, CommonNameSize);  ReturnStatus = 
+ X509GetCommonName (TestCert, sizeof (TestCert), CommonName, 
+ );  if (RETURN_ERROR (ReturnStatus)) {
+Print (L"\n  - Retrieving Common Name - [Fail]");
+return EFI_ABORTED;
+  } else {
+AsciiStrToUnicodeStrS (CommonName, CommonNameUnicode, CommonNameSize);
+Print (L"\n  - Retrieving Common Name = \"%s\" (Size = %d)", 
+ CommonNameUnicode, CommonNameSize);  }
+
   //
   // X509 Certificate Verification.
   //
diff --git a/CryptoPkg/Include/Library/BaseCryptLib.h 
b/CryptoPkg/Include/Library/BaseCryptLib.h
index 9c5ffcd9cf..2366a0218d 100644
--- a/CryptoPkg/Include/Library/BaseCryptLib.h
+++ b/CryptoPkg/Include/Library/BaseCryptLib.h
@@ -2171,6 +2171,41 @@ X509GetSubjectName (
   IN OUT  UINTN*SubjectSize
   );
 
+/**
+  Retrieve the common name (CN) string from one X.509 certificate.
+
+  @param[in]  Cert Pointer to the DER-encoded X509 certificate.
+  @param[in]  CertSize Size of the X509 certificate in bytes.
+  @param[out] CommonName   Buffer to contain the retrieved certificate 
common
+   name string. At most CommonNameSize bytes 
will be
+   written and the string will be null 
terminated. May be
+   NULL in order to determine the size buffer 
needed.
+  @param[in,out]  CommonNameSize   The size in bytes of the CommonName buffer 
on input,
+   and the size of buffer returned CommonName 
on output.
+   If CommonName is NULL then the amount of 
space needed
+   in buffer (including the final null) is 
returned.
+
+  @retval RETURN_SUCCESS   The certificate CommonName retrieved 
successfully.
+  @retval RETURN_INVALID_PARAMETER If Cert is NULL.
+   If CommonNameSize is NULL.
+   If CommonName is not NULL and 
CommonNameSize is 0.
+   If Certificate is invalid.
+  @retval RETURN_NOT_FOUND If no CommonName entry exists.
+  @retval RETURN_BUFFER_TOO_SMALL  If the CommonName is NULL. The required 
buffer size
+   (including the final 

[edk2] [Patch][edk2-platforms/devel-MinnowBoard3-UDK2017] Calibrate PMIC IMON.

[zwei4]

Contributed-under: TianoCore Contribution Agreement 1.1

Signed-off-by: zwei4 
---
 .../PlatformPostMemPei/PlatformInit.c  | 49 ++
 .../PlatformSettings/PlatformSetupDxe/UnCore.vfi   |  6 +--
 .../BroxtonSiPkg/NorthCluster/Include/SaRegs.h |  8 +++-
 3 files changed, 59 insertions(+), 4 deletions(-)

diff --git 
a/Platform/BroxtonPlatformPkg/Common/PlatformSettings/PlatformPostMemPei/PlatformInit.c
 
b/Platform/BroxtonPlatformPkg/Common/PlatformSettings/PlatformPostMemPei/PlatformInit.c
index bfed3bf1a..7d003e466 100644
--- 
a/Platform/BroxtonPlatformPkg/Common/PlatformSettings/PlatformPostMemPei/PlatformInit.c
+++ 
b/Platform/BroxtonPlatformPkg/Common/PlatformSettings/PlatformPostMemPei/PlatformInit.c
@@ -311,6 +311,53 @@ BXTPolicyInit (
   return EFI_SUCCESS;
 }
 
+VOID
+ConfigurePmicIMON (
+  VOID
+  )
+{
+  UINTN   PciD0F0RegBase = 0;
+  UINTN   MchBar = 0;
+  UINT32  Data;
+  UINT16  StallCount;
+  UINT64  PkgPwrSKU;
+
+  PciD0F0RegBase  = MmPciAddress (0,SA_MC_BUS,SA_MC_DEV,SA_MC_FUN,0);
+  MchBar  = MmioRead32 (PciD0F0RegBase + R_SA_MCHBAR_REG) &~BIT0;
+  PkgPwrSKU   = AsmReadMsr64 (MSR_PACKAGE_POWER_SKU);
+
+  StallCount = 0;
+  while (StallCount < 1000) {
+Data = MmioRead32 (MchBar + R_BIOS_MAILBOX_INTERFACE); 
+if ((Data & BIT31) == BIT31) {
+  MicroSecondDelay (1);
+} else {
+  break;
+}
+StallCount++;
+  }
+  MmioWrite32 ( (MchBar + R_BIOS_MAILBOX_DATA), 0xfa0d04a4);
+  MmioWrite32 ( (MchBar + R_BIOS_MAILBOX_INTERFACE), 0x811d);
+
+  StallCount = 0;
+  while (StallCount < 1000) {
+Data = MmioRead32 (MchBar + R_BIOS_MAILBOX_INTERFACE);
+if ((Data & BIT31) == BIT31) {
+  MicroSecondDelay (1);
+} else {
+  break;
+}
+StallCount++;
+  }
+
+  if ((PkgPwrSKU & 0x07FFF) >= 0x0903){
+MmioWrite32 ( (MchBar + R_BIOS_MAILBOX_DATA), 0xe8330466);
+MmioWrite32 ( (MchBar + R_BIOS_MAILBOX_INTERFACE), 0x801d);
+  } else { 
+MmioWrite32 ( (MchBar + R_BIOS_MAILBOX_DATA), 0xed3303b3);
+MmioWrite32 ( (MchBar + R_BIOS_MAILBOX_INTERFACE), 0x801d);
+  }
+}
 
 /**
   Platform Init PEI module entry point
@@ -363,6 +410,8 @@ PlatformInitEntryPoint (
   }
 
   PWM_Fan_Start ();
+  
+  ConfigurePmicIMON();
 
   //
   // Initialize PlatformInfo HOB
diff --git 
a/Platform/BroxtonPlatformPkg/Common/PlatformSettings/PlatformSetupDxe/UnCore.vfi
 
b/Platform/BroxtonPlatformPkg/Common/PlatformSettings/PlatformSetupDxe/UnCore.vfi
index 32eea2005..f8b4b47ec 100644
--- 
a/Platform/BroxtonPlatformPkg/Common/PlatformSettings/PlatformSetupDxe/UnCore.vfi
+++ 
b/Platform/BroxtonPlatformPkg/Common/PlatformSettings/PlatformSetupDxe/UnCore.vfi
@@ -1,7 +1,7 @@
 // /** @file
 //  UnCore Setup formset.
 //
-//  Copyright (c) 1999 - 2016, Intel Corporation. All rights reserved.
+//  Copyright (c) 1999 - 2017, Intel Corporation. All rights reserved.
 //
 //  This program and the accompanying materials
 //  are licensed and made available under the terms and conditions of the BSD 
License
@@ -104,8 +104,8 @@ form formid = UNCORE_FORM_ID,
   oneof varid = Setup.EnableRenderStandby,
prompt   = STRING_TOKEN(STR_VIDEO_RS2_PROMPT),
help = STRING_TOKEN(STR_VIDEO_RS2_HELP),
-   option text = STRING_TOKEN(STR_ENABLE), value = 1, flags = DEFAULT | 
MANUFACTURING | RESET_REQUIRED;
-   option text = STRING_TOKEN(STR_DISABLE), value = 0, flags = RESET_REQUIRED;
+   option text = STRING_TOKEN(STR_ENABLE), value = 1, flags = RESET_REQUIRED;
+   option text = STRING_TOKEN(STR_DISABLE), value = 0, flags = DEFAULT | 
MANUFACTURING | RESET_REQUIRED;
   endoneof;
 
   oneof varid= Setup.GTTSize,
diff --git a/Silicon/BroxtonSoC/BroxtonSiPkg/NorthCluster/Include/SaRegs.h 
b/Silicon/BroxtonSoC/BroxtonSiPkg/NorthCluster/Include/SaRegs.h
index 5dd844092..e985e75c4 100644
--- a/Silicon/BroxtonSoC/BroxtonSiPkg/NorthCluster/Include/SaRegs.h
+++ b/Silicon/BroxtonSoC/BroxtonSiPkg/NorthCluster/Include/SaRegs.h
@@ -15,7 +15,7 @@
   Registers / bits of new devices introduced in a SA generation will be just 
named
   as "_SA_" without [generation_name] inserted.
 
-  Copyright (c) 1999 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 1999 - 2017, Intel Corporation. All rights reserved.
 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
@@ -59,6 +59,12 @@
 #define R_SA_MC_CAPID0_B   0xE8
 #define R_SA_MCHBAR_REG0x48
 
+//
+// IA-Punit Mailbox on MCH BAR 
+//
+#define R_BIOS_MAILBOX_DATA0x7080
+#define R_BIOS_MAILBOX_INTERFACE   0x7084
+
 //
 // Silicon Steppings
 //
-- 
2.14.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 3/6] MdeModulePkg/Tpl: Fix negative value left shift

[Wu, Hao A]

Star and Paolo,

Thanks for the feedbacks. I will refine the patch according to your suggestions.


Best Regards,
Hao Wu


> -Original Message-
> From: Zeng, Star
> Sent: Thursday, September 21, 2017 10:57 AM
> To: Paolo Bonzini; Wu, Hao A; edk2-devel@lists.01.org
> Cc: Dong, Eric; Zeng, Star
> Subject: RE: [edk2] [PATCH 3/6] MdeModulePkg/Tpl: Fix negative value left
> shift
> 
> There is a case must be considered that gEventPending is 0, HighBitSet64 will
> return -1, then the code will be wrong.
> The code maybe:
> 
>   while (gEventPending != 0) {
> PendingTpl = (UINTN) HighBitSet64 (gEventPending);
> if (NewTpl >= PendingTpl) {
>   break;
> }
> gEfiCurrentTpl = PendingTpl;
> 
> ...
> 
>   }
> 
> 
> Thanks,
> Star
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Paolo
> Bonzini
> Sent: Wednesday, September 20, 2017 1:03 AM
> To: Wu, Hao A ; edk2-devel@lists.01.org
> Cc: Dong, Eric ; Zeng, Star 
> Subject: Re: [edk2] [PATCH 3/6] MdeModulePkg/Tpl: Fix negative value left
> shift
> 
> On 19/09/2017 13:43, Hao Wu wrote:
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=695
> >
> > Within function CoreRestoreTpl(), left shift a negative value -2 is
> > used
> > in:
> > "while (((-2 << NewTpl) & gEventPending) != 0) {"
> >
> > which involves undefined behavior.
> >
> > According to the C11 spec, Section 6.5.7:
> >> 4 The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated
> >>   bits are filled with zeros. If E1 has an unsigned type, the value
> >>   of the result is E1 * 2^E2 , reduced modulo one more than the
> >>   maximum value representable in the result type. If E1 has a signed
> >>   type and nonnegative value, and E1 * 2^E2 is representable in the
> >>   result type, then that is the resulting value; otherwise, the
> >>   behavior is undefined.
> >
> > This commit explicitly cast '-2' with UINTN to resolve this issue.
> >
> > Cc: Steven Shi 
> > Cc: Star Zeng 
> > Cc: Eric Dong 
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Hao Wu 
> > ---
> >  MdeModulePkg/Core/Dxe/Event/Tpl.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/MdeModulePkg/Core/Dxe/Event/Tpl.c
> > b/MdeModulePkg/Core/Dxe/Event/Tpl.c
> > index 8ad0a33701..8c50f61117 100644
> > --- a/MdeModulePkg/Core/Dxe/Event/Tpl.c
> > +++ b/MdeModulePkg/Core/Dxe/Event/Tpl.c
> > @@ -123,7 +123,7 @@ CoreRestoreTpl (
> >//
> >// Dispatch any pending events
> >//
> > -  while (((-2 << NewTpl) & gEventPending) != 0) {
> > +  while (UINTN)-2) << NewTpl) & gEventPending) != 0) {
> >  gEfiCurrentTpl = (UINTN) HighBitSet64 (gEventPending);
> >  if (gEfiCurrentTpl < TPL_HIGH_LEVEL) {
> >CoreSetInterruptState (TRUE);
> >
> 
> Maybe:
> 
>   for (;;) {
> PendingTpl = (UINTN) HighBitSet64 (gEventPending);
> if (NewTpl >= PendingTpl) {
>   break;
> }
> gEfiCurrentTpl = PendingTpl;
>   }
> 
> This is much more readable, and HighBitSet64 should be efficient on most
> modern processors.
> 
> Paolo
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] NVME DXE Driver and PATA SS

[Wu, Hao A]

Hi,

Could you help to provide more information on the firmware which you are
using? Is it built by yourself or provided by vender?

As far as I know, the edk2 NVME driver only manages the devices, it will
not create boot options for them. It's for the BDS-related modules to
create boot options for discovered devices.


Best Regards,
Hao Wu

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of david
> moheban
> Sent: Thursday, September 21, 2017 12:38 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] NVME DXE Driver and PATA SS
> 
> Hi,
> 
> Is the PATA SS message that comes up in the bios boot menu when you insert
> the NVME Express DXE driver from Edk2 into one's firmware by design or a
> side-effect of the system not identifying the new device correctly?
> 
> Thank you
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 3/6] MdeModulePkg/Tpl: Fix negative value left shift

[Zeng, Star]

There is a case must be considered that gEventPending is 0, HighBitSet64 will 
return -1, then the code will be wrong.
The code maybe:

  while (gEventPending != 0) {
PendingTpl = (UINTN) HighBitSet64 (gEventPending);
if (NewTpl >= PendingTpl) {
  break;
}
gEfiCurrentTpl = PendingTpl;

...

  }


Thanks,
Star
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Paolo 
Bonzini
Sent: Wednesday, September 20, 2017 1:03 AM
To: Wu, Hao A ; edk2-devel@lists.01.org
Cc: Dong, Eric ; Zeng, Star 
Subject: Re: [edk2] [PATCH 3/6] MdeModulePkg/Tpl: Fix negative value left shift

On 19/09/2017 13:43, Hao Wu wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=695
> 
> Within function CoreRestoreTpl(), left shift a negative value -2 is 
> used
> in:
> "while (((-2 << NewTpl) & gEventPending) != 0) {"
> 
> which involves undefined behavior.
> 
> According to the C11 spec, Section 6.5.7:
>> 4 The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated
>>   bits are filled with zeros. If E1 has an unsigned type, the value
>>   of the result is E1 * 2^E2 , reduced modulo one more than the
>>   maximum value representable in the result type. If E1 has a signed
>>   type and nonnegative value, and E1 * 2^E2 is representable in the
>>   result type, then that is the resulting value; otherwise, the
>>   behavior is undefined.
> 
> This commit explicitly cast '-2' with UINTN to resolve this issue.
> 
> Cc: Steven Shi 
> Cc: Star Zeng 
> Cc: Eric Dong 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu 
> ---
>  MdeModulePkg/Core/Dxe/Event/Tpl.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MdeModulePkg/Core/Dxe/Event/Tpl.c 
> b/MdeModulePkg/Core/Dxe/Event/Tpl.c
> index 8ad0a33701..8c50f61117 100644
> --- a/MdeModulePkg/Core/Dxe/Event/Tpl.c
> +++ b/MdeModulePkg/Core/Dxe/Event/Tpl.c
> @@ -123,7 +123,7 @@ CoreRestoreTpl (
>//
>// Dispatch any pending events
>//
> -  while (((-2 << NewTpl) & gEventPending) != 0) {
> +  while (UINTN)-2) << NewTpl) & gEventPending) != 0) {
>  gEfiCurrentTpl = (UINTN) HighBitSet64 (gEventPending);
>  if (gEfiCurrentTpl < TPL_HIGH_LEVEL) {
>CoreSetInterruptState (TRUE);
> 

Maybe:

  for (;;) {
PendingTpl = (UINTN) HighBitSet64 (gEventPending);
if (NewTpl >= PendingTpl) {
  break;
}
gEfiCurrentTpl = PendingTpl;
  }

This is much more readable, and HighBitSet64 should be efficient on most modern 
processors.

Paolo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v3] CryptoPkg: Add new API to retrieve commonName of X.509 certificate

[Qin Long]

v3: Add extra CommonNameSize check since OpenSSL didn't check this
input parameter. (One openssl issue was filed to address this risk:
https://github.com/openssl/openssl/issues/4392)
v2: Update function interface to return RETURN_STATUS to represent
different error cases.

Add one new API (X509GetCommonName()) to retrieve the subject commonName
string from one X.509 certificate.

Cc: Laszlo Ersek 
Cc: Ting Ye 
Cc: Chao Zhang 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qin Long 
---
 CryptoPkg/Application/Cryptest/RsaVerify2.c|  32 --
 CryptoPkg/Include/Library/BaseCryptLib.h   |  35 +++
 CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c  | 109 +
 CryptoPkg/Library/BaseCryptLib/Pk/CryptX509Null.c  |  32 ++
 .../Pk/CryptX509Null.c |  34 ++-
 5 files changed, 234 insertions(+), 8 deletions(-)

diff --git a/CryptoPkg/Application/Cryptest/RsaVerify2.c 
b/CryptoPkg/Application/Cryptest/RsaVerify2.c
index 98b5aad900..9db43d6eef 100644
--- a/CryptoPkg/Application/Cryptest/RsaVerify2.c
+++ b/CryptoPkg/Application/Cryptest/RsaVerify2.c
@@ -204,13 +204,17 @@ ValidateCryptRsa2 (
   VOID
   )
 {
-  BOOLEAN  Status;
-  VOID *RsaPrivKey;
-  VOID *RsaPubKey;
-  UINT8*Signature;
-  UINTNSigSize;
-  UINT8*Subject;
-  UINTNSubjectSize;
+  BOOLEANStatus;
+  VOID   *RsaPrivKey;
+  VOID   *RsaPubKey;
+  UINT8  *Signature;
+  UINTN  SigSize;
+  UINT8  *Subject;
+  UINTN  SubjectSize;
+  RETURN_STATUS  ReturnStatus;
+  CHAR8  CommonName[64];
+  CHAR16 CommonNameUnicode[64];
+  UINTN  CommonNameSize;
 
   Print (L"\nUEFI-OpenSSL RSA Key Retrieving Testing: ");
 
@@ -286,6 +290,20 @@ ValidateCryptRsa2 (
 Print (L"[Pass]");
   }
 
+  //
+  // Get CommonName from X509 Certificate Subject
+  //
+  CommonNameSize = 64;
+  ZeroMem (CommonName, CommonNameSize);
+  ReturnStatus = X509GetCommonName (TestCert, sizeof (TestCert), CommonName, 
);
+  if (RETURN_ERROR (ReturnStatus)) {
+Print (L"\n  - Retrieving Common Name - [Fail]");
+return EFI_ABORTED;
+  } else {
+AsciiStrToUnicodeStrS (CommonName, CommonNameUnicode, CommonNameSize);
+Print (L"\n  - Retrieving Common Name = \"%s\" (Size = %d)", 
CommonNameUnicode, CommonNameSize);
+  }
+
   //
   // X509 Certificate Verification.
   //
diff --git a/CryptoPkg/Include/Library/BaseCryptLib.h 
b/CryptoPkg/Include/Library/BaseCryptLib.h
index 9c5ffcd9cf..2366a0218d 100644
--- a/CryptoPkg/Include/Library/BaseCryptLib.h
+++ b/CryptoPkg/Include/Library/BaseCryptLib.h
@@ -2171,6 +2171,41 @@ X509GetSubjectName (
   IN OUT  UINTN*SubjectSize
   );
 
+/**
+  Retrieve the common name (CN) string from one X.509 certificate.
+
+  @param[in]  Cert Pointer to the DER-encoded X509 certificate.
+  @param[in]  CertSize Size of the X509 certificate in bytes.
+  @param[out] CommonName   Buffer to contain the retrieved certificate 
common
+   name string. At most CommonNameSize bytes 
will be
+   written and the string will be null 
terminated. May be
+   NULL in order to determine the size buffer 
needed.
+  @param[in,out]  CommonNameSize   The size in bytes of the CommonName buffer 
on input,
+   and the size of buffer returned CommonName 
on output.
+   If CommonName is NULL then the amount of 
space needed
+   in buffer (including the final null) is 
returned.
+
+  @retval RETURN_SUCCESS   The certificate CommonName retrieved 
successfully.
+  @retval RETURN_INVALID_PARAMETER If Cert is NULL.
+   If CommonNameSize is NULL.
+   If CommonName is not NULL and 
CommonNameSize is 0.
+   If Certificate is invalid.
+  @retval RETURN_NOT_FOUND If no CommonName entry exists.
+  @retval RETURN_BUFFER_TOO_SMALL  If the CommonName is NULL. The required 
buffer size
+   (including the final null) is returned in 
the 
+   CommonNameSize parameter.
+  @retval RETURN_UNSUPPORTED   The operation is not supported.
+
+**/
+RETURN_STATUS
+EFIAPI
+X509GetCommonName (
+  IN  CONST UINT8  *Cert,
+  IN  UINTNCertSize,
+  OUT CHAR8*CommonName,
+  IN OUT  UINTN*CommonNameSize
+  );
+
 /**
   Verify one X509 certificate was issued by the trusted CA.
 
diff --git a/CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c 
b/CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c
index 7d275977c5..bcd5ff49fd 100644
--- a/CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c
+++ 

Re: [edk2] [PATCH] MdePkg: add ARM/AARCH64 support to BaseCacheMaintenanceLib

[Gao, Liming]

Leif:
  I see current ArmLib in ArmPkg. It is not clean enough. ArmLib.h still 
includes Chipset/ArmV7 header. Its function has no function header. When you 
work the patch to move them to BaseLib, please make sure they align to BaseLib 
style.

Thanks
Liming
> -Original Message-
> From: Kinney, Michael D
> Sent: Thursday, September 21, 2017 1:32 AM
> To: Leif Lindholm ; Gao, Liming 
> ; Kinney, Michael D 
> Cc: edk2-devel@lists.01.org; Ard Biesheuvel 
> Subject: RE: [edk2] [PATCH] MdePkg: add ARM/AARCH64 support to 
> BaseCacheMaintenanceLib
> 
> Leif,
> 
> Adding the ARM specific functions to the BaseLib to provide access
> to ARM specific CPU registers/instructions makes sense and is
> what has already been done for IA32/X64/IPF/EBC.
> 
> Put the arch specific content in BaseLib.h inside #if clauses.
> 
> #if defined (MDE_CPU_ARM)
> 
> #if defined (MDE_CPU_AARCH64)
> 
> Or for content shared by ARM and AARCH64 put in:
> 
> #if defined (MDE_CPU_ARM) || defined (MDE_CPU_AARCH64)
> 
> I see a few ARM and AARCH64 elements are already in BaseLib.h.
> 
> Best regards,
> 
> Mike
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On
> > Behalf Of Leif Lindholm
> > Sent: Wednesday, September 20, 2017 8:06 AM
> > To: Gao, Liming 
> > Cc: Kinney, Michael D ; edk2-
> > de...@lists.01.org; Ard Biesheuvel 
> > Subject: Re: [edk2] [PATCH] MdePkg: add ARM/AARCH64 support to
> > BaseCacheMaintenanceLib
> >
> > Hi Liming,
> >
> > I understand the purity argument, but the situation (without
> > this
> > patch) is that:
> > 1) There is a non-functional BaseCacheMaintenanceLib
> > ARM/AARCH64
> >implementation with misleading information in MdePkg.
> > 2) ARM/AARCH64-based needs to include a different cache
> > maintenance
> >library than all other architectures. And they all need to
> > include
> >the same one.
> >
> > 2 is an issue for the logical conclusion of the RFC series I am
> > about
> > to post for creating common include files for "boilerplate"
> > bits of
> > .dsf/.fdf files.
> >
> > An alternative option would be to move ArmLib into MdePkg?
> > A casual glance suggests to me that the corresponding X86
> > features
> > (like AsmWbinvd) are exposed via BaseLib. Would you see any
> > issues
> > with merging the ArmLib functionality into BaseLib?
> >
> > Regards,
> >
> > Leif
> >
> > On Wed, Sep 20, 2017 at 02:45:30PM +, Gao, Liming wrote:
> > > Leif:
> > >   This change lets MdePkg BaseCacheMaintenanceLib depend on
> > ArmPkg
> > >   ArmLib. But, MdePkg is the basic package. It should not
> > depend on
> > >   other package. I suggest to add this ARM specific
> > >   BaseCacheMaintenanceLib library instance into ArmPkg.
> > >
> > > Thanks
> > > Liming
> > > > -Original Message-
> > > > From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> > > > Sent: Wednesday, September 20, 2017 9:23 PM
> > > > To: edk2-devel@lists.01.org
> > > > Cc: Kinney, Michael D ; Gao,
> > Liming ; Ard Biesheuvel
> > > > 
> > > > Subject: [PATCH] MdePkg: add ARM/AARCH64 support to
> > BaseCacheMaintenanceLib
> > > >
> > > > ARM platforms have been using a separately located library
> > in ArmPkg for
> > > > high-level cache maintenance calls. Resolve this anomaly by
> > overwriting
> > > > ArmCache.c with the contents of
> > > >
> > ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c,
> > and add
> > > > the ArmLib dependency for the affected architectures.
> > > >
> > > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > > Signed-off-by: Leif Lindholm 
> > > > ---
> > > >
> > > > The intent is to delete the ArmPkg version once no upstream
> > platforms
> > > > are using it.
> > > >
> > > >  MdePkg/Library/BaseCacheMaintenanceLib/ArmCache.c  | 222
> > +
> > > >  .../BaseCacheMaintenanceLib.inf|   2 +
> > > >  2 files changed, 55 insertions(+), 169 deletions(-)
> > > >
> > > > diff --git
> > a/MdePkg/Library/BaseCacheMaintenanceLib/ArmCache.c
> > b/MdePkg/Library/BaseCacheMaintenanceLib/ArmCache.c
> > > > index 79c84a0982..0759e38cd4 100644
> > > > --- a/MdePkg/Library/BaseCacheMaintenanceLib/ArmCache.c
> > > > +++ b/MdePkg/Library/BaseCacheMaintenanceLib/ArmCache.c
> > > > @@ -1,67 +1,63 @@
> > > >  /** @file
> > > > -  Cache Maintenance Functions. These functions vary by ARM
> > architecture so the MdePkg
> > > > -  versions are null functions used to make sure things
> > will compile.
> > > >
> > > > -  Copyright (c) 2006 - 2009, Intel Corporation. All rights
> > reserved.
> > > > -  Portions copyright (c) 2008 - 2009, Apple Inc. All
> > rights reserved.
> > > > +  Copyright (c) 2008 - 2009, Apple Inc. All rights
> > 

Re: [edk2] [PATCH 0/2] Use PCD for Watchdog count

[Daniil Egranov]

Hi Leif,

I tested it on Juno R2. I see a one EFI SBSA watchdog test failure but I see 
the same failure without the patches so it's not a patch issue.

It looks good for me.

Thanks,
Daniil

-Original Message-
From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
Sent: Wednesday, September 20, 2017 11:22 AM
To: Evan Lloyd
Cc: edk2-devel@lists.01.org; Ard Biesheuvel; Matteo Carlini; nd; Arvind 
Chauhan; Daniil Egranov; Thomas Panakamattam Abraham
Subject: Re: [PATCH 0/2] Use PCD for Watchdog count

Arvind, Daniil, Thomas - any comments?

I have no objections to this changeset.

/
Leif

On Mon, Sep 18, 2017 at 03:53:42PM +0100, evan.ll...@arm.com wrote:
> From: EvanLloyd 
>
> Paired patches for edk2 and edk2-platforms that add and use a PCD
> indicating the number of SBSA Watchdog timers present.  This makes
> things more configurable, and is consistent with other examples of
> platform characteristics. It may also help with debates over GTDT
> inclusion (or not) of secure timers.
>
> Sami Mujawar (1):
>   ArmPlatformPkg: Add PCD for SBSA Watchdog Count
>
>  ArmPlatformPkg/ArmPlatformPkg.dec   | 4 +++-
>  ArmPlatformPkg/ArmJunoPkg/Include/ArmPlatform.h | 4 ++--
>  2 files changed, 5 insertions(+), 3 deletions(-)
>
> Sami Mujawar (1):
>   Platforms/ARM: SBSA Watchdog PCD and build option
>
>  Platform/ARM/JunoPkg/ArmJuno.dsc |  7 ++-
>  Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc |  7 ++-
>  Platform/ARM/JunoPkg/AcpiTables/AcpiTables.inf   |  4 +++-
>  Platform/ARM/VExpressPkg/AcpiTables/AcpiTables.inf   |  4 +++-
>  Platform/ARM/JunoPkg/AcpiTables/Gtdt.aslc|  6 +-
>  Platform/ARM/VExpressPkg/AcpiTables/Gtdt.aslc| 14 +++---
>  6 files changed, 34 insertions(+), 8 deletions(-)
>
> --
> Guid("CE165669-3EF3-493F-B85D-6190EE5B9759")
>
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 5/6] MdeModulePkg/Crc32: Fix possible out of range left shift

[Wu, Hao A]

> -Original Message-
> From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo
> Bonzini
> Sent: Wednesday, September 20, 2017 1:06 AM
> To: Wu, Hao A; edk2-devel@lists.01.org
> Cc: Dong, Eric; Zeng, Star
> Subject: Re: [edk2] [PATCH 5/6] MdeModulePkg/Crc32: Fix possible out of
> range left shift
> 
> On 19/09/2017 13:43, Hao Wu wrote:
> >NewValue = 0;
> >for (Index = 0; Index < 32; Index++) {
> > -if ((Value & (1 << Index)) != 0) {
> > -  NewValue = NewValue | (1 << (31 - Index));
> > +if ((Value & (((UINT32)1) << Index)) != 0) {
> > +  NewValue = NewValue | (((UINT32)1) << (31 - Index));
> >  }
> 
> 
> Why not just "1u" instead of the cast?

Thanks for the feedback. I will update the patch according to the
suggestion.

Best Regards,
Hao Wu

> 
> Paolo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC 1/6] ConfigPkg: add new package for holding common config fragments

[Ard Biesheuvel]

On 20 September 2017 at 10:27, Leif Lindholm  wrote:
> Start with common networking options.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Leif Lindholm 
> ---
>  ConfigPkg/Network/Network.dsc.inc | 92 
> +++
>  ConfigPkg/Network/Network.fdf.inc | 47 
>  2 files changed, 139 insertions(+)
>  create mode 100644 ConfigPkg/Network/Network.dsc.inc
>  create mode 100644 ConfigPkg/Network/Network.fdf.inc
>
> diff --git a/ConfigPkg/Network/Network.dsc.inc 
> b/ConfigPkg/Network/Network.dsc.inc
> new file mode 100644
> index 00..8c53350deb
> --- /dev/null
> +++ b/ConfigPkg/Network/Network.dsc.inc
> @@ -0,0 +1,92 @@
> +## @file
> +#
> +# Copyright (c) 2017, Linaro ltd. All rights reserved.
> +#
> +#  This program and the accompanying materials are licensed and made 
> available
> +#  under the terms and conditions of the BSD License which accompanies this
> +#  distribution. The full text of the license may be found at
> +#  http://opensource.org/licenses/bsd-license.php
> +#
> +#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> +#
> +##
> +
> +
> +
> +#
> +# Library Class section
> +#
> +
> +[LibraryClasses]
> +  DpcLib|MdeModulePkg/Library/DxeDpcLib/DxeDpcLib.inf
> +  IpIoLib|MdeModulePkg/Library/DxeIpIoLib/DxeIpIoLib.inf
> +  NetLib|MdeModulePkg/Library/DxeNetLib/DxeNetLib.inf
> +  UdpIoLib|MdeModulePkg/Library/DxeUdpIoLib/DxeUdpIoLib.inf
> +

Now that you have made a clean spot: any reason we shouldn't do

DpcLib   |MdeModulePkg/Library/DxeDpcLib/DxeDpcLib.inf
IpIoLib  |MdeModulePkg/Library/DxeIpIoLib/DxeIpIoLib.inf
NetLib   |MdeModulePkg/Library/DxeNetLib/DxeNetLib.inf
UdpIoLib |MdeModulePkg/Library/DxeUdpIoLib/DxeUdpIoLib.inf

?

> +!if $(CONFIG_HTTP_BOOT_ENABLE) == TRUE
> +  HttpLib|MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.inf
> +!endif
> +
> +!if $(CONFIG_NETWORK_IP6_ENABLE) == TRUE
> +  BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
> +  IntrinsicLib|CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf
> +  TcpIoLib|MdeModulePkg/Library/DxeTcpIoLib/DxeTcpIoLib.inf
> +!endif
> +
> +!if $(CONFIG_TLS_ENABLE) == TRUE
> +  OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLib.inf
> +  TlsLib|CryptoPkg/Library/TlsLib/TlsLib.inf
> +!else
> +  OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
> +!endif
> +
> +
> +#
> +# Pcd Section
> +#
> +
> +[PcdsFixedAtBuild]
> +!if $(CONFIG_HTTP_BOOT_ENABLE) == TRUE
> +  gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections|TRUE
> +!endif
> +
> +
> +
> +#
> +# Components Section
> +#
> +
> +[Components]
> +  MdeModulePkg/Universal/Network/ArpDxe/ArpDxe.inf
> +  MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Dxe.inf
> +  MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf
> +  MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf
> +  MdeModulePkg/Universal/Network/MnpDxe/MnpDxe.inf
> +  MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf
> +  MdeModulePkg/Universal/Network/SnpDxe/SnpDxe.inf
> +  MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Dxe.inf
> +  MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf
> +!if $(CONFIG_NETWORK_IP6_ENABLE) == TRUE
> +  NetworkPkg/Dhcp6Dxe/Dhcp6Dxe.inf
> +  NetworkPkg/Ip6Dxe/Ip6Dxe.inf
> +  NetworkPkg/IScsiDxe/IScsiDxe.inf
> +  NetworkPkg/Mtftp6Dxe/Mtftp6Dxe.inf
> +  NetworkPkg/TcpDxe/TcpDxe.inf
> +  NetworkPkg/Udp6Dxe/Udp6Dxe.inf
> +  NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf
> +!else
> +  MdeModulePkg/Universal/Network/IScsiDxe/IScsiDxe.inf
> +  MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf
> +  MdeModulePkg/Universal/Network/UefiPxeBcDxe/UefiPxeBcDxe.inf
> +!endif
> +!if $(CONFIG_HTTP_BOOT_ENABLE) == TRUE
> +  NetworkPkg/DnsDxe/DnsDxe.inf
> +  NetworkPkg/HttpBootDxe/HttpBootDxe.inf
> +  NetworkPkg/HttpDxe/HttpDxe.inf
> +  NetworkPkg/HttpUtilitiesDxe/HttpUtilitiesDxe.inf
> +!endif
> +!if $(CONFIG_TLS_ENABLE) == TRUE
> +  NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf
> +  NetworkPkg/TlsDxe/TlsDxe.inf
> +!endif
> diff --git a/ConfigPkg/Network/Network.fdf.inc 
> b/ConfigPkg/Network/Network.fdf.inc
> new file mode 100644
> index 00..614fd18a9a
> --- /dev/null
> +++ b/ConfigPkg/Network/Network.fdf.inc
> @@ -0,0 +1,47 @@
> +## @file
> +#
> +# Copyright (c) 2017, Linaro ltd. All rights reserved.
> +#
> +#  This program and the accompanying materials are 

Re: [edk2] [PATCH 2/2] MdeModulePkg/Core: Fix out-of-sync issue in GCD

[Wang, Jian J]

Sure. I'll submit a new patch after enough validation. Thanks for the review.

-Original Message-
From: Zeng, Star 
Sent: Wednesday, September 20, 2017 5:30 PM
To: Wang, Jian J ; edk2-devel@lists.01.org
Cc: Kinney, Michael D ; Laszlo Ersek 
; Yao, Jiewen ; Dong, Eric 
; Zeng, Star 
Subject: RE: [edk2] [PATCH 2/2] MdeModulePkg/Core: Fix out-of-sync issue in GCD

Reviewed-by: Star Zeng  for this patch.

Please notice that the MemoryProtection.c is using gCpu->SetMemoryAttributes 
but not GCD SetMemorySpaceAttributes.
You should need update it to use GCD SetMemorySpaceAttributes, you can have 
separated patch to cover it.


Thanks,
Star
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jian J 
Wang
Sent: Tuesday, September 19, 2017 2:10 PM
To: edk2-devel@lists.01.org
Cc: Kinney, Michael D ; Laszlo Ersek 
; Yao, Jiewen ; Dong, Eric 
; Zeng, Star 
Subject: [edk2] [PATCH 2/2] MdeModulePkg/Core: Fix out-of-sync issue in GCD

>From GCD perspective, its SetMemorySpaceAttributes() method doesn't accept 
>page related attributes. That means users cannot use it to change page 
>attributes, and have to turn to CPU arch protocol to do it, which is not be 
>allowed by PI spec.

Cc: Jiewen Yao 
Cc: Eric Dong 
Cc: Star Zeng 
Cc: Laszlo Ersek 
Cc: Michael Kinney 
Suggested-by: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 MdeModulePkg/Core/Dxe/Gcd/Gcd.c | 45 -
 1 file changed, 27 insertions(+), 18 deletions(-)

diff --git a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c 
index a06f8bb77c..e9d1d5b612 100644
--- a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
+++ b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
@@ -40,6 +40,13 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 
 #define PRESENT_MEMORY_ATTRIBUTES (EFI_RESOURCE_ATTRIBUTE_PRESENT)
 
+#define EXCLUSIVE_MEMORY_ATTRIBUTES   (EFI_MEMORY_UC | EFI_MEMORY_WC | \
+   EFI_MEMORY_WT | EFI_MEMORY_WB | \
+   EFI_MEMORY_WP | EFI_MEMORY_UCE)
+
+#define NONEXCLUSIVE_MEMORY_ATTRIBUTES (EFI_MEMORY_XP | EFI_MEMORY_RP | \
+EFI_MEMORY_RO)
+
 #define INVALID_CPU_ARCH_ATTRIBUTES   0x
 
 //
@@ -654,28 +661,30 @@ ConverToCpuArchAttributes (
   UINT64 Attributes
   )
 {
-  if ( (Attributes & EFI_MEMORY_UC) == EFI_MEMORY_UC) {
-return EFI_MEMORY_UC;
-  }
+  UINT64  CpuArchAttributes;
 
-  if ( (Attributes & EFI_MEMORY_WC ) == EFI_MEMORY_WC) {
-return EFI_MEMORY_WC;
+  if ((Attributes & ~(EXCLUSIVE_MEMORY_ATTRIBUTES |
+  NONEXCLUSIVE_MEMORY_ATTRIBUTES)) != 0) {
+return INVALID_CPU_ARCH_ATTRIBUTES;
   }
 
-  if ( (Attributes & EFI_MEMORY_WT ) == EFI_MEMORY_WT) {
-return EFI_MEMORY_WT;
-  }
-
-  if ( (Attributes & EFI_MEMORY_WB) == EFI_MEMORY_WB) {
-return EFI_MEMORY_WB;
-  }
-
-  if ( (Attributes & EFI_MEMORY_WP) == EFI_MEMORY_WP) {
-return EFI_MEMORY_WP;
-  }
-
-  return INVALID_CPU_ARCH_ATTRIBUTES;
+  CpuArchAttributes = Attributes & NONEXCLUSIVE_MEMORY_ATTRIBUTES;
 
+  if ( (Attributes & EFI_MEMORY_UC) == EFI_MEMORY_UC) {
+CpuArchAttributes |= EFI_MEMORY_UC;  } else if ( (Attributes & 
+ EFI_MEMORY_WC ) == EFI_MEMORY_WC) {
+CpuArchAttributes |= EFI_MEMORY_WC;  } else if ( (Attributes & 
+ EFI_MEMORY_WT ) == EFI_MEMORY_WT) {
+CpuArchAttributes |= EFI_MEMORY_WT;  } else if ( (Attributes & 
+ EFI_MEMORY_WB) == EFI_MEMORY_WB) {
+CpuArchAttributes |= EFI_MEMORY_WB;  } else if ( (Attributes & 
+ EFI_MEMORY_UCE) == EFI_MEMORY_UCE) {
+CpuArchAttributes |= EFI_MEMORY_UCE;  } else if ( (Attributes & 
+ EFI_MEMORY_WP) == EFI_MEMORY_WP) {
+CpuArchAttributes |= EFI_MEMORY_WP;  }
+
+  return CpuArchAttributes;
 }
 
 
--
2.14.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v1] MdePkg: Add definitions for the SPI protocols introduced in UEFI PI 1.6.

[Marvin Häuser]

Hey Vincent,

Thank you for your response!
It would be very kind of you if you would post an update to edk2-devel and CC 
me once you get a response from the Forum!

In case you know somebody working on the MM part of the specification, could 
you please forward the following?
There is a potential problem with EFI_MM_IO_TRAP_DISPATCH_PROTOCOL.Register() 
that might prevent a Standalone MM implementation:
"If the base of the I/O range specified is zero, then an I/O range with the 
specified length and characteristics will be allocated and the Address field in 
RegisterContext updated."
With the current specification, the only way to allocate an I/O Range I know is 
via the DXE Services, though using the DXE services means that a Standalone MM 
implementation is not possible. Maybe 0 should no longer be accepted as a 
possible value (of course that would require an IoTrapDispatch2)? A Standalone 
MM driver which calls this function would then depend on a DXE driver to 
already have allocated the range via the DXE Services (the MM driver should 
probably hook the EndOfDxe event to make sure the DXE code has run). On the 
other hand, the Standalone MM IoTrap consumer has no way of knowing whether the 
allocation was completed successfully. So, the only proper way I see would be 
implementing I/O range allocation during PEI phase and then exposing those 
allocations via the HOB list, which is available to both the DXE Core to take 
note of the allocations, as well as the Standalone MM Core, which can expose 
them to the MM Standalone Drivers. Any comments? Did I maybe overlook something?

Thanks,
Marvin.

> -Original Message-
> From: Zimmer, Vincent [mailto:vincent.zim...@intel.com]
> Sent: Wednesday, September 20, 2017 10:24 PM
> To: Marvin Häuser ; edk2-
> de...@lists.01.org
> Cc: Bi, Dandan ; Shaw, Kevin W
> ; Leahy, Leroy P ; UEFI
> Administration 
> Subject: RE: [PATCH v1] MdePkg: Add definitions for the SPI protocols
> introduced in UEFI PI 1.6.
> 
> Marvin:
> 
> Thanks for all of the feedback on the SPI items from the most recent UEFI PI
> spec. We're updating the PI spec now responsive to your findings and these
> corrections will be reflected in an upcoming errata.
> 
> Sorry for the delayed response to you on the findings. I'll follow up w/ UEFI
> Forum on why we cannot readily use the fw/os forum mailing list for this
> type of discussion, too.
> 
> Vincent
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Marvin Häuser
> Sent: Friday, September 15, 2017 7:57 AM
> To: edk2-devel@lists.01.org
> Cc: Bi, Dandan 
> Subject: Re: [edk2] [PATCH v1] MdePkg: Add definitions for the SPI protocols
> introduced in UEFI PI 1.6.
> 
> Hey Dandan,
> 
> Sorry for the mistakes, I will send them a part of a V2 once you finished
> reviewing.
> No problem for the delay, it's not high priority at all. Thanks for reviewing 
> it!
> 
> There are problems within the specification regarding the SPI protocols
> anyway.
> I wanted to report these, though I don't know where to. Andrew suggested
> to post to the FW/OS Forum,
> though it is currently not available, so I'm awaiting response from the UEFI
> Forum administration.
> 
> Best regards,
> Marvin.
> 
> > -Original Message-
> > From: Bi, Dandan [mailto:dandan...@intel.com]
> > Sent: Friday, September 15, 2017 10:22 AM
> > To: Ni, Ruiyu ; Marvin Häuser
> > ; edk2-devel@lists.01.org
> > Cc: Kinney, Michael D ; Gao, Liming
> > 
> > Subject: RE: [PATCH v1] MdePkg: Add definitions for the SPI protocols
> > introduced in UEFI PI 1.6.
> >
> > Hi Marvin,
> >
> > Thank you for your contribution. I am reviewing this patch now. Currently I
> > just take a look at the SMM SPI part and find:
> >
> > 1. There is a typo in LegacySpiSmmController.h
> > The definition should be EFI_LEGACY_SPI_SMM_CONTROLLER_GUID, not
> > EFI_LEGACY_SPI_SMM_FLASH_PROTOCOL_GUID.
> > Typo:
> > #define EFI_LEGACY_SPI_SMM_FLASH_PROTOCOL_GUID  \
> >   { 0x62331b78, 0xd8d0, 0x4c8c, \
> > { 0x8c, 0xcb, 0xd2, 0x7d, 0xfe, 0x32, 0xdb, 0x9b }}
> > And it should  be:
> > #define EFI_LEGACY_SPI_SMM_CONTROLLER_GUID \
> > { 0x62331b78, 0xd8d0, 0x4c8c, { 0x8c, 0xcb, 0xd2, 0x7d, \ 0xfe, 0x32, 0xdb,
> > 0x9b }}
> >
> > 2. EFI_SPI_SMM_NOR_FLASH_PROTOCOL definition seems to be missing.
> >
> > I will review the remaining part. It may take some time. Sorry for the delay
> in
> > my response
> >
> > Thanks,
> > Dandan
> >
> > -Original Message-
> > From: Ni, Ruiyu
> > Sent: Thursday, September 7, 2017 3:13 PM
> > To: Marvin Häuser ; edk2-
> > de...@lists.01.org
> > Cc: Kinney, Michael D ; Gao, Liming
> > ; Bi, Dandan 

Re: [edk2] [RFC 0/6] Create central repository for boilerplate configuration

[Leif Lindholm]

On Wed, Sep 20, 2017 at 08:14:59PM +0200, Laszlo Ersek wrote:
> On 09/20/17 19:27, Leif Lindholm wrote:
> > An awful lot of platform configuration is just repeated verbatim for
> > every platform. This is my first stab at eliminating some of this
> > redundancy.
> > 
> > I have additional bits as work in progress, but before I sink too much
> > time into it, I would like to try to gather feedback on this approach
> > (all the way down to directory structure).
> > 
> > This first round deals with basic network support and Secure Boot
> > requirements.
> 
> I can't comment on the general "ConfigPkg" question, and the directory
> structure; I'll just assume that it's OK that way. (It will need
> documented maintainers though.)

Of course - I just thought I'd wait with that until we'd been through
whether it should live in MdeModulePkg or ...

> I do have some initial comments:
> 
> (1) Please update your git config so that the diff hunk headers display
> the INI-style section name that's being modified. Please search the
> following sections for "ini":

Agh, sorry - I lost that when I reinstalled my build machine a month
or so back. I did do 9, but I missed out rerunning
  git config diff.ini.xfuncname '^\[[A-Za-z0-9_., ]+]'

> https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers#contrib-05
> 
> https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers#contrib-09
> 
> Normally this is plain "helpful" for reviewers, but given the subject of
> this set, I'd say it's "important" (to me as a reviewer anyway), to see
> what section lines are removed from.

Indeed. Pure oversight. Now addressed.

> (2) Replacing a build define called FOOBAR with CONFIG_FOOBAR will break
> all downstream build scripts. Is the CONFIG_ prefix a requirement?

It was explicitly intended to break compatibility, to ensure we didn't
end up with things accidentally working until something unrelated
changed in the future.

Also a subject for discussion - hence the RFC.

> (3) I think PCDs should not be included in ConfigPkg DSC include files,
> even if several platforms set the same value. The set of libraries and
> driver modules commonly used for a given feature is mostly constant
> across platforms (and it is easy to extend, incrementally); but I don't
> think the same holds for PCDs. Especially if a user wants to change a
> PCD for one platform but not the other. Even if repeated settings for a
> PCD worked (all on the same level of "specificity"), I'd find the result
> confusing.

Also a subject for discussion.
My intent was that if most of the open source platforms had an
override on the default of a particular Pcd, we could override it in
the config fragments without changing the .dec (and affecting
non-public ports).

Individual platforms can still override (again).

Also a subject for discussion.

> (4) The Ia32X64 build of OVMF is a bit trickier than the rest; DXE
> modules should be built for X64, while PEI modules should be built for
> IA32. You can see this in the names of the [Components.IA32] and
> [Components.X64] sections. (Point (1) above helps with this.)
> 
> For example, in patch #1 you add "ArpDxe" to [Components], but in patch
> #3 you remove it from [Components.X64].

I'll be honest, I don't have any system on which I can currently build
IA32 - I get "unknown relocations" whenever I try. So Ia32X64 was only
compile tested, not linked.

> (5) In patch #4, there's a section for [LibraryClasses.ARM,
> LibraryClasses.AARCH64] -- why is it specific to ARM/AARCH64?

These mappings appeared to be necessary only for these architectures
at the time. The section started up larger than it ended up, It is
quite likely further work on Common.dsc.inc would remove more of these.

> If others like the ConfigPkg idea, I'd like to review the set (or v2)
> again, in more detail, but for that, please fix the patch formatting
> first, as requested in (1).

As stated above, pure oversight.

/
Leif

> Thanks!
> Laszlo
> 
> > 
> > Leif Lindholm (6):
> >   ConfigPkg: add new package for holding common config fragments
> >   ArmVirtPkg: use   ConfigPkg for common network items
> >   OvmfPkg: use ConfigPkg for common network items
> >   ConfigPkg: add common Security settings
> >   ArmVirtPkg: use ConfigPkg for common security items
> >   OvmfPkg: use ConfigPkg for common security items
> > 
> >  ArmVirtPkg/ArmVirt.dsc.inc   | 25 ++
> >  ArmVirtPkg/ArmVirtQemu.dsc   | 46 +++---
> >  ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc | 24 ++
> >  ArmVirtPkg/ArmVirtQemuKernel.dsc | 46 +++---
> >  ConfigPkg/Network/Network.dsc.inc| 92 
> > 
> >  ConfigPkg/Network/Network.fdf.inc| 47 ++
> >  ConfigPkg/Security/Security.dsc.inc  | 67 ++
> >  ConfigPkg/Security/Security.fdf.inc  | 17 

Re: [edk2] [PATCH v1] MdePkg: Add definitions for the SPI protocols introduced in UEFI PI 1.6.

[Zimmer, Vincent]

Marvin:

Thanks for all of the feedback on the SPI items from the most recent UEFI PI 
spec. We're updating the PI spec now responsive to your findings and these 
corrections will be reflected in an upcoming errata.

Sorry for the delayed response to you on the findings. I'll follow up w/ UEFI 
Forum on why we cannot readily use the fw/os forum mailing list for this type 
of discussion, too.

Vincent

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Marvin 
Häuser
Sent: Friday, September 15, 2017 7:57 AM
To: edk2-devel@lists.01.org
Cc: Bi, Dandan 
Subject: Re: [edk2] [PATCH v1] MdePkg: Add definitions for the SPI protocols 
introduced in UEFI PI 1.6.

Hey Dandan,

Sorry for the mistakes, I will send them a part of a V2 once you finished 
reviewing.
No problem for the delay, it's not high priority at all. Thanks for reviewing 
it!

There are problems within the specification regarding the SPI protocols anyway.
I wanted to report these, though I don't know where to. Andrew suggested to 
post to the FW/OS Forum,
though it is currently not available, so I'm awaiting response from the UEFI 
Forum administration.

Best regards,
Marvin.

> -Original Message-
> From: Bi, Dandan [mailto:dandan...@intel.com]
> Sent: Friday, September 15, 2017 10:22 AM
> To: Ni, Ruiyu ; Marvin Häuser
> ; edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Gao, Liming
> 
> Subject: RE: [PATCH v1] MdePkg: Add definitions for the SPI protocols
> introduced in UEFI PI 1.6.
> 
> Hi Marvin,
> 
> Thank you for your contribution. I am reviewing this patch now. Currently I
> just take a look at the SMM SPI part and find:
> 
> 1. There is a typo in LegacySpiSmmController.h
> The definition should be EFI_LEGACY_SPI_SMM_CONTROLLER_GUID, not
> EFI_LEGACY_SPI_SMM_FLASH_PROTOCOL_GUID.
> Typo:
> #define EFI_LEGACY_SPI_SMM_FLASH_PROTOCOL_GUID  \
>   { 0x62331b78, 0xd8d0, 0x4c8c, \
> { 0x8c, 0xcb, 0xd2, 0x7d, 0xfe, 0x32, 0xdb, 0x9b }}
> And it should  be:
> #define EFI_LEGACY_SPI_SMM_CONTROLLER_GUID \
> { 0x62331b78, 0xd8d0, 0x4c8c, { 0x8c, 0xcb, 0xd2, 0x7d, \ 0xfe, 0x32, 0xdb,
> 0x9b }}
> 
> 2. EFI_SPI_SMM_NOR_FLASH_PROTOCOL definition seems to be missing.
> 
> I will review the remaining part. It may take some time. Sorry for the delay 
> in
> my response
> 
> Thanks,
> Dandan
> 
> -Original Message-
> From: Ni, Ruiyu
> Sent: Thursday, September 7, 2017 3:13 PM
> To: Marvin Häuser ; edk2-
> de...@lists.01.org
> Cc: Kinney, Michael D ; Gao, Liming
> ; Bi, Dandan 
> Subject: RE: [PATCH v1] MdePkg: Add definitions for the SPI protocols
> introduced in UEFI PI 1.6.
> 
> Marvin,
> Thank you for your contribution. We will need some time to review the
> definitions against PI Spec.
> If there is a need to post V2, it might be better to separate the header 
> files in
> different groups.
> For example, LegacySpi group, SPI group, SMM SPI group.
> 
> Thanks/Ray
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Marvin Häuser
> > Sent: Wednesday, September 6, 2017 5:21 PM
> > To: edk2-devel@lists.01.org
> > Cc: Kinney, Michael D ; Gao, Liming
> > 
> > Subject: [edk2] [PATCH v1] MdePkg: Add definitions for the SPI protocols
> > introduced in UEFI PI 1.6.
> >
> > This commit adds header files for the SPI protocols introduced in the
> > UEFI PI 1.6 specification, as well as their GUIDs to MdePkg.dec.
> >
> > EFI_SPI_TRANSACTION_TYPE assumes an enum with its members ordered
> > the
> > way they are listed in the specification, as there are no values given
> > explicitely.
> > EFI_LEGACY_SPI_CONTROLLER_GUID assumes the character 'l' used in the
> > specification was meant to be '1'.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Marvin Haeuser 
> > ---
> >  MdePkg/Include/Protocol/LegacySpiController.h| 265
> > ++
> >  MdePkg/Include/Protocol/LegacySpiFlash.h | 201 ++
> >  MdePkg/Include/Protocol/LegacySpiSmmController.h |  36 +++
> >  MdePkg/Include/Protocol/LegacySpiSmmFlash.h  |  36 +++
> >  MdePkg/Include/Protocol/SpiConfiguration.h   | 293
> > 
> >  MdePkg/Include/Protocol/SpiHc.h  | 194 +
> >  MdePkg/Include/Protocol/SpiIo.h  | 292 +++
> >  MdePkg/Include/Protocol/SpiNorFlash.h| 289
> > +++
> >  MdePkg/Include/Protocol/SpiSmmConfiguration.h|  36 +++
> >  MdePkg/Include/Protocol/SpiSmmHc.h   |  36 +++
> >  MdePkg/MdePkg.dec|  31 +++
> >  11 files changed, 1709 insertions(+)
> >
> > diff 

[edk2] [Patch v2 3/3] ArmPkg/Include: Add ArmSvcLib header file.

[Supreeth Venkatesh]

ArmSvcLib header file to specify the SVC arguments structure and
function prototype to trigger an SVC call.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Achin Gupta 
Signed-off-by: Supreeth Venkatesh 
---
 ArmPkg/Include/Library/ArmSvcLib.h | 46 ++
 1 file changed, 46 insertions(+)
 create mode 100644 ArmPkg/Include/Library/ArmSvcLib.h

diff --git a/ArmPkg/Include/Library/ArmSvcLib.h 
b/ArmPkg/Include/Library/ArmSvcLib.h
new file mode 100644
index 00..77a60b3679
--- /dev/null
+++ b/ArmPkg/Include/Library/ArmSvcLib.h
@@ -0,0 +1,46 @@
+/** @file
+*
+*  Copyright (c) 2016 - 2017, ARM Limited. All rights reserved.
+*
+*  This program and the accompanying materials
+*  are licensed and made available under the terms and conditions of the BSD 
License
+*  which accompanies this distribution.  The full text of the license may be 
found at
+*  http://opensource.org/licenses/bsd-license.php
+*
+*  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+*  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+*
+**/
+
+#ifndef __ARM_SVC_LIB__
+#define __ARM_SVC_LIB__
+
+/**
+ * The size of the SVC arguments are different between AArch64 and AArch32.
+ * The native size is used for the arguments.
+ */
+typedef struct {
+  UINTN  Arg0;
+  UINTN  Arg1;
+  UINTN  Arg2;
+  UINTN  Arg3;
+  UINTN  Arg4;
+  UINTN  Arg5;
+  UINTN  Arg6;
+  UINTN  Arg7;
+} ARM_SVC_ARGS;
+
+/**
+  Trigger an SVC call
+
+  SVC calls can take up to 7 arguments and return up to 4 return values.
+  Therefore, the 4 first fields in the ARM_SVC_ARGS structure are used
+  for both input and output values.
+
+**/
+VOID
+ArmCallSvc (
+  IN OUT ARM_SVC_ARGS *Args
+  );
+
+#endif
-- 
2.14.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch v2 2/3] ArmPkg: Modify description file to build ArmSvcLib.

[Supreeth Venkatesh]

Add ArmPkg/Library/ArmSvcLib/ArmSvcLib.inf to [Components.common]
section of ArmPkg.dsc file to build it as part of Arm package.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Achin Gupta 
Signed-off-by: Supreeth Venkatesh 
---
 ArmPkg/ArmPkg.dsc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/ArmPkg/ArmPkg.dsc b/ArmPkg/ArmPkg.dsc
index fc24a788df..cf9a5c1210 100644
--- a/ArmPkg/ArmPkg.dsc
+++ b/ArmPkg/ArmPkg.dsc
@@ -133,6 +133,7 @@
   ArmPkg/Library/ArmSmcLib/ArmSmcLib.inf
   ArmPkg/Library/ArmSmcLibNull/ArmSmcLibNull.inf
   ArmPkg/Library/ArmHvcLib/ArmHvcLib.inf
+  ArmPkg/Library/ArmSvcLib/ArmSvcLib.inf
 
   ArmPkg/Filesystem/SemihostFs/SemihostFs.inf
 
-- 
2.14.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch v2 1/3] ArmPkg/ArmSvcLib: Add ArmSvcLib implementation.

[Supreeth Venkatesh]

This patch adds a library that enables invocation of SVCs from Exception
Level EL0. It will be used by the Standalone MM environment to request
services from a software running in a privileged EL e.g. ARM Trusted
Firmware. The library is derived directly from Arm SMC Library.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Achin Gupta 
Signed-off-by: Supreeth Venkatesh 
---
 ArmPkg/Library/ArmSvcLib/AArch64/ArmSvc.S | 43 +++
 ArmPkg/Library/ArmSvcLib/Arm/ArmSvc.S | 41 +
 ArmPkg/Library/ArmSvcLib/Arm/ArmSvc.asm   | 39 
 ArmPkg/Library/ArmSvcLib/ArmSvcLib.inf| 31 ++
 4 files changed, 154 insertions(+)
 create mode 100644 ArmPkg/Library/ArmSvcLib/AArch64/ArmSvc.S
 create mode 100644 ArmPkg/Library/ArmSvcLib/Arm/ArmSvc.S
 create mode 100644 ArmPkg/Library/ArmSvcLib/Arm/ArmSvc.asm
 create mode 100644 ArmPkg/Library/ArmSvcLib/ArmSvcLib.inf

diff --git a/ArmPkg/Library/ArmSvcLib/AArch64/ArmSvc.S 
b/ArmPkg/Library/ArmSvcLib/AArch64/ArmSvc.S
new file mode 100644
index 00..ffe005c07c
--- /dev/null
+++ b/ArmPkg/Library/ArmSvcLib/AArch64/ArmSvc.S
@@ -0,0 +1,43 @@
+//
+//  Copyright (c) 2012 - 2017, ARM Limited. All rights reserved.
+//
+//  This program and the accompanying materials
+//  are licensed and made available under the terms and conditions of the BSD 
License
+//  which accompanies this distribution.  The full text of the license may be 
found at
+//  http://opensource.org/licenses/bsd-license.php
+//
+//  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+//  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+//
+//
+
+.text
+.align 3
+
+GCC_ASM_EXPORT(ArmCallSvc)
+
+ASM_PFX(ArmCallSvc):
+  // Push x0 on the stack - The stack must always be quad-word aligned
+  str   x0, [sp, #-16]!
+  // Push frame pointer and return address on the stack
+  stp   x29, x30, [sp, #-16]!
+
+  // Load the SVC arguments values into the appropriate registers
+  ldp   x6, x7, [x0, #48]
+  ldp   x4, x5, [x0, #32]
+  ldp   x2, x3, [x0, #16]
+  ldp   x0, x1, [x0, #0]
+
+  svc   #0
+
+  // Pop the ARM_SVC_ARGS structure address from the stack into x9
+  ldr   x9, [sp], #32
+
+  // Store the SVC returned values into the ARM_SVC_ARGS structure.
+  // A SVC call can return up to 4 values - we do not need to store back x4-x7.
+  stp   x0, x1,[x9, #0]
+  stp   x2, x3,[x9, #16]
+
+  mov   x0, x9
+
+  ret
diff --git a/ArmPkg/Library/ArmSvcLib/Arm/ArmSvc.S 
b/ArmPkg/Library/ArmSvcLib/Arm/ArmSvc.S
new file mode 100644
index 00..6072d86d6f
--- /dev/null
+++ b/ArmPkg/Library/ArmSvcLib/Arm/ArmSvc.S
@@ -0,0 +1,41 @@
+//
+//  Copyright (c) 2016 - 2017, ARM Limited. All rights reserved.
+//
+//  This program and the accompanying materials
+//  are licensed and made available under the terms and conditions of the BSD 
License
+//  which accompanies this distribution.  The full text of the license may be 
found at
+//  http://opensource.org/licenses/bsd-license.php
+//
+//  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+//  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+//
+//
+
+.text
+.align 3
+.arch_extension sec
+
+GCC_ASM_EXPORT(ArmCallSvc)
+
+ASM_PFX(ArmCallSvc):
+// r0 will be popped just after the SVC call
+push{r0, r4-r8}
+
+// Load the SVC arguments values into the appropriate registers
+ldm r0,{r0-r7}
+
+svc #0
+
+// Pop the ARM_SVC_ARGS structure address from the stack into r8
+pop {r8}
+
+// Load the SVC returned values into the appropriate registers
+// A SVC call can return up to 4 values - we do not need to store back 
r4-r7.
+stm r8,{r0-r3}
+
+mov r0, r8
+
+// Restore the registers r4-r8
+pop {r4-r8}
+
+bx  lr
diff --git a/ArmPkg/Library/ArmSvcLib/Arm/ArmSvc.asm 
b/ArmPkg/Library/ArmSvcLib/Arm/ArmSvc.asm
new file mode 100644
index 00..fd3e77c3b6
--- /dev/null
+++ b/ArmPkg/Library/ArmSvcLib/Arm/ArmSvc.asm
@@ -0,0 +1,39 @@
+//
+//  Copyright (c) 2016 - 2017, ARM Limited. All rights reserved.
+//
+//  This program and the accompanying materials
+//  are licensed and made available under the terms and conditions of the BSD 
License
+//  which accompanies this distribution.  The full text of the license may be 
found at
+//  http://opensource.org/licenses/bsd-license.php
+//
+//  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+//  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+//
+//
+
+
+INCLUDE AsmMacroExport.inc
+
+ RVCT_ASM_EXPORT ArmCallSvc
+// r0 will be popped just after the SVC call
+push {r0, r4-r8}
+
+// Load the SVC arguments values into the appropriate registers
+ldm r0,{r0-r7}
+svc #0
+
+// Pop the ARM_SVC_ARGS structure address from 

[edk2] [Patch v2 0/3] *** Add ArmSvc Library ***

[Supreeth Venkatesh]

*** 
This patchset adds a library that enables invocation of SVCs from Exception
Level EL0. It will be used by the Standalone MM environment to request
services from a software running in a privileged EL e.g. ARM Trusted
Firmware. The library is derived directly from Arm SMC Library. 

Further, it builds the library during the build of Arm Pacakge and the library 
exports the header file for inclusion in other modules.

This is tested on AARCH64 Reference platform and 
has not been tested on ARM 32 bit Platform.

Changes Since v1:
(*) Update Review Comments from Ard.
(*) Reword Commit subject for the patches in the set to convey meaningful 
summary. 

***

Supreeth Venkatesh (3):
  ArmPkg/ArmSvcLib: Add ArmSvcLib implementation.
  ArmPkg: Modify description file to build ArmSvcLib.
  ArmPkg/Include: Add ArmSvcLib header file.

 ArmPkg/ArmPkg.dsc |  1 +
 ArmPkg/Include/Library/ArmSvcLib.h| 46 +++
 ArmPkg/Library/ArmSvcLib/AArch64/ArmSvc.S | 43 +
 ArmPkg/Library/ArmSvcLib/Arm/ArmSvc.S | 41 +++
 ArmPkg/Library/ArmSvcLib/Arm/ArmSvc.asm   | 39 ++
 ArmPkg/Library/ArmSvcLib/ArmSvcLib.inf| 31 +
 6 files changed, 201 insertions(+)
 create mode 100644 ArmPkg/Include/Library/ArmSvcLib.h
 create mode 100644 ArmPkg/Library/ArmSvcLib/AArch64/ArmSvc.S
 create mode 100644 ArmPkg/Library/ArmSvcLib/Arm/ArmSvc.S
 create mode 100644 ArmPkg/Library/ArmSvcLib/Arm/ArmSvc.asm
 create mode 100644 ArmPkg/Library/ArmSvcLib/ArmSvcLib.inf

-- 
2.14.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3 0/2] UDF partition driver fix

[Paulo Alcantara]

On September 20, 2017 4:25:10 PM GMT-03:00, Laszlo Ersek  
wrote:
>On 09/20/17 20:16, Paulo Alcantara wrote:
>
>> Please, test building these changes in toolchains other than GCC and
>> make sure they don't break the world :-)
>
>> Repo:   https://github.com/pcacjr/edk2.git
>> Branch: udf-partition-fix-v3
>
>I build-tested your branch with OVMF (both IA32 and X64), using:
>
>- gcc-4.8.5, GCC48, DEBUG
>- clang-3.8.1, CLANG38, NOOPT
>- gcc-7.1.1, GCC5, DEBUG
>
>and also cross-built your branch as part of ArmVirtQemu (both ARM and
>AARCH64), using:
>
>- gcc-6.1.1, GCC5, DEBUG
>
>If it matters, you can add:
>
>Build-tested-by: Laszlo Ersek 

Of course it does! :-) Thank you very much. You might be wondering why I didn't 
build-test it with MSVC - well, my wife's laptop got no Visual Studio 
installed, bul only the necessary 'format' command for formatting my USB stick 
with UDF :-)

Thanks!
Paulo

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3 0/2] UDF partition driver fix

[Laszlo Ersek]

On 09/20/17 20:16, Paulo Alcantara wrote:

> Please, test building these changes in toolchains other than GCC and
> make sure they don't break the world :-)

> Repo:   https://github.com/pcacjr/edk2.git
> Branch: udf-partition-fix-v3

I build-tested your branch with OVMF (both IA32 and X64), using:

- gcc-4.8.5, GCC48, DEBUG
- clang-3.8.1, CLANG38, NOOPT
- gcc-7.1.1, GCC5, DEBUG

and also cross-built your branch as part of ArmVirtQemu (both ARM and
AARCH64), using:

- gcc-6.1.1, GCC5, DEBUG

If it matters, you can add:

Build-tested-by: Laszlo Ersek 

Thanks!
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/3] OvmfPkg/QemuVideoDxe/VbeShim: handle PAM1 register on Q35 correctly

[Laszlo Ersek]

On 09/20/17 20:11, Jordan Justen wrote:
> Series Reviewed-by: Jordan Justen 

Much appreciated! :)


Aleksei, thank you for the LaunchPad bug report (complete with
bisection) and the testing.

Pushed: b68c793144e8..947f3737abf6.

Cheers,
Laszlo

> On 2017-09-19 12:18:12, Laszlo Ersek wrote:
>> Repo:   https://github.com/lersek/edk2.git
>> Branch: vbe_shim_q35_pam
>>
>> Fix the long-standing OVMF/Q35 bug recently exposed by a QEMU change,
>> and reported under .
>>
>> Aleksei, can you please fetch the branch, build it, and report back with
>> your Tested-by if it works for you?
>>
>> I performed my own tests as well; I'll include those in a separate
>> email.
>>
>> Cc: Aleksei Kovura 
>> Cc: Gerd Hoffmann 
>> Cc: Igor Mammedov 
>> Cc: Jordan Justen 
>> Cc: Ruiyu Ni 
>>
>> Thank you,
>> Laszlo
>>
>> Laszlo Ersek (3):
>>   OvmfPkg/CsmSupportLib: move PAM register addresses to IndustryStandard
>>   OvmfPkg/QemuVideoDxe/VbeShim: rename Status to
>> Segment0AllocationStatus
>>   OvmfPkg/QemuVideoDxe/VbeShim: handle PAM1 register on Q35 correctly
>>
>>  OvmfPkg/Csm/CsmSupportLib/LegacyRegion.c   | 62 ++--
>>  OvmfPkg/Csm/CsmSupportLib/LegacyRegion.h   | 22 +--
>>  OvmfPkg/Include/IndustryStandard/I440FxPiix4.h | 13 
>>  OvmfPkg/Include/IndustryStandard/Q35MchIch9.h  |  8 +++
>>  OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf  |  3 +-
>>  OvmfPkg/QemuVideoDxe/VbeShim.c | 47 ---
>>  6 files changed, 95 insertions(+), 60 deletions(-)
>>
>> -- 
>> 2.14.1.3.gb7cf6e02401b
>>

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v3 1/2] MdePkg: Add UDF volume structure definitions

[Paulo Alcantara]

This patch adds a few more UDF volume structures in order to detect an
UDF file system which is supported by current EDK2 UDF file system
implementation in Partition driver.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Laszlo Ersek 
Cc: Ruiyu Ni 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Paulo Alcantara 
---
 MdePkg/Include/IndustryStandard/Udf.h | 63 ++--
 1 file changed, 59 insertions(+), 4 deletions(-)

diff --git a/MdePkg/Include/IndustryStandard/Udf.h 
b/MdePkg/Include/IndustryStandard/Udf.h
index 0febb4bcda..002e87e150 100644
--- a/MdePkg/Include/IndustryStandard/Udf.h
+++ b/MdePkg/Include/IndustryStandard/Udf.h
@@ -24,11 +24,28 @@
 #define UDF_LOGICAL_SECTOR_SIZE   ((UINT64)(1ULL << UDF_LOGICAL_SECTOR_SHIFT))
 #define UDF_VRS_START_OFFSET  ((UINT64)(16ULL << UDF_LOGICAL_SECTOR_SHIFT))
 
-#define _GET_TAG_ID(_Pointer) \
-  (((UDF_DESCRIPTOR_TAG *)(_Pointer))->TagIdentifier)
+typedef enum {
+  UdfPrimaryVolumeDescriptor = 1,
+  UdfAnchorVolumeDescriptorPointer = 2,
+  UdfVolumeDescriptorPointer = 3,
+  UdfImplemenationUseVolumeDescriptor = 4,
+  UdfPartitionDescriptor = 5,
+  UdfLogicalVolumeDescriptor = 6,
+  UdfUnallocatedSpaceDescriptor = 7,
+  UdfTerminatingDescriptor = 8,
+  UdfLogicalVolumeIntegrityDescriptor = 9,
+  UdfFileSetDescriptor = 256,
+  UdfFileIdentifierDescriptor = 257,
+  UdfAllocationExtentDescriptor = 258,
+  UdfFileEntry = 261,
+  UdfExtendedFileEntry = 266,
+} UDF_VOLUME_DESCRIPTOR_ID;
 
-#define IS_AVDP(_Pointer) \
-  ((BOOLEAN)(_GET_TAG_ID (_Pointer) == 2))
+#define UDF_TAG_ID(_Tag) \
+  (UDF_VOLUME_DESCRIPTOR_ID)((_Tag)->TagIdentifier)
+
+#define UDF_LVD_REVISION(_Lv) \
+  *(UINT16 *)(UINTN)(_Lv)->DomainIdentifier.IdentifierSuffix
 
 #pragma pack(1)
 
@@ -49,12 +66,50 @@ typedef struct {
 } UDF_EXTENT_AD;
 
 typedef struct {
+  UINT8   CharacterSetType;
+  UINT8   CharacterSetInfo[63];
+} UDF_CHAR_SPEC;
+
+typedef struct {
+  UINT8   Flags;
+  UINT8   Identifier[23];
+  UINT8   IdentifierSuffix[8];
+} UDF_ENTITY_ID;
+
+typedef struct {
+  UINT32LogicalBlockNumber;
+  UINT16PartitionReferenceNumber;
+} UDF_LB_ADDR;
+
+typedef struct {
+  UINT32   ExtentLength;
+  UDF_LB_ADDR  ExtentLocation;
+  UINT8ImplementationUse[6];
+} UDF_LONG_ALLOCATION_DESCRIPTOR;
+
+typedef struct {
   UDF_DESCRIPTOR_TAG  DescriptorTag;
   UDF_EXTENT_AD   MainVolumeDescriptorSequenceExtent;
   UDF_EXTENT_AD   ReserveVolumeDescriptorSequenceExtent;
   UINT8   Reserved[480];
 } UDF_ANCHOR_VOLUME_DESCRIPTOR_POINTER;
 
+typedef struct {
+  UDF_DESCRIPTOR_TAG  DescriptorTag;
+  UINT32  VolumeDescriptorSequenceNumber;
+  UDF_CHAR_SPEC   DescriptorCharacterSet;
+  UINT8   LogicalVolumeIdentifier[128];
+  UINT32  LogicalBlockSize;
+  UDF_ENTITY_ID   DomainIdentifier;
+  UDF_LONG_ALLOCATION_DESCRIPTOR  LogicalVolumeContentsUse;
+  UINT32  MapTableLength;
+  UINT32  NumberOfPartitionMaps;
+  UDF_ENTITY_ID   ImplementationIdentifier;
+  UINT8   ImplementationUse[128];
+  UDF_EXTENT_AD   IntegritySequenceExtent;
+  UINT8   PartitionMaps[6];
+} UDF_LOGICAL_VOLUME_DESCRIPTOR;
+
 #pragma pack()
 
 #endif
-- 
2.11.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v3 2/2] MdeModulePkg/PartitionDxe: Fix creation of UDF logical partition

[Paulo Alcantara]

Do not reserve entire block device size for an UDF file system -
instead, reserve the appropriate space (UDF logical volume space) for
it.

Additionally, only create a logical partition for UDF logical volumes
that are currently supported by EDK2 UDF file system implementation. For
instance, an UDF volume with a single LVD and a single Physical (Type 1)
Partition will be supported.

Cc: Eric Dong 
Cc: Ruiyu Ni 
Cc: Star Zeng 
Cc: Laszlo Ersek 
Reported-by: Ruiyu Ni 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Paulo Alcantara 
---
 MdeModulePkg/Universal/Disk/PartitionDxe/Udf.c| 363 ++--
 MdeModulePkg/Universal/Disk/UdfDxe/File.c |  16 +-
 MdeModulePkg/Universal/Disk/UdfDxe/FileSystemOperations.c | 627 

 MdeModulePkg/Universal/Disk/UdfDxe/Udf.c  |   7 -
 MdeModulePkg/Universal/Disk/UdfDxe/Udf.h  | 158 ++---
 5 files changed, 606 insertions(+), 565 deletions(-)

diff --git a/MdeModulePkg/Universal/Disk/PartitionDxe/Udf.c 
b/MdeModulePkg/Universal/Disk/PartitionDxe/Udf.c
index 609f56cef6..572ba7a81a 100644
--- a/MdeModulePkg/Universal/Disk/PartitionDxe/Udf.c
+++ b/MdeModulePkg/Universal/Disk/PartitionDxe/Udf.c
@@ -64,11 +64,12 @@ FindAnchorVolumeDescriptorPointer (
   OUT  UDF_ANCHOR_VOLUME_DESCRIPTOR_POINTER  *AnchorPoint
   )
 {
-  EFI_STATUS  Status;
-  UINT32  BlockSize;
-  EFI_LBA EndLBA;
-  EFI_LBA DescriptorLBAs[4];
-  UINTN   Index;
+  EFI_STATUS  Status;
+  UINT32  BlockSize;
+  EFI_LBA EndLBA;
+  EFI_LBA DescriptorLBAs[4];
+  UINTN   Index;
+  UDF_DESCRIPTOR_TAG  *DescriptorTag;
 
   BlockSize = BlockIo->Media->BlockSize;
   EndLBA = BlockIo->Media->LastBlock;
@@ -88,10 +89,13 @@ FindAnchorVolumeDescriptorPointer (
 if (EFI_ERROR (Status)) {
   return Status;
 }
+
+DescriptorTag = >DescriptorTag;
+
 //
 // Check if read LBA has a valid AVDP descriptor.
 //
-if (IS_AVDP (AnchorPoint)) {
+if (DescriptorTag->TagIdentifier == UdfAnchorVolumeDescriptorPointer) {
   return EFI_SUCCESS;
 }
   }
@@ -102,23 +106,18 @@ FindAnchorVolumeDescriptorPointer (
 }
 
 /**
-  Check if block device supports a valid UDF file system as specified by OSTA
-  Universal Disk Format Specification 2.60.
+  Find UDF volume identifiers in a Volume Recognition Sequence.
 
-  @param[in]   BlockIo  BlockIo interface.
-  @param[in]   DiskIo   DiskIo interface.
+  @param[in]  BlockIo BlockIo interface.
+  @param[in]  DiskIo  DiskIo interface.
 
-  @retval EFI_SUCCESS  UDF file system found.
-  @retval EFI_UNSUPPORTED  UDF file system not found.
-  @retval EFI_NO_MEDIA The device has no media.
-  @retval EFI_DEVICE_ERROR The device reported an error.
-  @retval EFI_VOLUME_CORRUPTED The file system structures are corrupted.
-  @retval EFI_OUT_OF_RESOURCES The scan was not successful due to lack of
-   resources.
+  @retval EFI_SUCCESS UDF volume identifiers were found.
+  @retval EFI_NOT_FOUND   UDF volume identifiers were not found.
+  @retval other   Failed to perform disk I/O.
 
 **/
 EFI_STATUS
-SupportUdfFileSystem (
+FindUdfVolumeIdentifiers (
   IN EFI_BLOCK_IO_PROTOCOL  *BlockIo,
   IN EFI_DISK_IO_PROTOCOL   *DiskIo
   )
@@ -128,7 +127,6 @@ SupportUdfFileSystem (
   UINT64EndDiskOffset;
   CDROM_VOLUME_DESCRIPTOR   VolDescriptor;
   CDROM_VOLUME_DESCRIPTOR   TerminatingVolDescriptor;
-  UDF_ANCHOR_VOLUME_DESCRIPTOR_POINTER  AnchorPoint;
 
   ZeroMem ((VOID *), sizeof 
(CDROM_VOLUME_DESCRIPTOR));
 
@@ -167,7 +165,7 @@ SupportUdfFileSystem (
 (CompareMem ((VOID *),
  (VOID *),
  sizeof (CDROM_VOLUME_DESCRIPTOR)) == 0)) {
-  return EFI_UNSUPPORTED;
+  return EFI_NOT_FOUND;
 }
   }
 
@@ -176,7 +174,7 @@ SupportUdfFileSystem (
   //
   Offset += UDF_LOGICAL_SECTOR_SIZE;
   if (Offset >= EndDiskOffset) {
-return EFI_UNSUPPORTED;
+return EFI_NOT_FOUND;
   }
 
   Status = DiskIo->ReadDisk (
@@ -196,7 +194,7 @@ SupportUdfFileSystem (
   (CompareMem ((VOID *)VolDescriptor.Unknown.Id,
(VOID *)UDF_NSR3_IDENTIFIER,
sizeof (VolDescriptor.Unknown.Id)) != 0)) {
-return EFI_UNSUPPORTED;
+return EFI_NOT_FOUND;
   }
 
   //
@@ -204,7 +202,7 @@ SupportUdfFileSystem (
   //
   Offset += UDF_LOGICAL_SECTOR_SIZE;
   if (Offset >= EndDiskOffset) {
-return EFI_UNSUPPORTED;
+return EFI_NOT_FOUND;
   }
 
   Status = DiskIo->ReadDisk (
@@ -221,15 +219,291 @@ SupportUdfFileSystem (
   if (CompareMem ((VOID *)VolDescriptor.Unknown.Id,
   (VOID *)UDF_TEA_IDENTIFIER,
   sizeof 

[edk2] [PATCH v3 0/2] UDF partition driver fix

[Paulo Alcantara]

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=707

Hi,

This patchset fixes a bug in Partition driver that created UDF logical
partitions by using entire block device space and thus polluting
protocol database with broken handles.

v1->v2:
 - Followed Laszlo's suggestions to submit a proper patchset. Thanks!
 - As I'm still waiting for Ruiyu and Star to test this fix, I took
   advantage of it and did some code cleanups :-)

v2->v3:
 - Followed Ruiyu's suggestions to improve code and add additional
   checks for ensuring a valid UDF file system and supported by current
   EDK2 UDF file system implementation. Also run Ecc.py to make sure the
   files I touched did not break EDK2 C Coding Style, as well as
   PatchCheck.py for mal-formed patches.

I've had a chance to test these changes with my 32GiB USB stick
and formatted it on Windows 10 with `format` command. The UDF revisions
I tested (by specifying it with "/R:revision") were 1.02, 1.50, 2.00,
2.01 (default) and 2.50. They all worked except the 2.50 revision which
adds a Type 2 (Metadata) Partition and it's not supported by current
EDK2 UDF implementation -- which handles only Type 1 (Physical)
Partitions. The UDF 2.60 revision I tested with the usual
`sudo mkudffs -b 512 --media-type=hd /dev/sdX` command in Linux.

Remember, the *officially* supported revision is 2.60, however all
revisions use the same volume structures as defined by ECMA 167
specification, and they usually differ from each other by means of
new optional features, so that's why all those revisions worked with
this implementation.

Well, at least this what I understood when looking at the
specifications. Please correct me if I'm wrong.

Please, test building these changes in toolchains other than GCC and
make sure they don't break the world :-)

Thanks!
Paulo

Repo:   https://github.com/pcacjr/edk2.git
Branch: udf-partition-fix-v3

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Laszlo Ersek 
Cc: Ruiyu Ni 
Cc: Star Zeng 
Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.1
Reported-by: Ruiyu Ni 
Signed-off-by: Paulo Alcantara 
---

Paulo Alcantara (2):
  MdePkg: Add UDF volume structure definitions
  MdeModulePkg/PartitionDxe: Fix creation of UDF logical partition

 MdeModulePkg/Universal/Disk/PartitionDxe/Udf.c| 363 ++--
 MdeModulePkg/Universal/Disk/UdfDxe/File.c |  16 +-
 MdeModulePkg/Universal/Disk/UdfDxe/FileSystemOperations.c | 627 

 MdeModulePkg/Universal/Disk/UdfDxe/Udf.c  |   7 -
 MdeModulePkg/Universal/Disk/UdfDxe/Udf.h  | 158 ++---
 MdePkg/Include/IndustryStandard/Udf.h |  63 +-
 6 files changed, 665 insertions(+), 569 deletions(-)

-- 
2.11.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC 0/6] Create central repository for boilerplate configuration

[Laszlo Ersek]

On 09/20/17 19:27, Leif Lindholm wrote:
> An awful lot of platform configuration is just repeated verbatim for
> every platform. This is my first stab at eliminating some of this
> redundancy.
> 
> I have additional bits as work in progress, but before I sink too much
> time into it, I would like to try to gather feedback on this approach
> (all the way down to directory structure).
> 
> This first round deals with basic network support and Secure Boot
> requirements.

I can't comment on the general "ConfigPkg" question, and the directory
structure; I'll just assume that it's OK that way. (It will need
documented maintainers though.)

I do have some initial comments:

(1) Please update your git config so that the diff hunk headers display
the INI-style section name that's being modified. Please search the
following sections for "ini":

https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers#contrib-05

https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers#contrib-09

Normally this is plain "helpful" for reviewers, but given the subject of
this set, I'd say it's "important" (to me as a reviewer anyway), to see
what section lines are removed from.

(2) Replacing a build define called FOOBAR with CONFIG_FOOBAR will break
all downstream build scripts. Is the CONFIG_ prefix a requirement?

(3) I think PCDs should not be included in ConfigPkg DSC include files,
even if several platforms set the same value. The set of libraries and
driver modules commonly used for a given feature is mostly constant
across platforms (and it is easy to extend, incrementally); but I don't
think the same holds for PCDs. Especially if a user wants to change a
PCD for one platform but not the other. Even if repeated settings for a
PCD worked (all on the same level of "specificity"), I'd find the result
confusing.

(4) The Ia32X64 build of OVMF is a bit trickier than the rest; DXE
modules should be built for X64, while PEI modules should be built for
IA32. You can see this in the names of the [Components.IA32] and
[Components.X64] sections. (Point (1) above helps with this.)

For example, in patch #1 you add "ArpDxe" to [Components], but in patch
#3 you remove it from [Components.X64].

(5) In patch #4, there's a section for [LibraryClasses.ARM,
LibraryClasses.AARCH64] -- why is it specific to ARM/AARCH64?


If others like the ConfigPkg idea, I'd like to review the set (or v2)
again, in more detail, but for that, please fix the patch formatting
first, as requested in (1).

Thanks!
Laszlo

> 
> Leif Lindholm (6):
>   ConfigPkg: add new package for holding common config fragments
>   ArmVirtPkg: use ConfigPkg for common network items
>   OvmfPkg: use ConfigPkg for common network items
>   ConfigPkg: add common Security settings
>   ArmVirtPkg: use ConfigPkg for common security items
>   OvmfPkg: use ConfigPkg for common security items
> 
>  ArmVirtPkg/ArmVirt.dsc.inc   | 25 ++
>  ArmVirtPkg/ArmVirtQemu.dsc   | 46 +++---
>  ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc | 24 ++
>  ArmVirtPkg/ArmVirtQemuKernel.dsc | 46 +++---
>  ConfigPkg/Network/Network.dsc.inc| 92 
> 
>  ConfigPkg/Network/Network.fdf.inc| 47 ++
>  ConfigPkg/Security/Security.dsc.inc  | 67 ++
>  ConfigPkg/Security/Security.fdf.inc  | 17 +++
>  OvmfPkg/OvmfPkgIa32.dsc  | 92 
> 
>  OvmfPkg/OvmfPkgIa32.fdf  | 37 +--
>  OvmfPkg/OvmfPkgIa32X64.dsc   | 90 ---
>  OvmfPkg/OvmfPkgIa32X64.fdf   | 37 +--
>  OvmfPkg/OvmfPkgX64.dsc   | 92 
> 
>  OvmfPkg/OvmfPkgX64.fdf   | 37 +--
>  14 files changed, 276 insertions(+), 473 deletions(-)
>  create mode 100644 ConfigPkg/Network/Network.dsc.inc
>  create mode 100644 ConfigPkg/Network/Network.fdf.inc
>  create mode 100644 ConfigPkg/Security/Security.dsc.inc
>  create mode 100644 ConfigPkg/Security/Security.fdf.inc
> 

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/3] OvmfPkg/QemuVideoDxe/VbeShim: handle PAM1 register on Q35 correctly

[Jordan Justen]

Series Reviewed-by: Jordan Justen 

On 2017-09-19 12:18:12, Laszlo Ersek wrote:
> Repo:   https://github.com/lersek/edk2.git
> Branch: vbe_shim_q35_pam
> 
> Fix the long-standing OVMF/Q35 bug recently exposed by a QEMU change,
> and reported under .
> 
> Aleksei, can you please fetch the branch, build it, and report back with
> your Tested-by if it works for you?
> 
> I performed my own tests as well; I'll include those in a separate
> email.
> 
> Cc: Aleksei Kovura 
> Cc: Gerd Hoffmann 
> Cc: Igor Mammedov 
> Cc: Jordan Justen 
> Cc: Ruiyu Ni 
> 
> Thank you,
> Laszlo
> 
> Laszlo Ersek (3):
>   OvmfPkg/CsmSupportLib: move PAM register addresses to IndustryStandard
>   OvmfPkg/QemuVideoDxe/VbeShim: rename Status to
> Segment0AllocationStatus
>   OvmfPkg/QemuVideoDxe/VbeShim: handle PAM1 register on Q35 correctly
> 
>  OvmfPkg/Csm/CsmSupportLib/LegacyRegion.c   | 62 ++--
>  OvmfPkg/Csm/CsmSupportLib/LegacyRegion.h   | 22 +--
>  OvmfPkg/Include/IndustryStandard/I440FxPiix4.h | 13 
>  OvmfPkg/Include/IndustryStandard/Q35MchIch9.h  |  8 +++
>  OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf  |  3 +-
>  OvmfPkg/QemuVideoDxe/VbeShim.c | 47 ---
>  6 files changed, 95 insertions(+), 60 deletions(-)
> 
> -- 
> 2.14.1.3.gb7cf6e02401b
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Storing Non volatile variables on SD/NAND

[Andrew Fish]

> On Sep 20, 2017, at 10:39 AM, Ard Biesheuvel  
> wrote:
> 
> On 20 September 2017 at 10:39, Ard Biesheuvel  
> wrote:
>> On 20 September 2017 at 10:34, Udit Kumar  wrote:
>>> 
>>> When we want to have UEFI and OS accessing same media ,
>>> Possibilities I see
>>> 
>>> 1- Patch OS For status check of media (diversion from generic OS), Good 
>>> case will be modify low level driver.
>>> But we may end up some surprises on synchronization.
>>> 
>>> 2- no runtime service for OS . I guess this will not be possible
>>> 
>>> 3- Way the  Vladimir implemented for eMMC, This has risk of losing data in 
>>> case of AC power off.
>>> 
>>> 4- update hardware with dual view (Ard suggestion)
>>> 
>> 
>> 5 - abstract direct block device access into a firmware service that
>> is exposed via a DXE_RUNTIME_DRIVER.
>> 
>> The UEFI spec allows you to expose entry points into a
>> DXE_RUNTIME_DRIVER module via a UEFI configuration table, and the OS
>> can use a driver that uses the abstracted device rather than the real
>> device. Performance is going to be terrible, probably, and lots of
>> things that are specific to SD/MMC will no longer work, but it is a
>> possibility nonetheless.
> 
> BTW this would go beyond the UEFI spec, and would effectively be a
> PI/UEFI dependent feature.

The concept of a runtime EFI driver is in the UEFI spec, but the issue is there 
is no way to tell the OS to not bind it's driver for that device that is 
universal. If you boot an unmodified OS it is going to conflict with the EFI 
runtime service. 

My gut feel is if the OS has a driver for the device it may be better to make 
the media format the architectural point. That way the OS can read/write it via 
a driver/app. There could be an UEFI Services Table entry that implies what 
scheme is being used. That way there is only every one owner of the hardware 
device. I assume #3 is like this?

Thanks,

Andrew Fish

> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Storing Non volatile variables on SD/NAND

[Ard Biesheuvel]

On 20 September 2017 at 10:39, Ard Biesheuvel  wrote:
> On 20 September 2017 at 10:34, Udit Kumar  wrote:
>>
>> When we want to have UEFI and OS accessing same media ,
>> Possibilities I see
>>
>> 1- Patch OS For status check of media (diversion from generic OS), Good case 
>> will be modify low level driver.
>> But we may end up some surprises on synchronization.
>>
>> 2- no runtime service for OS . I guess this will not be possible
>>
>> 3- Way the  Vladimir implemented for eMMC, This has risk of losing data in 
>> case of AC power off.
>>
>> 4- update hardware with dual view (Ard suggestion)
>>
>
> 5 - abstract direct block device access into a firmware service that
> is exposed via a DXE_RUNTIME_DRIVER.
>
> The UEFI spec allows you to expose entry points into a
> DXE_RUNTIME_DRIVER module via a UEFI configuration table, and the OS
> can use a driver that uses the abstracted device rather than the real
> device. Performance is going to be terrible, probably, and lots of
> things that are specific to SD/MMC will no longer work, but it is a
> possibility nonetheless.

BTW this would go beyond the UEFI spec, and would effectively be a
PI/UEFI dependent feature.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Storing Non volatile variables on SD/NAND

[Ard Biesheuvel]

On 20 September 2017 at 10:34, Udit Kumar  wrote:
>
> When we want to have UEFI and OS accessing same media ,
> Possibilities I see
>
> 1- Patch OS For status check of media (diversion from generic OS), Good case 
> will be modify low level driver.
> But we may end up some surprises on synchronization.
>
> 2- no runtime service for OS . I guess this will not be possible
>
> 3- Way the  Vladimir implemented for eMMC, This has risk of losing data in 
> case of AC power off.
>
> 4- update hardware with dual view (Ard suggestion)
>

5 - abstract direct block device access into a firmware service that
is exposed via a DXE_RUNTIME_DRIVER.

The UEFI spec allows you to expose entry points into a
DXE_RUNTIME_DRIVER module via a UEFI configuration table, and the OS
can use a driver that uses the abstracted device rather than the real
device. Performance is going to be terrible, probably, and lots of
things that are specific to SD/MMC will no longer work, but it is a
possibility nonetheless.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Storing Non volatile variables on SD/NAND

[Andrew Fish]

Pankaj,

We understand the use cases. We just don't have a good solution for the spec 
that is OS, Firmware, and hardware agnostic. 

Thanks,

Andrew Fish

> On Sep 20, 2017, at 7:51 AM, Pankaj Bansal  wrote:
> 
> This use case also arises for single-board systems like raspberry-pi, which 
> do not have an onboard flash.
> The boot firmware/bootloader as well as operating system are loaded from SD 
> card.
> https://www.raspberrypi.org/documentation/configuration/config-txt/
> 
> Thanks & Regards,
> Pankaj Bansal
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Andrew 
> Fish
> Sent: Wednesday, September 20, 2017 10:48 AM
> To: Udit Kumar 
> Cc: edk2-devel@lists.01.org; Vladimir Olovyannikov 
> ; olivier.mar...@arm.com; Ard Biesheuvel 
> 
> Subject: Re: [edk2] Storing Non volatile variables on SD/NAND
> 
> 
>> On Sep 19, 2017, at 10:09 PM, Udit Kumar  wrote:
>> 
 On Sep 19, 2017, at 9:27 PM, Udit Kumar  wrote:
 
 
> On 18 September 2017 at 22:28, Udit Kumar  wrote:
>> Thanks Vladimir,
>> With your design, you did delayed write to eMMC due to sharing 
>> with OS.  But it works for you:) Say if eMMC controllers offers 
>> you a status bit, if eMMC storage is being used for not. Then this 
>> could be possible to
> update at run time, both OS/UEFI needs to check and wait if 
> controller is being used.
> 
> That is the problem right there. The nice thing about a firmware 
> spec is that you don't have to care about how it was implemented if 
> you adhere to
>>> the API rules.
 
 Yup, we are fine as long as long UEFI firmware is stored on dedicated 
 media.
 
> Imposing additional restrictions (such as requiring the OS to be 
> careful about not using the eMMC when it may be in use by the
> firmware) defeats the purpose of using UEFI, since you won't be 
> able to use a
>>> generic OS anyway.
> 
 
 Hmm,  so far, I haven't come across where UEFI specs says, we need a 
 separate Storage for firmware. (May be I missed some part of specs) 
 Irrespective of storage media, we have this problem if OS and UEFI 
 shares same storage.
 
>>> 
>>> Udit,
>>> 
>>> Can you point out the spec that states you can't boot Linux and 
>>> Windows at the same time on a PC? :)
>>> 
>>> When you write a spec it is not practical do document what is not 
>>> possible, you can only document the API the rest is implied by the 
>>> implementation. So for example the UEFI spec does not document why 
>>> the firmware and OS can't share a hardware device, just like you 
>>> can't have 2 operating systems running on bare metal at the same 
>>> time. It is a little like Occam's Razor the reason that the firmware 
>>> and the OS can not share a hardware device is the mechanics of how to 
>>> share a hardware device is not defined in the spec, thus it is not part of 
>>> the API and not possible.
>> 
>> Right,  This is left on implementation how to put firmware and OS.
>> Ideally, keeping both storage separate  is best case, no need to sync 
>> between two.
>> 
>> My reply to Ard, was to highlight that in any case (NOR or eMMC /NAND) 
>> if we are keeping OS and firmware on same storage, we will have same 
>> issue not limited to  eMMC.
>> 
>> For some requirement, if we need to keep firmware and OS on same 
>> media, Then implementation should make sure there is exclusive access 
>> (be it NOR controller, SD controller etc).
>> 
> 
> Udit,
> 
> Sorry I'm a little swamped on my email right now and might be a little behind 
> on the thread
> 
> Yea the only way to realistically Implement an EFI runtime service in UEFI is 
> to have UEFI own the hardware device. There is no architecture for sharing 
> the device, and the type of device is not really relevant. 
> 
> Thanks,
> 
> Andrew Fish
> 
>> Thanks
>> Udit
>> 
>>> Thanks,
>>> 
>>> Andrew Fish
>>> 
>> For sure,  some synchronization issues need to be ironed out (or 
>> maybe I am
> just dreaming here).
>> 
>> On part 2) where you forked VariableRuntime driver , could we 
>> think of updating VariableRuntime driver, to support non-XIP or 
>> memory mapped
> devices.
>> 
> 
> I think being able to support non-memorymapped FV volumes for the 
> variable store would be a big improvement. This does require 
> changes to both the FaultTolerantWrite drivers and the 
> VariableRuntime drivers, which both appear in PEI, DXE and SMM 
> flavors, and require thorough review due to the security impact 
> bugs have in this layer, so this is a
>>> rather large chunk of work to take on.
 
 Thanks,  your list is longer than what I was thinking :-) I think, 
 for embedded world with UEFI, later or 

Re: [edk2] Storing Non volatile variables on SD/NAND

[Udit Kumar]

When we want to have UEFI and OS accessing same media , 
Possibilities I see 

1- Patch OS For status check of media (diversion from generic OS), Good case 
will be modify low level driver. 
But we may end up some surprises on synchronization.
 
2- no runtime service for OS . I guess this will not be possible

3- Way the  Vladimir implemented for eMMC, This has risk of losing data in case 
of AC power off. 

4- update hardware with dual view (Ard suggestion) 

Thanks to add, if I missed some option here. 

> This use case also arises for single-board systems like raspberry-pi, which 
> do not
> have an onboard flash.
> The boot firmware/bootloader as well as operating system are loaded from SD
> card.
> https://www.raspberrypi.org/documentation/configuration/config-txt/


Raspberry follow the different boot scheme.  What I think, Linux running on 
Raspberry/ARM is unware of UEFI boot. 

Copied text 
Stage 1 boot is in the on-chip ROM. Loads Stage 2 in the L2 cache
Stage 2 is bootcode.bin. Enables SDRAM and loads Stage 3
Stage 3 is loader.bin. It knows about the .elf format and loads start.elf
Stage 4: start.elf loads kernel.img. It then also reads config.txt, cmdline.txt 
and bcm2835.dtb If the dtb file exists, it is loaded at 0×100 & kernel @ 0×8000 
If disable_commandline_tags is set it loads kernel @ 0×0 Otherwise it loads 
kernel @ 0×8000 and put ATAGS at 0×100
Stage 5: kernel.img is then run on the ARM

I think up to stage 4, we have GPU . 
Here SD is exclusivity used by UEFI or OS. Any corrections ?  
 

Thanks
Udit

> -Original Message-
> From: Pankaj Bansal
> Sent: Wednesday, September 20, 2017 8:22 PM
> To: Andrew Fish ; Udit Kumar ; edk2-
> de...@lists.01.org
> Cc: Vladimir Olovyannikov ;
> olivier.mar...@arm.com; Ard Biesheuvel 
> Subject: RE: [edk2] Storing Non volatile variables on SD/NAND
> 
> This use case also arises for single-board systems like raspberry-pi, which 
> do not
> have an onboard flash.
> The boot firmware/bootloader as well as operating system are loaded from SD
> card.
> https://www.raspberrypi.org/documentation/configuration/config-txt/
> 
> Thanks & Regards,
> Pankaj Bansal
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Andrew Fish
> Sent: Wednesday, September 20, 2017 10:48 AM
> To: Udit Kumar 
> Cc: edk2-devel@lists.01.org; Vladimir Olovyannikov
> ; olivier.mar...@arm.com; Ard
> Biesheuvel 
> Subject: Re: [edk2] Storing Non volatile variables on SD/NAND
> 
> 
> > On Sep 19, 2017, at 10:09 PM, Udit Kumar  wrote:
> >
> >>> On Sep 19, 2017, at 9:27 PM, Udit Kumar  wrote:
> >>>
> >>>
>  On 18 September 2017 at 22:28, Udit Kumar 
> wrote:
> > Thanks Vladimir,
> > With your design, you did delayed write to eMMC due to sharing
> > with OS.  But it works for you:) Say if eMMC controllers offers
> > you a status bit, if eMMC storage is being used for not. Then this
> > could be possible to
>  update at run time, both OS/UEFI needs to check and wait if
>  controller is being used.
> 
>  That is the problem right there. The nice thing about a firmware
>  spec is that you don't have to care about how it was implemented if
>  you adhere to
> >> the API rules.
> >>>
> >>> Yup, we are fine as long as long UEFI firmware is stored on dedicated
> media.
> >>>
>  Imposing additional restrictions (such as requiring the OS to be
>  careful about not using the eMMC when it may be in use by the
>  firmware) defeats the purpose of using UEFI, since you won't be
>  able to use a
> >> generic OS anyway.
> 
> >>>
> >>> Hmm,  so far, I haven't come across where UEFI specs says, we need a
> >>> separate Storage for firmware. (May be I missed some part of specs)
> >>> Irrespective of storage media, we have this problem if OS and UEFI
> >>> shares same storage.
> >>>
> >>
> >> Udit,
> >>
> >> Can you point out the spec that states you can't boot Linux and
> >> Windows at the same time on a PC? :)
> >>
> >> When you write a spec it is not practical do document what is not
> >> possible, you can only document the API the rest is implied by the
> >> implementation. So for example the UEFI spec does not document why
> >> the firmware and OS can't share a hardware device, just like you
> >> can't have 2 operating systems running on bare metal at the same
> >> time. It is a little like Occam's Razor the reason that the firmware
> >> and the OS can not share a hardware device is the mechanics of how to
> >> share a hardware device is not defined in the spec, thus it is not part of 
> >> the
> API and not possible.
> >
> > Right,  This is left on implementation how to put firmware and OS.
> > Ideally, keeping both storage separate  is 

Re: [edk2] [PATCH] MdePkg: add ARM/AARCH64 support to BaseCacheMaintenanceLib

[Kinney, Michael D]

Leif,

Adding the ARM specific functions to the BaseLib to provide access 
to ARM specific CPU registers/instructions makes sense and is 
what has already been done for IA32/X64/IPF/EBC.

Put the arch specific content in BaseLib.h inside #if clauses.

#if defined (MDE_CPU_ARM)

#if defined (MDE_CPU_AARCH64)

Or for content shared by ARM and AARCH64 put in:

#if defined (MDE_CPU_ARM) || defined (MDE_CPU_AARCH64)

I see a few ARM and AARCH64 elements are already in BaseLib.h.

Best regards,

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On
> Behalf Of Leif Lindholm
> Sent: Wednesday, September 20, 2017 8:06 AM
> To: Gao, Liming 
> Cc: Kinney, Michael D ; edk2-
> de...@lists.01.org; Ard Biesheuvel 
> Subject: Re: [edk2] [PATCH] MdePkg: add ARM/AARCH64 support to
> BaseCacheMaintenanceLib
> 
> Hi Liming,
> 
> I understand the purity argument, but the situation (without
> this
> patch) is that:
> 1) There is a non-functional BaseCacheMaintenanceLib
> ARM/AARCH64
>implementation with misleading information in MdePkg.
> 2) ARM/AARCH64-based needs to include a different cache
> maintenance
>library than all other architectures. And they all need to
> include
>the same one.
> 
> 2 is an issue for the logical conclusion of the RFC series I am
> about
> to post for creating common include files for "boilerplate"
> bits of
> .dsf/.fdf files.
> 
> An alternative option would be to move ArmLib into MdePkg?
> A casual glance suggests to me that the corresponding X86
> features
> (like AsmWbinvd) are exposed via BaseLib. Would you see any
> issues
> with merging the ArmLib functionality into BaseLib?
> 
> Regards,
> 
> Leif
> 
> On Wed, Sep 20, 2017 at 02:45:30PM +, Gao, Liming wrote:
> > Leif:
> >   This change lets MdePkg BaseCacheMaintenanceLib depend on
> ArmPkg
> >   ArmLib. But, MdePkg is the basic package. It should not
> depend on
> >   other package. I suggest to add this ARM specific
> >   BaseCacheMaintenanceLib library instance into ArmPkg.
> >
> > Thanks
> > Liming
> > > -Original Message-
> > > From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> > > Sent: Wednesday, September 20, 2017 9:23 PM
> > > To: edk2-devel@lists.01.org
> > > Cc: Kinney, Michael D ; Gao,
> Liming ; Ard Biesheuvel
> > > 
> > > Subject: [PATCH] MdePkg: add ARM/AARCH64 support to
> BaseCacheMaintenanceLib
> > >
> > > ARM platforms have been using a separately located library
> in ArmPkg for
> > > high-level cache maintenance calls. Resolve this anomaly by
> overwriting
> > > ArmCache.c with the contents of
> > >
> ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c,
> and add
> > > the ArmLib dependency for the affected architectures.
> > >
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Leif Lindholm 
> > > ---
> > >
> > > The intent is to delete the ArmPkg version once no upstream
> platforms
> > > are using it.
> > >
> > >  MdePkg/Library/BaseCacheMaintenanceLib/ArmCache.c  | 222
> +
> > >  .../BaseCacheMaintenanceLib.inf|   2 +
> > >  2 files changed, 55 insertions(+), 169 deletions(-)
> > >
> > > diff --git
> a/MdePkg/Library/BaseCacheMaintenanceLib/ArmCache.c
> b/MdePkg/Library/BaseCacheMaintenanceLib/ArmCache.c
> > > index 79c84a0982..0759e38cd4 100644
> > > --- a/MdePkg/Library/BaseCacheMaintenanceLib/ArmCache.c
> > > +++ b/MdePkg/Library/BaseCacheMaintenanceLib/ArmCache.c
> > > @@ -1,67 +1,63 @@
> > >  /** @file
> > > -  Cache Maintenance Functions. These functions vary by ARM
> architecture so the MdePkg
> > > -  versions are null functions used to make sure things
> will compile.
> > >
> > > -  Copyright (c) 2006 - 2009, Intel Corporation. All rights
> reserved.
> > > -  Portions copyright (c) 2008 - 2009, Apple Inc. All
> rights reserved.
> > > +  Copyright (c) 2008 - 2009, Apple Inc. All rights
> reserved.
> > > +  Copyright (c) 2011 - 2014, ARM Limited. All rights
> reserved.
> > > +
> > >This program and the accompanying materials
> > >are licensed and made available under the terms and
> conditions of the BSD License
> > >which accompanies this distribution.  The full text of
> the license may be found at
> > > -  http://opensource.org/licenses/bsd-license.php.
> > > +  http://opensource.org/licenses/bsd-license.php
> > >
> > >THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN
> "AS IS" BASIS,
> > >WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND,
> EITHER EXPRESS OR IMPLIED.
> > >
> > >  **/
> > > -
> > > -//
> > > -// Include common header file for this module.
> > > -//
> > >  #include 
> > > +#include 
> > >  #include 
> > > +#include 
> > >
> > > -/**
> > > -  Invalidates the entire instruction cache in cache
> coherency domain of the
> > > -  calling CPU.

[edk2] [RFC 5/6] ArmVirtPkg: use ConfigPkg for common security items

[Leif Lindholm]

Remove boilerplate from the QEMU platforms by including
ConfigPkg/Security/Security.{dsc|fdf}.inc.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Leif Lindholm 
---
 ArmVirtPkg/ArmVirt.dsc.inc   | 19 +++
 ArmVirtPkg/ArmVirtQemu.dsc   | 12 ++--
 ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc |  1 +
 ArmVirtPkg/ArmVirtQemuKernel.dsc | 12 ++--
 4 files changed, 8 insertions(+), 36 deletions(-)

diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
index a9fdddcd6c..5c8be2d689 100644
--- a/ArmVirtPkg/ArmVirt.dsc.inc
+++ b/ArmVirtPkg/ArmVirt.dsc.inc
@@ -131,18 +131,9 @@
   #
   # Secure Boot dependencies
   #
-!if $(SECURE_BOOT_ENABLE) == TRUE
-  IntrinsicLib|CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf
-  OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
-  
TpmMeasurementLib|SecurityPkg/Library/DxeTpmMeasurementLib/DxeTpmMeasurementLib.inf
-  AuthVariableLib|SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf
-  BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
-
+!if $(CONFIG_SECURE_BOOT_ENABLE) == TRUE
   # re-use the UserPhysicalPresent() dummy implementation from the ovmf tree
   PlatformSecureLib|OvmfPkg/Library/PlatformSecureLib/PlatformSecureLib.inf
-!else
-  
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
-  
AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
 !endif
   VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
   
UefiBootManagerLib|MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
@@ -225,10 +216,6 @@
   
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
   CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
 
-!if $(SECURE_BOOT_ENABLE) == TRUE
-  BaseCryptLib|CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf
-!endif
-
 [LibraryClasses.ARM]
   ArmSoftFloatLib|ArmPkg/Library/ArmSoftFloatLib/ArmSoftFloatLib.inf
 
@@ -323,7 +310,7 @@
   gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory|0
   gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIMemoryNVS|0
   gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiReservedMemoryType|0
-!if $(SECURE_BOOT_ENABLE) == TRUE
+!if $(CONFIG_SECURE_BOOT_ENABLE) == TRUE
   gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesData|600
   gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesCode|400
   gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiBootServicesCode|1500
@@ -336,7 +323,7 @@
   gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiLoaderCode|20
   gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiLoaderData|0
 
-!if $(SECURE_BOOT_ENABLE) == TRUE
+!if $(CONFIG_SECURE_BOOT_ENABLE) == TRUE
   # override the default values from SecurityPkg to ensure images from all 
sources are verified in secure boot
   gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x04
   gEfiSecurityPkgTokenSpaceGuid.PcdFixedMediaImageVerificationPolicy|0x04
diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index 71d3fb252f..635309c346 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -36,10 +36,11 @@
   DEFINE CONFIG_HTTP_BOOT_ENABLE= FALSE
   DEFINE CONFIG_NETWORK_IP6_ENABLE  = FALSE
   DEFINE CONFIG_TLS_ENABLE  = FALSE
-  DEFINE SECURE_BOOT_ENABLE  = FALSE
+  DEFINE CONFIG_SECURE_BOOT_ENABLE  = FALSE
 
 !include ArmVirtPkg/ArmVirt.dsc.inc
 !include ConfigPkg/Network/Network.dsc.inc
+!include ConfigPkg/Security/Security.dsc.inc
 
 [LibraryClasses.common]
   ArmLib|ArmPkg/Library/ArmLib/ArmBaseLib.inf
@@ -257,15 +258,6 @@
 
   NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
   }
-!if $(SECURE_BOOT_ENABLE) == TRUE
-  MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf {
-
-  
NULL|SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.inf
-  }
-  SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
-!else
-  MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
-!endif
   MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
   MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
   
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
diff --git a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc 
b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
index 504fdf5fa9..9cff352416 100644
--- a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
+++ b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
@@ -45,6 +45,7 @@ READ_LOCK_CAP  = TRUE
 READ_LOCK_STATUS   = TRUE
 
 !include ConfigPkg/Network/Network.fdf.inc
+!include ConfigPkg/Security/Security.fdf.inc
 
   INF MdeModulePkg/Core/Dxe/DxeMain.inf
   INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc b/ArmVirtPkg/ArmVirtQemuKernel.dsc
index db62c1d611..59ad54c3fb 100644
--- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
+++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
@@ -35,11 +35,12 @@
   #
   

[edk2] [RFC 6/6] OvmfPkg: use ConfigPkg for common security items

[Leif Lindholm]

Remove boilerplate from the Ovmf platforms by including
ConfigPkg/Security/Security.{dsc|fdf}.inc.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Leif Lindholm 
---
 OvmfPkg/OvmfPkgIa32.dsc| 25 -
 OvmfPkg/OvmfPkgIa32.fdf|  4 +---
 OvmfPkg/OvmfPkgIa32X64.dsc | 23 +++
 OvmfPkg/OvmfPkgIa32X64.fdf |  4 +---
 OvmfPkg/OvmfPkgX64.dsc | 25 -
 OvmfPkg/OvmfPkgX64.fdf |  4 +---
 6 files changed, 14 insertions(+), 71 deletions(-)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 99175155a2..c450733d7c 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -36,8 +36,8 @@
   #
   DEFINE CONFIG_HTTP_BOOT_ENABLE= FALSE
   DEFINE CONFIG_NETWORK_IP6_ENABLE  = FALSE
+  DEFINE CONFIG_SECURE_BOOT_ENABLE  = FALSE
   DEFINE CONFIG_TLS_ENABLE  = FALSE
-  DEFINE SECURE_BOOT_ENABLE  = FALSE
   DEFINE SMM_REQUIRE = FALSE
 
   #
@@ -60,6 +60,7 @@
 !endif
 
 !include ConfigPkg/Network/Network.dsc.inc
+!include ConfigPkg/Security/Security.dsc.inc
 
 [BuildOptions]
   GCC:*_UNIXGCC_*_CC_FLAGS = -DMDEPKG_NDEBUG
@@ -164,13 +165,8 @@
 
   IntrinsicLib|CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf
 
-!if $(SECURE_BOOT_ENABLE) == TRUE
+!if $(CONFIG_SECURE_BOOT_ENABLE) == TRUE
   PlatformSecureLib|OvmfPkg/Library/PlatformSecureLib/PlatformSecureLib.inf
-  
TpmMeasurementLib|SecurityPkg/Library/DxeTpmMeasurementLib/DxeTpmMeasurementLib.inf
-  AuthVariableLib|SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf
-!else
-  
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
-  
AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
 !endif
   VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
 
@@ -460,7 +456,7 @@
   gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmStackSize|0x4000
 !endif
 
-!if $(SECURE_BOOT_ENABLE) == TRUE
+!if $(CONFIG_SECURE_BOOT_ENABLE) == TRUE
   gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x00
 !endif
 
@@ -585,15 +581,6 @@
 
   MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
 
-!if $(SECURE_BOOT_ENABLE) == TRUE
-  MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf {
-
-  
NULL|SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.inf
-   }
-!else
-  MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
-!endif
-
   MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
   PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
   UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
@@ -759,10 +746,6 @@
   }
 !endif
 
-!if $(SECURE_BOOT_ENABLE) == TRUE
-  SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
-!endif
-
   OvmfPkg/PlatformDxe/Platform.inf
   OvmfPkg/IoMmuDxe/IoMmuDxe.inf
 
diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
index 68438afc13..dfe4e78568 100644
--- a/OvmfPkg/OvmfPkgIa32.fdf
+++ b/OvmfPkg/OvmfPkgIa32.fdf
@@ -230,9 +230,7 @@ INF  OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
 INF  OvmfPkg/XenBusDxe/XenBusDxe.inf
 INF  OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
 
-!if $(SECURE_BOOT_ENABLE) == TRUE
-  INF  
SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
-!endif
+!include ConfigPkg/Security/Security.fdf.inc
 
 INF  MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
 INF  
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 0e4c86d5bc..106de22bdc 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -36,8 +36,8 @@
   #
   DEFINE CONFIG_HTTP_BOOT_ENABLE= FALSE
   DEFINE CONFIG_NETWORK_IP6_ENABLE  = FALSE
+  DEFINE CONFIG_SECURE_BOOT_ENABLE  = FALSE
   DEFINE CONFIG_TLS_ENABLE  = FALSE
-  DEFINE SECURE_BOOT_ENABLE  = FALSE
   DEFINE SMM_REQUIRE = FALSE
 
   #
@@ -60,6 +60,7 @@
 !endif
 
 !include ConfigPkg/Network/Network.dsc.inc
+!include ConfigPkg/Security/Security.dsc.inc
 
 [BuildOptions]
   GCC:*_UNIXGCC_*_CC_FLAGS = -DMDEPKG_NDEBUG
@@ -171,11 +172,6 @@
 
 !if $(SECURE_BOOT_ENABLE) == TRUE
   PlatformSecureLib|OvmfPkg/Library/PlatformSecureLib/PlatformSecureLib.inf
-  
TpmMeasurementLib|SecurityPkg/Library/DxeTpmMeasurementLib/DxeTpmMeasurementLib.inf
-  AuthVariableLib|SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf
-!else
-  
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
-  
AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
 !endif
   VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
 
@@ -466,7 +462,7 @@
   gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmStackSize|0x4000
 !endif
 
-!if $(SECURE_BOOT_ENABLE) == TRUE
+!if $(CONFIG_SECURE_BOOT_ENABLE) == TRUE
   gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x00
 !endif
 
@@ -594,15 +590,6 @@
 
   

[edk2] [RFC 0/6] Create central repository for boilerplate configuration

[Leif Lindholm]

An awful lot of platform configuration is just repeated verbatim for
every platform. This is my first stab at eliminating some of this
redundancy.

I have additional bits as work in progress, but before I sink too much
time into it, I would like to try to gather feedback on this approach
(all the way down to directory structure).

This first round deals with basic network support and Secure Boot
requirements.

Leif Lindholm (6):
  ConfigPkg: add new package for holding common config fragments
  ArmVirtPkg: use   ConfigPkg for common network items
  OvmfPkg: use ConfigPkg for common network items
  ConfigPkg: add common Security settings
  ArmVirtPkg: use ConfigPkg for common security items
  OvmfPkg: use ConfigPkg for common security items

 ArmVirtPkg/ArmVirt.dsc.inc   | 25 ++
 ArmVirtPkg/ArmVirtQemu.dsc   | 46 +++---
 ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc | 24 ++
 ArmVirtPkg/ArmVirtQemuKernel.dsc | 46 +++---
 ConfigPkg/Network/Network.dsc.inc| 92 
 ConfigPkg/Network/Network.fdf.inc| 47 ++
 ConfigPkg/Security/Security.dsc.inc  | 67 ++
 ConfigPkg/Security/Security.fdf.inc  | 17 +++
 OvmfPkg/OvmfPkgIa32.dsc  | 92 
 OvmfPkg/OvmfPkgIa32.fdf  | 37 +--
 OvmfPkg/OvmfPkgIa32X64.dsc   | 90 ---
 OvmfPkg/OvmfPkgIa32X64.fdf   | 37 +--
 OvmfPkg/OvmfPkgX64.dsc   | 92 
 OvmfPkg/OvmfPkgX64.fdf   | 37 +--
 14 files changed, 276 insertions(+), 473 deletions(-)
 create mode 100644 ConfigPkg/Network/Network.dsc.inc
 create mode 100644 ConfigPkg/Network/Network.fdf.inc
 create mode 100644 ConfigPkg/Security/Security.dsc.inc
 create mode 100644 ConfigPkg/Security/Security.fdf.inc

-- 
2.11.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [RFC 3/6] OvmfPkg: use ConfigPkg for common network items

[Leif Lindholm]

Remove boilerplate from the Ovmf platforms by including
ConfigPkg/Network/Network.{dsc|fdf}.inc.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Leif Lindholm 
---
 OvmfPkg/OvmfPkgIa32.dsc| 67 +-
 OvmfPkg/OvmfPkgIa32.fdf| 33 +--
 OvmfPkg/OvmfPkgIa32X64.dsc | 67 +-
 OvmfPkg/OvmfPkgIa32X64.fdf | 33 +--
 OvmfPkg/OvmfPkgX64.dsc | 67 +-
 OvmfPkg/OvmfPkgX64.fdf | 33 +--
 6 files changed, 21 insertions(+), 279 deletions(-)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 92e943d4a0..99175155a2 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -34,11 +34,11 @@
   # Defines for default states.  These can be changed on the command line.
   # -D FLAG=VALUE
   #
+  DEFINE CONFIG_HTTP_BOOT_ENABLE= FALSE
+  DEFINE CONFIG_NETWORK_IP6_ENABLE  = FALSE
+  DEFINE CONFIG_TLS_ENABLE  = FALSE
   DEFINE SECURE_BOOT_ENABLE  = FALSE
-  DEFINE NETWORK_IP6_ENABLE  = FALSE
-  DEFINE HTTP_BOOT_ENABLE= FALSE
   DEFINE SMM_REQUIRE = FALSE
-  DEFINE TLS_ENABLE  = FALSE
 
   #
   # Flash size selection. Setting FD_SIZE_IN_KB on the command line directly to
@@ -59,6 +59,8 @@
 !endif
 !endif
 
+!include ConfigPkg/Network/Network.dsc.inc
+
 [BuildOptions]
   GCC:*_UNIXGCC_*_CC_FLAGS = -DMDEPKG_NDEBUG
   GCC:RELEASE_*_*_CC_FLAGS = -DMDEPKG_NDEBUG
@@ -136,10 +138,6 @@
   FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
   UefiCpuLib|UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.inf
   
SecurityManagementLib|MdeModulePkg/Library/DxeSecurityManagementLib/DxeSecurityManagementLib.inf
-  NetLib|MdeModulePkg/Library/DxeNetLib/DxeNetLib.inf
-  IpIoLib|MdeModulePkg/Library/DxeIpIoLib/DxeIpIoLib.inf
-  UdpIoLib|MdeModulePkg/Library/DxeUdpIoLib/DxeUdpIoLib.inf
-  DpcLib|MdeModulePkg/Library/DxeDpcLib/DxeDpcLib.inf
   UefiUsbLib|MdePkg/Library/UefiUsbLib/UefiUsbLib.inf
   
SerializeVariablesLib|OvmfPkg/Library/SerializeVariablesLib/SerializeVariablesLib.inf
   QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgDxeLib.inf
@@ -165,11 +163,6 @@
   
DebugPrintErrorLevelLib|MdePkg/Library/BaseDebugPrintErrorLevelLib/BaseDebugPrintErrorLevelLib.inf
 
   IntrinsicLib|CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf
-!if $(TLS_ENABLE) == TRUE
-  OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLib.inf
-!else
-  OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
-!endif
 
 !if $(SECURE_BOOT_ENABLE) == TRUE
   PlatformSecureLib|OvmfPkg/Library/PlatformSecureLib/PlatformSecureLib.inf
@@ -181,18 +174,6 @@
 !endif
   VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
 
-!if $(NETWORK_IP6_ENABLE) == TRUE
-  TcpIoLib|MdeModulePkg/Library/DxeTcpIoLib/DxeTcpIoLib.inf
-!endif
-
-!if $(HTTP_BOOT_ENABLE) == TRUE
-  HttpLib|MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.inf
-!endif
-
-!if $(TLS_ENABLE) == TRUE
-  TlsLib|CryptoPkg/Library/TlsLib/TlsLib.inf
-!endif
-
   
S3BootScriptLib|MdeModulePkg/Library/PiDxeS3BootScriptLib/DxeS3BootScriptLib.inf
   SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
   
OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
@@ -471,10 +452,6 @@
   gEfiSourceLevelDebugPkgTokenSpaceGuid.PcdDebugLoadImageMethod|0x2
 !endif
 
-!if $(HTTP_BOOT_ENABLE) == TRUE
-  gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections|TRUE
-!endif
-
 !ifndef $(USE_OLD_SHELL)
   gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile|{ 0x83, 0xA5, 0x04, 
0x7C, 0x3E, 0x9E, 0x1C, 0x4F, 0xAD, 0x65, 0xE0, 0x52, 0x68, 0xD0, 0xB4, 0xD1 }
 !endif
@@ -731,38 +708,6 @@
   #
   # Network Support
   #
-  MdeModulePkg/Universal/Network/SnpDxe/SnpDxe.inf
-  MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf
-  MdeModulePkg/Universal/Network/MnpDxe/MnpDxe.inf
-  MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf
-  MdeModulePkg/Universal/Network/ArpDxe/ArpDxe.inf
-  MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Dxe.inf
-  MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf
-  MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf
-  MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Dxe.inf
-!if $(NETWORK_IP6_ENABLE) == TRUE
-  NetworkPkg/Ip6Dxe/Ip6Dxe.inf
-  NetworkPkg/TcpDxe/TcpDxe.inf
-  NetworkPkg/Udp6Dxe/Udp6Dxe.inf
-  NetworkPkg/Dhcp6Dxe/Dhcp6Dxe.inf
-  NetworkPkg/Mtftp6Dxe/Mtftp6Dxe.inf
-  NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf
-  NetworkPkg/IScsiDxe/IScsiDxe.inf
-!else
-  MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf
-  MdeModulePkg/Universal/Network/UefiPxeBcDxe/UefiPxeBcDxe.inf
-  MdeModulePkg/Universal/Network/IScsiDxe/IScsiDxe.inf
-!endif
-!if $(HTTP_BOOT_ENABLE) == TRUE
-  NetworkPkg/DnsDxe/DnsDxe.inf
-  NetworkPkg/HttpUtilitiesDxe/HttpUtilitiesDxe.inf
-  

[edk2] [RFC 4/6] ConfigPkg: add common Security settings

[Leif Lindholm]

Collate universal Secure Boot and crypto settings under Security/.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Leif Lindholm 
---
 ConfigPkg/Security/Security.dsc.inc | 67 +
 ConfigPkg/Security/Security.fdf.inc | 17 ++
 2 files changed, 84 insertions(+)
 create mode 100644 ConfigPkg/Security/Security.dsc.inc
 create mode 100644 ConfigPkg/Security/Security.fdf.inc

diff --git a/ConfigPkg/Security/Security.dsc.inc 
b/ConfigPkg/Security/Security.dsc.inc
new file mode 100644
index 00..88100c992d
--- /dev/null
+++ b/ConfigPkg/Security/Security.dsc.inc
@@ -0,0 +1,67 @@
+## @file
+#
+# Copyright (c) 2017, Linaro ltd. All rights reserved.
+#
+#  This program and the accompanying materials are licensed and made available
+#  under the terms and conditions of the BSD License which accompanies this
+#  distribution. The full text of the license may be found at
+#  http://opensource.org/licenses/bsd-license.php
+#
+#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+#
+##
+
+
+
+#
+# Library Class section
+#
+
+[LibraryClasses.common]
+!if $(CONFIG_SECURE_BOOT_ENABLE) == TRUE
+  AuthVariableLib|SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf
+  BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
+  IntrinsicLib|CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf
+  
TpmMeasurementLib|SecurityPkg/Library/DxeTpmMeasurementLib/DxeTpmMeasurementLib.inf
+#
+!else
+#
+  
AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
+  
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
+!endif
+
+[LibraryClasses.ARM, LibraryClasses.AARCH64]
+!if $(CONFIG_SECURE_BOOT_ENABLE) == TRUE
+  OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
+!endif
+
+[LibraryClasses.common.DXE_RUNTIME_DRIVER]
+!if $(CONFIG_SECURE_BOOT_ENABLE) == TRUE
+  BaseCryptLib|CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf
+!endif
+
+
+
+#
+# Pcd Section
+#
+
+[PcdsFeatureFlag]
+
+
+
+#
+# Components Section
+#
+
+[Components]
+!if $(CONFIG_SECURE_BOOT_ENABLE) == TRUE
+  MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf {
+
+  
NULL|SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.inf
+  }
+  SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
+!else
+  MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
+!endif
diff --git a/ConfigPkg/Security/Security.fdf.inc 
b/ConfigPkg/Security/Security.fdf.inc
new file mode 100644
index 00..2a75446c9b
--- /dev/null
+++ b/ConfigPkg/Security/Security.fdf.inc
@@ -0,0 +1,17 @@
+## @file
+#
+# Copyright (c) 2017, Linaro ltd. All rights reserved.
+#
+#  This program and the accompanying materials are licensed and made available
+#  under the terms and conditions of the BSD License which accompanies this
+#  distribution. The full text of the license may be found at
+#  http://opensource.org/licenses/bsd-license.php
+#
+#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+#
+##
+
+!if $(CONFIGURE_SECURE_BOOT_ENABLE) == TRUE
+  INF  
SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
+!endif
-- 
2.11.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [RFC 1/6] ConfigPkg: add new package for holding common config fragments

[Leif Lindholm]

Start with common networking options.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Leif Lindholm 
---
 ConfigPkg/Network/Network.dsc.inc | 92 +++
 ConfigPkg/Network/Network.fdf.inc | 47 
 2 files changed, 139 insertions(+)
 create mode 100644 ConfigPkg/Network/Network.dsc.inc
 create mode 100644 ConfigPkg/Network/Network.fdf.inc

diff --git a/ConfigPkg/Network/Network.dsc.inc 
b/ConfigPkg/Network/Network.dsc.inc
new file mode 100644
index 00..8c53350deb
--- /dev/null
+++ b/ConfigPkg/Network/Network.dsc.inc
@@ -0,0 +1,92 @@
+## @file
+#
+# Copyright (c) 2017, Linaro ltd. All rights reserved.
+#
+#  This program and the accompanying materials are licensed and made available
+#  under the terms and conditions of the BSD License which accompanies this
+#  distribution. The full text of the license may be found at
+#  http://opensource.org/licenses/bsd-license.php
+#
+#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+#
+##
+
+
+
+#
+# Library Class section
+#
+
+[LibraryClasses]
+  DpcLib|MdeModulePkg/Library/DxeDpcLib/DxeDpcLib.inf
+  IpIoLib|MdeModulePkg/Library/DxeIpIoLib/DxeIpIoLib.inf
+  NetLib|MdeModulePkg/Library/DxeNetLib/DxeNetLib.inf
+  UdpIoLib|MdeModulePkg/Library/DxeUdpIoLib/DxeUdpIoLib.inf
+
+!if $(CONFIG_HTTP_BOOT_ENABLE) == TRUE
+  HttpLib|MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.inf
+!endif
+
+!if $(CONFIG_NETWORK_IP6_ENABLE) == TRUE
+  BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
+  IntrinsicLib|CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf
+  TcpIoLib|MdeModulePkg/Library/DxeTcpIoLib/DxeTcpIoLib.inf
+!endif
+
+!if $(CONFIG_TLS_ENABLE) == TRUE
+  OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLib.inf
+  TlsLib|CryptoPkg/Library/TlsLib/TlsLib.inf
+!else
+  OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
+!endif
+
+
+#
+# Pcd Section
+#
+
+[PcdsFixedAtBuild]
+!if $(CONFIG_HTTP_BOOT_ENABLE) == TRUE
+  gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections|TRUE
+!endif
+
+
+
+#
+# Components Section
+#
+
+[Components]
+  MdeModulePkg/Universal/Network/ArpDxe/ArpDxe.inf
+  MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Dxe.inf
+  MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf
+  MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf
+  MdeModulePkg/Universal/Network/MnpDxe/MnpDxe.inf
+  MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf
+  MdeModulePkg/Universal/Network/SnpDxe/SnpDxe.inf
+  MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Dxe.inf
+  MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf
+!if $(CONFIG_NETWORK_IP6_ENABLE) == TRUE
+  NetworkPkg/Dhcp6Dxe/Dhcp6Dxe.inf
+  NetworkPkg/Ip6Dxe/Ip6Dxe.inf
+  NetworkPkg/IScsiDxe/IScsiDxe.inf
+  NetworkPkg/Mtftp6Dxe/Mtftp6Dxe.inf
+  NetworkPkg/TcpDxe/TcpDxe.inf
+  NetworkPkg/Udp6Dxe/Udp6Dxe.inf
+  NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf
+!else
+  MdeModulePkg/Universal/Network/IScsiDxe/IScsiDxe.inf
+  MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf
+  MdeModulePkg/Universal/Network/UefiPxeBcDxe/UefiPxeBcDxe.inf
+!endif
+!if $(CONFIG_HTTP_BOOT_ENABLE) == TRUE
+  NetworkPkg/DnsDxe/DnsDxe.inf
+  NetworkPkg/HttpBootDxe/HttpBootDxe.inf
+  NetworkPkg/HttpDxe/HttpDxe.inf
+  NetworkPkg/HttpUtilitiesDxe/HttpUtilitiesDxe.inf
+!endif
+!if $(CONFIG_TLS_ENABLE) == TRUE
+  NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf
+  NetworkPkg/TlsDxe/TlsDxe.inf
+!endif
diff --git a/ConfigPkg/Network/Network.fdf.inc 
b/ConfigPkg/Network/Network.fdf.inc
new file mode 100644
index 00..614fd18a9a
--- /dev/null
+++ b/ConfigPkg/Network/Network.fdf.inc
@@ -0,0 +1,47 @@
+## @file
+#
+# Copyright (c) 2017, Linaro ltd. All rights reserved.
+#
+#  This program and the accompanying materials are licensed and made available
+#  under the terms and conditions of the BSD License which accompanies this
+#  distribution. The full text of the license may be found at
+#  http://opensource.org/licenses/bsd-license.php
+#
+#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+#
+##
+
+
+  INF  MdeModulePkg/Universal/Network/ArpDxe/ArpDxe.inf
+  INF  MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Dxe.inf
+  INF  MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf
+  INF  MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf
+  INF  

[edk2] [RFC 2/6] ArmVirtPkg: use ConfigPkg for common network items

[Leif Lindholm]

Remove boilerplate from   the QEMU platforms by including
ConfigPkg/Network/Network.{dsc|fdf}.inc.

As a side effect, this enables support for building in IPv6 support,
by specifying -D CONFIG_NETWORK_IP6_ENABLE=TRUE.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Leif Lindholm 
---
 ArmVirtPkg/ArmVirt.dsc.inc   |  6 --
 ArmVirtPkg/ArmVirtQemu.dsc   | 34 --
 ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc | 23 ++-
 ArmVirtPkg/ArmVirtQemuKernel.dsc | 34 --
 4 files changed, 10 insertions(+), 87 deletions(-)

diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
index c92a69281a..a9fdddcd6c 100644
--- a/ArmVirtPkg/ArmVirt.dsc.inc
+++ b/ArmVirtPkg/ArmVirt.dsc.inc
@@ -71,12 +71,6 @@
   # use the accelerated BaseMemoryLibOptDxe by default, overrides for SEC/PEI 
below
   BaseMemoryLib|MdePkg/Library/BaseMemoryLibOptDxe/BaseMemoryLibOptDxe.inf
 
-  # Networking Requirements
-  NetLib|MdeModulePkg/Library/DxeNetLib/DxeNetLib.inf
-  DpcLib|MdeModulePkg/Library/DxeDpcLib/DxeDpcLib.inf
-  UdpIoLib|MdeModulePkg/Library/DxeUdpIoLib/DxeUdpIoLib.inf
-  IpIoLib|MdeModulePkg/Library/DxeIpIoLib/DxeIpIoLib.inf
-
   #
   # It is not possible to prevent the ARM compiler from inserting calls to 
intrinsic functions.
   # This library provides the instrinsic functions such a compiler may 
generate calls to.
diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index 8a60b61f2a..71d3fb252f 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -33,10 +33,13 @@
   # Defines for default states.  These can be changed on the command line.
   # -D FLAG=VALUE
   #
+  DEFINE CONFIG_HTTP_BOOT_ENABLE= FALSE
+  DEFINE CONFIG_NETWORK_IP6_ENABLE  = FALSE
+  DEFINE CONFIG_TLS_ENABLE  = FALSE
   DEFINE SECURE_BOOT_ENABLE  = FALSE
-  DEFINE HTTP_BOOT_ENABLE= FALSE
 
 !include ArmVirtPkg/ArmVirt.dsc.inc
+!include ConfigPkg/Network/Network.dsc.inc
 
 [LibraryClasses.common]
   ArmLib|ArmPkg/Library/ArmLib/ArmBaseLib.inf
@@ -64,10 +67,6 @@
   PciSegmentLib|MdePkg/Library/BasePciSegmentLibPci/BasePciSegmentLibPci.inf
   
PciHostBridgeLib|ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf
 
-!if $(HTTP_BOOT_ENABLE) == TRUE
-  HttpLib|MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.inf
-!endif
-
 [LibraryClasses.common.UEFI_DRIVER]
   UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
 
@@ -129,10 +128,6 @@
   #
   gArmTokenSpaceGuid.PcdArmArchTimerFreqInHz|0
 
-!if $(HTTP_BOOT_ENABLE) == TRUE
-  gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections|TRUE
-!endif
-
   # System Memory Base -- fixed at 0x4000_
   gArmTokenSpaceGuid.PcdSystemMemoryBase|0x4000
 
@@ -334,27 +329,6 @@
   }
 
   #
-  # Networking stack
-  #
-  MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf
-  MdeModulePkg/Universal/Network/ArpDxe/ArpDxe.inf
-  MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Dxe.inf
-  MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf
-  MdeModulePkg/Universal/Network/MnpDxe/MnpDxe.inf
-  MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf
-  MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf
-  MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf
-  MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Dxe.inf
-  MdeModulePkg/Universal/Network/UefiPxeBcDxe/UefiPxeBcDxe.inf
-  MdeModulePkg/Universal/Network/IScsiDxe/IScsiDxe.inf
-!if $(HTTP_BOOT_ENABLE) == TRUE
-  NetworkPkg/DnsDxe/DnsDxe.inf
-  NetworkPkg/HttpUtilitiesDxe/HttpUtilitiesDxe.inf
-  NetworkPkg/HttpDxe/HttpDxe.inf
-  NetworkPkg/HttpBootDxe/HttpBootDxe.inf
-!endif
-
-  #
   # SCSI Bus and Disk Driver
   #
   MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf
diff --git a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc 
b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
index 744006d13c..504fdf5fa9 100644
--- a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
+++ b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
@@ -44,6 +44,8 @@ READ_STATUS= TRUE
 READ_LOCK_CAP  = TRUE
 READ_LOCK_STATUS   = TRUE
 
+!include ConfigPkg/Network/Network.fdf.inc
+
   INF MdeModulePkg/Core/Dxe/DxeMain.inf
   INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
   INF ArmVirtPkg/VirtioFdtDxe/VirtioFdtDxe.inf
@@ -115,27 +117,6 @@ READ_LOCK_STATUS   = TRUE
   INF MdeModulePkg/Application/UiApp/UiApp.inf
 
   #
-  # Networking stack
-  #
-  INF MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf
-  INF MdeModulePkg/Universal/Network/ArpDxe/ArpDxe.inf
-  INF MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Dxe.inf
-  INF MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf
-  INF MdeModulePkg/Universal/Network/MnpDxe/MnpDxe.inf
-  INF MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf
-  INF MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf
-  INF MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf
-  INF MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Dxe.inf
-  INF 

Re: [edk2] [PATCH v2] CryptoPkg: Add new API to retrieve commonName of X.509 certificate

[Laszlo Ersek]

On 09/20/17 19:04, Long, Qin wrote:
> 
> 
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, September 21, 2017 12:38 AM
> To: Long, Qin ; Ye, Ting ; Zhang, Chao 
> B 
> Cc: edk2-devel@lists.01.org
> Subject: Re: [PATCH v2] CryptoPkg: Add new API to retrieve commonName of 
> X.509 certificate
> 
> Hello Qin,
> 
> On 09/20/17 18:05, Qin Long wrote:
>> v2: Update function interface to return RETURN_STATUS to represent
>> different error cases.
>>
>> Add one new API (X509GetCommonName()) to retrieve the subject commonName
>> string from one X.509 certificate.
>>
>> Cc: Laszlo Ersek >
>> Cc: Ting Ye >
>> Cc: Chao Zhang >
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Qin Long >
>> ---
>>  CryptoPkg/Application/Cryptest/RsaVerify2.c|  32 +--
>>  CryptoPkg/Include/Library/BaseCryptLib.h   |  34 +++
>>  CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c  | 106 
>> +
>>  CryptoPkg/Library/BaseCryptLib/Pk/CryptX509Null.c  |  32 +++
>>  .../Pk/CryptX509Null.c |  34 ++-
>>  5 files changed, 230 insertions(+), 8 deletions(-)
>>
>> diff --git a/CryptoPkg/Include/Library/BaseCryptLib.h 
>> b/CryptoPkg/Include/Library/BaseCryptLib.h
>> index 9c5ffcd9cf..48e9531758 100644
>> --- a/CryptoPkg/Include/Library/BaseCryptLib.h
>> +++ b/CryptoPkg/Include/Library/BaseCryptLib.h
>> @@ -2171,6 +2171,40 @@ X509GetSubjectName (
>>IN OUT  UINTN*SubjectSize
>>);
>>
>> +/**
>> +  Retrieve the common name (CN) string from one X.509 certificate.
>> +
>> +  @param[in]  Cert Pointer to the DER-encoded X509 
>> certificate.
>> +  @param[in]  CertSize Size of the X509 certificate in bytes.
>> +  @param[out] CommonName   Buffer to contain the retrieved 
>> certificate common
>> +   name string. At most CommonNameSize 
>> bytes will be
>> +   written and the string will be null 
>> terminated. May be
>> +   NULL in order to determine the size 
>> buffer needed.
>> +  @param[in,out]  CommonNameSize   The size in bytes of the CommonName 
>> buffer on input,
>> +   and the size of buffer returned 
>> CommonName on output.
>> +   If CommonName is NULL then the amount of 
>> space needed
>> +   in buffer (including the final null) is 
>> returned.
>> +
>> +  @retval RETURN_SUCCESS   The certificate CommonName retrieved 
>> successfully.
>> +  @retval RETURN_INVALID_PARAMETER If Cert is NULL.
>> +   If CommonNameSize is NULL.
>> +   If Certificate is invalid.
>> +  @retval RETURN_NOT_FOUND If no CommonName entry exists.
>> +  @retval RETURN_BUFFER_TOO_SMALL  If the CommonName is NULL. The required 
>> buffer size
>> +   (including the final null) is returned 
>> in the
>> +   CommonNameSize parameter.
>> +  @retval RETURN_UNSUPPORTED   The operation is not supported.
>> +
>> +**/
>> +RETURN_STATUS
>> +EFIAPI
>> +X509GetCommonName (
>> +  IN  CONST UINT8  *Cert,
>> +  IN  UINTNCertSize,
>> +  OUT CHAR8*CommonName,
>> +  IN OUT  UINTN*CommonNameSize
>> +  );
>> +
>>  /**
>>Verify one X509 certificate was issued by the trusted CA.
>>
> 
> I think the RETURN_BUFFER_TOO_SMALL description is incorrect -- it
> shouldn't only cover the (CommonName == NULL) case, but any other case
> when *CommonNameSize is not large enough, for formatting the full CN,
> plus the terminating '\0'.
> 
> Relatedly, the output value of *CommonNameSize should always be the
> number of bytes required to format the NUL-terminated common name,
> regardless if there is enough room or not. The return status will tell
> the caller:
> - if the return status is BUFFER_TOO_SMALL, then a larger buffer is
> needed -- how large is explained by *CommonNameSize
> - if the return status is SUCCESS, then the buffer was large enough, and
> *CommonNameSize bytes have been used from it.
> 
> [qlong] good catch.
> The current implementation is based on OpenSSL X509_NAME_get_text_by_OBJ
> API, and we can only get the real written data size or required size (by 
> passing
> NULL CommonName) with this interface.
> I didn’t want to introduce additional handling (e.g. extra ASN1_STRING 
> parsing) in
> this API. For fixed CommonNameSize buffer, it’s acceptable to receive the 
> truncated
> string (e.g. for display purpose) depending on the API usage (and the CN 
> string should
> be less than 64 char per the 

Re: [edk2] [PATCH v2] CryptoPkg: Add new API to retrieve commonName of X.509 certificate

[Long, Qin]

From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Thursday, September 21, 2017 12:38 AM
To: Long, Qin ; Ye, Ting ; Zhang, Chao B 

Cc: edk2-devel@lists.01.org
Subject: Re: [PATCH v2] CryptoPkg: Add new API to retrieve commonName of X.509 
certificate

Hello Qin,

On 09/20/17 18:05, Qin Long wrote:
> v2: Update function interface to return RETURN_STATUS to represent
> different error cases.
>
> Add one new API (X509GetCommonName()) to retrieve the subject commonName
> string from one X.509 certificate.
>
> Cc: Laszlo Ersek >
> Cc: Ting Ye >
> Cc: Chao Zhang >
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Qin Long >
> ---
>  CryptoPkg/Application/Cryptest/RsaVerify2.c|  32 +--
>  CryptoPkg/Include/Library/BaseCryptLib.h   |  34 +++
>  CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c  | 106 
> +
>  CryptoPkg/Library/BaseCryptLib/Pk/CryptX509Null.c  |  32 +++
>  .../Pk/CryptX509Null.c |  34 ++-
>  5 files changed, 230 insertions(+), 8 deletions(-)
>
> diff --git a/CryptoPkg/Include/Library/BaseCryptLib.h 
> b/CryptoPkg/Include/Library/BaseCryptLib.h
> index 9c5ffcd9cf..48e9531758 100644
> --- a/CryptoPkg/Include/Library/BaseCryptLib.h
> +++ b/CryptoPkg/Include/Library/BaseCryptLib.h
> @@ -2171,6 +2171,40 @@ X509GetSubjectName (
>IN OUT  UINTN*SubjectSize
>);
>
> +/**
> +  Retrieve the common name (CN) string from one X.509 certificate.
> +
> +  @param[in]  Cert Pointer to the DER-encoded X509 
> certificate.
> +  @param[in]  CertSize Size of the X509 certificate in bytes.
> +  @param[out] CommonName   Buffer to contain the retrieved 
> certificate common
> +   name string. At most CommonNameSize bytes 
> will be
> +   written and the string will be null 
> terminated. May be
> +   NULL in order to determine the size 
> buffer needed.
> +  @param[in,out]  CommonNameSize   The size in bytes of the CommonName 
> buffer on input,
> +   and the size of buffer returned 
> CommonName on output.
> +   If CommonName is NULL then the amount of 
> space needed
> +   in buffer (including the final null) is 
> returned.
> +
> +  @retval RETURN_SUCCESS   The certificate CommonName retrieved 
> successfully.
> +  @retval RETURN_INVALID_PARAMETER If Cert is NULL.
> +   If CommonNameSize is NULL.
> +   If Certificate is invalid.
> +  @retval RETURN_NOT_FOUND If no CommonName entry exists.
> +  @retval RETURN_BUFFER_TOO_SMALL  If the CommonName is NULL. The required 
> buffer size
> +   (including the final null) is returned in 
> the
> +   CommonNameSize parameter.
> +  @retval RETURN_UNSUPPORTED   The operation is not supported.
> +
> +**/
> +RETURN_STATUS
> +EFIAPI
> +X509GetCommonName (
> +  IN  CONST UINT8  *Cert,
> +  IN  UINTNCertSize,
> +  OUT CHAR8*CommonName,
> +  IN OUT  UINTN*CommonNameSize
> +  );
> +
>  /**
>Verify one X509 certificate was issued by the trusted CA.
>

I think the RETURN_BUFFER_TOO_SMALL description is incorrect -- it
shouldn't only cover the (CommonName == NULL) case, but any other case
when *CommonNameSize is not large enough, for formatting the full CN,
plus the terminating '\0'.

Relatedly, the output value of *CommonNameSize should always be the
number of bytes required to format the NUL-terminated common name,
regardless if there is enough room or not. The return status will tell
the caller:
- if the return status is BUFFER_TOO_SMALL, then a larger buffer is
needed -- how large is explained by *CommonNameSize
- if the return status is SUCCESS, then the buffer was large enough, and
*CommonNameSize bytes have been used from it.

[qlong] good catch.
The current implementation is based on OpenSSL X509_NAME_get_text_by_OBJ
API, and we can only get the real written data size or required size (by passing
NULL CommonName) with this interface.
I didn’t want to introduce additional handling (e.g. extra ASN1_STRING parsing) 
in
this API. For fixed CommonNameSize buffer, it’s acceptable to receive the 
truncated
string (e.g. for display purpose) depending on the API usage (and the CN string 
should
be less than 64 char per the standard).

Additional question: does the code handle the case when *CommonNameSize
is zero, on input? (I.e., when there isn't even room for storing a '\0'
character.)

[qlong] It’s one missed 

Re: [edk2] [PATCH v2] CryptoPkg: Add new API to retrieve commonName of X.509 certificate

[Laszlo Ersek]

Hello Qin,

On 09/20/17 18:05, Qin Long wrote:
> v2: Update function interface to return RETURN_STATUS to represent
> different error cases.
> 
> Add one new API (X509GetCommonName()) to retrieve the subject commonName
> string from one X.509 certificate.
> 
> Cc: Laszlo Ersek 
> Cc: Ting Ye 
> Cc: Chao Zhang 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Qin Long 
> ---
>  CryptoPkg/Application/Cryptest/RsaVerify2.c|  32 +--
>  CryptoPkg/Include/Library/BaseCryptLib.h   |  34 +++
>  CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c  | 106 
> +
>  CryptoPkg/Library/BaseCryptLib/Pk/CryptX509Null.c  |  32 +++
>  .../Pk/CryptX509Null.c |  34 ++-
>  5 files changed, 230 insertions(+), 8 deletions(-)
> 
> diff --git a/CryptoPkg/Include/Library/BaseCryptLib.h 
> b/CryptoPkg/Include/Library/BaseCryptLib.h
> index 9c5ffcd9cf..48e9531758 100644
> --- a/CryptoPkg/Include/Library/BaseCryptLib.h
> +++ b/CryptoPkg/Include/Library/BaseCryptLib.h
> @@ -2171,6 +2171,40 @@ X509GetSubjectName (
>IN OUT  UINTN*SubjectSize
>);
>  
> +/**
> +  Retrieve the common name (CN) string from one X.509 certificate.
> +
> +  @param[in]  Cert Pointer to the DER-encoded X509 
> certificate.
> +  @param[in]  CertSize Size of the X509 certificate in bytes.
> +  @param[out] CommonName   Buffer to contain the retrieved 
> certificate common
> +   name string. At most CommonNameSize bytes 
> will be
> +   written and the string will be null 
> terminated. May be
> +   NULL in order to determine the size 
> buffer needed.
> +  @param[in,out]  CommonNameSize   The size in bytes of the CommonName 
> buffer on input,
> +   and the size of buffer returned 
> CommonName on output.
> +   If CommonName is NULL then the amount of 
> space needed
> +   in buffer (including the final null) is 
> returned.
> +
> +  @retval RETURN_SUCCESS   The certificate CommonName retrieved 
> successfully.
> +  @retval RETURN_INVALID_PARAMETER If Cert is NULL.
> +   If CommonNameSize is NULL.
> +   If Certificate is invalid.
> +  @retval RETURN_NOT_FOUND If no CommonName entry exists.
> +  @retval RETURN_BUFFER_TOO_SMALL  If the CommonName is NULL. The required 
> buffer size
> +   (including the final null) is returned in 
> the 
> +   CommonNameSize parameter.
> +  @retval RETURN_UNSUPPORTED   The operation is not supported.
> +
> +**/
> +RETURN_STATUS
> +EFIAPI
> +X509GetCommonName (
> +  IN  CONST UINT8  *Cert,
> +  IN  UINTNCertSize,
> +  OUT CHAR8*CommonName,
> +  IN OUT  UINTN*CommonNameSize
> +  );
> +
>  /**
>Verify one X509 certificate was issued by the trusted CA.
>  

I think the RETURN_BUFFER_TOO_SMALL description is incorrect -- it
shouldn't only cover the (CommonName == NULL) case, but any other case
when *CommonNameSize is not large enough, for formatting the full CN,
plus the terminating '\0'.

Relatedly, the output value of *CommonNameSize should always be the
number of bytes required to format the NUL-terminated common name,
regardless if there is enough room or not. The return status will tell
the caller:
- if the return status is BUFFER_TOO_SMALL, then a larger buffer is
needed -- how large is explained by *CommonNameSize
- if the return status is SUCCESS, then the buffer was large enough, and
*CommonNameSize bytes have been used from it.

Additional question: does the code handle the case when *CommonNameSize
is zero, on input? (I.e., when there isn't even room for storing a '\0'
character.)

Thanks,
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] NVME DXE Driver and PATA SS

[david moheban]

Hi,

Is the PATA SS message that comes up in the bios boot menu when you insert
the NVME Express DXE driver from Edk2 into one's firmware by design or a
side-effect of the system not identifying the new device correctly?

Thank you
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/2] Use PCD for Watchdog count

[Leif Lindholm]

Arvind, Daniil, Thomas - any comments?

I have no objections to this changeset.

/
Leif

On Mon, Sep 18, 2017 at 03:53:42PM +0100, evan.ll...@arm.com wrote:
> From: EvanLloyd 
> 
> Paired patches for edk2 and edk2-platforms that add and use a PCD
> indicating the number of SBSA Watchdog timers present.  This makes
> things more configurable, and is consistent with other examples of
> platform characteristics. It may also help with debates over GTDT
> inclusion (or not) of secure timers.
> 
> Sami Mujawar (1):
>   ArmPlatformPkg: Add PCD for SBSA Watchdog Count
> 
>  ArmPlatformPkg/ArmPlatformPkg.dec   | 4 +++-
>  ArmPlatformPkg/ArmJunoPkg/Include/ArmPlatform.h | 4 ++--
>  2 files changed, 5 insertions(+), 3 deletions(-)
> 
> Sami Mujawar (1):
>   Platforms/ARM: SBSA Watchdog PCD and build option
> 
>  Platform/ARM/JunoPkg/ArmJuno.dsc |  7 ++-
>  Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc |  7 ++-
>  Platform/ARM/JunoPkg/AcpiTables/AcpiTables.inf   |  4 +++-
>  Platform/ARM/VExpressPkg/AcpiTables/AcpiTables.inf   |  4 +++-
>  Platform/ARM/JunoPkg/AcpiTables/Gtdt.aslc|  6 +-
>  Platform/ARM/VExpressPkg/AcpiTables/Gtdt.aslc| 14 +++---
>  6 files changed, 34 insertions(+), 8 deletions(-)
> 
> -- 
> Guid("CE165669-3EF3-493F-B85D-6190EE5B9759")
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2] CryptoPkg: Add new API to retrieve commonName of X.509 certificate

[Qin Long]

v2: Update function interface to return RETURN_STATUS to represent
different error cases.

Add one new API (X509GetCommonName()) to retrieve the subject commonName
string from one X.509 certificate.

Cc: Laszlo Ersek 
Cc: Ting Ye 
Cc: Chao Zhang 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qin Long 
---
 CryptoPkg/Application/Cryptest/RsaVerify2.c|  32 +--
 CryptoPkg/Include/Library/BaseCryptLib.h   |  34 +++
 CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c  | 106 +
 CryptoPkg/Library/BaseCryptLib/Pk/CryptX509Null.c  |  32 +++
 .../Pk/CryptX509Null.c |  34 ++-
 5 files changed, 230 insertions(+), 8 deletions(-)

diff --git a/CryptoPkg/Application/Cryptest/RsaVerify2.c 
b/CryptoPkg/Application/Cryptest/RsaVerify2.c
index 98b5aad900..9db43d6eef 100644
--- a/CryptoPkg/Application/Cryptest/RsaVerify2.c
+++ b/CryptoPkg/Application/Cryptest/RsaVerify2.c
@@ -204,13 +204,17 @@ ValidateCryptRsa2 (
   VOID
   )
 {
-  BOOLEAN  Status;
-  VOID *RsaPrivKey;
-  VOID *RsaPubKey;
-  UINT8*Signature;
-  UINTNSigSize;
-  UINT8*Subject;
-  UINTNSubjectSize;
+  BOOLEANStatus;
+  VOID   *RsaPrivKey;
+  VOID   *RsaPubKey;
+  UINT8  *Signature;
+  UINTN  SigSize;
+  UINT8  *Subject;
+  UINTN  SubjectSize;
+  RETURN_STATUS  ReturnStatus;
+  CHAR8  CommonName[64];
+  CHAR16 CommonNameUnicode[64];
+  UINTN  CommonNameSize;
 
   Print (L"\nUEFI-OpenSSL RSA Key Retrieving Testing: ");
 
@@ -286,6 +290,20 @@ ValidateCryptRsa2 (
 Print (L"[Pass]");
   }
 
+  //
+  // Get CommonName from X509 Certificate Subject
+  //
+  CommonNameSize = 64;
+  ZeroMem (CommonName, CommonNameSize);
+  ReturnStatus = X509GetCommonName (TestCert, sizeof (TestCert), CommonName, 
);
+  if (RETURN_ERROR (ReturnStatus)) {
+Print (L"\n  - Retrieving Common Name - [Fail]");
+return EFI_ABORTED;
+  } else {
+AsciiStrToUnicodeStrS (CommonName, CommonNameUnicode, CommonNameSize);
+Print (L"\n  - Retrieving Common Name = \"%s\" (Size = %d)", 
CommonNameUnicode, CommonNameSize);
+  }
+
   //
   // X509 Certificate Verification.
   //
diff --git a/CryptoPkg/Include/Library/BaseCryptLib.h 
b/CryptoPkg/Include/Library/BaseCryptLib.h
index 9c5ffcd9cf..48e9531758 100644
--- a/CryptoPkg/Include/Library/BaseCryptLib.h
+++ b/CryptoPkg/Include/Library/BaseCryptLib.h
@@ -2171,6 +2171,40 @@ X509GetSubjectName (
   IN OUT  UINTN*SubjectSize
   );
 
+/**
+  Retrieve the common name (CN) string from one X.509 certificate.
+
+  @param[in]  Cert Pointer to the DER-encoded X509 certificate.
+  @param[in]  CertSize Size of the X509 certificate in bytes.
+  @param[out] CommonName   Buffer to contain the retrieved certificate 
common
+   name string. At most CommonNameSize bytes 
will be
+   written and the string will be null 
terminated. May be
+   NULL in order to determine the size buffer 
needed.
+  @param[in,out]  CommonNameSize   The size in bytes of the CommonName buffer 
on input,
+   and the size of buffer returned CommonName 
on output.
+   If CommonName is NULL then the amount of 
space needed
+   in buffer (including the final null) is 
returned.
+
+  @retval RETURN_SUCCESS   The certificate CommonName retrieved 
successfully.
+  @retval RETURN_INVALID_PARAMETER If Cert is NULL.
+   If CommonNameSize is NULL.
+   If Certificate is invalid.
+  @retval RETURN_NOT_FOUND If no CommonName entry exists.
+  @retval RETURN_BUFFER_TOO_SMALL  If the CommonName is NULL. The required 
buffer size
+   (including the final null) is returned in 
the 
+   CommonNameSize parameter.
+  @retval RETURN_UNSUPPORTED   The operation is not supported.
+
+**/
+RETURN_STATUS
+EFIAPI
+X509GetCommonName (
+  IN  CONST UINT8  *Cert,
+  IN  UINTNCertSize,
+  OUT CHAR8*CommonName,
+  IN OUT  UINTN*CommonNameSize
+  );
+
 /**
   Verify one X509 certificate was issued by the trusted CA.
 
diff --git a/CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c 
b/CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c
index 7d275977c5..c3cf97b262 100644
--- a/CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c
+++ b/CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c
@@ -297,6 +297,112 @@ _Exit:
   return Status;
 }
 
+/**
+  Retrieve the common name (CN) string from one X.509 certificate.
+
+  @param[in]  Cert Pointer to the DER-encoded X509 certificate.
+  @param[in]  CertSize Size of 

Re: [edk2] [PATCH 1/1] ArmPkg/ArmSvcLib: Add ArmSvcLib implementation.

[Supreeth Venkatesh]

On Tue, 2017-09-19 at 13:14 -0700, Ard Biesheuvel wrote:
> Hi Supreeth,
> 
> On 19 September 2017 at 12:55, Supreeth Venkatesh
>  wrote:
> > 
> > This patch adds a library that enables invocation of SVCs from
> > Exception
> > Level EL0. It will be used by the Standalone MM environment to
> > request
> > services from a software running in a privileged EL e.g. ARM
> > Trusted
> > Firmware. The library is a derived directly from Arm SMC Library.
> > 
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Achin Gupta 
> > Signed-off-by: Supreeth Venkatesh 
> > ---
> >  ArmPkg/Library/ArmSvcLib/AArch64/ArmSvc.S | 41
> > 
> >  ArmPkg/Library/ArmSvcLib/Arm/ArmSvc.S | 52
> > +++
> >  ArmPkg/Library/ArmSvcLib/Arm/ArmSvc.asm   | 51
> > ++
> >  ArmPkg/Library/ArmSvcLib/ArmSvcLib.inf| 31 ++
> Please add this library to the [Components] section of ArmPkg.dsc so
> it gets built when we build that package.
> 
> Also, it appears the header file is missing, although I suppose it
> could be part of a separate patch. However, this is 1/1 and it's
> missing from this patch.
Ard,

Thank you for reviewing it.

I intended to send ArmPkg.dsc and header changes as a separate patch.
However, if you want it as part of this series, I can do that as well.
> 
> 
> > 
> >  4 files changed, 175 insertions(+)
> >  create mode 100644 ArmPkg/Library/ArmSvcLib/AArch64/ArmSvc.S
> >  create mode 100644 ArmPkg/Library/ArmSvcLib/Arm/ArmSvc.S
> >  create mode 100644 ArmPkg/Library/ArmSvcLib/Arm/ArmSvc.asm
> >  create mode 100644 ArmPkg/Library/ArmSvcLib/ArmSvcLib.inf
> > 
> > diff --git a/ArmPkg/Library/ArmSvcLib/AArch64/ArmSvc.S
> > b/ArmPkg/Library/ArmSvcLib/AArch64/ArmSvc.S
> > new file mode 100644
> > index 00..70122bbb0e
> > --- /dev/null
> > +++ b/ArmPkg/Library/ArmSvcLib/AArch64/ArmSvc.S
> > @@ -0,0 +1,41 @@
> > +//
> > +//  Copyright (c) 2012 - 2017, ARM Limited. All rights reserved.
> > +//
> > +//  This program and the accompanying materials
> > +//  are licensed and made available under the terms and conditions
> > of the BSD License
> > +//  which accompanies this distribution.  The full text of the
> > license may be found at
> > +//  http://opensource.org/licenses/bsd-license.php
> > +//
> > +//  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> > BASIS,
> > +//  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> > EXPRESS OR IMPLIED.
> > +//
> > +//
> > +
> > +.text
> > +.align 3
> > +
> > +GCC_ASM_EXPORT(ArmCallSvc)
> > +
> > +ASM_PFX(ArmCallSvc):
> > +  // Push x0 on the stack - The stack must always be quad-word
> > aligned
> > +  str   x0, [sp, #-16]!
> > +
> Please create a proper stackframe here, by pushing the frame pointer
> and return address to the stack as well. You should always do that
> when you use the stack, even if the return address and frame pointer
> are not corrupted by this function.
Can do. However, this is a direct replica of ArmSmcLib. Let me know if
you want me to send a patch to reflect the above changes in ArmSmcLib
as well.
> 
> > 
> > +  // Load the SVC arguments values into the appropriate registers
> > +  ldp   x6, x7, [x0, #48]
> > +  ldp   x4, x5, [x0, #32]
> > +  ldp   x2, x3, [x0, #16]
> > +  ldp   x0, x1, [x0, #0]
> > +
> > +  svc   #0
> > +
> > +  // Pop the ARM_SVC_ARGS structure address from the stack into x9
> > +  ldr   x9, [sp], #16
> > +
> > +  // Store the SVC returned values into the ARM_SVC_ARGS
> > structure.
> > +  // A SVC call can return up to 4 values - we do not need to
> > store back x4-x7.
> > +  stp   x2, x3, [x9, #16]
> > +  stp   x0, x1, [x9, #0]
> > +
> Nit: no reason to do the stores in opposite order here.
Agree. Can change it to reflect ascending register order.
> 
> > 
> > +  mov   x0, x9
> > +
> > +  ret
> > diff --git a/ArmPkg/Library/ArmSvcLib/Arm/ArmSvc.S
> > b/ArmPkg/Library/ArmSvcLib/Arm/ArmSvc.S
> > new file mode 100644
> > index 00..a7ac2966c3
> > --- /dev/null
> > +++ b/ArmPkg/Library/ArmSvcLib/Arm/ArmSvc.S
> > @@ -0,0 +1,52 @@
> > +//
> > +//  Copyright (c) 2016 - 2017, ARM Limited. All rights reserved.
> > +//
> > +//  This program and the accompanying materials
> > +//  are licensed and made available under the terms and conditions
> > of the BSD License
> > +//  which accompanies this distribution.  The full text of the
> > license may be found at
> > +//  http://opensource.org/licenses/bsd-license.php
> > +//
> > +//  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> > BASIS,
> > +//  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> > EXPRESS OR IMPLIED.
> > +//
> > +//
> > +
> > +.text
> > +.align 3
> > +.arch_extension sec
> > +
> > +GCC_ASM_EXPORT(ArmCallSvc)
> > +
> > +ASM_PFX(ArmCallSvc):
> > +push{r4-r8}
> > +// r0 will be popped just after the SVC call
> > +push

[edk2] [Patch][edk2-platforms/devel-MinnowBoard3-UDK2017] Calibrate PMIC IMON.

[zwei4]

Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: zwei4 
---
 .../PlatformPostMemPei/PlatformInit.c  | 76 ++
 .../PlatformSettings/PlatformSetupDxe/UnCore.vfi   |  6 +-
 .../BroxtonSiPkg/NorthCluster/Include/SaRegs.h |  8 ++-
 3 files changed, 86 insertions(+), 4 deletions(-)

diff --git 
a/Platform/BroxtonPlatformPkg/Common/PlatformSettings/PlatformPostMemPei/PlatformInit.c
 
b/Platform/BroxtonPlatformPkg/Common/PlatformSettings/PlatformPostMemPei/PlatformInit.c
index bfed3bf1a..66b0e49f4 100644
--- 
a/Platform/BroxtonPlatformPkg/Common/PlatformSettings/PlatformPostMemPei/PlatformInit.c
+++ 
b/Platform/BroxtonPlatformPkg/Common/PlatformSettings/PlatformPostMemPei/PlatformInit.c
@@ -311,6 +311,80 @@ BXTPolicyInit (
   return EFI_SUCCESS;
 }
 
+VOID
+ConfigurePmicIMON (
+  VOID
+  )
+{
+  UINTN   PciD0F0RegBase = 0;
+  UINTN   MchBar = 0;
+  UINT32  Data;
+  UINT16  StallCount;
+  UINT64  PkgPwrSKU;
+
+  PciD0F0RegBase  = MmPciAddress (0,SA_MC_BUS,SA_MC_DEV,SA_MC_FUN,0);
+  MchBar  = MmioRead32 (PciD0F0RegBase + R_SA_MCHBAR_REG) &~BIT0;
+  PkgPwrSKU   = AsmReadMsr64 (MSR_PACKAGE_POWER_SKU);
+
+  StallCount = 0;
+  while (StallCount < 1000) {
+Data = MmioRead32 (MchBar + R_BIOS_MAILBOX_INTERFACE);
+if ((Data & BIT31) == BIT31) {
+  MicroSecondDelay (1); 
+} else {
+  break;
+}
+StallCount++;
+  }
+  MmioWrite32 ( (MchBar + R_BIOS_MAILBOX_DATA), 0xfa0d04a4);
+  MmioWrite32 ( (MchBar + R_BIOS_MAILBOX_INTERFACE), 0x811d);
+
+  StallCount = 0;
+  while (StallCount < 1000) {
+Data = MmioRead32 (MchBar + R_BIOS_MAILBOX_INTERFACE);
+if ((Data & BIT31) == BIT31) {
+  MicroSecondDelay (1);
+} else {
+  break;
+}
+StallCount++;
+  }
+
+  if ((PkgPwrSKU & 0x07FFF) >= 0x0903){
+MmioWrite32 ( (MchBar + R_BIOS_MAILBOX_DATA), 0xe8330466);
+MmioWrite32 ( (MchBar + R_BIOS_MAILBOX_INTERFACE), 0x801d);
+  } else { 
+MmioWrite32 ( (MchBar + R_BIOS_MAILBOX_DATA), 0xed3303b3);
+MmioWrite32 ( (MchBar + R_BIOS_MAILBOX_INTERFACE), 0x801d);
+  }
+
+}
 
 /**
   Platform Init PEI module entry point
@@ -363,6 +437,8 @@ PlatformInitEntryPoint (
   }
 
   PWM_Fan_Start ();
+  
+  ConfigurePmicIMON();
 
   //
   // Initialize PlatformInfo HOB
diff --git 
a/Platform/BroxtonPlatformPkg/Common/PlatformSettings/PlatformSetupDxe/UnCore.vfi
 
b/Platform/BroxtonPlatformPkg/Common/PlatformSettings/PlatformSetupDxe/UnCore.vfi
index 32eea2005..f8b4b47ec 100644
--- 
a/Platform/BroxtonPlatformPkg/Common/PlatformSettings/PlatformSetupDxe/UnCore.vfi
+++ 
b/Platform/BroxtonPlatformPkg/Common/PlatformSettings/PlatformSetupDxe/UnCore.vfi
@@ -1,7 +1,7 @@
 // /** @file
 //  UnCore Setup formset.
 //
-//  Copyright (c) 1999 - 2016, Intel Corporation. All rights reserved.
+//  Copyright (c) 1999 - 2017, Intel Corporation. All rights reserved.
 //
 //  This program and the accompanying materials
 //  are licensed and made available under the terms and conditions of the BSD 
License
@@ -104,8 +104,8 @@ form formid = UNCORE_FORM_ID,
   oneof varid = Setup.EnableRenderStandby,
prompt   = STRING_TOKEN(STR_VIDEO_RS2_PROMPT),
help = STRING_TOKEN(STR_VIDEO_RS2_HELP),
-   option text = STRING_TOKEN(STR_ENABLE), value = 1, flags = DEFAULT | 
MANUFACTURING | RESET_REQUIRED;
-   option text = STRING_TOKEN(STR_DISABLE), value = 0, flags = RESET_REQUIRED;
+   option text = STRING_TOKEN(STR_ENABLE), value = 1, flags = RESET_REQUIRED;
+   option text = STRING_TOKEN(STR_DISABLE), value = 0, flags = DEFAULT | 
MANUFACTURING | RESET_REQUIRED;
   endoneof;
 
   oneof varid= Setup.GTTSize,
diff --git a/Silicon/BroxtonSoC/BroxtonSiPkg/NorthCluster/Include/SaRegs.h 
b/Silicon/BroxtonSoC/BroxtonSiPkg/NorthCluster/Include/SaRegs.h
index 5dd844092..e985e75c4 100644
--- a/Silicon/BroxtonSoC/BroxtonSiPkg/NorthCluster/Include/SaRegs.h
+++ b/Silicon/BroxtonSoC/BroxtonSiPkg/NorthCluster/Include/SaRegs.h
@@ -15,7 +15,7 @@
   Registers / bits of new devices introduced in a SA generation will be just 
named
   as "_SA_" without [generation_name] inserted.
 
-  Copyright (c) 1999 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 1999 - 2017, Intel Corporation. All rights reserved.
 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
@@ -59,6 +59,12 @@
 #define R_SA_MC_CAPID0_B   0xE8
 #define R_SA_MCHBAR_REG0x48
 
+//
+// IA-Punit Mailbox on MCH BAR 
+//
+#define R_BIOS_MAILBOX_DATA0x7080
+#define R_BIOS_MAILBOX_INTERFACE   0x7084
+
 //
 // Silicon Steppings
 //
-- 
2.14.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdePkg: add ARM/AARCH64 support to BaseCacheMaintenanceLib

[Leif Lindholm]

Hi Liming,

I understand the purity argument, but the situation (without this
patch) is that:
1) There is a non-functional BaseCacheMaintenanceLib ARM/AARCH64
   implementation with misleading information in MdePkg.
2) ARM/AARCH64-based needs to include a different cache maintenance
   library than all other architectures. And they all need to include
   the same one.

2 is an issue for the logical conclusion of the RFC series I am about
to post for creating common include files for "boilerplate" bits of
.dsf/.fdf files.

An alternative option would be to move ArmLib into MdePkg?
A casual glance suggests to me that the corresponding X86 features
(like AsmWbinvd) are exposed via BaseLib. Would you see any issues
with merging the ArmLib functionality into BaseLib?

Regards,

Leif

On Wed, Sep 20, 2017 at 02:45:30PM +, Gao, Liming wrote:
> Leif:
>   This change lets MdePkg BaseCacheMaintenanceLib depend on ArmPkg
>   ArmLib. But, MdePkg is the basic package. It should not depend on
>   other package. I suggest to add this ARM specific
>   BaseCacheMaintenanceLib library instance into ArmPkg.
> 
> Thanks
> Liming
> > -Original Message-
> > From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> > Sent: Wednesday, September 20, 2017 9:23 PM
> > To: edk2-devel@lists.01.org
> > Cc: Kinney, Michael D ; Gao, Liming 
> > ; Ard Biesheuvel
> > 
> > Subject: [PATCH] MdePkg: add ARM/AARCH64 support to BaseCacheMaintenanceLib
> > 
> > ARM platforms have been using a separately located library in ArmPkg for
> > high-level cache maintenance calls. Resolve this anomaly by overwriting
> > ArmCache.c with the contents of
> > ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c, and add
> > the ArmLib dependency for the affected architectures.
> > 
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Leif Lindholm 
> > ---
> > 
> > The intent is to delete the ArmPkg version once no upstream platforms
> > are using it.
> > 
> >  MdePkg/Library/BaseCacheMaintenanceLib/ArmCache.c  | 222 
> > +
> >  .../BaseCacheMaintenanceLib.inf|   2 +
> >  2 files changed, 55 insertions(+), 169 deletions(-)
> > 
> > diff --git a/MdePkg/Library/BaseCacheMaintenanceLib/ArmCache.c 
> > b/MdePkg/Library/BaseCacheMaintenanceLib/ArmCache.c
> > index 79c84a0982..0759e38cd4 100644
> > --- a/MdePkg/Library/BaseCacheMaintenanceLib/ArmCache.c
> > +++ b/MdePkg/Library/BaseCacheMaintenanceLib/ArmCache.c
> > @@ -1,67 +1,63 @@
> >  /** @file
> > -  Cache Maintenance Functions. These functions vary by ARM architecture so 
> > the MdePkg
> > -  versions are null functions used to make sure things will compile.
> > 
> > -  Copyright (c) 2006 - 2009, Intel Corporation. All rights reserved.
> > -  Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
> > +  Copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
> > +  Copyright (c) 2011 - 2014, ARM Limited. All rights reserved.
> > +
> >This program and the accompanying materials
> >are licensed and made available under the terms and conditions of the 
> > BSD License
> >which accompanies this distribution.  The full text of the license may 
> > be found at
> > -  http://opensource.org/licenses/bsd-license.php.
> > +  http://opensource.org/licenses/bsd-license.php
> > 
> >THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> >WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> > IMPLIED.
> > 
> >  **/
> > -
> > -//
> > -// Include common header file for this module.
> > -//
> >  #include 
> > +#include 
> >  #include 
> > +#include 
> > 
> > -/**
> > -  Invalidates the entire instruction cache in cache coherency domain of the
> > -  calling CPU.
> > -
> > -  Invalidates the entire instruction cache in cache coherency domain of the
> > -  calling CPU.
> > +STATIC
> > +VOID
> > +CacheRangeOperation (
> > +  IN  VOID*Start,
> > +  IN  UINTN   Length,
> > +  IN  LINE_OPERATION  LineOperation,
> > +  IN  UINTN   LineLength
> > +  )
> > +{
> > +  UINTN ArmCacheLineAlignmentMask  = LineLength - 1;
> > +
> > +  // Align address (rounding down)
> > +  UINTN AlignedAddress = (UINTN)Start - ((UINTN)Start & 
> > ArmCacheLineAlignmentMask);
> > +  UINTN EndAddress = (UINTN)Start + Length;
> > +
> > +  // Perform the line operation on an address in each cache line
> > +  while (AlignedAddress < EndAddress) {
> > +LineOperation(AlignedAddress);
> > +AlignedAddress += LineLength;
> > +  }
> > +  ArmDataSynchronizationBarrier ();
> > +}
> > 
> > -**/
> >  VOID
> >  EFIAPI
> >  InvalidateInstructionCache (
> >VOID
> >)
> >  {
> > -  ASSERT(FALSE);
> > +  ASSERT (FALSE);
> >  }
> > 
> > -/**
> > -  Invalidates a range of instruction cache lines in the cache coherency 
> > domain
> > -  of the calling CPU.
> > -
> > 

Re: [edk2] [PATCH v2] PeiLib : Inform UEFI memory to Linux

[Gao, Liming]

To reserve the memory resource in boot phase and open them for OS phase, after 
create system resource hob, we can create memory allocation hob to take some 
range in PEI phase. Then, these ranges will not be allocated in DXE phase, but 
they will still be reported in UEFI memory map. So, for this case, I suggest to 
create memory hob instead of resource hob with non present memory attribute. 

Thanks
Liming
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Meenakshi Aggarwal
> Sent: Tuesday, September 19, 2017 8:32 PM
> To: edk2-devel@lists.01.org; leif.lindh...@linaro.org; 
> ard.biesheu...@linaro.org
> Subject: [edk2] [PATCH v2] PeiLib : Inform UEFI memory to Linux
> 
> While creating Hob list, ArmPlatformPkg is hiding UEFI memory.
> whereas this memory can be used by OS.
> 
> This patch, allows OS to use UEFI code area.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Udit Kumar 
> Signed-off-by: Meenakshi Aggarwal 
> ---
>  ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c | 69 
> -
>  1 file changed, 69 deletions(-)
> 
> diff --git a/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c 
> b/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c
> index 2feb11f..d03214b 100644
> --- a/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c
> +++ b/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c
> @@ -70,11 +70,7 @@ MemoryPeim (
>  {
>ARM_MEMORY_REGION_DESCRIPTOR *MemoryTable;
>EFI_RESOURCE_ATTRIBUTE_TYPE  ResourceAttributes;
> -  UINT64   ResourceLength;
>EFI_PEI_HOB_POINTERS NextHob;
> -  EFI_PHYSICAL_ADDRESS FdTop;
> -  EFI_PHYSICAL_ADDRESS SystemMemoryTop;
> -  EFI_PHYSICAL_ADDRESS ResourceTop;
>BOOLEAN  Found;
> 
>// Get Virtual Memory Map from the Platform Library
> @@ -121,71 +117,6 @@ MemoryPeim (
>  );
>}
> 
> -  //
> -  // Reserved the memory space occupied by the firmware volume
> -  //
> -
> -  SystemMemoryTop = (EFI_PHYSICAL_ADDRESS)PcdGet64 (PcdSystemMemoryBase) + 
> (EFI_PHYSICAL_ADDRESS)PcdGet64
> (PcdSystemMemorySize);
> -  FdTop = (EFI_PHYSICAL_ADDRESS)PcdGet64 (PcdFdBaseAddress) + 
> (EFI_PHYSICAL_ADDRESS)PcdGet32 (PcdFdSize);
> -
> -  // EDK2 does not have the concept of boot firmware copied into DRAM. To 
> avoid the DXE
> -  // core to overwrite this area we must mark the region with the attribute 
> non-present
> -  if ((PcdGet64 (PcdFdBaseAddress) >= PcdGet64 (PcdSystemMemoryBase)) && 
> (FdTop <= SystemMemoryTop)) {
> -Found = FALSE;
> -
> -// Search for System Memory Hob that contains the firmware
> -NextHob.Raw = GetHobList ();
> -while ((NextHob.Raw = GetNextHob (EFI_HOB_TYPE_RESOURCE_DESCRIPTOR, 
> NextHob.Raw)) != NULL) {
> -  if ((NextHob.ResourceDescriptor->ResourceType == 
> EFI_RESOURCE_SYSTEM_MEMORY) &&
> -  (PcdGet64 (PcdFdBaseAddress) >= 
> NextHob.ResourceDescriptor->PhysicalStart) &&
> -  (FdTop <= NextHob.ResourceDescriptor->PhysicalStart + 
> NextHob.ResourceDescriptor->ResourceLength))
> -  {
> -ResourceAttributes = NextHob.ResourceDescriptor->ResourceAttribute;
> -ResourceLength = NextHob.ResourceDescriptor->ResourceLength;
> -ResourceTop = NextHob.ResourceDescriptor->PhysicalStart + 
> ResourceLength;
> -
> -if (PcdGet64 (PcdFdBaseAddress) == 
> NextHob.ResourceDescriptor->PhysicalStart) {
> -  if (SystemMemoryTop == FdTop) {
> -NextHob.ResourceDescriptor->ResourceAttribute = 
> ResourceAttributes & ~EFI_RESOURCE_ATTRIBUTE_PRESENT;
> -  } else {
> -// Create the System Memory HOB for the firmware with the 
> non-present attribute
> -BuildResourceDescriptorHob (EFI_RESOURCE_SYSTEM_MEMORY,
> -ResourceAttributes & 
> ~EFI_RESOURCE_ATTRIBUTE_PRESENT,
> -PcdGet64 (PcdFdBaseAddress),
> -PcdGet32 (PcdFdSize));
> -
> -// Top of the FD is system memory available for UEFI
> -NextHob.ResourceDescriptor->PhysicalStart += PcdGet32(PcdFdSize);
> -NextHob.ResourceDescriptor->ResourceLength -= 
> PcdGet32(PcdFdSize);
> -  }
> -} else {
> -  // Create the System Memory HOB for the firmware with the 
> non-present attribute
> -  BuildResourceDescriptorHob (EFI_RESOURCE_SYSTEM_MEMORY,
> -  ResourceAttributes & 
> ~EFI_RESOURCE_ATTRIBUTE_PRESENT,
> -  PcdGet64 (PcdFdBaseAddress),
> -  PcdGet32 (PcdFdSize));
> -
> -  // Update the HOB
> -  NextHob.ResourceDescriptor->ResourceLength = PcdGet64 
> (PcdFdBaseAddress) -
> NextHob.ResourceDescriptor->PhysicalStart;
> -
> -  // If there is some memory available on the 

Re: [edk2] Storing Non volatile variables on SD/NAND

[Pankaj Bansal]

This use case also arises for single-board systems like raspberry-pi, which do 
not have an onboard flash.
The boot firmware/bootloader as well as operating system are loaded from SD 
card.
https://www.raspberrypi.org/documentation/configuration/config-txt/

Thanks & Regards,
Pankaj Bansal

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Andrew 
Fish
Sent: Wednesday, September 20, 2017 10:48 AM
To: Udit Kumar 
Cc: edk2-devel@lists.01.org; Vladimir Olovyannikov 
; olivier.mar...@arm.com; Ard Biesheuvel 

Subject: Re: [edk2] Storing Non volatile variables on SD/NAND


> On Sep 19, 2017, at 10:09 PM, Udit Kumar  wrote:
> 
>>> On Sep 19, 2017, at 9:27 PM, Udit Kumar  wrote:
>>> 
>>> 
 On 18 September 2017 at 22:28, Udit Kumar  wrote:
> Thanks Vladimir,
> With your design, you did delayed write to eMMC due to sharing 
> with OS.  But it works for you:) Say if eMMC controllers offers 
> you a status bit, if eMMC storage is being used for not. Then this 
> could be possible to
 update at run time, both OS/UEFI needs to check and wait if 
 controller is being used.
 
 That is the problem right there. The nice thing about a firmware 
 spec is that you don't have to care about how it was implemented if 
 you adhere to
>> the API rules.
>>> 
>>> Yup, we are fine as long as long UEFI firmware is stored on dedicated media.
>>> 
 Imposing additional restrictions (such as requiring the OS to be 
 careful about not using the eMMC when it may be in use by the
 firmware) defeats the purpose of using UEFI, since you won't be 
 able to use a
>> generic OS anyway.
 
>>> 
>>> Hmm,  so far, I haven't come across where UEFI specs says, we need a 
>>> separate Storage for firmware. (May be I missed some part of specs) 
>>> Irrespective of storage media, we have this problem if OS and UEFI 
>>> shares same storage.
>>> 
>> 
>> Udit,
>> 
>> Can you point out the spec that states you can't boot Linux and 
>> Windows at the same time on a PC? :)
>> 
>> When you write a spec it is not practical do document what is not 
>> possible, you can only document the API the rest is implied by the 
>> implementation. So for example the UEFI spec does not document why 
>> the firmware and OS can't share a hardware device, just like you 
>> can't have 2 operating systems running on bare metal at the same 
>> time. It is a little like Occam's Razor the reason that the firmware 
>> and the OS can not share a hardware device is the mechanics of how to 
>> share a hardware device is not defined in the spec, thus it is not part of 
>> the API and not possible.
> 
> Right,  This is left on implementation how to put firmware and OS.
> Ideally, keeping both storage separate  is best case, no need to sync between 
> two.
> 
> My reply to Ard, was to highlight that in any case (NOR or eMMC /NAND) 
> if we are keeping OS and firmware on same storage, we will have same 
> issue not limited to  eMMC.
> 
> For some requirement, if we need to keep firmware and OS on same 
> media, Then implementation should make sure there is exclusive access 
> (be it NOR controller, SD controller etc).
> 

Udit,

Sorry I'm a little swamped on my email right now and might be a little behind 
on the thread

Yea the only way to realistically Implement an EFI runtime service in UEFI is 
to have UEFI own the hardware device. There is no architecture for sharing the 
device, and the type of device is not really relevant. 

Thanks,

Andrew Fish

> Thanks
> Udit
> 
>> Thanks,
>> 
>> Andrew Fish
>> 
> For sure,  some synchronization issues need to be ironed out (or 
> maybe I am
 just dreaming here).
> 
> On part 2) where you forked VariableRuntime driver , could we 
> think of updating VariableRuntime driver, to support non-XIP or 
> memory mapped
 devices.
> 
 
 I think being able to support non-memorymapped FV volumes for the 
 variable store would be a big improvement. This does require 
 changes to both the FaultTolerantWrite drivers and the 
 VariableRuntime drivers, which both appear in PEI, DXE and SMM 
 flavors, and require thorough review due to the security impact 
 bugs have in this layer, so this is a
>> rather large chunk of work to take on.
>>> 
>>> Thanks,  your list is longer than what I was thinking :-) I think, 
>>> for embedded world with UEFI, later or sooner, this will be required.
>>> 
>>> Thanks
>>> Udit
>>> ___
>>> edk2-devel mailing list
>>> edk2-devel@lists.01.org
>>> https://lists.01.org/mailman/listinfo/edk2-devel

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdePkg: add ARM/AARCH64 support to BaseCacheMaintenanceLib

[Gao, Liming]

Leif:
  This change lets MdePkg BaseCacheMaintenanceLib depend on ArmPkg ArmLib. But, 
MdePkg is the basic package. It should not depend on other package. I suggest 
to add this ARM specific BaseCacheMaintenanceLib library instance into ArmPkg. 

Thanks  
Liming
> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Wednesday, September 20, 2017 9:23 PM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Gao, Liming 
> ; Ard Biesheuvel
> 
> Subject: [PATCH] MdePkg: add ARM/AARCH64 support to BaseCacheMaintenanceLib
> 
> ARM platforms have been using a separately located library in ArmPkg for
> high-level cache maintenance calls. Resolve this anomaly by overwriting
> ArmCache.c with the contents of
> ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c, and add
> the ArmLib dependency for the affected architectures.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Leif Lindholm 
> ---
> 
> The intent is to delete the ArmPkg version once no upstream platforms
> are using it.
> 
>  MdePkg/Library/BaseCacheMaintenanceLib/ArmCache.c  | 222 
> +
>  .../BaseCacheMaintenanceLib.inf|   2 +
>  2 files changed, 55 insertions(+), 169 deletions(-)
> 
> diff --git a/MdePkg/Library/BaseCacheMaintenanceLib/ArmCache.c 
> b/MdePkg/Library/BaseCacheMaintenanceLib/ArmCache.c
> index 79c84a0982..0759e38cd4 100644
> --- a/MdePkg/Library/BaseCacheMaintenanceLib/ArmCache.c
> +++ b/MdePkg/Library/BaseCacheMaintenanceLib/ArmCache.c
> @@ -1,67 +1,63 @@
>  /** @file
> -  Cache Maintenance Functions. These functions vary by ARM architecture so 
> the MdePkg
> -  versions are null functions used to make sure things will compile.
> 
> -  Copyright (c) 2006 - 2009, Intel Corporation. All rights reserved.
> -  Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
> +  Copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
> +  Copyright (c) 2011 - 2014, ARM Limited. All rights reserved.
> +
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD 
> License
>which accompanies this distribution.  The full text of the license may be 
> found at
> -  http://opensource.org/licenses/bsd-license.php.
> +  http://opensource.org/licenses/bsd-license.php
> 
>THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
>WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> 
>  **/
> -
> -//
> -// Include common header file for this module.
> -//
>  #include 
> +#include 
>  #include 
> +#include 
> 
> -/**
> -  Invalidates the entire instruction cache in cache coherency domain of the
> -  calling CPU.
> -
> -  Invalidates the entire instruction cache in cache coherency domain of the
> -  calling CPU.
> +STATIC
> +VOID
> +CacheRangeOperation (
> +  IN  VOID*Start,
> +  IN  UINTN   Length,
> +  IN  LINE_OPERATION  LineOperation,
> +  IN  UINTN   LineLength
> +  )
> +{
> +  UINTN ArmCacheLineAlignmentMask  = LineLength - 1;
> +
> +  // Align address (rounding down)
> +  UINTN AlignedAddress = (UINTN)Start - ((UINTN)Start & 
> ArmCacheLineAlignmentMask);
> +  UINTN EndAddress = (UINTN)Start + Length;
> +
> +  // Perform the line operation on an address in each cache line
> +  while (AlignedAddress < EndAddress) {
> +LineOperation(AlignedAddress);
> +AlignedAddress += LineLength;
> +  }
> +  ArmDataSynchronizationBarrier ();
> +}
> 
> -**/
>  VOID
>  EFIAPI
>  InvalidateInstructionCache (
>VOID
>)
>  {
> -  ASSERT(FALSE);
> +  ASSERT (FALSE);
>  }
> 
> -/**
> -  Invalidates a range of instruction cache lines in the cache coherency 
> domain
> -  of the calling CPU.
> -
> -  Invalidates the instruction cache lines specified by Address and Length. If
> -  Address is not aligned on a cache line boundary, then entire instruction
> -  cache line containing Address is invalidated. If Address + Length is not
> -  aligned on a cache line boundary, then the entire instruction cache line
> -  containing Address + Length -1 is invalidated. This function may choose to
> -  invalidate the entire instruction cache if that is more efficient than
> -  invalidating the specified range. If Length is 0, then no instruction cache
> -  lines are invalidated. Address is returned.
> -
> -  If Length is greater than (MAX_ADDRESS - Address + 1), then ASSERT().
> -
> -  @param  Address The base address of the instruction cache lines to
> -  invalidate. If the CPU is in a physical addressing mode, 
> then
> -  Address is a physical address. If the CPU is in a virtual
> -  addressing mode, then Address is a virtual address.
> -
> -  @param  Length  The number of bytes to invalidate from the instruction 
> cache.
> -
> -  @return 

Re: [edk2] [PATCH 0/3] OvmfPkg/QemuVideoDxe/VbeShim: handle PAM1 register on Q35 correctly

[Aleksei]

Tested-by: Aleksei Kovura

Works for me with Qemu 2.10.0.


On 19/09/17 22:18, Laszlo Ersek wrote:

Repo:   https://github.com/lersek/edk2.git
Branch: vbe_shim_q35_pam

Fix the long-standing OVMF/Q35 bug recently exposed by a QEMU change,
and reported under .

Aleksei, can you please fetch the branch, build it, and report back with
your Tested-by if it works for you?

I performed my own tests as well; I'll include those in a separate
email.

Cc: Aleksei Kovura 
Cc: Gerd Hoffmann 
Cc: Igor Mammedov 
Cc: Jordan Justen 
Cc: Ruiyu Ni 

Thank you,
Laszlo

Laszlo Ersek (3):
   OvmfPkg/CsmSupportLib: move PAM register addresses to IndustryStandard
   OvmfPkg/QemuVideoDxe/VbeShim: rename Status to
 Segment0AllocationStatus
   OvmfPkg/QemuVideoDxe/VbeShim: handle PAM1 register on Q35 correctly

  OvmfPkg/Csm/CsmSupportLib/LegacyRegion.c   | 62 ++--
  OvmfPkg/Csm/CsmSupportLib/LegacyRegion.h   | 22 +--
  OvmfPkg/Include/IndustryStandard/I440FxPiix4.h | 13 
  OvmfPkg/Include/IndustryStandard/Q35MchIch9.h  |  8 +++
  OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf  |  3 +-
  OvmfPkg/QemuVideoDxe/VbeShim.c | 47 ---
  6 files changed, 95 insertions(+), 60 deletions(-)



--
/--Regards, Aleksei/
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] MdePkg: add ARM/AARCH64 support to BaseCacheMaintenanceLib

[Leif Lindholm]

ARM platforms have been using a separately located library in ArmPkg for
high-level cache maintenance calls. Resolve this anomaly by overwriting
ArmCache.c with the contents of
ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c, and add
the ArmLib dependency for the affected architectures.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Leif Lindholm 
---

The intent is to delete the ArmPkg version once no upstream platforms
are using it.

 MdePkg/Library/BaseCacheMaintenanceLib/ArmCache.c  | 222 +
 .../BaseCacheMaintenanceLib.inf|   2 +
 2 files changed, 55 insertions(+), 169 deletions(-)

diff --git a/MdePkg/Library/BaseCacheMaintenanceLib/ArmCache.c 
b/MdePkg/Library/BaseCacheMaintenanceLib/ArmCache.c
index 79c84a0982..0759e38cd4 100644
--- a/MdePkg/Library/BaseCacheMaintenanceLib/ArmCache.c
+++ b/MdePkg/Library/BaseCacheMaintenanceLib/ArmCache.c
@@ -1,67 +1,63 @@
 /** @file
-  Cache Maintenance Functions. These functions vary by ARM architecture so the 
MdePkg 
-  versions are null functions used to make sure things will compile. 
 
-  Copyright (c) 2006 - 2009, Intel Corporation. All rights reserved.
-  Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
+  Copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
+  Copyright (c) 2011 - 2014, ARM Limited. All rights reserved.
+
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
-  http://opensource.org/licenses/bsd-license.php.
+  http://opensource.org/licenses/bsd-license.php
 
   THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
   WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
 
 **/
-
-//
-// Include common header file for this module.
-//
 #include 
+#include 
 #include 
+#include 
 
-/**
-  Invalidates the entire instruction cache in cache coherency domain of the
-  calling CPU.
-
-  Invalidates the entire instruction cache in cache coherency domain of the
-  calling CPU.
+STATIC
+VOID
+CacheRangeOperation (
+  IN  VOID*Start,
+  IN  UINTN   Length,
+  IN  LINE_OPERATION  LineOperation,
+  IN  UINTN   LineLength
+  )
+{
+  UINTN ArmCacheLineAlignmentMask  = LineLength - 1;
+
+  // Align address (rounding down)
+  UINTN AlignedAddress = (UINTN)Start - ((UINTN)Start & 
ArmCacheLineAlignmentMask);
+  UINTN EndAddress = (UINTN)Start + Length;
+
+  // Perform the line operation on an address in each cache line
+  while (AlignedAddress < EndAddress) {
+LineOperation(AlignedAddress);
+AlignedAddress += LineLength;
+  }
+  ArmDataSynchronizationBarrier ();
+}
 
-**/
 VOID
 EFIAPI
 InvalidateInstructionCache (
   VOID
   )
 {
-  ASSERT(FALSE);
+  ASSERT (FALSE);
 }
 
-/**
-  Invalidates a range of instruction cache lines in the cache coherency domain
-  of the calling CPU.
-
-  Invalidates the instruction cache lines specified by Address and Length. If
-  Address is not aligned on a cache line boundary, then entire instruction
-  cache line containing Address is invalidated. If Address + Length is not
-  aligned on a cache line boundary, then the entire instruction cache line
-  containing Address + Length -1 is invalidated. This function may choose to
-  invalidate the entire instruction cache if that is more efficient than
-  invalidating the specified range. If Length is 0, then no instruction cache
-  lines are invalidated. Address is returned.
-
-  If Length is greater than (MAX_ADDRESS - Address + 1), then ASSERT().
-
-  @param  Address The base address of the instruction cache lines to
-  invalidate. If the CPU is in a physical addressing mode, then
-  Address is a physical address. If the CPU is in a virtual
-  addressing mode, then Address is a virtual address.
-
-  @param  Length  The number of bytes to invalidate from the instruction cache.
-
-  @return Address
+VOID
+EFIAPI
+InvalidateDataCache (
+  VOID
+  )
+{
+  ASSERT (FALSE);
+}
 
-**/
 VOID *
 EFIAPI
 InvalidateInstructionCacheRange (
@@ -69,56 +65,26 @@ InvalidateInstructionCacheRange (
   IN  UINTN Length
   )
 {
-  ASSERT (Length <= MAX_ADDRESS - (UINTN)Address + 1);
-  ASSERT(FALSE);
-  return Address;
-}
+  CacheRangeOperation (Address, Length, ArmCleanDataCacheEntryToPoUByMVA,
+ArmDataCacheLineLength ());
+  CacheRangeOperation (Address, Length,
+ArmInvalidateInstructionCacheEntryToPoUByMVA,
+ArmInstructionCacheLineLength ());
 
-/**
-  Writes back and invalidates the entire data cache in cache coherency domain
-  of the calling CPU.
+  ArmInstructionSynchronizationBarrier ();
 
-  Writes Back and Invalidates the entire data cache in cache coherency domain
-  of the calling CPU. This function guarantees that all dirty cache 

[edk2] [PATCH V6 6/6] MdeModulePkg/DriverSample: Add questions with bit/union VarStore

[Dandan Bi]

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=545

Cc: Eric Dong 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi 
---
 .../Universal/DriverSampleDxe/DriverSample.c   | 120 ++
 .../Universal/DriverSampleDxe/DriverSample.h   |   2 +
 .../Universal/DriverSampleDxe/NVDataStruc.h|  34 +++-
 MdeModulePkg/Universal/DriverSampleDxe/Vfr.vfr | 172 +
 .../Universal/DriverSampleDxe/VfrStrings.uni   |  63 
 5 files changed, 390 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c 
b/MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c
index bbd9713..af31615 100644
--- a/MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c
+++ b/MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c
@@ -18,10 +18,13 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 
 #define DISPLAY_ONLY_MY_ITEM  0x0002
 
 CHAR16 VariableName[] = L"MyIfrNVData";
 CHAR16 MyEfiVar[] = L"MyEfiVar";
+CHAR16 MyEfiBitVar[] = L"MyEfiBitVar";
+CHAR16 MyEfiUnionVar[] = L"MyEfiUnionVar";
+
 EFI_HANDLE  DriverHandle[2] = {NULL, NULL};
 DRIVER_SAMPLE_PRIVATE_DATA  *mPrivateData = NULL;
 EFI_EVENT   mEvent;
 
 HII_VENDOR_DEVICE_PATH  mHiiVendorDevicePath0 = {
@@ -662,10 +665,17 @@ ExtractConfig (
 // through hii database, not support in this path.
 //
 if (HiiIsConfigHdrMatch(Request, , MyEfiVar)) {
   return EFI_UNSUPPORTED;
 }
+if (HiiIsConfigHdrMatch(Request, , MyEfiBitVar)) {
+  return EFI_UNSUPPORTED;
+}
+if (HiiIsConfigHdrMatch(Request, , 
MyEfiUnionVar)) {
+  return EFI_UNSUPPORTED;
+}
+
 //
 // Set Request to the unified request string.
 //
 ConfigRequest = Request;
 //
@@ -883,10 +893,16 @@ RouteConfig (
   // through hii database, not support in this path.
   //
   if (HiiIsConfigHdrMatch(Configuration, , MyEfiVar)) 
{
 return EFI_UNSUPPORTED;
   }
+  if (HiiIsConfigHdrMatch(Configuration, , 
MyEfiBitVar)) {
+return EFI_UNSUPPORTED;
+  }
+  if (HiiIsConfigHdrMatch(Configuration, , 
MyEfiUnionVar)) {
+return EFI_UNSUPPORTED;
+  }
 
   //
   // Get Buffer Storage data from EFI variable
   //
   BufferSize = sizeof (DRIVER_SAMPLE_CONFIGURATION);
@@ -1295,10 +1311,14 @@ DriverCallback (
 for (Index = 0; Index < 3; Index ++) {
   SetArrayData (Value, EFI_IFR_TYPE_NUM_SIZE_8, Index, BufferValue--);
 }
   break;
 
+  case 0x:
+Value->u8 = 12;
+break;
+
   default:
 Status = EFI_UNSUPPORTED;
   break;
   }
 }
@@ -1309,10 +1329,14 @@ DriverCallback (
   switch (QuestionId) {
   case 0x1240:
 Value->u8 = DEFAULT_CLASS_MANUFACTURING_VALUE;
   break;
 
+ case 0x:
+Value->u8 = 13;
+break;
+
   default:
 Status = EFI_UNSUPPORTED;  
   break;
   }
 }
@@ -1703,10 +1727,12 @@ DriverSampleInit (
   DRIVER_SAMPLE_CONFIGURATION *Configuration;
   BOOLEAN ActionFlag;
   EFI_STRING  ConfigRequestHdr;
   EFI_STRING  NameRequestHdr;
   MY_EFI_VARSTORE_DATA*VarStoreConfig;
+  MY_EFI_BITS_VARSTORE_DATA   *BitsVarStoreConfig;
+  MY_EFI_UNION_DATA   *UnionConfig;
   EFI_INPUT_KEY   HotKey;
   EDKII_FORM_BROWSER_EXTENSION_PROTOCOL *FormBrowserEx;
 
   //
   // Initialize the local variables.
@@ -1991,10 +2017,104 @@ DriverSampleInit (
   return EFI_INVALID_PARAMETER;
 }
   }
   FreePool (ConfigRequestHdr);
 
+  //
+  // Initialize Bits efi varstore configuration data
+  //
+  BitsVarStoreConfig = >BitsVarStoreConfig;
+  ZeroMem (BitsVarStoreConfig, sizeof (MY_EFI_BITS_VARSTORE_DATA));
+
+  ConfigRequestHdr = HiiConstructConfigHdr (, 
MyEfiBitVar, DriverHandle[0]);
+  ASSERT (ConfigRequestHdr != NULL);
+
+  BufferSize = sizeof (MY_EFI_BITS_VARSTORE_DATA);
+  Status = gRT->GetVariable (MyEfiBitVar, , NULL, 
, BitsVarStoreConfig);
+  if (EFI_ERROR (Status)) {
+//
+// Store zero data to EFI variable Storage.
+//
+Status = gRT->SetVariable(
+MyEfiBitVar,
+,
+EFI_VARIABLE_NON_VOLATILE | 
EFI_VARIABLE_BOOTSERVICE_ACCESS,
+sizeof (MY_EFI_BITS_VARSTORE_DATA),
+BitsVarStoreConfig
+);
+if (EFI_ERROR (Status)) {
+  DriverSampleUnload (ImageHandle);
+  return Status;
+}
+//
+// EFI variable for NV config doesn't exit, we should build this variable
+// based on default values stored in IFR
+//
+ActionFlag = HiiSetToDefaults (ConfigRequestHdr, 
EFI_HII_DEFAULT_CLASS_STANDARD);
+if (!ActionFlag) {
+  DriverSampleUnload (ImageHandle);
+  return EFI_INVALID_PARAMETER;

[edk2] [PATCH V6 2/6] MdeModulePkg: Add GUID/flags to implement BitField support

[Dandan Bi]

V6:Update EDKII extenstion MACRO name with EDKII prefix
which are missing in V5.

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=545

Cc: Eric Dong 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi 
---
 MdeModulePkg/Include/Guid/MdeModuleHii.h | 20 +++-
 MdeModulePkg/MdeModulePkg.dec|  4 
 2 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Include/Guid/MdeModuleHii.h 
b/MdeModulePkg/Include/Guid/MdeModuleHii.h
index 81821da..e2ebb55 100644
--- a/MdeModulePkg/Include/Guid/MdeModuleHii.h
+++ b/MdeModulePkg/Include/Guid/MdeModuleHii.h
@@ -1,9 +1,9 @@
 /** @file
   EDKII extented HII IFR guid opcodes.
 
-Copyright (c) 2006 - 2010, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
 This program and the accompanying materials are licensed and made available 
under 
 the terms and conditions of the BSD License that accompanies this 
distribution.  
 The full text of the license may be found at
 http://opensource.org/licenses/bsd-license.php.

 
@@ -209,12 +209,30 @@ typedef struct _EFI_IFR_GUID_VAREQNAME {
   /// The the Unicode String will be used as a EFI Variable Name.
   ///
   UINT16  NameId;
 } EFI_IFR_GUID_VAREQNAME;
 
+///
+/// EDKII implementation extension GUID, used to indaicate there are bit 
fields in the varstore.
+///
+#define EDKII_IFR_BIT_VARSTORE_GUID \
+  {0x82DDD68B, 0x9163, 0x4187, {0x9B, 0x27, 0x20, 0xA8, 0xFD, 0x60,0xA7, 0x1D}}
+
+///
+/// EDKII implementation extension flags, used to indaicate the disply style 
and bit width for bit filed storage.
+/// Two high bits for display style and the low six bits for bit width.
+///
+#define EDKII_IFR_DISPLAY_BIT0xC0
+#define EDKII_IFR_DISPLAY_INT_DEC_BIT0x00
+#define EDKII_IFR_DISPLAY_UINT_DEC_BIT   0x40
+#define EDKII_IFR_DISPLAY_UINT_HEX_BIT   0x80
+
+#define EDKII_IFR_NUMERIC_SIZE_BIT   0x3F
+
 #pragma pack()
 
 extern EFI_GUID gEfiIfrTianoGuid;
 extern EFI_GUID gEfiIfrFrameworkGuid;
+extern EFI_GUID gEdkiiIfrBitVarstoreGuid;
 
 #endif
 
diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index 403a66a..a3c0633 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -182,10 +182,14 @@
 
   ## Guid for EDKII implementation GUIDed opcodes
   #  Include/Guid/MdeModuleHii.h
   gEfiIfrTianoGuid  = { 0xf0b1735, 0x87a0, 0x4193, {0xb2, 0x66, 0x53, 
0x8c, 0x38, 0xaf, 0x48, 0xce }}
 
+  ## Guid for EDKII implementation extension, used to indaicate there are bit 
fields in the varstore.
+  #  Include/Guid/MdeModuleHii.h
+  gEdkiiIfrBitVarstoreGuid  = {0x82DDD68B, 0x9163, 0x4187, {0x9B, 0x27, 0x20, 
0xA8, 0xFD, 0x60,0xA7, 0x1D}}
+
   ## Guid for Framework vfr GUIDed opcodes.
   #  Include/Guid/MdeModuleHii.h
   gEfiIfrFrameworkGuid  = { 0x31ca5d1a, 0xd511, 0x4931, { 0xb7, 0x82, 0xae, 
0x6b, 0x2b, 0x17, 0x8c, 0xd7 }}
 
   ## Guid to specify the System Non Volatile FV
-- 
1.9.5.msysgit.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH V6 3/6] MdeModulePkg/UefiHiiLib: Validate question with bit fields

[Dandan Bi]

V6:Update EDKII extenstion MACRO name with EDKII prefix
which are missing in V5.

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=545

In UefiHiiLib, there are codes to validate the current setting of
questions, now update the logic to handle question with bit storage.

Cc: Eric Dong 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi 
---
 MdeModulePkg/Library/UefiHiiLib/HiiLib.c | 250 ---
 MdeModulePkg/Library/UefiHiiLib/InternalHiiLib.h |   4 +-
 MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf   |   5 +-
 3 files changed, 182 insertions(+), 77 deletions(-)

diff --git a/MdeModulePkg/Library/UefiHiiLib/HiiLib.c 
b/MdeModulePkg/Library/UefiHiiLib/HiiLib.c
index 583b9e5..ce894c0 100644
--- a/MdeModulePkg/Library/UefiHiiLib/HiiLib.c
+++ b/MdeModulePkg/Library/UefiHiiLib/HiiLib.c
@@ -1167,10 +1167,17 @@ ValidateQuestionFromVfr (
   EFI_IFR_STRING   *IfrString;
   CHAR8*VarStoreName;
   UINTNIndex;
   CHAR16   *QuestionName;
   CHAR16   *StringPtr;
+  UINT16   BitOffset;
+  UINT16   BitWidth;
+  UINT16   TotalBits;
+  UINTNStartBit;
+  UINTNEndBit;
+  BOOLEAN  QuestionReferBitField;
+  UINT32   BufferValue;
 
   //
   // Initialize the local variables.
   //
   Index = 0;
@@ -1180,10 +1187,13 @@ ValidateQuestionFromVfr (
   IfrVarStore   = NULL;
   IfrNameValueStore = NULL;
   IfrEfiVarStore= NULL;
   ZeroMem (, sizeof (IFR_VARSTORAGE_DATA));
   ZeroMem (, sizeof (VarBlockData));
+  BitOffset = 0;
+  BitWidth = 0;
+  QuestionReferBitField = FALSE;
 
   //
   // Check IFR value is in block data, then Validate Value
   //
   PackageOffset = sizeof (EFI_HII_PACKAGE_LIST_HEADER);
@@ -1343,12 +1353,23 @@ ValidateQuestionFromVfr (
 }
   } else {
 //
 // Get Offset by Question header and Width by DataType Flags
 //
-Offset = IfrOneOf->Question.VarStoreInfo.VarOffset;
-Width  = (UINT16) (1 << (IfrOneOf->Flags & EFI_IFR_NUMERIC_SIZE));
+if (QuestionReferBitField) {
+  //
+  // Get the byte offset/width for bit field.
+  //
+  BitOffset = IfrOneOf->Question.VarStoreInfo.VarOffset;
+  BitWidth = IfrOneOf->Flags & EDKII_IFR_NUMERIC_SIZE_BIT;
+  Offset = BitOffset / 8;
+  TotalBits = BitOffset % 8 + BitWidth;
+  Width = (TotalBits % 8 == 0 ? TotalBits / 8: TotalBits / 8 + 1);
+} else {
+  Offset = IfrOneOf->Question.VarStoreInfo.VarOffset;
+  Width  = (UINT16) (1 << (IfrOneOf->Flags & 
EFI_IFR_NUMERIC_SIZE));
+}
 //
 // Check whether this question is in current block array.
 //
 if (!BlockArrayCheck (CurrentBlockArray, Offset, Width)) {
   //
@@ -1368,11 +1389,21 @@ ValidateQuestionFromVfr (
 
 //
 // Get the current value for oneof opcode
 //
 VarValue = 0;
-CopyMem (, VarBuffer +  Offset, Width);
+if (QuestionReferBitField) {
+  //
+  // Get the value in bit fields.
+  //
+  StartBit = BitOffset % 8;
+  EndBit = StartBit + BitWidth - 1;
+  CopyMem ((UINT8 *) , VarBuffer + Offset, Width);
+  VarValue = BitFieldRead32 (BufferValue, StartBit, EndBit);
+} else {
+  CopyMem (, VarBuffer +  Offset, Width);
+}
   }
   //
   // Set Block Data, to be checked in the following Oneof option 
opcode.
   //
   VarBlockData.OpCode = IfrOpHdr->OpCode;
@@ -1414,12 +1445,23 @@ ValidateQuestionFromVfr (
 }
   } else {
 //
 // Get Offset by Question header and Width by DataType Flags
 //
-Offset = IfrNumeric->Question.VarStoreInfo.VarOffset;
-Width  = (UINT16) (1 << (IfrNumeric->Flags & 
EFI_IFR_NUMERIC_SIZE));
+if (QuestionReferBitField) {
+  //
+  // Get the byte offset/width for bit field.
+  //
+  BitOffset = IfrNumeric->Question.VarStoreInfo.VarOffset;
+  BitWidth = IfrNumeric->Flags & EDKII_IFR_NUMERIC_SIZE_BIT;
+  Offset = BitOffset / 8;
+  TotalBits = BitOffset % 8 + BitWidth;
+  Width  = (TotalBits % 8 == 0 ? TotalBits / 8: TotalBits / 8 + 1);
+} else {
+  Offset = IfrNumeric->Question.VarStoreInfo.VarOffset;
+  Width  = (UINT16) (1 << (IfrNumeric->Flags & 
EFI_IFR_NUMERIC_SIZE));
+   

[edk2] [PATCH V6 5/6] MdeModulePkg/SetupBrowser: Handle questions with Bit VarStore

[Dandan Bi]

V6:Update EDKII extenstion MACRO name with EDKII prefix
which are missing in V5.

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=545

For oneof/numeric/CheckBox(storage can be Bit VarStore)
If the question value can be updated and shown correctly
in UI page, we need do enhancements in following cases:
1. Parse the Ifr data to get the bit VarStore info correctly.
2. Set/get value to/from bit VarStore correctly.

Cc: Eric Dong 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi 
---
 MdeModulePkg/Universal/SetupBrowserDxe/IfrParse.c  | 138 -
 MdeModulePkg/Universal/SetupBrowserDxe/Setup.c | 117 +++--
 MdeModulePkg/Universal/SetupBrowserDxe/Setup.h |   3 +
 .../Universal/SetupBrowserDxe/SetupBrowserDxe.inf  |   3 +-
 4 files changed, 219 insertions(+), 42 deletions(-)

diff --git a/MdeModulePkg/Universal/SetupBrowserDxe/IfrParse.c 
b/MdeModulePkg/Universal/SetupBrowserDxe/IfrParse.c
index 6b3e5e0..9bda482 100644
--- a/MdeModulePkg/Universal/SetupBrowserDxe/IfrParse.c
+++ b/MdeModulePkg/Universal/SetupBrowserDxe/IfrParse.c
@@ -57,10 +57,11 @@ CreateStatement (
 
   Statement->Signature = FORM_BROWSER_STATEMENT_SIGNATURE;
 
   Statement->Operand = ((EFI_IFR_OP_HEADER *) OpCodeData)->OpCode;
   Statement->OpCode  = (EFI_IFR_OP_HEADER *) OpCodeData;
+  Statement->QuestionReferToBitField = FALSE;
 
   StatementHdr = (EFI_IFR_STATEMENT_HEADER *) (OpCodeData + sizeof 
(EFI_IFR_OP_HEADER));
   CopyMem (>Prompt, >Prompt, sizeof (EFI_STRING_ID));
   CopyMem (>Help, >Help, sizeof (EFI_STRING_ID));
 
@@ -1312,10 +1313,12 @@ ParseOpCodes (
   BOOLEAN InUnknownScope;
   UINT8   UnknownDepth;
   FORMSET_DEFAULTSTORE*PreDefaultStore;
   LIST_ENTRY  *DefaultLink;
   BOOLEAN HaveInserted;
+  UINT16  TotalBits;
+  BOOLEAN QuestionReferBitField;
 
   SuppressForQuestion  = FALSE;
   SuppressForOption= FALSE;
   InScopeDisable   = FALSE;
   DepthOfDisable   = 0;
@@ -1333,10 +1336,11 @@ ParseOpCodes (
   MapExpressionList= NULL;
   TempVarstoreId   = 0;
   ConditionalExprCount = 0;
   InUnknownScope   = FALSE;
   UnknownDepth = 0;
+  QuestionReferBitField= FALSE;
 
   //
   // Get the number of Statements and Expressions
   //
   CountOpCodes (FormSet, , );
@@ -1978,47 +1982,98 @@ ParseOpCodes (
   ASSERT(CurrentStatement != NULL);
 
   CurrentStatement->Flags = ((EFI_IFR_ONE_OF *) OpCodeData)->Flags;
   Value = >HiiValue;
 
-  switch (CurrentStatement->Flags & EFI_IFR_NUMERIC_SIZE) {
-  case EFI_IFR_NUMERIC_SIZE_1:
-CurrentStatement->Minimum = ((EFI_IFR_NUMERIC *) 
OpCodeData)->data.u8.MinValue;
-CurrentStatement->Maximum = ((EFI_IFR_NUMERIC *) 
OpCodeData)->data.u8.MaxValue;
-CurrentStatement->Step= ((EFI_IFR_NUMERIC *) 
OpCodeData)->data.u8.Step;
-CurrentStatement->StorageWidth = (UINT16) sizeof (UINT8);
-Value->Type = EFI_IFR_TYPE_NUM_SIZE_8;
-break;
+  if (QuestionReferBitField) {
+//
+// Get the bit var store info (bit/byte offset, bit/byte offset)
+//
+CurrentStatement->QuestionReferToBitField = TRUE;
+CurrentStatement->BitStorageWidth = CurrentStatement->Flags & 
EDKII_IFR_NUMERIC_SIZE_BIT;
+CurrentStatement->BitVarOffset = 
CurrentStatement->VarStoreInfo.VarOffset;
+CurrentStatement->VarStoreInfo.VarOffset = 
CurrentStatement->BitVarOffset / 8;
+TotalBits = CurrentStatement->BitVarOffset % 8 + 
CurrentStatement->BitStorageWidth;
+CurrentStatement->StorageWidth = (TotalBits % 8 == 0? TotalBits / 8: 
TotalBits / 8 + 1);
 
-  case EFI_IFR_NUMERIC_SIZE_2:
-CopyMem (>Minimum, &((EFI_IFR_NUMERIC *) 
OpCodeData)->data.u16.MinValue, sizeof (UINT16));
-CopyMem (>Maximum, &((EFI_IFR_NUMERIC *) 
OpCodeData)->data.u16.MaxValue, sizeof (UINT16));
-CopyMem (>Step,&((EFI_IFR_NUMERIC *) 
OpCodeData)->data.u16.Step, sizeof (UINT16));
-CurrentStatement->StorageWidth = (UINT16) sizeof (UINT16);
-Value->Type = EFI_IFR_TYPE_NUM_SIZE_16;
-break;
+//
+// Get the Minimum/Maximum/Step value(Note: bit field type has been 
stored as UINT32 type)
+//
+CurrentStatement->Minimum = ((EFI_IFR_NUMERIC *) 
OpCodeData)->data.u32.MinValue;
+CurrentStatement->Maximum = ((EFI_IFR_NUMERIC *) 
OpCodeData)->data.u32.MaxValue;
+CurrentStatement->Step= ((EFI_IFR_NUMERIC *) 
OpCodeData)->data.u32.Step;
 
-  case EFI_IFR_NUMERIC_SIZE_4:
-CopyMem (>Minimum, &((EFI_IFR_NUMERIC *) 
OpCodeData)->data.u32.MinValue, sizeof (UINT32));
-CopyMem (>Maximum, &((EFI_IFR_NUMERIC *) 
OpCodeData)->data.u32.MaxValue, sizeof (UINT32));
-CopyMem (>Step,&((EFI_IFR_NUMERIC *) 

[edk2] [PATCH V6 4/6] MdeModulePkg/HiiDatabase: Handle questions with Bit VarStore

[Dandan Bi]

V6:Update EDKII extenstion MACRO name with EDKII prefix
which are missing in V5.

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=545

For oneof/numeric/checkbox, their storage may be bit field.
When generating  string to get default value
for these questions, we need to parse the Ifr data to get
the bit Varstore info,and then generating the correct
 string.

Cc: Eric Dong 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi 
---
 .../Universal/HiiDatabaseDxe/ConfigRouting.c   | 346 +++--
 .../Universal/HiiDatabaseDxe/HiiDatabase.h |   6 +-
 .../Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf|   3 +-
 3 files changed, 319 insertions(+), 36 deletions(-)

diff --git a/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c 
b/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c
index c9ff1cf..646864f 100644
--- a/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c
+++ b/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c
@@ -1223,19 +1223,19 @@ InsertBlockData (
   // Insert block data in its Offset and Width order.
   //
   for (Link = BlockLink->ForwardLink; Link != BlockLink; Link = 
Link->ForwardLink) {
 BlockArray = BASE_CR (Link, IFR_BLOCK_DATA, Entry);
 if (BlockArray->Offset == BlockSingleData->Offset) {
-  if (BlockArray->Width > BlockSingleData->Width) {
+  if ((BlockArray->Width > BlockSingleData->Width) || 
(BlockSingleData->IsBitVar && BlockArray->Width == BlockSingleData->Width)) {
 //
 // Insert this block data in the front of block array
 //
 InsertTailList (Link, >Entry);
 return;
   }
 
-  if (BlockArray->Width == BlockSingleData->Width) {
+  if ((!BlockSingleData->IsBitVar) && BlockArray->Width == 
BlockSingleData->Width) {
 //
 // The same block array has been added.
 //
 if (BlockSingleData != BlockArray) {
   FreePool (BlockSingleData);
@@ -1978,10 +1978,11 @@ Done:
   @param  HiiHandle  The hii handle for this form package.
   @param  VarStorageData The varstore data structure.
   @param  IfrOpHdr   Ifr opcode header for this opcode.
   @param  VarWidth   The buffer width for this opcode.
   @param  ReturnData The data block added for this opcode.
+  @param  IsBitVar   Whether the the opcode refers to bit storage.
 
   @retval  EFI_SUCCESS   This opcode is required.
   @retval  EFI_NOT_FOUND This opcode is not required.
   @retval  OthersContain some error.
  
@@ -1991,20 +1992,26 @@ IsThisOpcodeRequired (
   IN IFR_BLOCK_DATA   *RequestBlockArray,
   IN EFI_HII_HANDLE   HiiHandle,
   IN OUT IFR_VARSTORAGE_DATA  *VarStorageData,
   IN EFI_IFR_OP_HEADER*IfrOpHdr,
   IN UINT16   VarWidth,
-  OUTIFR_BLOCK_DATA   **ReturnData
+  OUTIFR_BLOCK_DATA   **ReturnData,
+  IN BOOLEAN  IsBitVar
   )
 {
   IFR_BLOCK_DATA   *BlockData;
   UINT16   VarOffset;
   EFI_STRING_IDNameId;
   EFI_IFR_QUESTION_HEADER  *IfrQuestionHdr;
+  UINT16   BitOffset;
+  UINT16   BitWidth;
+  UINT16   TotalBits;
 
   NameId= 0;
   VarOffset = 0;
+  BitOffset = 0;
+  BitWidth = 0;
   IfrQuestionHdr = (EFI_IFR_QUESTION_HEADER  *)((CHAR8 *) IfrOpHdr + sizeof 
(EFI_IFR_OP_HEADER));
 
   if (VarStorageData->Type == EFI_HII_VARSTORE_NAME_VALUE) {
 NameId = IfrQuestionHdr->VarStoreInfo.VarName;
 
@@ -2016,11 +2023,27 @@ IsThisOpcodeRequired (
   // This question is not in the requested string. Skip it.
   //
   return EFI_NOT_FOUND;
 }
   } else {
-VarOffset = IfrQuestionHdr->VarStoreInfo.VarOffset;
+//
+// Get the byte offset/with and bit offset/width
+//
+if (IsBitVar) {
+  BitOffset = IfrQuestionHdr->VarStoreInfo.VarOffset;
+  BitWidth = VarWidth;
+  VarOffset = BitOffset / 8;
+  //
+  // Use current bit width and the bit width before current bit (with same 
byte offset) to calculate the byte width.
+  //
+  TotalBits = BitOffset % 8 + BitWidth;
+  VarWidth = (TotalBits % 8 == 0 ? TotalBits / 8: TotalBits / 8 + 1);
+} else {
+  VarOffset = IfrQuestionHdr->VarStoreInfo.VarOffset;
+  BitWidth = VarWidth;
+  BitOffset = VarOffset * 8;
+}
 
 //
 // Check whether this question is in requested block array.
 //
 if (!BlockArrayCheck (RequestBlockArray, VarOffset, VarWidth, FALSE, 
HiiHandle)) {
@@ -2051,10 +2074,13 @@ IsThisOpcodeRequired (
 
   BlockData->Width  = VarWidth;
   BlockData->QuestionId = IfrQuestionHdr->QuestionId;
   BlockData->OpCode = IfrOpHdr->OpCode;
   BlockData->Scope  = IfrOpHdr->Scope;
+  BlockData->IsBitVar   = IsBitVar;

[edk2] [PATCH V6 0/6] Support bitfield in storage of vfr

[Dandan Bi]

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=545

This patch series is to:
(1) Update VfrCompiler to parse bit field in data structure.
(2) Update HiiDatabase,SetupBrowser and UefiHiiLib to handle questions with Bit 
VarStore.
(3) Add sample questions with bit/union VarStore in DriverSample.

Cc: Eric Dong 
Cc: Liming Gao 

Dandan Bi (6):
  BaseTool/VfrCompiler: Support Bit fields in EFI/Buffer VarStore
  MdeModulePkg: Add GUID/flags to implement BitField support
  MdeModulePkg/UefiHiiLib: Validate question with bit fields
  MdeModulePkg/HiiDatabase: Handle questions with Bit VarStore
  MdeModulePkg/SetupBrowser: Handle questions with Bit VarStore
  MdeModulePkg/DriverSample: Add questions with bit/union VarStore

 BaseTools/Source/C/Include/Common/MdeModuleHii.h   |   20 +-
 BaseTools/Source/C/VfrCompile/VfrError.cpp |3 +-
 BaseTools/Source/C/VfrCompile/VfrError.h   |3 +-
 BaseTools/Source/C/VfrCompile/VfrFormPkg.cpp   |  105 +-
 BaseTools/Source/C/VfrCompile/VfrFormPkg.h |   52 +-
 BaseTools/Source/C/VfrCompile/VfrSyntax.g  | 1238 +---
 BaseTools/Source/C/VfrCompile/VfrUtilityLib.cpp|  240 +++-
 BaseTools/Source/C/VfrCompile/VfrUtilityLib.h  |   23 +-
 MdeModulePkg/Include/Guid/MdeModuleHii.h   |   20 +-
 MdeModulePkg/Library/UefiHiiLib/HiiLib.c   |  250 ++--
 MdeModulePkg/Library/UefiHiiLib/InternalHiiLib.h   |4 +-
 MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf |5 +-
 MdeModulePkg/MdeModulePkg.dec  |4 +
 .../Universal/DriverSampleDxe/DriverSample.c   |  120 ++
 .../Universal/DriverSampleDxe/DriverSample.h   |2 +
 .../Universal/DriverSampleDxe/NVDataStruc.h|   34 +-
 MdeModulePkg/Universal/DriverSampleDxe/Vfr.vfr |  172 +++
 .../Universal/DriverSampleDxe/VfrStrings.uni   |   63 +
 .../Universal/HiiDatabaseDxe/ConfigRouting.c   |  346 +-
 .../Universal/HiiDatabaseDxe/HiiDatabase.h |6 +-
 .../Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf|3 +-
 MdeModulePkg/Universal/SetupBrowserDxe/IfrParse.c  |  138 ++-
 MdeModulePkg/Universal/SetupBrowserDxe/Setup.c |  117 +-
 MdeModulePkg/Universal/SetupBrowserDxe/Setup.h |3 +
 .../Universal/SetupBrowserDxe/SetupBrowserDxe.inf  |3 +-
 25 files changed, 2327 insertions(+), 647 deletions(-)

-- 
1.9.5.msysgit.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] CryptoPkg: Add new API to retrieve commonName of X.509 certificate

[Long, Qin]

Laszlo.

It's one good feedback.

This is one historical design issue. We choose to use simple BOOLEAN as the 
return value, because OpenSSL has complicated return data (reason) with extra 
api (e.g. ERR_get_error()...). It's hard to map these error messages directly, 
then we just used one simplest way before, and always kept this kind of API 
style in late updates.

I also think the return value (true/false) in current BaseCryptLib is really 
ambiguous to tell any more useful information. RETURN_xxx is more valuable in 
this new-added case. I would like to update the patch per your suggestion.

Thanks for raising this.

Best Regards & Thanks,
LONG, Qin

From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo 
Ersek
Sent: Wednesday, September 20, 2017 8:09 PM
To: Long, Qin ; Ye, Ting ; Zhang, Chao B 

Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] [PATCH] CryptoPkg: Add new API to retrieve commonName of 
X.509 certificate

Hello Qin,

On 09/19/17 05:38, Long Qin wrote:
> Add one new API (X509GetCommonName()) to retrieve the subject commonName
> string from one X.509 certificate.
>
> Cc: Ting Ye >
> Cc: Chao Zhang >
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Qin Long >
> ---
>  CryptoPkg/Application/Cryptest/RsaVerify2.c| 17 
>  CryptoPkg/Include/Library/BaseCryptLib.h   | 32 
>  CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c  | 93 
> ++
>  CryptoPkg/Library/BaseCryptLib/Pk/CryptX509Null.c  | 32 
>  .../Pk/CryptX509Null.c | 34 +++-
>  5 files changed, 207 insertions(+), 1 deletion(-)

> diff --git a/CryptoPkg/Include/Library/BaseCryptLib.h 
> b/CryptoPkg/Include/Library/BaseCryptLib.h
> index 9c5ffcd9cf..d861be6725 100644
> --- a/CryptoPkg/Include/Library/BaseCryptLib.h
> +++ b/CryptoPkg/Include/Library/BaseCryptLib.h
> @@ -2171,6 +2171,38 @@ X509GetSubjectName (
>IN OUT  UINTN*SubjectSize
>);
>
> +/**
> +  Retrieve the common name (CN) string from one X.509 certificate.
> +
> +  If Cert or CommonNameSize is NULL, then return FALSE.
> +  If this interface is not supported, then return FALSE.
> +
> +  @param[in]  CertPointer to the DER-encoded X509 
> certificate.
> +  @param[in]  CertSizeSize of the X509 certificate in bytes.
> +  @param[out] CommonName  Buffer to contain the retrieved 
> certificate common
> +  name string. At most CommonNameSize bytes 
> will be
> +  written and the string will be null 
> terminated. May be
> +  NULL in order to determine the size buffer 
> needed.
> +  @param[in,out]  CommonNameSize  The size in bytes of the CommonName buffer 
> on input,
> +  and the size of buffer returned CommonName 
> on output.
> +  if CommonName is NULL then the amount of 
> space needed
> +  in buffer (including the final null) is 
> returned.
> +
> +  @retval  TRUE   The certificate CommonName retrieved successfully.
> +  @retval  FALSE  Invalid certificate, or CommonNameSize is NULL,
> +  or no CommonName entry exists.
> +  @retval  FALSE  This interface is not supported.
> +
> +**/
> +BOOLEAN
> +EFIAPI
> +X509GetCommonName (
> +  IN  CONST UINT8  *Cert,
> +  IN  UINTNCertSize,
> +  OUT CHAR8*CommonName,
> +  IN OUT  UINTN*CommonNameSize
> +  );
> +
>  /**
>Verify one X509 certificate was issued by the trusted CA.
>

I hope my questions / suggestions aren't unwelcome (or misguided) --
have you considered returning RETURN_STATUS from this function?

Currently FALSE is returned for several error cases, but we have good
RETURN_xxx macros for telling them apart:

- RETURN_BUFFER_TOO_SMALL: "The buffer was not large enough to hold the
requested data. The required buffer size is returned in the appropriate
parameter when this error occurs."

- RETURN_UNSUPPORTED: "The operation is not supported."

- RETURN_NOT_FOUND: "The item was not found." -- this can be used for
"no CommonName entry exists".

- RETURN_INVALID_PARAMETER: "The parameter was incorrect." -- this can
be used for "CommonNameSize is NULL", and likely for "Invalid
certificate" as well.

If you don't want to update the interface, I'm OK with that of course; I
just figured I'd raise the question.

Thanks!
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org

Re: [edk2] [PATCH v2 2/3] MdeModulePkg/PartitionDxe: Fix creation of UDF logical partition

[Gao, Liming]

Laszlo:
  ECC depends on antlr V3.0.1. It can be downloaded from 
http://www.antlr3.org/download/Python/
  After download it, use python setup.py install to install it. I try this way 
on Windows OS, it can work. 

Thanks
Liming
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo 
> Ersek
> Sent: Wednesday, September 20, 2017 7:10 PM
> To: Ni, Ruiyu ; Paulo Alcantara ; 
> edk2-devel@lists.01.org
> Cc: Dong, Eric ; Zeng, Star 
> Subject: Re: [edk2] [PATCH v2 2/3] MdeModulePkg/PartitionDxe: Fix creation of 
> UDF logical partition
> 
> On 09/20/17 12:11, Ni, Ruiyu wrote:
> > I am surprised that you don't know ECC tool. 
> > It's a much more complex tool than PatchCheck.py.
> > It's to report all coding style issues that doesn't follow EDKII C coding 
> > style.
> 
> Well, before my previous email, I tried to execute the command line you 
> named, but it didn't work:
> 
> $ source edksetup.sh
> 
> $ Ecc -t MdeModulePkg/Universal/Disk/PartitionDxe -s
> Traceback (most recent call last):
>   File "BaseTools/BinWrappers/PosixLike/../../Source/Python/Ecc/Ecc.py", line 
> 24, in 
> from Check import Check
>   File "BaseTools/Source/Python/Ecc/Check.py", line 20, in 
> import c
>   File "BaseTools/Source/Python/Ecc/c.py", line 18, in 
> import CodeFragmentCollector
>   File "BaseTools/Source/Python/Ecc/CodeFragmentCollector.py", line 23, in 
> 
> import antlr3
> ImportError: No module named antlr3
> 
> Now I'v checked both Fedora and RHEL7 packages for an "antlr3" python module, 
> but it doesn't exist. The "antlr3" package itself exists
> in both distros, but the changelogs say,
> 
> > * Thu Feb 23 2012 Miloš Jakubíček 
> > - 3.4-5 - Disable python runtime (incompatible with current antlr version)
> 
> The following RHBZ looks relevant: 
> 
> 
> Either way, I don't think I can use the ECC tool.
> 
> Thanks,
> Laszlo
> 
> 
> >> -Original Message-
> >> From: Laszlo Ersek [mailto:ler...@redhat.com]
> >> Sent: Wednesday, September 20, 2017 5:59 PM
> >> To: Ni, Ruiyu ; Paulo Alcantara ;
> >> edk2-devel@lists.01.org
> >> Cc: Dong, Eric ; Zeng, Star 
> >> Subject: Re: [PATCH v2 2/3] MdeModulePkg/PartitionDxe: Fix creation of
> >> UDF logical partition
> >>
> >> Ray,
> >>
> >> On 09/20/17 10:14, Ni, Ruiyu wrote:
> >>
> >>> When you add the header comments, please run Python
> >>> BaseTools/Source/Python/Ecc/Ecc.py -t
> >>> MdeModulePkg/Universal/Disk/PartitionDxe -s To make sure there is no
> >> other coding style issue.
> >>
> >> side question: do you mean "PatchCheck.py"?
> >>
> >> I've never heard of "Ecc.py" before, what does it do? (The top comment only
> >> says "This file is used to be the main entrance of ECC tool", and the
> >> "BaseTools/UserManuals" directory doesn't seem to contain anything
> >> related.)
> >>
> >> Thanks,
> >> Laslzo
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] CryptoPkg: Add new API to retrieve commonName of X.509 certificate

[Laszlo Ersek]

Hello Qin,

On 09/19/17 05:38, Long Qin wrote:
> Add one new API (X509GetCommonName()) to retrieve the subject commonName
> string from one X.509 certificate.
> 
> Cc: Ting Ye 
> Cc: Chao Zhang 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Qin Long 
> ---
>  CryptoPkg/Application/Cryptest/RsaVerify2.c| 17 
>  CryptoPkg/Include/Library/BaseCryptLib.h   | 32 
>  CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c  | 93 
> ++
>  CryptoPkg/Library/BaseCryptLib/Pk/CryptX509Null.c  | 32 
>  .../Pk/CryptX509Null.c | 34 +++-
>  5 files changed, 207 insertions(+), 1 deletion(-)

> diff --git a/CryptoPkg/Include/Library/BaseCryptLib.h 
> b/CryptoPkg/Include/Library/BaseCryptLib.h
> index 9c5ffcd9cf..d861be6725 100644
> --- a/CryptoPkg/Include/Library/BaseCryptLib.h
> +++ b/CryptoPkg/Include/Library/BaseCryptLib.h
> @@ -2171,6 +2171,38 @@ X509GetSubjectName (
>IN OUT  UINTN*SubjectSize
>);
>  
> +/**
> +  Retrieve the common name (CN) string from one X.509 certificate.
> +
> +  If Cert or CommonNameSize is NULL, then return FALSE.
> +  If this interface is not supported, then return FALSE.
> +
> +  @param[in]  CertPointer to the DER-encoded X509 
> certificate.
> +  @param[in]  CertSizeSize of the X509 certificate in bytes.
> +  @param[out] CommonName  Buffer to contain the retrieved 
> certificate common
> +  name string. At most CommonNameSize bytes 
> will be
> +  written and the string will be null 
> terminated. May be
> +  NULL in order to determine the size buffer 
> needed.
> +  @param[in,out]  CommonNameSize  The size in bytes of the CommonName buffer 
> on input,
> +  and the size of buffer returned CommonName 
> on output.
> +  if CommonName is NULL then the amount of 
> space needed
> +  in buffer (including the final null) is 
> returned.
> +
> +  @retval  TRUE   The certificate CommonName retrieved successfully.
> +  @retval  FALSE  Invalid certificate, or CommonNameSize is NULL,
> +  or no CommonName entry exists.
> +  @retval  FALSE  This interface is not supported.
> +
> +**/
> +BOOLEAN
> +EFIAPI
> +X509GetCommonName (
> +  IN  CONST UINT8  *Cert,
> +  IN  UINTNCertSize,
> +  OUT CHAR8*CommonName,
> +  IN OUT  UINTN*CommonNameSize
> +  );
> +
>  /**
>Verify one X509 certificate was issued by the trusted CA.
>  

I hope my questions / suggestions aren't unwelcome (or misguided) --
have you considered returning RETURN_STATUS from this function?

Currently FALSE is returned for several error cases, but we have good
RETURN_xxx macros for telling them apart:

- RETURN_BUFFER_TOO_SMALL: "The buffer was not large enough to hold the
requested data. The required buffer size is returned in the appropriate
parameter when this error occurs."

- RETURN_UNSUPPORTED: "The operation is not supported."

- RETURN_NOT_FOUND: "The item was not found." -- this can be used for
"no CommonName entry exists".

- RETURN_INVALID_PARAMETER: "The parameter was incorrect." -- this can
be used for "CommonNameSize is NULL", and likely for "Invalid
certificate" as well.

If you don't want to update the interface, I'm OK with that of course; I
just figured I'd raise the question.

Thanks!
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/3] OvmfPkg/QemuVideoDxe/VbeShim: handle PAM1 register on Q35 correctly

[Laszlo Ersek]

On 09/20/17 09:05, Aleksei wrote:
> Hi Laszlo,
> 
> I've built it (despite edk2/ovmf build process being as convoluted as
> ever)

Criticism well deserved :) , but at least we have excuses
(multi-platform, multi-compiler build system, and freestanding (i.e.,
not hosted) codebase).

> and am trying to run it with qemu 2.10.0 - it's not booting at
> all, stuck at "Guest has not initialized the display (yet)."
> 
> Maybe the problem is gcc version? I have 7.2.0 while edk2 instructions
> mention gcc5.

Hm, my prime suspect isn't gcc-7.2 (it should work with the GCC5
toolchain, but just to be sure you can try the GCC49 toolchain as well
with it).

My prime suspect is that you've been using a 2MB firmware image
(speaking in unified image terms) from Gerd's firmware repo, but the
upstream default is now 4MB.

You can't mix and match (a) firmware binary and (b) variable store
between different unified sizes; that is, if your previous firmware was
2MB in size (unified), you have to pass the following switch to your new
build too:

  -D FD_SIZE_2MB

Are you on IRC? I'll hop on #edk2 on OFTC for a while now (nick is
"lersek").

Thanks,
Laszlo

> 
> On 19/09/17 22:18, Laszlo Ersek wrote:
>> Repo:   https://github.com/lersek/edk2.git
>> Branch: vbe_shim_q35_pam
>>
>> Fix the long-standing OVMF/Q35 bug recently exposed by a QEMU change,
>> and reported under .
>>
>> Aleksei, can you please fetch the branch, build it, and report back with
>> your Tested-by if it works for you?
>>
>> I performed my own tests as well; I'll include those in a separate
>> email.
>>
>> Cc: Aleksei Kovura 
>> Cc: Gerd Hoffmann 
>> Cc: Igor Mammedov 
>> Cc: Jordan Justen 
>> Cc: Ruiyu Ni 
>>
>> Thank you,
>> Laszlo
>>
>> Laszlo Ersek (3):
>>    OvmfPkg/CsmSupportLib: move PAM register addresses to IndustryStandard
>>    OvmfPkg/QemuVideoDxe/VbeShim: rename Status to
>>  Segment0AllocationStatus
>>    OvmfPkg/QemuVideoDxe/VbeShim: handle PAM1 register on Q35 correctly
>>
>>   OvmfPkg/Csm/CsmSupportLib/LegacyRegion.c   | 62
>> ++--
>>   OvmfPkg/Csm/CsmSupportLib/LegacyRegion.h   | 22 +--
>>   OvmfPkg/Include/IndustryStandard/I440FxPiix4.h | 13 
>>   OvmfPkg/Include/IndustryStandard/Q35MchIch9.h  |  8 +++
>>   OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf  |  3 +-
>>   OvmfPkg/QemuVideoDxe/VbeShim.c | 47 ---
>>   6 files changed, 95 insertions(+), 60 deletions(-)
>>
> 

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 2/3] MdeModulePkg/PartitionDxe: Fix creation of UDF logical partition

[Laszlo Ersek]

On 09/20/17 12:11, Ni, Ruiyu wrote:
> I am surprised that you don't know ECC tool. 
> It's a much more complex tool than PatchCheck.py.
> It's to report all coding style issues that doesn't follow EDKII C coding 
> style.

Well, before my previous email, I tried to execute the command line you named, 
but it didn't work:

$ source edksetup.sh

$ Ecc -t MdeModulePkg/Universal/Disk/PartitionDxe -s
Traceback (most recent call last):
  File "BaseTools/BinWrappers/PosixLike/../../Source/Python/Ecc/Ecc.py", line 
24, in 
from Check import Check
  File "BaseTools/Source/Python/Ecc/Check.py", line 20, in 
import c
  File "BaseTools/Source/Python/Ecc/c.py", line 18, in 
import CodeFragmentCollector
  File "BaseTools/Source/Python/Ecc/CodeFragmentCollector.py", line 23, in 

import antlr3
ImportError: No module named antlr3

Now I'v checked both Fedora and RHEL7 packages for an "antlr3" python module, 
but it doesn't exist. The "antlr3" package itself exists in both distros, but 
the changelogs say,

> * Thu Feb 23 2012 Miloš Jakubíček 
> - 3.4-5 - Disable python runtime (incompatible with current antlr version)

The following RHBZ looks relevant: 


Either way, I don't think I can use the ECC tool.

Thanks,
Laszlo


>> -Original Message-
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Wednesday, September 20, 2017 5:59 PM
>> To: Ni, Ruiyu ; Paulo Alcantara ;
>> edk2-devel@lists.01.org
>> Cc: Dong, Eric ; Zeng, Star 
>> Subject: Re: [PATCH v2 2/3] MdeModulePkg/PartitionDxe: Fix creation of
>> UDF logical partition
>>
>> Ray,
>>
>> On 09/20/17 10:14, Ni, Ruiyu wrote:
>>
>>> When you add the header comments, please run Python
>>> BaseTools/Source/Python/Ecc/Ecc.py -t
>>> MdeModulePkg/Universal/Disk/PartitionDxe -s To make sure there is no
>> other coding style issue.
>>
>> side question: do you mean "PatchCheck.py"?
>>
>> I've never heard of "Ecc.py" before, what does it do? (The top comment only
>> says "This file is used to be the main entrance of ECC tool", and the
>> "BaseTools/UserManuals" directory doesn't seem to contain anything
>> related.)
>>
>> Thanks,
>> Laslzo

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 2/3] MdeModulePkg/PartitionDxe: Fix creation of UDF logical partition

[Ni, Ruiyu]

I am surprised that you don't know ECC tool. 
It's a much more complex tool than PatchCheck.py.
It's to report all coding style issues that doesn't follow EDKII C coding style.


Thanks/Ray

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Wednesday, September 20, 2017 5:59 PM
> To: Ni, Ruiyu ; Paulo Alcantara ;
> edk2-devel@lists.01.org
> Cc: Dong, Eric ; Zeng, Star 
> Subject: Re: [PATCH v2 2/3] MdeModulePkg/PartitionDxe: Fix creation of
> UDF logical partition
> 
> Ray,
> 
> On 09/20/17 10:14, Ni, Ruiyu wrote:
> 
> > When you add the header comments, please run Python
> > BaseTools/Source/Python/Ecc/Ecc.py -t
> > MdeModulePkg/Universal/Disk/PartitionDxe -s To make sure there is no
> other coding style issue.
> 
> side question: do you mean "PatchCheck.py"?
> 
> I've never heard of "Ecc.py" before, what does it do? (The top comment only
> says "This file is used to be the main entrance of ECC tool", and the
> "BaseTools/UserManuals" directory doesn't seem to contain anything
> related.)
> 
> Thanks,
> Laslzo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 2/3] MdeModulePkg/PartitionDxe: Fix creation of UDF logical partition

[Laszlo Ersek]

Ray,

On 09/20/17 10:14, Ni, Ruiyu wrote:

> When you add the header comments, please run
> Python BaseTools/Source/Python/Ecc/Ecc.py -t 
> MdeModulePkg/Universal/Disk/PartitionDxe -s
> To make sure there is no other coding style issue.

side question: do you mean "PatchCheck.py"?

I've never heard of "Ecc.py" before, what does it do? (The top comment
only says "This file is used to be the main entrance of ECC tool", and
the "BaseTools/UserManuals" directory doesn't seem to contain anything
related.)

Thanks,
Laslzo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 2/2] MdeModulePkg/Core: Fix out-of-sync issue in GCD

[Zeng, Star]

Reviewed-by: Star Zeng  for this patch.

Please notice that the MemoryProtection.c is using gCpu->SetMemoryAttributes 
but not GCD SetMemorySpaceAttributes.
You should need update it to use GCD SetMemorySpaceAttributes, you can have 
separated patch to cover it.


Thanks,
Star
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jian J 
Wang
Sent: Tuesday, September 19, 2017 2:10 PM
To: edk2-devel@lists.01.org
Cc: Kinney, Michael D ; Laszlo Ersek 
; Yao, Jiewen ; Dong, Eric 
; Zeng, Star 
Subject: [edk2] [PATCH 2/2] MdeModulePkg/Core: Fix out-of-sync issue in GCD

>From GCD perspective, its SetMemorySpaceAttributes() method doesn't accept 
>page related attributes. That means users cannot use it to change page 
>attributes, and have to turn to CPU arch protocol to do it, which is not be 
>allowed by PI spec.

Cc: Jiewen Yao 
Cc: Eric Dong 
Cc: Star Zeng 
Cc: Laszlo Ersek 
Cc: Michael Kinney 
Suggested-by: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 MdeModulePkg/Core/Dxe/Gcd/Gcd.c | 45 -
 1 file changed, 27 insertions(+), 18 deletions(-)

diff --git a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c 
index a06f8bb77c..e9d1d5b612 100644
--- a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
+++ b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
@@ -40,6 +40,13 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 
 #define PRESENT_MEMORY_ATTRIBUTES (EFI_RESOURCE_ATTRIBUTE_PRESENT)
 
+#define EXCLUSIVE_MEMORY_ATTRIBUTES   (EFI_MEMORY_UC | EFI_MEMORY_WC | \
+   EFI_MEMORY_WT | EFI_MEMORY_WB | \
+   EFI_MEMORY_WP | EFI_MEMORY_UCE)
+
+#define NONEXCLUSIVE_MEMORY_ATTRIBUTES (EFI_MEMORY_XP | EFI_MEMORY_RP | \
+EFI_MEMORY_RO)
+
 #define INVALID_CPU_ARCH_ATTRIBUTES   0x
 
 //
@@ -654,28 +661,30 @@ ConverToCpuArchAttributes (
   UINT64 Attributes
   )
 {
-  if ( (Attributes & EFI_MEMORY_UC) == EFI_MEMORY_UC) {
-return EFI_MEMORY_UC;
-  }
+  UINT64  CpuArchAttributes;
 
-  if ( (Attributes & EFI_MEMORY_WC ) == EFI_MEMORY_WC) {
-return EFI_MEMORY_WC;
+  if ((Attributes & ~(EXCLUSIVE_MEMORY_ATTRIBUTES |
+  NONEXCLUSIVE_MEMORY_ATTRIBUTES)) != 0) {
+return INVALID_CPU_ARCH_ATTRIBUTES;
   }
 
-  if ( (Attributes & EFI_MEMORY_WT ) == EFI_MEMORY_WT) {
-return EFI_MEMORY_WT;
-  }
-
-  if ( (Attributes & EFI_MEMORY_WB) == EFI_MEMORY_WB) {
-return EFI_MEMORY_WB;
-  }
-
-  if ( (Attributes & EFI_MEMORY_WP) == EFI_MEMORY_WP) {
-return EFI_MEMORY_WP;
-  }
-
-  return INVALID_CPU_ARCH_ATTRIBUTES;
+  CpuArchAttributes = Attributes & NONEXCLUSIVE_MEMORY_ATTRIBUTES;
 
+  if ( (Attributes & EFI_MEMORY_UC) == EFI_MEMORY_UC) {
+CpuArchAttributes |= EFI_MEMORY_UC;  } else if ( (Attributes & 
+ EFI_MEMORY_WC ) == EFI_MEMORY_WC) {
+CpuArchAttributes |= EFI_MEMORY_WC;  } else if ( (Attributes & 
+ EFI_MEMORY_WT ) == EFI_MEMORY_WT) {
+CpuArchAttributes |= EFI_MEMORY_WT;  } else if ( (Attributes & 
+ EFI_MEMORY_WB) == EFI_MEMORY_WB) {
+CpuArchAttributes |= EFI_MEMORY_WB;  } else if ( (Attributes & 
+ EFI_MEMORY_UCE) == EFI_MEMORY_UCE) {
+CpuArchAttributes |= EFI_MEMORY_UCE;  } else if ( (Attributes & 
+ EFI_MEMORY_WP) == EFI_MEMORY_WP) {
+CpuArchAttributes |= EFI_MEMORY_WP;  }
+
+  return CpuArchAttributes;
 }
 
 
--
2.14.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH V5 5/6] MdeModulePkg/SetupBrowser: Handle questions with Bit VarStore

[Dandan Bi]

V5: Update the EDKII extension GUID name with EDKII/Edkii prefix.
Refine the interface and implemetation of function
GetBitsQuestionValue and SetBitsQuestionValue.

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=545

For oneof/numeric/CheckBox(storage can be Bit VarStore)
If the question value can be updated and shown correctly
in UI page, we need do enhancements in following cases:
1. Parse the Ifr data to get the bit VarStore info correctly.
2. Set/get value to/from bit VarStore correctly.

Cc: Eric Dong 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi 
---
 MdeModulePkg/Universal/SetupBrowserDxe/IfrParse.c  | 138 -
 MdeModulePkg/Universal/SetupBrowserDxe/Setup.c | 117 +++--
 MdeModulePkg/Universal/SetupBrowserDxe/Setup.h |   3 +
 .../Universal/SetupBrowserDxe/SetupBrowserDxe.inf  |   3 +-
 4 files changed, 219 insertions(+), 42 deletions(-)

diff --git a/MdeModulePkg/Universal/SetupBrowserDxe/IfrParse.c 
b/MdeModulePkg/Universal/SetupBrowserDxe/IfrParse.c
index 6b3e5e0..3081eb8 100644
--- a/MdeModulePkg/Universal/SetupBrowserDxe/IfrParse.c
+++ b/MdeModulePkg/Universal/SetupBrowserDxe/IfrParse.c
@@ -57,10 +57,11 @@ CreateStatement (
 
   Statement->Signature = FORM_BROWSER_STATEMENT_SIGNATURE;
 
   Statement->Operand = ((EFI_IFR_OP_HEADER *) OpCodeData)->OpCode;
   Statement->OpCode  = (EFI_IFR_OP_HEADER *) OpCodeData;
+  Statement->QuestionReferToBitField = FALSE;
 
   StatementHdr = (EFI_IFR_STATEMENT_HEADER *) (OpCodeData + sizeof 
(EFI_IFR_OP_HEADER));
   CopyMem (>Prompt, >Prompt, sizeof (EFI_STRING_ID));
   CopyMem (>Help, >Help, sizeof (EFI_STRING_ID));
 
@@ -1312,10 +1313,12 @@ ParseOpCodes (
   BOOLEAN InUnknownScope;
   UINT8   UnknownDepth;
   FORMSET_DEFAULTSTORE*PreDefaultStore;
   LIST_ENTRY  *DefaultLink;
   BOOLEAN HaveInserted;
+  UINT16  TotalBits;
+  BOOLEAN QuestionReferBitField;
 
   SuppressForQuestion  = FALSE;
   SuppressForOption= FALSE;
   InScopeDisable   = FALSE;
   DepthOfDisable   = 0;
@@ -1333,10 +1336,11 @@ ParseOpCodes (
   MapExpressionList= NULL;
   TempVarstoreId   = 0;
   ConditionalExprCount = 0;
   InUnknownScope   = FALSE;
   UnknownDepth = 0;
+  QuestionReferBitField= FALSE;
 
   //
   // Get the number of Statements and Expressions
   //
   CountOpCodes (FormSet, , );
@@ -1978,47 +1982,98 @@ ParseOpCodes (
   ASSERT(CurrentStatement != NULL);
 
   CurrentStatement->Flags = ((EFI_IFR_ONE_OF *) OpCodeData)->Flags;
   Value = >HiiValue;
 
-  switch (CurrentStatement->Flags & EFI_IFR_NUMERIC_SIZE) {
-  case EFI_IFR_NUMERIC_SIZE_1:
-CurrentStatement->Minimum = ((EFI_IFR_NUMERIC *) 
OpCodeData)->data.u8.MinValue;
-CurrentStatement->Maximum = ((EFI_IFR_NUMERIC *) 
OpCodeData)->data.u8.MaxValue;
-CurrentStatement->Step= ((EFI_IFR_NUMERIC *) 
OpCodeData)->data.u8.Step;
-CurrentStatement->StorageWidth = (UINT16) sizeof (UINT8);
-Value->Type = EFI_IFR_TYPE_NUM_SIZE_8;
-break;
+  if (QuestionReferBitField) {
+//
+// Get the bit var store info (bit/byte offset, bit/byte offset)
+//
+CurrentStatement->QuestionReferToBitField = TRUE;
+CurrentStatement->BitStorageWidth = CurrentStatement->Flags & 
EFI_IFR_NUMERIC_SIZE_BIT;
+CurrentStatement->BitVarOffset = 
CurrentStatement->VarStoreInfo.VarOffset;
+CurrentStatement->VarStoreInfo.VarOffset = 
CurrentStatement->BitVarOffset / 8;
+TotalBits = CurrentStatement->BitVarOffset % 8 + 
CurrentStatement->BitStorageWidth;
+CurrentStatement->StorageWidth = (TotalBits % 8 == 0? TotalBits / 8: 
TotalBits / 8 + 1);
 
-  case EFI_IFR_NUMERIC_SIZE_2:
-CopyMem (>Minimum, &((EFI_IFR_NUMERIC *) 
OpCodeData)->data.u16.MinValue, sizeof (UINT16));
-CopyMem (>Maximum, &((EFI_IFR_NUMERIC *) 
OpCodeData)->data.u16.MaxValue, sizeof (UINT16));
-CopyMem (>Step,&((EFI_IFR_NUMERIC *) 
OpCodeData)->data.u16.Step, sizeof (UINT16));
-CurrentStatement->StorageWidth = (UINT16) sizeof (UINT16);
-Value->Type = EFI_IFR_TYPE_NUM_SIZE_16;
-break;
+//
+// Get the Minimum/Maximum/Step value(Note: bit field type has been 
stored as UINT32 type)
+//
+CurrentStatement->Minimum = ((EFI_IFR_NUMERIC *) 
OpCodeData)->data.u32.MinValue;
+CurrentStatement->Maximum = ((EFI_IFR_NUMERIC *) 
OpCodeData)->data.u32.MaxValue;
+CurrentStatement->Step= ((EFI_IFR_NUMERIC *) 
OpCodeData)->data.u32.Step;
 
-  case EFI_IFR_NUMERIC_SIZE_4:
-CopyMem (>Minimum, &((EFI_IFR_NUMERIC *) 
OpCodeData)->data.u32.MinValue, sizeof (UINT32));
-CopyMem (>Maximum, &((EFI_IFR_NUMERIC *) 

[edk2] [PATCH V5 6/6] MdeModulePkg/DriverSample: Add questions with bit/union VarStore

[Dandan Bi]

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=545

Cc: Eric Dong 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi 
---
 .../Universal/DriverSampleDxe/DriverSample.c   | 120 ++
 .../Universal/DriverSampleDxe/DriverSample.h   |   2 +
 .../Universal/DriverSampleDxe/NVDataStruc.h|  34 +++-
 MdeModulePkg/Universal/DriverSampleDxe/Vfr.vfr | 172 +
 .../Universal/DriverSampleDxe/VfrStrings.uni   |  63 
 5 files changed, 390 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c 
b/MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c
index bbd9713..af31615 100644
--- a/MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c
+++ b/MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c
@@ -18,10 +18,13 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 
 #define DISPLAY_ONLY_MY_ITEM  0x0002
 
 CHAR16 VariableName[] = L"MyIfrNVData";
 CHAR16 MyEfiVar[] = L"MyEfiVar";
+CHAR16 MyEfiBitVar[] = L"MyEfiBitVar";
+CHAR16 MyEfiUnionVar[] = L"MyEfiUnionVar";
+
 EFI_HANDLE  DriverHandle[2] = {NULL, NULL};
 DRIVER_SAMPLE_PRIVATE_DATA  *mPrivateData = NULL;
 EFI_EVENT   mEvent;
 
 HII_VENDOR_DEVICE_PATH  mHiiVendorDevicePath0 = {
@@ -662,10 +665,17 @@ ExtractConfig (
 // through hii database, not support in this path.
 //
 if (HiiIsConfigHdrMatch(Request, , MyEfiVar)) {
   return EFI_UNSUPPORTED;
 }
+if (HiiIsConfigHdrMatch(Request, , MyEfiBitVar)) {
+  return EFI_UNSUPPORTED;
+}
+if (HiiIsConfigHdrMatch(Request, , 
MyEfiUnionVar)) {
+  return EFI_UNSUPPORTED;
+}
+
 //
 // Set Request to the unified request string.
 //
 ConfigRequest = Request;
 //
@@ -883,10 +893,16 @@ RouteConfig (
   // through hii database, not support in this path.
   //
   if (HiiIsConfigHdrMatch(Configuration, , MyEfiVar)) 
{
 return EFI_UNSUPPORTED;
   }
+  if (HiiIsConfigHdrMatch(Configuration, , 
MyEfiBitVar)) {
+return EFI_UNSUPPORTED;
+  }
+  if (HiiIsConfigHdrMatch(Configuration, , 
MyEfiUnionVar)) {
+return EFI_UNSUPPORTED;
+  }
 
   //
   // Get Buffer Storage data from EFI variable
   //
   BufferSize = sizeof (DRIVER_SAMPLE_CONFIGURATION);
@@ -1295,10 +1311,14 @@ DriverCallback (
 for (Index = 0; Index < 3; Index ++) {
   SetArrayData (Value, EFI_IFR_TYPE_NUM_SIZE_8, Index, BufferValue--);
 }
   break;
 
+  case 0x:
+Value->u8 = 12;
+break;
+
   default:
 Status = EFI_UNSUPPORTED;
   break;
   }
 }
@@ -1309,10 +1329,14 @@ DriverCallback (
   switch (QuestionId) {
   case 0x1240:
 Value->u8 = DEFAULT_CLASS_MANUFACTURING_VALUE;
   break;
 
+ case 0x:
+Value->u8 = 13;
+break;
+
   default:
 Status = EFI_UNSUPPORTED;  
   break;
   }
 }
@@ -1703,10 +1727,12 @@ DriverSampleInit (
   DRIVER_SAMPLE_CONFIGURATION *Configuration;
   BOOLEAN ActionFlag;
   EFI_STRING  ConfigRequestHdr;
   EFI_STRING  NameRequestHdr;
   MY_EFI_VARSTORE_DATA*VarStoreConfig;
+  MY_EFI_BITS_VARSTORE_DATA   *BitsVarStoreConfig;
+  MY_EFI_UNION_DATA   *UnionConfig;
   EFI_INPUT_KEY   HotKey;
   EDKII_FORM_BROWSER_EXTENSION_PROTOCOL *FormBrowserEx;
 
   //
   // Initialize the local variables.
@@ -1991,10 +2017,104 @@ DriverSampleInit (
   return EFI_INVALID_PARAMETER;
 }
   }
   FreePool (ConfigRequestHdr);
 
+  //
+  // Initialize Bits efi varstore configuration data
+  //
+  BitsVarStoreConfig = >BitsVarStoreConfig;
+  ZeroMem (BitsVarStoreConfig, sizeof (MY_EFI_BITS_VARSTORE_DATA));
+
+  ConfigRequestHdr = HiiConstructConfigHdr (, 
MyEfiBitVar, DriverHandle[0]);
+  ASSERT (ConfigRequestHdr != NULL);
+
+  BufferSize = sizeof (MY_EFI_BITS_VARSTORE_DATA);
+  Status = gRT->GetVariable (MyEfiBitVar, , NULL, 
, BitsVarStoreConfig);
+  if (EFI_ERROR (Status)) {
+//
+// Store zero data to EFI variable Storage.
+//
+Status = gRT->SetVariable(
+MyEfiBitVar,
+,
+EFI_VARIABLE_NON_VOLATILE | 
EFI_VARIABLE_BOOTSERVICE_ACCESS,
+sizeof (MY_EFI_BITS_VARSTORE_DATA),
+BitsVarStoreConfig
+);
+if (EFI_ERROR (Status)) {
+  DriverSampleUnload (ImageHandle);
+  return Status;
+}
+//
+// EFI variable for NV config doesn't exit, we should build this variable
+// based on default values stored in IFR
+//
+ActionFlag = HiiSetToDefaults (ConfigRequestHdr, 
EFI_HII_DEFAULT_CLASS_STANDARD);
+if (!ActionFlag) {
+  DriverSampleUnload (ImageHandle);
+  return EFI_INVALID_PARAMETER;

[edk2] [PATCH V5 3/6] MdeModulePkg/UefiHiiLib: Validate question with bit fields

[Dandan Bi]

V5: Update the EDKII extension GUID name with EDKII/Edkii prefix.

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=545

In UefiHiiLib, there are codes to validate the current setting of
questions, now update the logic to handle question with bit storage.

Cc: Eric Dong 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi 
---
 MdeModulePkg/Library/UefiHiiLib/HiiLib.c | 246 ---
 MdeModulePkg/Library/UefiHiiLib/InternalHiiLib.h |   4 +-
 MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf   |   5 +-
 3 files changed, 178 insertions(+), 77 deletions(-)

diff --git a/MdeModulePkg/Library/UefiHiiLib/HiiLib.c 
b/MdeModulePkg/Library/UefiHiiLib/HiiLib.c
index 583b9e5..e9e94f4 100644
--- a/MdeModulePkg/Library/UefiHiiLib/HiiLib.c
+++ b/MdeModulePkg/Library/UefiHiiLib/HiiLib.c
@@ -1167,10 +1167,16 @@ ValidateQuestionFromVfr (
   EFI_IFR_STRING   *IfrString;
   CHAR8*VarStoreName;
   UINTNIndex;
   CHAR16   *QuestionName;
   CHAR16   *StringPtr;
+  UINT16   BitOffset;
+  UINT16   BitWidth;
+  UINT16   TotalBits;
+  UINTNStartBit;
+  UINTNEndBit;
+  BOOLEAN  QuestionReferBitField;
 
   //
   // Initialize the local variables.
   //
   Index = 0;
@@ -1180,10 +1186,13 @@ ValidateQuestionFromVfr (
   IfrVarStore   = NULL;
   IfrNameValueStore = NULL;
   IfrEfiVarStore= NULL;
   ZeroMem (, sizeof (IFR_VARSTORAGE_DATA));
   ZeroMem (, sizeof (VarBlockData));
+  BitOffset = 0;
+  BitWidth = 0;
+  QuestionReferBitField = FALSE;
 
   //
   // Check IFR value is in block data, then Validate Value
   //
   PackageOffset = sizeof (EFI_HII_PACKAGE_LIST_HEADER);
@@ -1343,12 +1352,23 @@ ValidateQuestionFromVfr (
 }
   } else {
 //
 // Get Offset by Question header and Width by DataType Flags
 //
-Offset = IfrOneOf->Question.VarStoreInfo.VarOffset;
-Width  = (UINT16) (1 << (IfrOneOf->Flags & EFI_IFR_NUMERIC_SIZE));
+if (QuestionReferBitField) {
+  //
+  // Get the byte offset/width for bit field.
+  //
+  BitOffset = IfrOneOf->Question.VarStoreInfo.VarOffset;
+  BitWidth = IfrOneOf->Flags & EFI_IFR_NUMERIC_SIZE_BIT;
+  Offset = BitOffset / 8;
+  TotalBits = BitOffset % 8 + BitWidth;
+  Width = (TotalBits % 8 == 0 ? TotalBits / 8: TotalBits / 8 + 1);
+} else {
+  Offset = IfrOneOf->Question.VarStoreInfo.VarOffset;
+  Width  = (UINT16) (1 << (IfrOneOf->Flags & 
EFI_IFR_NUMERIC_SIZE));
+}
 //
 // Check whether this question is in current block array.
 //
 if (!BlockArrayCheck (CurrentBlockArray, Offset, Width)) {
   //
@@ -1368,11 +1388,20 @@ ValidateQuestionFromVfr (
 
 //
 // Get the current value for oneof opcode
 //
 VarValue = 0;
-CopyMem (, VarBuffer +  Offset, Width);
+if (QuestionReferBitField) {
+  //
+  // Get the value in bit fields.
+  //
+  StartBit = BitOffset % 8;
+  EndBit = StartBit + BitWidth - 1;
+  VarValue = BitFieldRead32 (*(UINT32*)(VarBuffer + Offset), 
StartBit, EndBit);
+} else {
+  CopyMem (, VarBuffer +  Offset, Width);
+}
   }
   //
   // Set Block Data, to be checked in the following Oneof option 
opcode.
   //
   VarBlockData.OpCode = IfrOpHdr->OpCode;
@@ -1414,12 +1443,23 @@ ValidateQuestionFromVfr (
 }
   } else {
 //
 // Get Offset by Question header and Width by DataType Flags
 //
-Offset = IfrNumeric->Question.VarStoreInfo.VarOffset;
-Width  = (UINT16) (1 << (IfrNumeric->Flags & 
EFI_IFR_NUMERIC_SIZE));
+if (QuestionReferBitField) {
+  //
+  // Get the byte offset/width for bit field.
+  //
+  BitOffset = IfrNumeric->Question.VarStoreInfo.VarOffset;
+  BitWidth = IfrNumeric->Flags & EFI_IFR_NUMERIC_SIZE_BIT;
+  Offset = BitOffset / 8;
+  TotalBits = BitOffset % 8 + BitWidth;
+  Width  = (TotalBits % 8 == 0 ? TotalBits / 8: TotalBits / 8 + 1);
+} else {
+  Offset = IfrNumeric->Question.VarStoreInfo.VarOffset;
+  Width  = (UINT16) (1 << (IfrNumeric->Flags & 
EFI_IFR_NUMERIC_SIZE));
+}
 //
 // Check whether this question is in current block array.
 

[edk2] [PATCH V5 0/6] Support bitfield in storage of vfr

[Dandan Bi]

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=545

This patch series is to:
(1) Update VfrCompiler to parse bit field in data structure.
(2) Update HiiDatabase,SetupBrowser and UefiHiiLib to handle questions with Bit 
VarStore.
(3) Add sample questions with bit/union VarStore in DriverSample.

Cc: Eric Dong 
Cc: Liming Gao 

Dandan Bi (6):
  BaseTool/VfrCompiler: Support Bit fields in EFI/Buffer VarStore
  MdeModulePkg: Add GUID/flags to implement BitField support
  MdeModulePkg/UefiHiiLib: Validate question with bit fields
  MdeModulePkg/HiiDatabase: Handle questions with Bit VarStore
  MdeModulePkg/SetupBrowser: Handle questions with Bit VarStore
  MdeModulePkg/DriverSample: Add questions with bit/union VarStore

 BaseTools/Source/C/Include/Common/MdeModuleHii.h   |   20 +-
 BaseTools/Source/C/VfrCompile/VfrError.cpp |3 +-
 BaseTools/Source/C/VfrCompile/VfrError.h   |3 +-
 BaseTools/Source/C/VfrCompile/VfrFormPkg.cpp   |  105 +-
 BaseTools/Source/C/VfrCompile/VfrFormPkg.h |   52 +-
 BaseTools/Source/C/VfrCompile/VfrSyntax.g  | 1238 +---
 BaseTools/Source/C/VfrCompile/VfrUtilityLib.cpp|  240 +++-
 BaseTools/Source/C/VfrCompile/VfrUtilityLib.h  |   23 +-
 MdeModulePkg/Include/Guid/MdeModuleHii.h   |   20 +-
 MdeModulePkg/Library/UefiHiiLib/HiiLib.c   |  246 ++--
 MdeModulePkg/Library/UefiHiiLib/InternalHiiLib.h   |4 +-
 MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf |5 +-
 MdeModulePkg/MdeModulePkg.dec  |4 +
 .../Universal/DriverSampleDxe/DriverSample.c   |  120 ++
 .../Universal/DriverSampleDxe/DriverSample.h   |2 +
 .../Universal/DriverSampleDxe/NVDataStruc.h|   34 +-
 MdeModulePkg/Universal/DriverSampleDxe/Vfr.vfr |  172 +++
 .../Universal/DriverSampleDxe/VfrStrings.uni   |   63 +
 .../Universal/HiiDatabaseDxe/ConfigRouting.c   |  346 +-
 .../Universal/HiiDatabaseDxe/HiiDatabase.h |6 +-
 .../Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf|3 +-
 MdeModulePkg/Universal/SetupBrowserDxe/IfrParse.c  |  138 ++-
 MdeModulePkg/Universal/SetupBrowserDxe/Setup.c |  117 +-
 MdeModulePkg/Universal/SetupBrowserDxe/Setup.h |3 +
 .../Universal/SetupBrowserDxe/SetupBrowserDxe.inf  |3 +-
 25 files changed, 2323 insertions(+), 647 deletions(-)

-- 
1.9.5.msysgit.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH V5 4/6] MdeModulePkg/HiiDatabase: Handle questions with Bit VarStore

[Dandan Bi]

V5: Update the EDKII extension GUID name with EDKII/Edkii prefix.

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=545

For oneof/numeric/checkbox, their storage may be bit field.
When generating  string to get default value
for these questions, we need to parse the Ifr data to get
the bit Varstore info,and then generating the correct
 string.

Cc: Eric Dong 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi 
---
 .../Universal/HiiDatabaseDxe/ConfigRouting.c   | 346 +++--
 .../Universal/HiiDatabaseDxe/HiiDatabase.h |   6 +-
 .../Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf|   3 +-
 3 files changed, 319 insertions(+), 36 deletions(-)

diff --git a/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c 
b/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c
index c9ff1cf..a87f31e 100644
--- a/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c
+++ b/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c
@@ -1223,19 +1223,19 @@ InsertBlockData (
   // Insert block data in its Offset and Width order.
   //
   for (Link = BlockLink->ForwardLink; Link != BlockLink; Link = 
Link->ForwardLink) {
 BlockArray = BASE_CR (Link, IFR_BLOCK_DATA, Entry);
 if (BlockArray->Offset == BlockSingleData->Offset) {
-  if (BlockArray->Width > BlockSingleData->Width) {
+  if ((BlockArray->Width > BlockSingleData->Width) || 
(BlockSingleData->IsBitVar && BlockArray->Width == BlockSingleData->Width)) {
 //
 // Insert this block data in the front of block array
 //
 InsertTailList (Link, >Entry);
 return;
   }
 
-  if (BlockArray->Width == BlockSingleData->Width) {
+  if ((!BlockSingleData->IsBitVar) && BlockArray->Width == 
BlockSingleData->Width) {
 //
 // The same block array has been added.
 //
 if (BlockSingleData != BlockArray) {
   FreePool (BlockSingleData);
@@ -1978,10 +1978,11 @@ Done:
   @param  HiiHandle  The hii handle for this form package.
   @param  VarStorageData The varstore data structure.
   @param  IfrOpHdr   Ifr opcode header for this opcode.
   @param  VarWidth   The buffer width for this opcode.
   @param  ReturnData The data block added for this opcode.
+  @param  IsBitVar   Whether the the opcode refers to bit storage.
 
   @retval  EFI_SUCCESS   This opcode is required.
   @retval  EFI_NOT_FOUND This opcode is not required.
   @retval  OthersContain some error.
  
@@ -1991,20 +1992,26 @@ IsThisOpcodeRequired (
   IN IFR_BLOCK_DATA   *RequestBlockArray,
   IN EFI_HII_HANDLE   HiiHandle,
   IN OUT IFR_VARSTORAGE_DATA  *VarStorageData,
   IN EFI_IFR_OP_HEADER*IfrOpHdr,
   IN UINT16   VarWidth,
-  OUTIFR_BLOCK_DATA   **ReturnData
+  OUTIFR_BLOCK_DATA   **ReturnData,
+  IN BOOLEAN  IsBitVar
   )
 {
   IFR_BLOCK_DATA   *BlockData;
   UINT16   VarOffset;
   EFI_STRING_IDNameId;
   EFI_IFR_QUESTION_HEADER  *IfrQuestionHdr;
+  UINT16   BitOffset;
+  UINT16   BitWidth;
+  UINT16   TotalBits;
 
   NameId= 0;
   VarOffset = 0;
+  BitOffset = 0;
+  BitWidth = 0;
   IfrQuestionHdr = (EFI_IFR_QUESTION_HEADER  *)((CHAR8 *) IfrOpHdr + sizeof 
(EFI_IFR_OP_HEADER));
 
   if (VarStorageData->Type == EFI_HII_VARSTORE_NAME_VALUE) {
 NameId = IfrQuestionHdr->VarStoreInfo.VarName;
 
@@ -2016,11 +2023,27 @@ IsThisOpcodeRequired (
   // This question is not in the requested string. Skip it.
   //
   return EFI_NOT_FOUND;
 }
   } else {
-VarOffset = IfrQuestionHdr->VarStoreInfo.VarOffset;
+//
+// Get the byte offset/with and bit offset/width
+//
+if (IsBitVar) {
+  BitOffset = IfrQuestionHdr->VarStoreInfo.VarOffset;
+  BitWidth = VarWidth;
+  VarOffset = BitOffset / 8;
+  //
+  // Use current bit width and the bit width before current bit (with same 
byte offset) to calculate the byte width.
+  //
+  TotalBits = BitOffset % 8 + BitWidth;
+  VarWidth = (TotalBits % 8 == 0 ? TotalBits / 8: TotalBits / 8 + 1);
+} else {
+  VarOffset = IfrQuestionHdr->VarStoreInfo.VarOffset;
+  BitWidth = VarWidth;
+  BitOffset = VarOffset * 8;
+}
 
 //
 // Check whether this question is in requested block array.
 //
 if (!BlockArrayCheck (RequestBlockArray, VarOffset, VarWidth, FALSE, 
HiiHandle)) {
@@ -2051,10 +2074,13 @@ IsThisOpcodeRequired (
 
   BlockData->Width  = VarWidth;
   BlockData->QuestionId = IfrQuestionHdr->QuestionId;
   BlockData->OpCode = IfrOpHdr->OpCode;
   BlockData->Scope  = IfrOpHdr->Scope;
+  BlockData->IsBitVar   = IsBitVar;
+  

[edk2] [PATCH V5 2/6] MdeModulePkg: Add GUID/flags to implement BitField support

[Dandan Bi]

V5: Update the EDKII extension GUID name with EDKII/Edkii prefix.

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=545

Cc: Eric Dong 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi 
---
 MdeModulePkg/Include/Guid/MdeModuleHii.h | 20 +++-
 MdeModulePkg/MdeModulePkg.dec|  4 
 2 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Include/Guid/MdeModuleHii.h 
b/MdeModulePkg/Include/Guid/MdeModuleHii.h
index 81821da..177ef25 100644
--- a/MdeModulePkg/Include/Guid/MdeModuleHii.h
+++ b/MdeModulePkg/Include/Guid/MdeModuleHii.h
@@ -1,9 +1,9 @@
 /** @file
   EDKII extented HII IFR guid opcodes.
 
-Copyright (c) 2006 - 2010, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
 This program and the accompanying materials are licensed and made available 
under 
 the terms and conditions of the BSD License that accompanies this 
distribution.  
 The full text of the license may be found at
 http://opensource.org/licenses/bsd-license.php.

 
@@ -209,12 +209,30 @@ typedef struct _EFI_IFR_GUID_VAREQNAME {
   /// The the Unicode String will be used as a EFI Variable Name.
   ///
   UINT16  NameId;
 } EFI_IFR_GUID_VAREQNAME;
 
+///
+/// EDKII implementation extension GUID, used to indaicate there are bit 
fields in the varstore.
+///
+#define EDKII_IFR_BIT_VARSTORE_GUID \
+  {0x82DDD68B, 0x9163, 0x4187, {0x9B, 0x27, 0x20, 0xA8, 0xFD, 0x60,0xA7, 0x1D}}
+
+///
+/// EDKII implementation extension flags, used to indaicate the disply style 
and bit width for bit filed storage.
+/// Two high bits for display style and the low six bits for bit width.
+///
+#define EFI_IFR_DISPLAY_BIT0xC0
+#define EFI_IFR_DISPLAY_INT_DEC_BIT0x00
+#define EFI_IFR_DISPLAY_UINT_DEC_BIT   0x40
+#define EFI_IFR_DISPLAY_UINT_HEX_BIT   0x80
+
+#define EFI_IFR_NUMERIC_SIZE_BIT   0x3F
+
 #pragma pack()
 
 extern EFI_GUID gEfiIfrTianoGuid;
 extern EFI_GUID gEfiIfrFrameworkGuid;
+extern EFI_GUID gEdkiiIfrBitVarstoreGuid;
 
 #endif
 
diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index 403a66a..a3c0633 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -182,10 +182,14 @@
 
   ## Guid for EDKII implementation GUIDed opcodes
   #  Include/Guid/MdeModuleHii.h
   gEfiIfrTianoGuid  = { 0xf0b1735, 0x87a0, 0x4193, {0xb2, 0x66, 0x53, 
0x8c, 0x38, 0xaf, 0x48, 0xce }}
 
+  ## Guid for EDKII implementation extension, used to indaicate there are bit 
fields in the varstore.
+  #  Include/Guid/MdeModuleHii.h
+  gEdkiiIfrBitVarstoreGuid  = {0x82DDD68B, 0x9163, 0x4187, {0x9B, 0x27, 0x20, 
0xA8, 0xFD, 0x60,0xA7, 0x1D}}
+
   ## Guid for Framework vfr GUIDed opcodes.
   #  Include/Guid/MdeModuleHii.h
   gEfiIfrFrameworkGuid  = { 0x31ca5d1a, 0xd511, 0x4931, { 0xb7, 0x82, 0xae, 
0x6b, 0x2b, 0x17, 0x8c, 0xd7 }}
 
   ## Guid to specify the System Non Volatile FV
-- 
1.9.5.msysgit.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] CryptoPkg: Add new API to retrieve commonName of X.509 certificate

[Zhang, Chao B]

Qin:
   Thanks for your explanation. It makes sense to me.
Reviewed-by: Chao Zhang  

-Original Message-
From: Long, Qin 
Sent: Wednesday, September 20, 2017 4:25 PM
To: Zhang, Chao B ; Ye, Ting 
Cc: edk2-devel@lists.01.org
Subject: RE: [PATCH] CryptoPkg: Add new API to retrieve commonName of X.509 
certificate

Thanks, Chao.
Cryptest just simply use the hard-coded test vectors for API usage 
demonstration. So 64 is big enough for the given test X.509 data.


Best Regards & Thanks,
LONG, Qin

-Original Message-
From: Zhang, Chao B
Sent: Wednesday, September 20, 2017 2:57 PM
To: Long, Qin ; Ye, Ting 
Cc: edk2-devel@lists.01.org
Subject: RE: [PATCH] CryptoPkg: Add new API to retrieve commonName of X.509 
certificate

Qin:
   For cryptest, do we need to support 64 maximum CN name and NULL? That makes 
buffer size 65 instead of 64.
Others are good to me.
 


-Original Message-
From: Long, Qin
Sent: Tuesday, September 19, 2017 11:39 AM
To: Ye, Ting ; Zhang, Chao B 
Cc: edk2-devel@lists.01.org; Long, Qin 
Subject: [PATCH] CryptoPkg: Add new API to retrieve commonName of X.509 
certificate

Add one new API (X509GetCommonName()) to retrieve the subject commonName string 
from one X.509 certificate.

Cc: Ting Ye 
Cc: Chao Zhang 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qin Long 
---
 CryptoPkg/Application/Cryptest/RsaVerify2.c| 17 
 CryptoPkg/Include/Library/BaseCryptLib.h   | 32 
 CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c  | 93 ++
 CryptoPkg/Library/BaseCryptLib/Pk/CryptX509Null.c  | 32 
 .../Pk/CryptX509Null.c | 34 +++-
 5 files changed, 207 insertions(+), 1 deletion(-)

diff --git a/CryptoPkg/Application/Cryptest/RsaVerify2.c 
b/CryptoPkg/Application/Cryptest/RsaVerify2.c
index 98b5aad900..f9b70d5794 100644
--- a/CryptoPkg/Application/Cryptest/RsaVerify2.c
+++ b/CryptoPkg/Application/Cryptest/RsaVerify2.c
@@ -211,6 +211,9 @@ ValidateCryptRsa2 (
   UINTNSigSize;
   UINT8*Subject;
   UINTNSubjectSize;
+  CHAR8CommonName[64];
+  CHAR16   CommonNameUnicode[64];
+  UINTNCommonNameSize;
 
   Print (L"\nUEFI-OpenSSL RSA Key Retrieving Testing: ");
 
@@ -286,6 +289,20 @@ ValidateCryptRsa2 (
 Print (L"[Pass]");
   }
 
+  //
+  // Get CommonName from X509 Certificate Subject  //  CommonNameSize = 
+ 64;  ZeroMem (CommonName, CommonNameSize);  Status = X509GetCommonName 
+ (TestCert, sizeof (TestCert), CommonName, );  if
+ (!Status) {
+Print (L"\n  - Retrieving Common Name - [Fail]");
+return EFI_ABORTED;
+  } else {
+AsciiStrToUnicodeStrS (CommonName, CommonNameUnicode, CommonNameSize);
+Print (L"\n  - Retrieving Common Name = \"%s\" (Size = %d)", 
+ CommonNameUnicode, CommonNameSize);  }
+
   //
   // X509 Certificate Verification.
   //
diff --git a/CryptoPkg/Include/Library/BaseCryptLib.h 
b/CryptoPkg/Include/Library/BaseCryptLib.h
index 9c5ffcd9cf..d861be6725 100644
--- a/CryptoPkg/Include/Library/BaseCryptLib.h
+++ b/CryptoPkg/Include/Library/BaseCryptLib.h
@@ -2171,6 +2171,38 @@ X509GetSubjectName (
   IN OUT  UINTN*SubjectSize
   );
 
+/**
+  Retrieve the common name (CN) string from one X.509 certificate.
+
+  If Cert or CommonNameSize is NULL, then return FALSE.
+  If this interface is not supported, then return FALSE.
+
+  @param[in]  CertPointer to the DER-encoded X509 certificate.
+  @param[in]  CertSizeSize of the X509 certificate in bytes.
+  @param[out] CommonName  Buffer to contain the retrieved certificate 
common
+  name string. At most CommonNameSize bytes 
will be
+  written and the string will be null 
terminated. May be
+  NULL in order to determine the size buffer 
needed.
+  @param[in,out]  CommonNameSize  The size in bytes of the CommonName buffer 
on input,
+  and the size of buffer returned CommonName 
on output.
+  if CommonName is NULL then the amount of 
space needed
+  in buffer (including the final null) is 
returned.
+
+  @retval  TRUE   The certificate CommonName retrieved successfully.
+  @retval  FALSE  Invalid certificate, or CommonNameSize is NULL,
+  or no CommonName entry exists.
+  @retval  FALSE  This interface is not supported.
+
+**/
+BOOLEAN
+EFIAPI
+X509GetCommonName (
+  IN  CONST UINT8  *Cert,
+  IN  UINTNCertSize,
+  OUT CHAR8*CommonName,
+  IN OUT  UINTN*CommonNameSize
+  );
+
 /**
   Verify one X509 certificate was issued by the trusted CA.
 
diff --git 

Re: [edk2] [PATCH] CryptoPkg: Add new API to retrieve commonName of X.509 certificate

[Long, Qin]

Thanks, Chao.
Cryptest just simply use the hard-coded test vectors for API usage 
demonstration. So 64 is big enough for the given test X.509 data.


Best Regards & Thanks,
LONG, Qin

-Original Message-
From: Zhang, Chao B 
Sent: Wednesday, September 20, 2017 2:57 PM
To: Long, Qin ; Ye, Ting 
Cc: edk2-devel@lists.01.org
Subject: RE: [PATCH] CryptoPkg: Add new API to retrieve commonName of X.509 
certificate

Qin:
   For cryptest, do we need to support 64 maximum CN name and NULL? That makes 
buffer size 65 instead of 64.
Others are good to me.
 


-Original Message-
From: Long, Qin
Sent: Tuesday, September 19, 2017 11:39 AM
To: Ye, Ting ; Zhang, Chao B 
Cc: edk2-devel@lists.01.org; Long, Qin 
Subject: [PATCH] CryptoPkg: Add new API to retrieve commonName of X.509 
certificate

Add one new API (X509GetCommonName()) to retrieve the subject commonName string 
from one X.509 certificate.

Cc: Ting Ye 
Cc: Chao Zhang 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qin Long 
---
 CryptoPkg/Application/Cryptest/RsaVerify2.c| 17 
 CryptoPkg/Include/Library/BaseCryptLib.h   | 32 
 CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c  | 93 ++
 CryptoPkg/Library/BaseCryptLib/Pk/CryptX509Null.c  | 32 
 .../Pk/CryptX509Null.c | 34 +++-
 5 files changed, 207 insertions(+), 1 deletion(-)

diff --git a/CryptoPkg/Application/Cryptest/RsaVerify2.c 
b/CryptoPkg/Application/Cryptest/RsaVerify2.c
index 98b5aad900..f9b70d5794 100644
--- a/CryptoPkg/Application/Cryptest/RsaVerify2.c
+++ b/CryptoPkg/Application/Cryptest/RsaVerify2.c
@@ -211,6 +211,9 @@ ValidateCryptRsa2 (
   UINTNSigSize;
   UINT8*Subject;
   UINTNSubjectSize;
+  CHAR8CommonName[64];
+  CHAR16   CommonNameUnicode[64];
+  UINTNCommonNameSize;
 
   Print (L"\nUEFI-OpenSSL RSA Key Retrieving Testing: ");
 
@@ -286,6 +289,20 @@ ValidateCryptRsa2 (
 Print (L"[Pass]");
   }
 
+  //
+  // Get CommonName from X509 Certificate Subject  //  CommonNameSize = 
+ 64;  ZeroMem (CommonName, CommonNameSize);  Status = X509GetCommonName 
+ (TestCert, sizeof (TestCert), CommonName, );  if
+ (!Status) {
+Print (L"\n  - Retrieving Common Name - [Fail]");
+return EFI_ABORTED;
+  } else {
+AsciiStrToUnicodeStrS (CommonName, CommonNameUnicode, CommonNameSize);
+Print (L"\n  - Retrieving Common Name = \"%s\" (Size = %d)", 
+ CommonNameUnicode, CommonNameSize);  }
+
   //
   // X509 Certificate Verification.
   //
diff --git a/CryptoPkg/Include/Library/BaseCryptLib.h 
b/CryptoPkg/Include/Library/BaseCryptLib.h
index 9c5ffcd9cf..d861be6725 100644
--- a/CryptoPkg/Include/Library/BaseCryptLib.h
+++ b/CryptoPkg/Include/Library/BaseCryptLib.h
@@ -2171,6 +2171,38 @@ X509GetSubjectName (
   IN OUT  UINTN*SubjectSize
   );
 
+/**
+  Retrieve the common name (CN) string from one X.509 certificate.
+
+  If Cert or CommonNameSize is NULL, then return FALSE.
+  If this interface is not supported, then return FALSE.
+
+  @param[in]  CertPointer to the DER-encoded X509 certificate.
+  @param[in]  CertSizeSize of the X509 certificate in bytes.
+  @param[out] CommonName  Buffer to contain the retrieved certificate 
common
+  name string. At most CommonNameSize bytes 
will be
+  written and the string will be null 
terminated. May be
+  NULL in order to determine the size buffer 
needed.
+  @param[in,out]  CommonNameSize  The size in bytes of the CommonName buffer 
on input,
+  and the size of buffer returned CommonName 
on output.
+  if CommonName is NULL then the amount of 
space needed
+  in buffer (including the final null) is 
returned.
+
+  @retval  TRUE   The certificate CommonName retrieved successfully.
+  @retval  FALSE  Invalid certificate, or CommonNameSize is NULL,
+  or no CommonName entry exists.
+  @retval  FALSE  This interface is not supported.
+
+**/
+BOOLEAN
+EFIAPI
+X509GetCommonName (
+  IN  CONST UINT8  *Cert,
+  IN  UINTNCertSize,
+  OUT CHAR8*CommonName,
+  IN OUT  UINTN*CommonNameSize
+  );
+
 /**
   Verify one X509 certificate was issued by the trusted CA.
 
diff --git a/CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c 
b/CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c
index 7d275977c5..e45c214bd1 100644
--- a/CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c
+++ b/CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c
@@ -297,6 +297,99 @@ _Exit:
   return Status;
 }
 
+/**
+  Retrieve the common name (CN) string from one X.509 certificate.
+
+  If Cert or CommonNameSize is NULL, then 

Re: [edk2] [PATCH v2] PeiLib : Inform UEFI memory to Linux

[Sakar Arora]

Thanks for the information. Seems my understanding was not correct in this 
context. I have no other doubts on this change.

-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: Wednesday, September 20, 2017 12:02 PM
To: Sakar Arora 
Cc: Meenakshi Aggarwal ; edk2-devel@lists.01.org; 
leif.lindh...@linaro.org
Subject: Re: [edk2] [PATCH v2] PeiLib : Inform UEFI memory to Linux

On 19 September 2017 at 22:32, Sakar Arora  wrote:
> The DXE core dispatcher relies on the available memory to allocate space for 
> loading the rest of the modules from the UEFI image. If we declare the UEFI 
> image memory space (from which DXE dispatcher reads the efi modules) open to 
> allocation, it might lead to data corruption, depending on the location of 
> UEFI image and cumulative size of uncompressed EFI modules.
>
> Also, since UEFI allows unloading and loading of drivers at runtime, IMO, 
> there is a need to preserve the UEFI image even after all the modules have 
> been decompressed and loaded in the boot sequence.
>

None of this is relevant. The uncompressed firmware volume containing DXE core 
and everything else is preserved as before. The only thing that gets discarded 
is the outer FV, which only contains the PrePi SEC module, and the compressed 
FV, neither of which is ever touched again after DXE core has started 
executing. So we should not register the FV in the first place, and not reserve 
the memory so we don't lose it.

If you still think this may break anything, could you please elaborate?



> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Tuesday, September 19, 2017 6:18 PM
> To: Sakar Arora 
> Cc: Meenakshi Aggarwal ;
> edk2-devel@lists.01.org; leif.lindh...@linaro.org
> Subject: Re: [edk2] [PATCH v2] PeiLib : Inform UEFI memory to Linux
>
> On 19 September 2017 at 01:07, Sakar Arora  wrote:
>> This change will create the possibility for memory space holding the UEFI 
>> image to be over-written by the DXE core code, since this space will then be 
>> available for allocation.
>
> Yes. But why does this matter after the entire payload has been decompressed 
> into memory already?
>
>
>> Any such change, if required, should be done just before booting the OS.
>>
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
>> Of Meenakshi Aggarwal
>> Sent: Tuesday, September 19, 2017 6:02 PM
>> To: edk2-devel@lists.01.org; leif.lindh...@linaro.org;
>> ard.biesheu...@linaro.org
>> Subject: [edk2] [PATCH v2] PeiLib : Inform UEFI memory to Linux
>>
>> While creating Hob list, ArmPlatformPkg is hiding UEFI memory.
>> whereas this memory can be used by OS.
>>
>> This patch, allows OS to use UEFI code area.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Udit Kumar 
>> Signed-off-by: Meenakshi Aggarwal 
>> ---
>>  ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c | 69
>> -
>>  1 file changed, 69 deletions(-)
>>
>> diff --git a/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c
>> b/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c
>> index 2feb11f..d03214b 100644
>> --- a/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c
>> +++ b/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c
>> @@ -70,11 +70,7 @@ MemoryPeim (
>>  {
>>ARM_MEMORY_REGION_DESCRIPTOR *MemoryTable;
>>EFI_RESOURCE_ATTRIBUTE_TYPE  ResourceAttributes;
>> -  UINT64   ResourceLength;
>>EFI_PEI_HOB_POINTERS NextHob;
>> -  EFI_PHYSICAL_ADDRESS FdTop;
>> -  EFI_PHYSICAL_ADDRESS SystemMemoryTop;
>> -  EFI_PHYSICAL_ADDRESS ResourceTop;
>>BOOLEAN  Found;
>>
>>// Get Virtual Memory Map from the Platform Library @@ -121,71 +117,6 @@ 
>> MemoryPeim (
>>  );
>>}
>>
>> -  //
>> -  // Reserved the memory space occupied by the firmware volume
>> -  //
>> -
>> -  SystemMemoryTop = (EFI_PHYSICAL_ADDRESS)PcdGet64
>> (PcdSystemMemoryBase) + (EFI_PHYSICAL_ADDRESS)PcdGet64
>> (PcdSystemMemorySize);
>> -  FdTop = (EFI_PHYSICAL_ADDRESS)PcdGet64 (PcdFdBaseAddress) +
>> (EFI_PHYSICAL_ADDRESS)PcdGet32 (PcdFdSize);
>> -
>> -  // EDK2 does not have the concept of boot firmware copied into
>> DRAM. To avoid the DXE
>> -  // core to overwrite this area we must mark the region with the
>> attribute non-present
>> -  if ((PcdGet64 (PcdFdBaseAddress) >= PcdGet64 (PcdSystemMemoryBase)) && 
>> (FdTop <= SystemMemoryTop)) {
>> -Found = FALSE;
>> -
>> -// Search for System Memory Hob that contains the firmware
>> -NextHob.Raw = GetHobList ();
>> -while ((NextHob.Raw = GetNextHob (EFI_HOB_TYPE_RESOURCE_DESCRIPTOR, 
>> NextHob.Raw)) != NULL) {
>> -  if ((NextHob.ResourceDescriptor->ResourceType == 
>> 

Re: [edk2] [Patch] MdeModulePkg/DxeNetLib: Check the actual packet size before trim data from Nbuf.

[Wu, Jiaxin]

Hi Siyuan,

Maybe we can add more check for the Len to return directly, what do you think?

  if (Len == 0) {
return 0;
  }

> +  if (Nbuf->TotalSize == 0) {
> +return 0;
> +  }

Thanks,
Jiaxin


> -Original Message-
> From: Fu, Siyuan
> Sent: Wednesday, September 20, 2017 11:24 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Jiaxin ; Ye, Ting ; Michael
> Turner 
> Subject: [Patch] MdeModulePkg/DxeNetLib: Check the actual packet size
> before trim data from Nbuf.
> 
> In NetbufTrim() function, the NetBuf TotalSize should be checked with 0
> before
> making the trim operation, otherwise the function will fall into infinite 
> loop.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Fu Siyuan 
> Cc: Wu Jiaxin 
> Cc: Ye Ting 
> Cc: Michael Turner 
> ---
>  MdeModulePkg/Library/DxeNetLib/NetBuffer.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/MdeModulePkg/Library/DxeNetLib/NetBuffer.c
> b/MdeModulePkg/Library/DxeNetLib/NetBuffer.c
> index 95cb71714b..25fc78e49e 100644
> --- a/MdeModulePkg/Library/DxeNetLib/NetBuffer.c
> +++ b/MdeModulePkg/Library/DxeNetLib/NetBuffer.c
> @@ -1175,6 +1175,10 @@ NetbufTrim (
> 
>NET_CHECK_SIGNATURE (Nbuf, NET_BUF_SIGNATURE);
> 
> +  if (Nbuf->TotalSize == 0) {
> +return 0;
> +  }
> +
>if (Len > Nbuf->TotalSize) {
>  Len = Nbuf->TotalSize;
>}
> --
> 2.13.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 2/3] MdeModulePkg/PartitionDxe: Fix creation of UDF logical partition

[Ni, Ruiyu]

Thanks/Ray

> -Original Message-
> From: Paulo Alcantara [mailto:pca...@zytor.com]
> Sent: Tuesday, September 19, 2017 12:38 AM
> To: Ni, Ruiyu ; edk2-devel@lists.01.org
> Cc: Dong, Eric ; Zeng, Star ;
> Laszlo Ersek 
> Subject: Re: [PATCH v2 2/3] MdeModulePkg/PartitionDxe: Fix creation of
> UDF logical partition
> 
> Hi,
> 
> On 9/17/2017 9:54 PM, Ni, Ruiyu wrote:
> > Paulo,
> > Several comments:
> > 1. Can below logic be removed in PartitionDxe/Udf.c?
> > while (!IsDevicePathEnd (DevicePathNode)) {
> >  //
> >  // Do not allow checking for UDF file systems in CDROM "El Torito"
> >  // partitions, and skip duplicate installation of UDF file system child
> >  // nodes.
> >  //
> >  if (DevicePathType (DevicePathNode) == MEDIA_DEVICE_PATH) {
> >if (DevicePathSubType (DevicePathNode) == MEDIA_CDROM_DP) {
> >  return EFI_NOT_FOUND;
> >}
> >if (DevicePathSubType (DevicePathNode) == MEDIA_VENDOR_DP) {
> >  VendorDefinedGuid = (EFI_GUID *)((UINTN)DevicePathNode +
> >   OFFSET_OF (VENDOR_DEVICE_PATH, 
> > Guid));
> >  if (CompareGuid (VendorDefinedGuid, )) {
> >return EFI_NOT_FOUND;
> >  }
> >}
> >  }
> >  //
> >  // Try next device path node
> >  //
> >  DevicePathNode = NextDevicePathNode (DevicePathNode);
> >}
> 
> I think it's no longer necessary, so I'll remove it.
> 
> >
> > 2. Can you add function header comments for the newly added functions?
> 
> Sure.

When you add the header comments, please run
Python BaseTools/Source/Python/Ecc/Ecc.py -t 
MdeModulePkg/Universal/Disk/PartitionDxe -s
To make sure there is no other coding style issue.

> 
> >
> > 3. Change the consuming code of IS_UDF_XXX macro after patch #1 is
> changed.
> 
> ACK.

I think you may also need to declare the Buffer as UDF_DESCRIPTOR_TAG.

> 
> >
> > 4. Perhaps to add more checks for these numbers read from the UDF
> CDROM.
> > As Jiewen mentioned in another mail, secure code needs to validate all
> external inputs.
> > We shouldn't assume the UDF CDROM is a well-formatted CDROM.
> > A hacker may create a UDF CDROM to hack the system by using mechanism
> > like buffer overflow, integer overflow, etc.
> 
> OK, when we start the Main Volume Descriptor Sequence (MVDS), we rely
> on "ExtentAd->ExtentLocation" to know the LBA where to start the
> sequence, and on "ExtentAd->ExtentLength" to know many LBAs the
> sequence has. We only care about LVD, PD and TD descriptors. We currently
> check whether a TD descriptor exists, or the search exceed ExtentAd-
> >ExtentLength blocks to determine when stopping the sequence. That
> doesn't seem to be safe enough, but here are some thoughts:
> 
> a. "ExtentAd->ExtentLength" may point to a bad value. If it's greater than or
> equal to BlockIo->Media->LastBlock, and there is no TD descriptor, we'll have
> to walk the entire disk and there will too much I/O overhead and then
> impacting bootup. Obviously, when it's greater than LastBlock, DiksIo-
> >ReadDisk() should not allow to read a non-existent LBA and then return
> EFI_INVALID_PARAMETER, as per UEFI spec.
> 
> b. "ExtentAd->ExtentLocation" might point to a invalid LBA, although
> DiskIo->ReadDisk() would not allow it.
> 
> So, it's time to look at UDF 2.60 spec again:
> 
>  > Volume Descriptor Sequence Extent
>  >
>  > Both the main and reserve volume descriptor sequence extents  > shall
> each have a minimum length of 16 logical sectors. The VDS  > Extent may be
> terminated by the extent length.
> 
> It doesn't tell us either a limit of logical blocks, or a maximum number.
> 
> Next:
> 
>  > 6.9.2.3 Step 3. Volume Descriptor Sequence  > Read logical sectors:
>  > MVDS_Location through MVDS_Location + (MVDS_Length - 1) /
> SectorSize  > ...
> 
> MVDS_Length == ExtentAd->ExtentLength, so still insufficient.
> 
> Next:
> 
>  > The data located in bytes 0-3 and 5 of the Anchor Volume Descriptor
> Pointer may be  > used for format verification if desired. Verifying the Tag
> Checksum in byte 4 and  > Descriptor CRC in bytes 8-11 are good additional
> verifications to perform.
>  > MVDS_Location and MVDS_Length are read from this structure.
> 
> Seems like a great check prior to reading ExtentAd->ExtentLocation and
> ExtentAd->ExtentLength contents. Would that be sufficient to you?


OK to me.

> 
> I haven't found a way to limit the number of blocks a Volume Descriptor
> Sequence might have.
> 
> Thanks,
> Paulo
> 
> >
> >
> > Thanks/Ray
> >
> >> -Original Message-
> >> From: Paulo Alcantara [mailto:pca...@zytor.com]
> >> Sent: Sunday, September 17, 2017 9:13 PM
> >> To: edk2-devel@lists.01.org
> >> Cc: Paulo Alcantara ; Dong, Eric
> >> ; Ni, Ruiyu ; Zeng, Star
> >> ; Laszlo Ersek 
> >> Subject: 

Re: [edk2] [PATCH 0/2] Fixe out-of-sync issue between GCD and CPU driver

[Yao, Jiewen]

Thanks. I have no other comments.

From: Wang, Jian J
Sent: Wednesday, September 20, 2017 3:54 PM
To: Yao, Jiewen ; edk2-devel@lists.01.org
Cc: Kinney, Michael D ; Laszlo Ersek 
; Dong, Eric ; Zeng, Star 

Subject: RE: [edk2] [PATCH 0/2] Fixe out-of-sync issue between GCD and CPU 
driver

Jiewen,

Yes. The patch has passed the validation of the UEFI booting Windows 10, 
Windows 7 and Fedora 25.

If no comments from you and others, I'll push the patch to upstream soon.

Thanks,
Jian Wang

-Original Message-
From: Yao, Jiewen
Sent: Wednesday, September 20, 2017 2:08 PM
To: Wang, Jian J >; 
edk2-devel@lists.01.org
Cc: Kinney, Michael D 
>; Laszlo Ersek 
>; Dong, Eric 
>; Zeng, Star 
>
Subject: RE: [edk2] [PATCH 0/2] Fixe out-of-sync issue between GCD and CPU 
driver

Hi
I take a look at the driver. I think the update is good.

Would you please share what test you have done with the updated UEFI memory map?
Such as UEFI Windows boot, UEFI Linux boot?

Thank you
Yao Jiewen


> -Original Message-
> From: Wang, Jian J
> Sent: Wednesday, September 20, 2017 1:12 PM
> To: Wang, Jian J >; 
> edk2-devel@lists.01.org
> Cc: Kinney, Michael D 
> >; Laszlo Ersek
> >; Yao, Jiewen 
> >; Dong, Eric
> >; Zeng, Star 
> >
> Subject: RE: [edk2] [PATCH 0/2] Fixe out-of-sync issue between GCD and CPU
> driver
>
> Jiewen,
>
> Any comments on this patch?
>
>
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jian J
> Wang
> Sent: Tuesday, September 19, 2017 2:10 PM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D 
> >; Laszlo Ersek
> >; Yao, Jiewen 
> >; Dong, Eric
> >; Zeng, Star 
> >
> Subject: [edk2] [PATCH 0/2] Fixe out-of-sync issue between GCD and CPU driver
>
> There're two issues here actually.
>
> From GCD perspective, its SetMemorySpaceAttributes() method doesn't
> accept page related attributes. That means users cannot use it to
> change page attributes, and have to turn to CPU arch protocol to do it,
> which is not be allowed by PI spec.
>
> From CpuDxe driver perspective, it doesn't update GCD memory attributes
> from current page table setup during its initialization. So the memory
> attributes in GCD might not reflect all memory attributes in real world.
>
> Cc: Jiewen Yao >
> Cc: Eric Dong >
> Cc: Star Zeng >
> Cc: Laszlo Ersek >
> Cc: Michael Kinney 
> >
> Suggested-by: Jiewen Yao >
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang 
> >
>
> Jian J Wang (2):
>   UefiCpuPkg/CpuDxe: Fix out-of-sync issue in CpuDxe
>   MdeModulePkg/Core: Fix out-of-sync issue in GCD
>
>  MdeModulePkg/Core/Dxe/Gcd/Gcd.c  | 45 ++
>  UefiCpuPkg/CpuDxe/CpuDxe.c   |  5 ++
>  UefiCpuPkg/CpuDxe/CpuDxe.h   |  9 
>  UefiCpuPkg/CpuDxe/CpuPageTable.c | 99
> 
>  4 files changed, 140 insertions(+), 18 deletions(-)
>
> --
> 2.14.1.windows.1
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 3/3] MdeModulePkg/UdfDxe: Rework driver to support PartitionDxe changes

[Ni, Ruiyu]

OK I understood the reason now.

I tried to understand the relationship between AVDP, LVD, and PD, but failed.
The code below in Partition driver seems to say the LVD and PD are close to 
each other.
Is it always true? If it is, I agree with the implementation.

//
// Cover the main VDS area so UdfDxe driver will also be able to get LVD and
// PD descriptors out from the file system.
//
*MainVdsStartLsn = GuardMainVdsStartLsn;
*LogicalVolEndLsn = *MainVdsStartLsn + (UINT64)ExtentAd->ExtentLength;

//
// Cover UDF partition area
//
*LogicalVolEndLsn +=
  ((UINT64)PartitionDesc->PartitionStartingLocation -
   *LogicalVolEndLsn) + PartitionDesc->PartitionLength - 1;
Thanks/Ray

> -Original Message-
> From: Paulo Alcantara [mailto:pca...@zytor.com]
> Sent: Tuesday, September 19, 2017 12:51 AM
> To: Ni, Ruiyu ; edk2-devel@lists.01.org
> Cc: Dong, Eric ; Zeng, Star ;
> Laszlo Ersek 
> Subject: Re: [PATCH v2 3/3] MdeModulePkg/UdfDxe: Rework driver to
> support PartitionDxe changes
> 
> 
> 
> On 9/17/2017 10:00 PM, Ni, Ruiyu wrote:
> > Paulo,
> > With the change in partition driver, I suppose UdfDxe driver only
> > needs to take care of area covered by the partition descriptor.
> > But why StartMainVolumeDescriptorSequence() still reads LVD, TD, and
> > PD?
> 
> We still need the LVD again for a few reasons:
> 
> 1. GetVolumeSize() needs to read LVID (Logical Volume Integrity Descriptor),
> which is located in LVD, in order to calculate free and used volume space.
> 2. To find FSD (File Set Descriptor), where the root directory is located.
> 3. To know which Partition Descriptor to use based on partition number from
> LVD->PartitionMaps field. I know UDF 2.60 spec says that there should be
> only one Partition Descriptor that covers the entire space of a single LVD, 
> but
> it's good to make sure we're reading it correctly.
> 
> TD descriptor is used to know when stopping the Volume Descriptor
> Sequence and then we don't need to read all ExtentAd->ExtentLength blocks
> unnecessarily.
> 
> Thanks,
> Paulo
> 
> >
> > I thought the UdfDxe driver's logic can be simplified a lot.
> > There should be no duplicated logic in Partition driver and udf driver.
> >
> > Can you explain more?
> >
> > Thanks/Ray
> >
> >> -Original Message-
> >> From: Paulo Alcantara [mailto:pca...@zytor.com]
> >> Sent: Sunday, September 17, 2017 9:13 PM
> >> To: edk2-devel@lists.01.org
> >> Cc: Paulo Alcantara ; Dong, Eric
> >> ; Ni, Ruiyu ; Zeng, Star
> >> ; Laszlo Ersek 
> >> Subject: [PATCH v2 3/3] MdeModulePkg/UdfDxe: Rework driver to
> support
> >> PartitionDxe changes
> >>
> >> This patch reworks the driver to support Partition driver changes.
> >>
> >> Cc: Eric Dong 
> >> Cc: Paulo Alcantara 
> >> Cc: Ruiyu Ni 
> >> Cc: Star Zeng 
> >> Cc: Laszlo Ersek 
> >> Contributed-under: TianoCore Contribution Agreement 1.1
> >> Signed-off-by: Paulo Alcantara 
> >> ---
> >>   MdeModulePkg/Universal/Disk/UdfDxe/File.c |  13 +-
> >>   MdeModulePkg/Universal/Disk/UdfDxe/FileSystemOperations.c | 515
> >> 
> >>   MdeModulePkg/Universal/Disk/UdfDxe/Udf.c  |   7 -
> >>   MdeModulePkg/Universal/Disk/UdfDxe/Udf.h  |  88 +---
> >>   4 files changed, 204 insertions(+), 419 deletions(-)
> >>
> >> diff --git a/MdeModulePkg/Universal/Disk/UdfDxe/File.c
> >> b/MdeModulePkg/Universal/Disk/UdfDxe/File.c
> >> index 01361141bb..f2c62967e8 100644
> >> --- a/MdeModulePkg/Universal/Disk/UdfDxe/File.c
> >> +++ b/MdeModulePkg/Universal/Disk/UdfDxe/File.c
> >> @@ -100,6 +100,7 @@ UdfOpenVolume (
> >>   >Volume,
> >>   >Root
> >>   );
> >> +  ASSERT_EFI_ERROR (Status);
> >> if (EFI_ERROR (Status)) {
> >>   goto Error_Find_Root_Dir;
> >> }
> >> @@ -131,7 +132,6 @@ Error_Alloc_Priv_File_Data:
> >> CleanupFileInformation (>Root);
> >>
> >>   Error_Find_Root_Dir:
> >> -  CleanupVolumeInformation (>Volume);
> >>
> >>   Error_Read_Udf_Volume:
> >>   Error_Invalid_Params:
> >> @@ -528,7 +528,6 @@ UdfClose (
> >> EFI_TPL OldTpl;
> >> EFI_STATUS  Status;
> >> PRIVATE_UDF_FILE_DATA   *PrivFileData;
> >> -  PRIVATE_UDF_SIMPLE_FS_DATA  *PrivFsData;
> >>
> >> OldTpl = gBS->RaiseTPL (TPL_CALLBACK);
> >>
> >> @@ -541,8 +540,6 @@ UdfClose (
> >>
> >> PrivFileData = PRIVATE_UDF_FILE_DATA_FROM_THIS (This);
> >>
> >> -  PrivFsData = PRIVATE_UDF_SIMPLE_FS_DATA_FROM_THIS
> (PrivFileData-
> >>> SimpleFs);
> >> -
> >> if (!PrivFileData->IsRootDirectory) {
> >>   CleanupFileInformation (>File);
> >>
> >> @@ -551,10 +548,6 @@ UdfClose (
> >>   }
> >> }
> >>
> >> -  if 

Re: [edk2] [PATCH 0/2] Fixe out-of-sync issue between GCD and CPU driver

[Wang, Jian J]

Jiewen,

Yes. The patch has passed the validation of the UEFI booting Windows 10, 
Windows 7 and Fedora 25.

If no comments from you and others, I'll push the patch to upstream soon.

Thanks,
Jian Wang

-Original Message-
From: Yao, Jiewen 
Sent: Wednesday, September 20, 2017 2:08 PM
To: Wang, Jian J ; edk2-devel@lists.01.org
Cc: Kinney, Michael D ; Laszlo Ersek 
; Dong, Eric ; Zeng, Star 

Subject: RE: [edk2] [PATCH 0/2] Fixe out-of-sync issue between GCD and CPU 
driver

Hi
I take a look at the driver. I think the update is good.

Would you please share what test you have done with the updated UEFI memory map?
Such as UEFI Windows boot, UEFI Linux boot?

Thank you
Yao Jiewen


> -Original Message-
> From: Wang, Jian J
> Sent: Wednesday, September 20, 2017 1:12 PM
> To: Wang, Jian J ; edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Laszlo Ersek
> ; Yao, Jiewen ; Dong, Eric
> ; Zeng, Star 
> Subject: RE: [edk2] [PATCH 0/2] Fixe out-of-sync issue between GCD and CPU
> driver
> 
> Jiewen,
> 
> Any comments on this patch?
> 
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jian J
> Wang
> Sent: Tuesday, September 19, 2017 2:10 PM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Laszlo Ersek
> ; Yao, Jiewen ; Dong, Eric
> ; Zeng, Star 
> Subject: [edk2] [PATCH 0/2] Fixe out-of-sync issue between GCD and CPU driver
> 
> There're two issues here actually.
> 
> From GCD perspective, its SetMemorySpaceAttributes() method doesn't
> accept page related attributes. That means users cannot use it to
> change page attributes, and have to turn to CPU arch protocol to do it,
> which is not be allowed by PI spec.
> 
> From CpuDxe driver perspective, it doesn't update GCD memory attributes
> from current page table setup during its initialization. So the memory
> attributes in GCD might not reflect all memory attributes in real world.
> 
> Cc: Jiewen Yao 
> Cc: Eric Dong 
> Cc: Star Zeng 
> Cc: Laszlo Ersek 
> Cc: Michael Kinney 
> Suggested-by: Jiewen Yao 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang 
> 
> Jian J Wang (2):
>   UefiCpuPkg/CpuDxe: Fix out-of-sync issue in CpuDxe
>   MdeModulePkg/Core: Fix out-of-sync issue in GCD
> 
>  MdeModulePkg/Core/Dxe/Gcd/Gcd.c  | 45 ++
>  UefiCpuPkg/CpuDxe/CpuDxe.c   |  5 ++
>  UefiCpuPkg/CpuDxe/CpuDxe.h   |  9 
>  UefiCpuPkg/CpuDxe/CpuPageTable.c | 99
> 
>  4 files changed, 140 insertions(+), 18 deletions(-)
> 
> --
> 2.14.1.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch][edk2-platforms/minnowboard-max-udk2017] Vlv2TbltDevicePkg: Add ESRT table in OS

[Guo, Mang]

1. Add ESRT table in OS. 2. Changed SystemFirmware Descriptor. 3. Remove 
redundant code.

Contributed-under: TianoCore Contribution Agreement 1.1

Signed-off-by: Guo Mang 
---
 .../SystemFirmwareDescriptor.acpi  | Bin 172 -> 0 bytes
 .../SystemFirmwareDescriptor.inf   |   7 +-
 .../SystemFirmwareDescriptorPei.c  |  36 +++-
 .../SystemFirmwareDescriptorTable.inf  |  28 --
 .../Library/PlatformBdsLib/BdsPlatform.c   |   3 +
 Vlv2TbltDevicePkg/PlatformPkg.fdf  |  96 +
 Vlv2TbltDevicePkg/PlatformPkgGcc.fdf   |  94 +---
 Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc|  31 +--
 Vlv2TbltDevicePkg/PlatformPkgIA32.dsc  |  33 +--
 Vlv2TbltDevicePkg/PlatformPkgX64.dsc   |  44 +++---
 10 files changed, 41 insertions(+), 331 deletions(-)
 delete mode 100644 
Vlv2TbltDevicePkg/Feature/Capsule/SystemFirmwareDescriptor/SystemFirmwareDescriptor.acpi
 delete mode 100644 
Vlv2TbltDevicePkg/Feature/Capsule/SystemFirmwareDescriptor/SystemFirmwareDescriptorTable.inf

diff --git 
a/Vlv2TbltDevicePkg/Feature/Capsule/SystemFirmwareDescriptor/SystemFirmwareDescriptor.acpi
 
b/Vlv2TbltDevicePkg/Feature/Capsule/SystemFirmwareDescriptor/SystemFirmwareDescriptor.acpi
deleted file mode 100644
index 
b355bb47e8715e083320305d76178667a50b0c6c..
GIT binary patch
literal 0
HcmV?d1

literal 172
zcmWG`^K_|TU|?7S#Q%X{4v=O9;%c>N4qUfhJ8gaa@3X8z&6Y5qFr)Z*w-k_CCLnGD
zVhCseQ~XdKjD~W-X2ICVbQnVpLm7h+gBwE%P}qQ>0*H~J5l}RgA&(&}S1
E0K^~~$p8QV

diff --git 
a/Vlv2TbltDevicePkg/Feature/Capsule/SystemFirmwareDescriptor/SystemFirmwareDescriptor.inf
 
b/Vlv2TbltDevicePkg/Feature/Capsule/SystemFirmwareDescriptor/SystemFirmwareDescriptor.inf
index 3cae775..b89d326 100644
--- 
a/Vlv2TbltDevicePkg/Feature/Capsule/SystemFirmwareDescriptor/SystemFirmwareDescriptor.inf
+++ 
b/Vlv2TbltDevicePkg/Feature/Capsule/SystemFirmwareDescriptor/SystemFirmwareDescriptor.inf
@@ -15,22 +15,21 @@
 [Defines]
   INF_VERSION= 0x00010005
   BASE_NAME  = SystemFirmwareDescriptor
-  FILE_GUID  = A3E13E7F-9FD9-4057-84FA-37423C789612
+  FILE_GUID  = 90B2B846-CA6D-4D6E-A8D3-C140A8E110AC
   MODULE_TYPE= PEIM
   VERSION_STRING = 1.0
   ENTRY_POINT= SystemFirmwareDescriptorPeimEntry
 
 [Sources]
   SystemFirmwareDescriptorPei.c
+  SystemFirmwareDescriptor.aslc
 
 [Packages]
   MdePkg/MdePkg.dec
+  MdeModulePkg/MdeModulePkg.dec
   SignedCapsulePkg/SignedCapsulePkg.dec
   Vlv2TbltDevicePkg/PlatformPkg.dec
 
-[Guids]
-  gEdkiiSystemFirmwareImageDescriptorFileGuid
-
 [LibraryClasses]
   PcdLib
   PeiServicesLib
diff --git 
a/Vlv2TbltDevicePkg/Feature/Capsule/SystemFirmwareDescriptor/SystemFirmwareDescriptorPei.c
 
b/Vlv2TbltDevicePkg/Feature/Capsule/SystemFirmwareDescriptor/SystemFirmwareDescriptorPei.c
index 792cbf8..b5a9323 100644
--- 
a/Vlv2TbltDevicePkg/Feature/Capsule/SystemFirmwareDescriptor/SystemFirmwareDescriptorPei.c
+++ 
b/Vlv2TbltDevicePkg/Feature/Capsule/SystemFirmwareDescriptor/SystemFirmwareDescriptorPei.c
@@ -19,8 +19,6 @@
 #include 
 #include 
 
-
-
 /**
   Entrypoint for SystemFirmwareDescriptor PEIM.
 
@@ -32,7 +30,7 @@
 EFI_STATUS
 EFIAPI
 SystemFirmwareDescriptorPeimEntry (
-  IN EFI_PEI_FILE_HANDLE PeiFileHandle,
+  IN EFI_PEI_FILE_HANDLE FileHandle,
   IN CONST EFI_PEI_SERVICES  **PeiServices
   )
 {
@@ -41,34 +39,22 @@ SystemFirmwareDescriptorPeimEntry (
   UINTN   Size;
   UINTN   Index;
   UINT32  AuthenticationStatus;
-  EFI_PEI_FV_HANDLE   VolumeHandle;
-  EFI_PEI_FILE_HANDLE FileHandle;
 
+  //
+  // Search RAW section.
+  //
   Index = 0;
   while (TRUE) {
-Status = PeiServicesFfsFindNextVolume (Index++, );
-if (EFI_ERROR (Status)) {
-  return Status;
+Status = PeiServicesFfsFindSectionData3(EFI_SECTION_RAW, Index, 
FileHandle, (VOID **), );
+if (EFI_ERROR(Status)) {
+  // Should not happen, must something wrong in FDF.
+  ASSERT(FALSE);
+  return EFI_NOT_FOUND;
 }
-Status = PeiServicesFfsFindFileByName 
(, VolumeHandle, );
-if (!EFI_ERROR (Status)) {
-  //
-  // Search RAW section.
-  //
-  Index = 0;
-  while (TRUE) {
-Status = PeiServicesFfsFindSectionData3(EFI_SECTION_RAW, Index++, 
FileHandle, (VOID **), );
-if (EFI_ERROR(Status)) {
-  // Should not happen, must something wrong in FDF.
-  ASSERT(FALSE);
-  return EFI_NOT_FOUND;
-}
-if (Descriptor->Signature == 
EDKII_SYSTEM_FIRMWARE_IMAGE_DESCRIPTOR_SIGNATURE) {
-  break;
-}
-  }
+if (Descriptor->Signature == 

Re: [edk2] [PATCH 0/3] OvmfPkg/QemuVideoDxe/VbeShim: handle PAM1 register on Q35 correctly

[Aleksei]

Hi Laszlo,

I've built it (despite edk2/ovmf build process being as convoluted as 
ever) and am trying to run it with qemu 2.10.0 - it's not booting at 
all, stuck at "Guest has not initialized the display (yet)."


Maybe the problem is gcc version? I have 7.2.0 while edk2 instructions 
mention gcc5.


On 19/09/17 22:18, Laszlo Ersek wrote:

Repo:   https://github.com/lersek/edk2.git
Branch: vbe_shim_q35_pam

Fix the long-standing OVMF/Q35 bug recently exposed by a QEMU change,
and reported under .

Aleksei, can you please fetch the branch, build it, and report back with
your Tested-by if it works for you?

I performed my own tests as well; I'll include those in a separate
email.

Cc: Aleksei Kovura 
Cc: Gerd Hoffmann 
Cc: Igor Mammedov 
Cc: Jordan Justen 
Cc: Ruiyu Ni 

Thank you,
Laszlo

Laszlo Ersek (3):
   OvmfPkg/CsmSupportLib: move PAM register addresses to IndustryStandard
   OvmfPkg/QemuVideoDxe/VbeShim: rename Status to
 Segment0AllocationStatus
   OvmfPkg/QemuVideoDxe/VbeShim: handle PAM1 register on Q35 correctly

  OvmfPkg/Csm/CsmSupportLib/LegacyRegion.c   | 62 ++--
  OvmfPkg/Csm/CsmSupportLib/LegacyRegion.h   | 22 +--
  OvmfPkg/Include/IndustryStandard/I440FxPiix4.h | 13 
  OvmfPkg/Include/IndustryStandard/Q35MchIch9.h  |  8 +++
  OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf  |  3 +-
  OvmfPkg/QemuVideoDxe/VbeShim.c | 47 ---
  6 files changed, 95 insertions(+), 60 deletions(-)



--
/--Regards, Aleksei/
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] CryptoPkg: Add new API to retrieve commonName of X.509 certificate

[Zhang, Chao B]

Qin:
   For cryptest, do we need to support 64 maximum CN name and NULL? That makes 
buffer size 65 instead of 64.
Others are good to me.
 


-Original Message-
From: Long, Qin 
Sent: Tuesday, September 19, 2017 11:39 AM
To: Ye, Ting ; Zhang, Chao B 
Cc: edk2-devel@lists.01.org; Long, Qin 
Subject: [PATCH] CryptoPkg: Add new API to retrieve commonName of X.509 
certificate

Add one new API (X509GetCommonName()) to retrieve the subject commonName string 
from one X.509 certificate.

Cc: Ting Ye 
Cc: Chao Zhang 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qin Long 
---
 CryptoPkg/Application/Cryptest/RsaVerify2.c| 17 
 CryptoPkg/Include/Library/BaseCryptLib.h   | 32 
 CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c  | 93 ++
 CryptoPkg/Library/BaseCryptLib/Pk/CryptX509Null.c  | 32 
 .../Pk/CryptX509Null.c | 34 +++-
 5 files changed, 207 insertions(+), 1 deletion(-)

diff --git a/CryptoPkg/Application/Cryptest/RsaVerify2.c 
b/CryptoPkg/Application/Cryptest/RsaVerify2.c
index 98b5aad900..f9b70d5794 100644
--- a/CryptoPkg/Application/Cryptest/RsaVerify2.c
+++ b/CryptoPkg/Application/Cryptest/RsaVerify2.c
@@ -211,6 +211,9 @@ ValidateCryptRsa2 (
   UINTNSigSize;
   UINT8*Subject;
   UINTNSubjectSize;
+  CHAR8CommonName[64];
+  CHAR16   CommonNameUnicode[64];
+  UINTNCommonNameSize;
 
   Print (L"\nUEFI-OpenSSL RSA Key Retrieving Testing: ");
 
@@ -286,6 +289,20 @@ ValidateCryptRsa2 (
 Print (L"[Pass]");
   }
 
+  //
+  // Get CommonName from X509 Certificate Subject  //  CommonNameSize = 
+ 64;  ZeroMem (CommonName, CommonNameSize);  Status = X509GetCommonName 
+ (TestCert, sizeof (TestCert), CommonName, );  if 
+ (!Status) {
+Print (L"\n  - Retrieving Common Name - [Fail]");
+return EFI_ABORTED;
+  } else {
+AsciiStrToUnicodeStrS (CommonName, CommonNameUnicode, CommonNameSize);
+Print (L"\n  - Retrieving Common Name = \"%s\" (Size = %d)", 
+ CommonNameUnicode, CommonNameSize);  }
+
   //
   // X509 Certificate Verification.
   //
diff --git a/CryptoPkg/Include/Library/BaseCryptLib.h 
b/CryptoPkg/Include/Library/BaseCryptLib.h
index 9c5ffcd9cf..d861be6725 100644
--- a/CryptoPkg/Include/Library/BaseCryptLib.h
+++ b/CryptoPkg/Include/Library/BaseCryptLib.h
@@ -2171,6 +2171,38 @@ X509GetSubjectName (
   IN OUT  UINTN*SubjectSize
   );
 
+/**
+  Retrieve the common name (CN) string from one X.509 certificate.
+
+  If Cert or CommonNameSize is NULL, then return FALSE.
+  If this interface is not supported, then return FALSE.
+
+  @param[in]  CertPointer to the DER-encoded X509 certificate.
+  @param[in]  CertSizeSize of the X509 certificate in bytes.
+  @param[out] CommonName  Buffer to contain the retrieved certificate 
common
+  name string. At most CommonNameSize bytes 
will be
+  written and the string will be null 
terminated. May be
+  NULL in order to determine the size buffer 
needed.
+  @param[in,out]  CommonNameSize  The size in bytes of the CommonName buffer 
on input,
+  and the size of buffer returned CommonName 
on output.
+  if CommonName is NULL then the amount of 
space needed
+  in buffer (including the final null) is 
returned.
+
+  @retval  TRUE   The certificate CommonName retrieved successfully.
+  @retval  FALSE  Invalid certificate, or CommonNameSize is NULL,
+  or no CommonName entry exists.
+  @retval  FALSE  This interface is not supported.
+
+**/
+BOOLEAN
+EFIAPI
+X509GetCommonName (
+  IN  CONST UINT8  *Cert,
+  IN  UINTNCertSize,
+  OUT CHAR8*CommonName,
+  IN OUT  UINTN*CommonNameSize
+  );
+
 /**
   Verify one X509 certificate was issued by the trusted CA.
 
diff --git a/CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c 
b/CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c
index 7d275977c5..e45c214bd1 100644
--- a/CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c
+++ b/CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c
@@ -297,6 +297,99 @@ _Exit:
   return Status;
 }
 
+/**
+  Retrieve the common name (CN) string from one X.509 certificate.
+
+  If Cert or CommonNameSize is NULL, then return FALSE.
+  If this interface is not supported, then return FALSE.
+
+  @param[in]  CertPointer to the DER-encoded X509 certificate.
+  @param[in]  CertSizeSize of the X509 certificate in bytes.
+  @param[out] CommonName  Buffer to contain the retrieved certificate 
common
+  name string. At most CommonNameSize bytes 
will be
+  written and the 

[edk2] Repeated condition check

[Santhapur Naveen]

Hi all,

There is a redundant condition check in the API PxeBcIcmp6ErrorDpcHandle()

VOID
EFIAPI
PxeBcIcmp6ErrorDpcHandle (
  IN VOID *Context
  )
{
 ...

  if (Type != ICMP_V6_DEST_UNREACHABLE &&
  Type != ICMP_V6_PACKET_TOO_BIG &&
-Type != ICMP_V6_PACKET_TOO_BIG &&
+Type != ICMP_V6_TIME_EXCEEDED &&
  Type != ICMP_V6_PARAMETER_PROBLEM) {
//
// The type of the receveid packet should be an ICMP6 error message.
//
gBS->SignalEvent (RxData->RecycleSignal);
goto ON_EXIT;
  }
  ...
}

Unfortunately, some error checking tools were not able to capture this.
Please confirm and take the necessary action.

Thank you
Naveen
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 2/3] IntelSiliconPkg/IntelVTdPmrPei: Parse RMRR table.

[Yao, Jiewen]

Yes, Typo. will be fixed.

> -Original Message-
> From: Zeng, Star
> Sent: Wednesday, September 20, 2017 2:30 PM
> To: Yao, Jiewen ; edk2-devel@lists.01.org
> Cc: Zeng, Star 
> Subject: RE: [PATCH 2/3] IntelSiliconPkg/IntelVTdPmrPei: Parse RMRR table.
> 
> Sorry, should it be "rest"?
> 
> -Original Message-
> From: Zeng, Star
> Sent: Wednesday, September 20, 2017 2:29 PM
> To: Yao, Jiewen ; edk2-devel@lists.01.org
> Cc: Zeng, Star 
> Subject: RE: [PATCH 2/3] IntelSiliconPkg/IntelVTdPmrPei: Parse RMRR table.
> 
> The typo "reset" in commit log? Should it be "reset"?
> 
> Thanks,
> Star
> -Original Message-
> From: Yao, Jiewen
> Sent: Sunday, September 17, 2017 2:07 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star 
> Subject: [PATCH 2/3] IntelSiliconPkg/IntelVTdPmrPei: Parse RMRR table.
> 
> In order to support PEI graphic, we let VTdPmrPei driver parse DMAR table RMRR
> entry and allow the UMA access.
> 
> If a system has no PEI IGD, no RMRR is needed. The behavior is unchanged.
> 
> If a system has PEI IGD, it must report RMRR in PEI phase.
> The PeiVTdPrm will program the IGD VTd engine to skip the RMRR region, and
> program the reset PCI VTd engine to skip the another DMA buffer allocated in 
> PEI
> phase for other device driver.
> 
> Cc: Star Zeng 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jiewen Yao 
> ---
>  IntelSiliconPkg/Feature/VTd/IntelVTdPmrPei/IntelVTdPmr.c|  52 +-
>  IntelSiliconPkg/Feature/VTd/IntelVTdPmrPei/IntelVTdPmrPei.c | 581
> +++-
> IntelSiliconPkg/Feature/VTd/IntelVTdPmrPei/IntelVTdPmrPei.h |  20 +-
>  3 files changed, 624 insertions(+), 29 deletions(-)
> 
> diff --git a/IntelSiliconPkg/Feature/VTd/IntelVTdPmrPei/IntelVTdPmr.c
> b/IntelSiliconPkg/Feature/VTd/IntelVTdPmrPei/IntelVTdPmr.c
> index ef08e29..be841aa 100644
> --- a/IntelSiliconPkg/Feature/VTd/IntelVTdPmrPei/IntelVTdPmr.c
> +++ b/IntelSiliconPkg/Feature/VTd/IntelVTdPmrPei/IntelVTdPmr.c
> @@ -22,7 +22,7 @@
> 
>  #include "IntelVTdPmrPei.h"
> 
> -extern EDKII_VTD_INFO_PPI*mVTdInfoPpi;
> +extern VTD_INFO*mVTdInfo;
> 
>  /**
>Get protected low memory alignment.
> @@ -60,7 +60,7 @@ GetPhmrAlignment (
>UINT64Data64;
>UINT8 HostAddressWidth;
> 
> -  HostAddressWidth = mVTdInfoPpi->HostAddressWidth;
> +  HostAddressWidth = mVTdInfo->HostAddressWidth;
> 
>MmioWrite64 (VtdUnitBaseAddress + R_PMEN_HIGH_BASE_REG,
> 0x);
>Data64 = MmioRead64 (VtdUnitBaseAddress + R_PMEN_HIGH_BASE_REG);
> @@ -73,11 +73,13 @@ GetPhmrAlignment (
>  /**
>Get protected low memory alignment.
> 
> +  @param EngineMask The mask of the VTd engine to be accessed.
> +
>@return protected low memory alignment.
>  **/
>  UINT32
>  GetLowMemoryAlignment (
> -  VOID
> +  IN UINT64EngineMask
>)
>  {
>UINTN Index;
> @@ -85,8 +87,11 @@ GetLowMemoryAlignment (
>UINT32FinalAlignment;
> 
>FinalAlignment = 0;
> -  for (Index = 0; Index < mVTdInfoPpi->VTdEngineCount; Index++) {
> -Alignment = GetPlmrAlignment
> ((UINTN)mVTdInfoPpi->VTdEngineAddress[Index]);
> +  for (Index = 0; Index < mVTdInfo->VTdEngineCount; Index++) {
> +if ((EngineMask & LShiftU64(1, Index)) == 0) {
> +  continue;
> +}
> +Alignment = GetPlmrAlignment
> + ((UINTN)mVTdInfo->VTdEngineAddress[Index]);
>  if (FinalAlignment < Alignment) {
>FinalAlignment = Alignment;
>  }
> @@ -97,11 +102,13 @@ GetLowMemoryAlignment (
>  /**
>Get protected high memory alignment.
> 
> +  @param EngineMask The mask of the VTd engine to be accessed.
> +
>@return protected high memory alignment.
>  **/
>  UINT64
>  GetHighMemoryAlignment (
> -  VOID
> +  IN UINT64EngineMask
>)
>  {
>UINTN Index;
> @@ -109,8 +116,11 @@ GetHighMemoryAlignment (
>UINT64FinalAlignment;
> 
>FinalAlignment = 0;
> -  for (Index = 0; Index < mVTdInfoPpi->VTdEngineCount; Index++) {
> -Alignment = GetPhmrAlignment
> ((UINTN)mVTdInfoPpi->VTdEngineAddress[Index]);
> +  for (Index = 0; Index < mVTdInfo->VTdEngineCount; Index++) {
> +if ((EngineMask & LShiftU64(1, Index)) == 0) {
> +  continue;
> +}
> +Alignment = GetPhmrAlignment
> + ((UINTN)mVTdInfo->VTdEngineAddress[Index]);
>  if (FinalAlignment < Alignment) {
>FinalAlignment = Alignment;
>  }
> @@ -246,6 +256,7 @@ SetPmrRegion (
>  /**
>Set DMA protected region.
> 
> +  @param EngineMask The mask of the VTd engine to be accessed.
>@param LowMemoryBase  The protected low memory region base.
>@param LowMemoryLengthThe protected low memory region length.
>@param HighMemoryBase The protected high memory region base.
> @@ -256,6 +267,7 @@ SetPmrRegion (
>  **/
>  EFI_STATUS
>  

Re: [edk2] [PATCH 1/3] IntelSiliconPkg/VTdInfoPpi: Let it follow DMAR table.

[Yao, Jiewen]

Agree!

> -Original Message-
> From: Zeng, Star
> Sent: Wednesday, September 20, 2017 2:30 PM
> To: Yao, Jiewen ; edk2-devel@lists.01.org
> Cc: Zeng, Star 
> Subject: RE: [PATCH 1/3] IntelSiliconPkg/VTdInfoPpi: Let it follow DMAR table.
> 
> I think we'd better to add #include  in
> DmaRemappingReportingTable.h, but not VtdInfo.h.
> 
> Thanks,
> Star
> -Original Message-
> From: Yao, Jiewen
> Sent: Sunday, September 17, 2017 2:07 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star 
> Subject: [PATCH 1/3] IntelSiliconPkg/VTdInfoPpi: Let it follow DMAR table.
> 
> We notice that there is real usage in PEI to show the graphic output. As such 
> we
> need report RMRR table in PEI to let VTdPmrPei driver skip the IGD UMA region.
> 
> Now the VTD_INFO PPI uses the same DMAR data structure.
> 
> Cc: Star Zeng 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jiewen Yao 
> ---
>  IntelSiliconPkg/Include/Ppi/VtdInfo.h | 26 +++-
>  1 file changed, 15 insertions(+), 11 deletions(-)
> 
> diff --git a/IntelSiliconPkg/Include/Ppi/VtdInfo.h
> b/IntelSiliconPkg/Include/Ppi/VtdInfo.h
> index e8be63f..a0a6f9c 100644
> --- a/IntelSiliconPkg/Include/Ppi/VtdInfo.h
> +++ b/IntelSiliconPkg/Include/Ppi/VtdInfo.h
> @@ -17,22 +17,26 @@
>  #ifndef __VTD_INFO_PPI_H__
>  #define __VTD_INFO_PPI_H__
> 
> +#include 
> +#include 
> +
>  #define EDKII_VTD_INFO_PPI_GUID \
>  { \
>0x8a59fcb3, 0xf191, 0x400c, { 0x97, 0x67, 0x67, 0xaf, 0x2b, 0x25, 0x68,
> 0x4a } \
>  }
> 
> -typedef struct _EDKII_VTD_INFO_PPI  EDKII_VTD_INFO_PPI;
> -
> -#define EDKII_VTD_INFO_PPI_REVISION 0x0001
> -
> -struct _EDKII_VTD_INFO_PPI {
> -  UINT64  Revision;
> -  UINT8   HostAddressWidth;
> -  UINT8   Reserved[3];
> -  UINT32  VTdEngineCount;
> -  UINT64  VTdEngineAddress[1];
> -};
> +//
> +// VTD info PPI just use same data structure as DMAR table.
> +//
> +// The reported information must include what is needed in PEI phase, e.g.
> +//   the VTd engine (such as DRHD)
> +//   the reserved DMA address in PEI for eary graphic (such as RMRR for
> graphic UMA)
> +//
> +// The reported information can be and might be a subset of full DMAR table,
> e.g.
> +//   if some data is not avaiable (such as ANDD),
> +//   if some data is not needed (such as RMRR for legacy USB).
> +//
> +typedef EFI_ACPI_DMAR_HEADER EDKII_VTD_INFO_PPI;
> 
>  extern EFI_GUID gEdkiiVTdInfoPpiGuid;
> 
> --
> 2.7.4.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2] PeiLib : Inform UEFI memory to Linux

[Ard Biesheuvel]

On 19 September 2017 at 22:32, Sakar Arora  wrote:
> The DXE core dispatcher relies on the available memory to allocate space for 
> loading the rest of the modules from the UEFI image. If we declare the UEFI 
> image memory space (from which DXE dispatcher reads the efi modules) open to 
> allocation, it might lead to data corruption, depending on the location of 
> UEFI image and cumulative size of uncompressed EFI modules.
>
> Also, since UEFI allows unloading and loading of drivers at runtime, IMO, 
> there is a need to preserve the UEFI image even after all the modules have 
> been decompressed and loaded in the boot sequence.
>

None of this is relevant. The uncompressed firmware volume containing
DXE core and everything else is preserved as before. The only thing
that gets discarded is the outer FV, which only contains the PrePi SEC
module, and the compressed FV, neither of which is ever touched again
after DXE core has started executing. So we should not register the FV
in the first place, and not reserve the memory so we don't lose it.

If you still think this may break anything, could you please elaborate?



> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Tuesday, September 19, 2017 6:18 PM
> To: Sakar Arora 
> Cc: Meenakshi Aggarwal ; edk2-devel@lists.01.org; 
> leif.lindh...@linaro.org
> Subject: Re: [edk2] [PATCH v2] PeiLib : Inform UEFI memory to Linux
>
> On 19 September 2017 at 01:07, Sakar Arora  wrote:
>> This change will create the possibility for memory space holding the UEFI 
>> image to be over-written by the DXE core code, since this space will then be 
>> available for allocation.
>
> Yes. But why does this matter after the entire payload has been decompressed 
> into memory already?
>
>
>> Any such change, if required, should be done just before booting the OS.
>>
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Meenakshi Aggarwal
>> Sent: Tuesday, September 19, 2017 6:02 PM
>> To: edk2-devel@lists.01.org; leif.lindh...@linaro.org;
>> ard.biesheu...@linaro.org
>> Subject: [edk2] [PATCH v2] PeiLib : Inform UEFI memory to Linux
>>
>> While creating Hob list, ArmPlatformPkg is hiding UEFI memory.
>> whereas this memory can be used by OS.
>>
>> This patch, allows OS to use UEFI code area.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Udit Kumar 
>> Signed-off-by: Meenakshi Aggarwal 
>> ---
>>  ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c | 69
>> -
>>  1 file changed, 69 deletions(-)
>>
>> diff --git a/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c
>> b/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c
>> index 2feb11f..d03214b 100644
>> --- a/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c
>> +++ b/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c
>> @@ -70,11 +70,7 @@ MemoryPeim (
>>  {
>>ARM_MEMORY_REGION_DESCRIPTOR *MemoryTable;
>>EFI_RESOURCE_ATTRIBUTE_TYPE  ResourceAttributes;
>> -  UINT64   ResourceLength;
>>EFI_PEI_HOB_POINTERS NextHob;
>> -  EFI_PHYSICAL_ADDRESS FdTop;
>> -  EFI_PHYSICAL_ADDRESS SystemMemoryTop;
>> -  EFI_PHYSICAL_ADDRESS ResourceTop;
>>BOOLEAN  Found;
>>
>>// Get Virtual Memory Map from the Platform Library @@ -121,71 +117,6 @@ 
>> MemoryPeim (
>>  );
>>}
>>
>> -  //
>> -  // Reserved the memory space occupied by the firmware volume
>> -  //
>> -
>> -  SystemMemoryTop = (EFI_PHYSICAL_ADDRESS)PcdGet64
>> (PcdSystemMemoryBase) + (EFI_PHYSICAL_ADDRESS)PcdGet64
>> (PcdSystemMemorySize);
>> -  FdTop = (EFI_PHYSICAL_ADDRESS)PcdGet64 (PcdFdBaseAddress) +
>> (EFI_PHYSICAL_ADDRESS)PcdGet32 (PcdFdSize);
>> -
>> -  // EDK2 does not have the concept of boot firmware copied into
>> DRAM. To avoid the DXE
>> -  // core to overwrite this area we must mark the region with the
>> attribute non-present
>> -  if ((PcdGet64 (PcdFdBaseAddress) >= PcdGet64 (PcdSystemMemoryBase)) && 
>> (FdTop <= SystemMemoryTop)) {
>> -Found = FALSE;
>> -
>> -// Search for System Memory Hob that contains the firmware
>> -NextHob.Raw = GetHobList ();
>> -while ((NextHob.Raw = GetNextHob (EFI_HOB_TYPE_RESOURCE_DESCRIPTOR, 
>> NextHob.Raw)) != NULL) {
>> -  if ((NextHob.ResourceDescriptor->ResourceType == 
>> EFI_RESOURCE_SYSTEM_MEMORY) &&
>> -  (PcdGet64 (PcdFdBaseAddress) >= 
>> NextHob.ResourceDescriptor->PhysicalStart) &&
>> -  (FdTop <= NextHob.ResourceDescriptor->PhysicalStart + 
>> NextHob.ResourceDescriptor->ResourceLength))
>> -  {
>> -ResourceAttributes = NextHob.ResourceDescriptor->ResourceAttribute;
>> -ResourceLength = NextHob.ResourceDescriptor->ResourceLength;
>> -ResourceTop = NextHob.ResourceDescriptor->PhysicalStart + 
>> 

Re: [edk2] [PATCH 0/3] IntelSiliconPkg/InteVTdPei: Add RMRR support in PEI

[Zeng, Star]

Minor comments added for separated patches, with that fixed, Reviewed-by: Star 
Zeng 


Thanks,
Star
-Original Message-
From: Yao, Jiewen 
Sent: Sunday, September 17, 2017 2:07 PM
To: edk2-devel@lists.01.org
Cc: Zeng, Star 
Subject: [PATCH 0/3] IntelSiliconPkg/InteVTdPei: Add RMRR support in PEI

We notice that there is real usage in PEI to show the graphic output.
The Integrated Graphic Device is blocked by current IntelVTdPei because the DMA 
buffer is fully controlled by VTd PEIM. The UMA is not allowed.

In DXE phase, the UMA is reported via RMRR table.

As such, we need similar way in PEI to let VTd PEI get the RMRR information.

This series patch resolves this problem.

We also updated sample driver to show how to get the RMRR information.

Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jiewen Yao 

Jiewen Yao (3):
  IntelSiliconPkg/VTdInfoPpi: Let it follow DMAR table.
  IntelSiliconPkg/IntelVTdPmrPei: Parse RMRR table.
  IntelSiliconPkg/VTdInfoSample: Add RMRR table.

 IntelSiliconPkg/Feature/VTd/IntelVTdPmrPei/IntelVTdPmr.c   
   |  52 +-
 IntelSiliconPkg/Feature/VTd/IntelVTdPmrPei/IntelVTdPmrPei.c
   | 581 +++-
 IntelSiliconPkg/Feature/VTd/IntelVTdPmrPei/IntelVTdPmrPei.h
   |  20 +-
 
IntelSiliconPkg/Feature/VTd/PlatformVTdInfoSamplePei/PlatformVTdInfoSamplePei.c 
  | 156 +-
 
IntelSiliconPkg/Feature/VTd/PlatformVTdInfoSamplePei/PlatformVTdInfoSamplePei.inf
 |   3 +
 IntelSiliconPkg/Include/Ppi/VtdInfo.h  
   |  26 +-
 6 files changed, 788 insertions(+), 50 deletions(-)

--
2.7.4.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel