[edk2] 答复: FCE tool parse edk2 bios fd( build by linux gcc) failed

[xujiawu]

HI, Liming,
Thanks for your fast and kindly reply.
I will try the latest edk2 as your suggestion.

BR,
Robin.

-邮件原件-
发件人: Gao, Liming [mailto:liming@intel.com] 
发送时间: 2017年2月24日 15:43
收件人: xujiawu; edk2-de...@ml01.01.org
抄送: 'Daisy Wang'
主题: RE: [edk2] FCE tool parse edk2 bios fd( build by linux gcc) failed

I know BaseTools has one issue to parse GCC map file. It may cause this
issue. But, BaseTools issue has been fixed in edk2
3e7e8571da891122c6821ebc428ce6dbd8a35ff3. 

Could you try the latest edk2 trunk?

Thanks
Liming
>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>xujiawu
>Sent: Friday, February 24, 2017 2:59 PM
>To: edk2-de...@ml01.01.org
>Cc: 'Daisy Wang' ; 'xujiawu'
>
>Subject: [edk2] FCE tool parse edk2 bios fd( build by linux gcc) failed
>
>Hello, edk2-devel
>
>I want to report a bug about fce tool:
>
>Fce tool parse edk2 bios fd( build by linux gcc) failed
>
>
>
>Reproduce step:
>
>1.  Build OVMF.fd by linux gcc (ubuntu14.04, gcc version 4.85)
>
>2.  Command: Fce read -i OVMF.fd
>
>3.  Fce Failed and show: error while parse the FFS file.
>
>
>
>I want to know if fce tool doesn't support parse edk2 bios fd build by
linux
>gcc.
>
>
>
>Thanks,
>
>Robin
>
>___
>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] FCE tool parse edk2 bios fd( build by linux gcc) failed

[Gao, Liming]

I know BaseTools has one issue to parse GCC map file. It may cause this issue. 
But, BaseTools issue has been fixed in edk2 
3e7e8571da891122c6821ebc428ce6dbd8a35ff3. 

Could you try the latest edk2 trunk?

Thanks
Liming
>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>xujiawu
>Sent: Friday, February 24, 2017 2:59 PM
>To: edk2-de...@ml01.01.org
>Cc: 'Daisy Wang' ; 'xujiawu'
>
>Subject: [edk2] FCE tool parse edk2 bios fd( build by linux gcc) failed
>
>Hello, edk2-devel
>
>I want to report a bug about fce tool:
>
>Fce tool parse edk2 bios fd( build by linux gcc) failed
>
>
>
>Reproduce step:
>
>1.  Build OVMF.fd by linux gcc (ubuntu14.04, gcc version 4.85)
>
>2.  Command: Fce read -i OVMF.fd
>
>3.  Fce Failed and show: error while parse the FFS file.
>
>
>
>I want to know if fce tool doesn't support parse edk2 bios fd build by linux
>gcc.
>
>
>
>Thanks,
>
>Robin
>
>___
>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] Should Path Name in File Path Media Device Path node be NULL terminated?

[Tian, Feng]

UEFI spec clearly say:

"Path Name" is A NULL-terminated Path string including directory and file 
names. The length of this string n can be determined by
subtracting 4 from the Length entry. A device path may contain one or more of 
these nodes. Each node can optionally add a "\" separator to the beginning 
and/or the end of the Path Name string. The complete path to a file can be 
found by logically concatenating all the Path Name strings in the File Path 
Media Device Path nodes. This is typically used to describe the directory path 
in one node, and the filename in another node.

Thanks
Feng

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Andrei 
Borzenkov
Sent: Friday, February 24, 2017 3:06 PM
To: edk2-devel-01 ; The development of GNU GRUB 

Subject: [edk2] Should Path Name in File Path Media Device Path node be NULL 
terminated?

Historically grub2 built image paths using two File Path nodes - one for 
directory and one for file name relative to directory. These nodes had path 
names that were not NULL terminated.

Recently we had bug report that secure boot using grub2 failed. It was tracked 
down to exactly the fact that paths were not NULL terminated.
See
http://git.savannah.gnu.org/cgit/grub.git/commit/?id=ce95549cc54b5d6f494608a7c390dba3aab4fba7

Unfortunately this caused another regression which looks like firmware 
truncating passed image path on first NULL

https://bugzilla.opensuse.org/show_bug.cgi?id=1026344

Could someone clarify what is expected by EFI spec? Should each Path Name (even 
intermediate) be NULL terminated, or spec intends to say that only full path 
must be NULL terminated?
___
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] BaseTools: Skip module AutoGen by comparing timestamp.

[Derek Lin]

[Introduction]

The BaseTool Build.py AutoGen parse INF meta-file and generate
AutoGen.c/AutoGen.h/makefile. When we only change .c .h code, the
AutoGen might be not necessary, but Build.py spend a lot of time on it.
There's a -u flag to skip all module's AutoGen. In my environment, it save
35%~50% of time in rebuild a ROM.
However, if user change one .INF meta-file, then -u flag is not available.

[Idea]

AutoGen can compare meta-file's timestamp and decide if the module's
AutoGen can be skipped. With this, when a module's INF is changed, we
only run this module's AutoGen, we don't need to run other module's.

[Implementation]

In the end of a module's AutoGen, we create a AutoGenTimeStamp.
The file save a file list that related to this module's AutoGen.
In other word, the file list in AutoGenTimeStamp is INPUT files of
module AutoGen, AutoGenTimeStamp file is OUTPUT.
During rebuild, we compare time stamp between INPUT and OUTPUT, and
decide if we can skip it.

Below is the Input/Output of a module's AutoGen.

[Input]
  1. All the DSC/DEC/FDF used by the platform.
  2. Macro and PCD defined by Build Options such as "build -D AAA=TRUE
 --pcd BbbPcd=0".
  3. INF file of a module.
  4. Source files of a module, list in [Sources] section of INF.
  5. All the library link by the module.
  6. All the .h files included by the module's sources.

[Output]
  AutoGen.c/AutoGen.h/makefile/AutoGenTimeStamp

[Testing]

This patch save my build time. When I make a change without touching
DSC/DEC/FDF, it is absolutely much faster than original rebuild,
35%~50% time saving in my environment
(compare to original tool rebuild time).
If I change any DSC/DEC/FDF, there's no performance improve, because it
can't skip any module's AutoGen.

Please note that if your environment will generate DSC/FDF during prebuild,
it will not skip any AutoGen because of DSC timestamp is changed. This will
require prebuild script not to update metafile when content is not changed.

---
Changes in v3:
- Consider BuildOption such as -D AAA=TRUE --pcd BbbPcd=0, add BuildOption
  meta-file.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Derek Lin 
---
 BaseTools/Source/Python/AutoGen/AutoGen.py | 136 +
 BaseTools/Source/Python/AutoGen/GenMake.py |   3 +
 BaseTools/Source/Python/GenFds/FdfParser.py|   4 +
 .../Source/Python/Workspace/MetaFileParser.py  |   4 +
 4 files changed, 147 insertions(+)

diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py 
b/BaseTools/Source/Python/AutoGen/AutoGen.py
index f35ae252b0..6a2ea7d7ca 100644
--- a/BaseTools/Source/Python/AutoGen/AutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
@@ -42,6 +42,7 @@ from GenPcdDb import CreatePcdDatabaseCode
 from Workspace.MetaFileCommentParser import UsageList
 from Common.MultipleWorkspace import MultipleWorkspace as mws
 import InfSectionParser
+import datetime
 
 ## Regular expression for splitting Dependency Expression string into tokens
 gDepexTokenPattern = re.compile("(\(|\)|\w+| \S+\.inf)")
@@ -640,6 +641,41 @@ class WorkspaceAutoGen(AutoGen):
 self._MakeFileDir = None
 self._BuildCommand = None
 
+#
+# Create BuildOptions Macro & PCD metafile.
+#
+content = 'gCommandLineDefines: '
+content += str(GlobalData.gCommandLineDefines)
+content += os.linesep
+content += 'BuildOptionPcd: '
+content += str(GlobalData.BuildOptionPcd)
+SaveFileOnChange(os.path.join(self.BuildDir, 'BuildOptions'), content, 
False)
+
+#
+# Get set of workspace metafiles
+#
+AllWorkSpaceMetaFiles = self._GetMetaFiles(Target, Toolchain, Arch)
+
+#
+# Retrieve latest modified time of all metafiles
+#
+SrcTimeStamp = 0
+for f in AllWorkSpaceMetaFiles:
+if os.stat(f)[8] > SrcTimeStamp:
+SrcTimeStamp = os.stat(f)[8]
+self._SrcTimeStamp = SrcTimeStamp
+
+#
+# Write metafile list to build directory
+#
+AutoGenFilePath = os.path.join(self.BuildDir, 'AutoGen')
+if os.path.exists (AutoGenFilePath):
+os.remove(AutoGenFilePath)
+if not os.path.exists(self.BuildDir):
+os.makedirs(self.BuildDir)
+with open(os.path.join(self.BuildDir, 'AutoGen'), 'w+') as file:
+for f in AllWorkSpaceMetaFiles:
+print >> file, f
 return True
 
 def _BuildOptionPcdValueFormat(self, TokenSpaceGuidCName, TokenCName, 
PcdDatumType, Value):
@@ -668,6 +704,45 @@ class WorkspaceAutoGen(AutoGen):
 Value = '0'
 return  Value
 
+def _GetMetaFiles(self, Target, Toolchain, Arch):
+AllWorkSpaceMetaFiles = set()
+#
+# add fdf
+#
+if self.FdfFile:
+AllWorkSpaceMetaFiles.add (self.FdfFile.Path)
+if self.FdfFile:
+FdfFiles = GlobalData.gFdfParser.G

[edk2] Should Path Name in File Path Media Device Path node be NULL terminated?

[Andrei Borzenkov]

Historically grub2 built image paths using two File Path nodes - one for
directory and one for file name relative to directory. These nodes had
path names that were not NULL terminated.

Recently we had bug report that secure boot using grub2 failed. It was
tracked down to exactly the fact that paths were not NULL terminated.
See
http://git.savannah.gnu.org/cgit/grub.git/commit/?id=ce95549cc54b5d6f494608a7c390dba3aab4fba7

Unfortunately this caused another regression which looks like firmware
truncating passed image path on first NULL

https://bugzilla.opensuse.org/show_bug.cgi?id=1026344

Could someone clarify what is expected by EFI spec? Should each Path
Name (even intermediate) be NULL terminated, or spec intends to say that
only full path must be NULL terminated?
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] 撤回: FCE tool retrieve edk2 bios fd( build by linux gcc) failed

[xujiawu]

xujiawu 将撤回邮件“FCE tool retrieve edk2 bios fd( build by linux gcc)
failed”。
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] FCE tool retrieve edk2 bios fd( build by linux gcc) failed

[xujiawu]

Hello, edk2-devel

  I want to report a bug about fce tool.

But fce tool show error while retrieve the bios fd file (build by linux
gcc).

 

Reproduce step:

1.  Build OVMF.fd by linux gcc (ubuntu14.04, gcc version 4.85)

2.  Fce read -i OVMF.fd

3.  Failed and show: error while parse the FFS file.

 

I want to know if fce tool doesn't support parse edk2 bios fd build by linux
gcc.

 

Thanks,

Robin

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

Re: [edk2] [PATCH v3 2/7] MdePkg IndustryStandard/Scsi.h: Add sense code macro

[Tian, Feng]

Linton,

Could you let me know where the +#define EFI_SCSI_REQUEST_SENSE_ERROR  (0x70) 
comes from?

According to SCSI SPC5r08 spec, the first byte of sense data is the RESPONSE 
CODE field. 

And 0x70 means

a) the result of an error, exception condition, or protocol specific failure 
that is associated with CHECK
CONDITION status; or
b) additional information that is associated with a status other than CHECK 
CONDITION.

It's possible that 0x70 means success... so this naming may be not quite 
appropriate.

And in your usage, you forcedly convert Packet->SenseData to UINT8 and access 
each sense data field by array index. I think it's unnecessary. 
Packet->SenseData is EFI_SCSI_SENSE_DATA type, which has defined the meaning of 
each field. With this structure, you don't need introduce EFI_SCSI_SK_VALUE 
macro again.

+sense = (UINT8 *)Packet->SenseData;
+if ((Packet->SenseDataLength > 13) &&
+(sense[0] & EFI_SCSI_REQUEST_SENSE_ERROR)) {
+  DEBUG ((DEBUG_INFO, "SiI3132ScsiPassRead() Key %X ASC(Q) %02X%02X\n",
+  EFI_SCSI_SK_VALUE (sense[2]), sense[12], sense[13]));
+}

Thanks
Feng

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jeremy 
Linton
Sent: Friday, February 24, 2017 6:34 AM
To: edk2-devel@lists.01.org
Cc: ard.biesheu...@linaro.org; steve.cap...@arm.com; ryan.har...@linaro.org; 
leif.lindh...@linaro.org; linaro-u...@lists.linaro.org
Subject: [edk2] [PATCH v3 2/7] MdePkg IndustryStandard/Scsi.h: Add sense code 
macro

Add some definitions to mask the sense key from sense data, and check the 
validity of the returned sense data.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeremy Linton 
---
 MdePkg/Include/IndustryStandard/Scsi.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MdePkg/Include/IndustryStandard/Scsi.h 
b/MdePkg/Include/IndustryStandard/Scsi.h
index 0d81314..802479e 100644
--- a/MdePkg/Include/IndustryStandard/Scsi.h
+++ b/MdePkg/Include/IndustryStandard/Scsi.h
@@ -369,6 +369,8 @@ typedef struct {
 //
 // Sense Key
 //
+#define EFI_SCSI_REQUEST_SENSE_ERROR  (0x70)
+#define EFI_SCSI_SK_VALUE(byte)   (byte&0x0F)
 #define EFI_SCSI_SK_NO_SENSE  (0x0)
 #define EFI_SCSI_SK_RECOVERY_ERROR(0x1)
 #define EFI_SCSI_SK_NOT_READY (0x2)
--
2.9.3

___
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] NetworkPkg: Add check logic for some variable in iSCSI driver.

[Zhang Lubo]

Add check logic for some attempt variable to enhance code in iSCSI.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo 
Cc: Ye Ting 
Cc: Fu Siyuan 
Cc: Wu Jiaxin 
---
 NetworkPkg/IScsiDxe/IScsiConfig.c | 75 +--
 1 file changed, 41 insertions(+), 34 deletions(-)

diff --git a/NetworkPkg/IScsiDxe/IScsiConfig.c 
b/NetworkPkg/IScsiDxe/IScsiConfig.c
index b169620..f8c0a61 100644
--- a/NetworkPkg/IScsiDxe/IScsiConfig.c
+++ b/NetworkPkg/IScsiDxe/IScsiConfig.c
@@ -628,37 +628,42 @@ IScsiConvertAttemptConfigDataToIfrNvDataByKeyword (
   ISCSI_SESSION_CONFIG_NVDATA   *SessionConfigData;
   ISCSI_CHAP_AUTH_CONFIG_NVDATA *AuthConfigData;
   CHAR16AttemptNameList[ATTEMPT_NAME_LIST_SIZE];
   EFI_IP_ADDRESSIp;
   UINTN Index;
+  UINTN StringLen;
 
   ZeroMem (AttemptNameList, sizeof (AttemptNameList));
 
   NET_LIST_FOR_EACH (Entry, &mPrivate->AttemptConfigs) {
 Attempt = NET_LIST_USER_STRUCT (Entry, ISCSI_ATTEMPT_CONFIG_NVDATA, Link);
 //
 // Normal session configuration parameters.
 //
 SessionConfigData = &Attempt->SessionConfigData;
 
+ASSERT ((Attempt->AttemptConfigIndex > 0) && (Attempt->AttemptConfigIndex 
<= FixedPcdGet8 (PcdMaxIScsiAttemptNumber)));
 Index   = Attempt->AttemptConfigIndex - 1;
 
 //
 // Save the attempt to AttemptNameList as Attempt:1 Attempt:2
 //
 AsciiStrToUnicodeStrS (
   Attempt->AttemptName,
   AttemptNameList + StrLen (AttemptNameList),
-  ATTEMPT_NAME_LIST_SIZE
+  ATTEMPT_NAME_LIST_SIZE - StrLen (AttemptNameList)
 );
-*(AttemptNameList + StrLen (AttemptNameList) - 2) = L':';
-*(AttemptNameList + StrLen (AttemptNameList)) = L' ';
+
+StringLen = StrLen (AttemptNameList);
+ASSERT (StringLen > 2);
+*(AttemptNameList + StringLen - 2) = L':';
+*(AttemptNameList + StringLen) = L' ';
 
 AsciiStrToUnicodeStrS (
   Attempt->AttemptName,
   IfrNvData->ISCSIAttemptName  + ATTEMPT_NAME_SIZE * Index,
-  ATTEMPT_NAME_SIZE
+  ATTEMPT_NAME_LIST_SIZE - ATTEMPT_NAME_SIZE * Index
 );
 
 IfrNvData->ISCSIBootEnableList[Index]  = 
SessionConfigData->Enabled;
 IfrNvData->ISCSIIpAddressTypeList[Index]   = SessionConfigData->IpMode;
 
@@ -1199,10 +1204,11 @@ IScsiConvertlfrNvDataToAttemptConfigDataByKeyword (
   EFI_IP_ADDRESS   Gateway;
   EFI_INPUT_KEYKey;
   UINT64   Lun;
   EFI_STATUS   Status;
 
+  Attempt = NULL;
   ZeroMem (IScsiName, sizeof (IScsiName));
 
   if (OffSet < ATTEMPT_BOOTENABLE_VAR_OFFSET) {
 return EFI_SUCCESS;
 
@@ -1726,11 +1732,11 @@ IScsiConvertlfrNvDataToAttemptConfigDataByKeyword (
 
 
   //
   // Record the user configuration information in NVR.
   //
-
+  ASSERT (Attempt != NULL);
   UnicodeSPrint (mPrivate->PortString, (UINTN) ISCSI_NAME_IFR_MAX_SIZE, 
L"Attempt %d", Attempt->AttemptConfigIndex);
   return gRT->SetVariable (
 mPrivate->PortString,
 &gEfiIScsiInitiatorNameProtocolGuid,
 ISCSI_CONFIG_VAR_ATTR,
@@ -2705,10 +2711,11 @@ IScsiConfigProcessDefault (
   UINT8   *AttemptConfigOrder;
   UINTN   AttemptConfigOrderSize;
   UINTN   Index;
   EFI_INPUT_KEY   Key;
 
+  AttemptConfigData = NULL;
   //
   // Is User creating a new attempt?
   //
   NewAttempt = FALSE;
 
@@ -2749,41 +2756,40 @@ IScsiConfigProcessDefault (
L"InitialAttemptOrder",
&gIScsiConfigGuid,
&AttemptConfigOrderSize
);
 
-if (AttemptConfigOrder != NULL) {
-
-  for (Index = 0; Index < AttemptConfigOrderSize / sizeof (UINT8); 
Index++) {
-UnicodeSPrint (
-  mPrivate->PortString,
-  (UINTN) ISCSI_NAME_IFR_MAX_SIZE,
-  L"Attempt %d",
-  (UINTN) AttemptConfigOrder[Index]
-  );
-GetVariable2 (
- mPrivate->PortString,
- &gEfiIScsiInitiatorNameProtocolGuid,
- (VOID**)&AttemptConfigData,
- NULL
- );
-if (AttemptConfigData == NULL || AttemptConfigData->Actived == 
ISCSI_ACTIVE_ENABLED) {
-  continue;
-}
-
-break;
-  }
+ASSERT (AttemptConfigOrder != NULL);
 
-  if (Index > PcdGet8 (PcdMaxIScsiAttemptNumber)) {
-CreatePopUp (
-  EFI_LIGHTGRAY | EFI_BACKGROUND_BLUE,
-  &Key,
-  L"Can not create more attempts, Please configure the 
PcdMaxIScsiAttemptNumber if needed!",
-  NULL
-  );
-return EFI_UNSUPPORTED;
+for (Index = 0; Index < AttemptConfigOrderSize / sizeof (UINT8); Index++) {
+  UnicodeSPrint (
+mPrivate->PortString,
+(UI

Re: [edk2] [PATCH] UefiCpuPkg/CpuDxe: Do not ASSERT on AllocateMemorySpace() error

[Zeng, Star]

Reviewed-by: Star Zeng 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jeff Fan
Sent: Friday, February 24, 2017 2:12 PM
To: edk2-devel@lists.01.org
Cc: Kinney, Michael D ; Tian, Feng 
; Laszlo Ersek ; Zeng, Star 

Subject: [edk2] [PATCH] UefiCpuPkg/CpuDxe: Do not ASSERT on 
AllocateMemorySpace() error

Platform PEI may add LOCAL APIC memory mapped space into 
EFI_HOB_MEMORY_ALLOCATION. Or platform may allocate this range before.

So, we skip AllocateMemorySpace()'s return status checking. Instead, we add one 
DEBUG message for possible trace.

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

This updating is suggested by Ersek's comments at 
https://www.mail-archive.com/edk2-devel@lists.01.org/msg22585.html

Cc: Laszlo Ersek 
Cc: Star Zeng 
Cc: Feng Tian 
Cc: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
---
 UefiCpuPkg/CpuDxe/CpuDxe.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/UefiCpuPkg/CpuDxe/CpuDxe.c b/UefiCpuPkg/CpuDxe/CpuDxe.c index 
2fd2f31..4a5e282 100644
--- a/UefiCpuPkg/CpuDxe/CpuDxe.c
+++ b/UefiCpuPkg/CpuDxe/CpuDxe.c
@@ -1075,6 +1075,11 @@ AddLocalApicMemorySpace (
   Status = AddMemoryMappedIoSpace (BaseAddress, SIZE_4KB, EFI_MEMORY_UC);
   ASSERT_EFI_ERROR (Status);
 
+  //
+  // Try to allocate APIC memory mapped space, does not check return  
+ // status because it may be allocated by other driver, or DXE Core if  
+ // this range is built into Memory Allocation HOB.
+  //
   Status = gDS->AllocateMemorySpace (
   EfiGcdAllocateAddress,
   EfiGcdMemoryTypeMemoryMappedIo, @@ -1084,7 +1089,10 @@ 
AddLocalApicMemorySpace (
   ImageHandle,
   NULL
   );
-  ASSERT_EFI_ERROR (Status);
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_INFO, "%a: %a: AllocateMemorySpace() Status - %r\n",
+ gEfiCallerBaseName, __FUNCTION__, Status));  }
 }
 
 /**
-- 
2.9.3.windows.2

___
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 5/5] OvmfPkg: exclude libssl functionality from OpensslLib if TLS_ENABLE=FALSE

[Gary Lin]

On Thu, Feb 23, 2017 at 10:57:44PM +0100, Laszlo Ersek wrote:
> The OpensslLibNoSsl library instance (which does not contain libssl
> functions) is sufficient for the Secure Boot feature.
> 
> Ease security analsysis by excluding libssl functionality from the
> OpensslLib instance we use with TLS_ENABLE=FALSE.
> 
> Cc: Gary Lin 
> Cc: Jordan Justen 
> Cc: Tomas Hoger 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek 

Look good to me.

Reviewed-by: Gary Lin 
> ---
>  OvmfPkg/OvmfPkgIa32.dsc| 4 
>  OvmfPkg/OvmfPkgIa32X64.dsc | 4 
>  OvmfPkg/OvmfPkgX64.dsc | 4 
>  3 files changed, 12 insertions(+)
> 
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index 993547d4859e..44c74c2674e3 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -143,7 +143,11 @@ [LibraryClasses]
>
> 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/OpensslLibNoSsl.inf
> +!endif
>  
>  !if $(SECURE_BOOT_ENABLE) == TRUE
>PlatformSecureLib|OvmfPkg/Library/PlatformSecureLib/PlatformSecureLib.inf
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index f36604ecb4d8..41ae1d88495b 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -148,7 +148,11 @@ [LibraryClasses]
>
> 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/OpensslLibNoSsl.inf
> +!endif
>  
>  !if $(SECURE_BOOT_ENABLE) == TRUE
>PlatformSecureLib|OvmfPkg/Library/PlatformSecureLib/PlatformSecureLib.inf
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index c5bf1a672b1e..fa4fdc81b44f 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -148,7 +148,11 @@ [LibraryClasses]
>
> 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/OpensslLibNoSsl.inf
> +!endif
>  
>  !if $(SECURE_BOOT_ENABLE) == TRUE
>PlatformSecureLib|OvmfPkg/Library/PlatformSecureLib/PlatformSecureLib.inf
> -- 
> 2.9.3
> 
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] UefiCpuPkg/CpuDxe: Do not ASSERT on AllocateMemorySpace() error

[Tian, Feng]

Reviewed-by: Feng Tian 

Thanks
Feng

-Original Message-
From: Fan, Jeff 
Sent: Friday, February 24, 2017 2:12 PM
To: edk2-devel@lists.01.org
Cc: Laszlo Ersek ; Zeng, Star ; Tian, 
Feng ; Kinney, Michael D 
Subject: [PATCH] UefiCpuPkg/CpuDxe: Do not ASSERT on AllocateMemorySpace() error

Platform PEI may add LOCAL APIC memory mapped space into 
EFI_HOB_MEMORY_ALLOCATION. Or platform may allocate this range before.

So, we skip AllocateMemorySpace()'s return status checking. Instead, we add one 
DEBUG message for possible trace.

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

This updating is suggested by Ersek's comments at 
https://www.mail-archive.com/edk2-devel@lists.01.org/msg22585.html

Cc: Laszlo Ersek 
Cc: Star Zeng 
Cc: Feng Tian 
Cc: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
---
 UefiCpuPkg/CpuDxe/CpuDxe.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/UefiCpuPkg/CpuDxe/CpuDxe.c b/UefiCpuPkg/CpuDxe/CpuDxe.c index 
2fd2f31..4a5e282 100644
--- a/UefiCpuPkg/CpuDxe/CpuDxe.c
+++ b/UefiCpuPkg/CpuDxe/CpuDxe.c
@@ -1075,6 +1075,11 @@ AddLocalApicMemorySpace (
   Status = AddMemoryMappedIoSpace (BaseAddress, SIZE_4KB, EFI_MEMORY_UC);
   ASSERT_EFI_ERROR (Status);
 
+  //
+  // Try to allocate APIC memory mapped space, does not check return  
+ // status because it may be allocated by other driver, or DXE Core if  
+ // this range is built into Memory Allocation HOB.
+  //
   Status = gDS->AllocateMemorySpace (
   EfiGcdAllocateAddress,
   EfiGcdMemoryTypeMemoryMappedIo, @@ -1084,7 +1089,10 @@ 
AddLocalApicMemorySpace (
   ImageHandle,
   NULL
   );
-  ASSERT_EFI_ERROR (Status);
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_INFO, "%a: %a: AllocateMemorySpace() Status - %r\n",
+ gEfiCallerBaseName, __FUNCTION__, Status));  }
 }
 
 /**
-- 
2.9.3.windows.2

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

[edk2] [PATCH] UefiCpuPkg/CpuDxe: Do not ASSERT on AllocateMemorySpace() error

[Jeff Fan]

Platform PEI may add LOCAL APIC memory mapped space into
EFI_HOB_MEMORY_ALLOCATION. Or platform may allocate this range before.

So, we skip AllocateMemorySpace()'s return status checking. Instead, we add one
DEBUG message for possible trace.

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

This updating is suggested by Ersek's comments at
https://www.mail-archive.com/edk2-devel@lists.01.org/msg22585.html

Cc: Laszlo Ersek 
Cc: Star Zeng 
Cc: Feng Tian 
Cc: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
---
 UefiCpuPkg/CpuDxe/CpuDxe.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/UefiCpuPkg/CpuDxe/CpuDxe.c b/UefiCpuPkg/CpuDxe/CpuDxe.c
index 2fd2f31..4a5e282 100644
--- a/UefiCpuPkg/CpuDxe/CpuDxe.c
+++ b/UefiCpuPkg/CpuDxe/CpuDxe.c
@@ -1075,6 +1075,11 @@ AddLocalApicMemorySpace (
   Status = AddMemoryMappedIoSpace (BaseAddress, SIZE_4KB, EFI_MEMORY_UC);
   ASSERT_EFI_ERROR (Status);
 
+  //
+  // Try to allocate APIC memory mapped space, does not check return 
+  // status because it may be allocated by other driver, or DXE Core if
+  // this range is built into Memory Allocation HOB.
+  //
   Status = gDS->AllocateMemorySpace (
   EfiGcdAllocateAddress,
   EfiGcdMemoryTypeMemoryMappedIo,
@@ -1084,7 +1089,10 @@ AddLocalApicMemorySpace (
   ImageHandle,
   NULL
   );
-  ASSERT_EFI_ERROR (Status);
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_INFO, "%a: %a: AllocateMemorySpace() Status - %r\n",
+ gEfiCallerBaseName, __FUNCTION__, Status));
+  }
 }
 
 /**
-- 
2.9.3.windows.2

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

Re: [edk2] [PATCH 4/5] Nt32Pkg: exclude libssl functionality from OpensslLib if TLS_ENABLE=FALSE

[Wu, Jiaxin]

Okay, I can review the patch.

Laszlo,

Would you like to change the module name (OpensslLibNoSsl or OpensslLibCrypto)?

Best Regards,
Jiaxin 

> -Original Message-
> From: Ni, Ruiyu
> Sent: Friday, February 24, 2017 12:09 PM
> To: Laszlo Ersek ; edk2-devel-01  de...@ml01.01.org>; Wu, Jiaxin 
> Cc: Tomas Hoger 
> Subject: RE: [edk2] [PATCH 4/5] Nt32Pkg: exclude libssl functionality from
> OpensslLib if TLS_ENABLE=FALSE
> 
> Jiaxin,
> can you review this patch?
> 
> Regards,
> Ray
> 
> >-Original Message-
> >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Laszlo Ersek
> >Sent: Friday, February 24, 2017 5:58 AM
> >To: edk2-devel-01 
> >Cc: Ni, Ruiyu ; Tomas Hoger 
> >Subject: [edk2] [PATCH 4/5] Nt32Pkg: exclude libssl functionality from
> OpensslLib if TLS_ENABLE=FALSE
> >
> >Ease security analsysis by excluding libssl functionality from the
> >OpensslLib instance we use with TLS_ENABLE=FALSE.
> >
> >Cc: Ruiyu Ni 
> >Cc: Tomas Hoger 
> >Contributed-under: TianoCore Contribution Agreement 1.0
> >Signed-off-by: Laszlo Ersek 
> >---
> >
> >Notes:
> >I can't build-test this.
> >
> > Nt32Pkg/Nt32Pkg.dsc | 4 
> > 1 file changed, 4 insertions(+)
> >
> >diff --git a/Nt32Pkg/Nt32Pkg.dsc b/Nt32Pkg/Nt32Pkg.dsc
> >index 47e37ecae134..c84bd71be408 100644
> >--- a/Nt32Pkg/Nt32Pkg.dsc
> >+++ b/Nt32Pkg/Nt32Pkg.dsc
> >@@ -159,7 +159,11 @@ [LibraryClasses]
> >
> CpuExceptionHandlerLib|MdeModulePkg/Library/CpuExceptionHandlerLibN
> ull/CpuExceptionHandlerLibNull.inf
> >   LockBoxLib|MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.inf
> >   IntrinsicLib|CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf
> >+!if $(TLS_ENABLE) == TRUE
> >   OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLib.inf
> >+!else
> >+  OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLibNoSsl.inf
> >+!endif
> >
> > !if $(SECURE_BOOT_ENABLE) == TRUE
> >
> PlatformSecureLib|Nt32Pkg/Library/PlatformSecureLib/PlatformSecureLib.in
> f
> >--
> >2.9.3
> >
> >
> >___
> >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] Tcg2Pei.efi assert after sync to latest trunk

[wang xiaofeng]

Hi Liming,
   Thanks! The issue is fixed after I sync basetool fix.








At 2017-02-23 21:01:25, "Gao, Liming"  wrote:
>This is BaseTools regression issue. It is fixed today. Please try it on 
>tomorrow. 
>
>Thanks
>Liming
>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of wang 
>xiaofeng
>Sent: Thursday, February 23, 2017 7:21 PM
>To: edk2-devel@lists.01.org
>Subject: [edk2] Tcg2Pei.efi assert after sync to latest trunk
>
>Hi All,
>   I just updated to latest edk2 trunk this afternoon , and meet the following 
> error:
>
>
>Loading PEIM at 0x8FB1000 EntryPoint=0x8FB13CF Tcg2Pei.efi
>PROGRESS CODE: V03020002 I0
>WARNING: Tpm2RegisterTpm2DeviceLib - does not support 
>286BF25A-C2C3-408C-B3B4-25E6758B7317 registration
>WARNING: Tpm2RegisterTpm2DeviceLib - does not support 
>286BF25A-C2C3-408C-B3B4-25E6758B7317 registration
>Hash Interface (2AE9D80F-3FB2-4095-B7B1-E93157B946B6) has been registered
>ASSERT_EFI_ERROR (Status = Already started)
>ASSERT [Tcg2Pei] 
>e:\code\cl819sync\Build\SariPlatformPkg\DEBUG_VS2013x86\IA32\SecurityPkg\Tcg\Tcg2Pei\Tcg2Pei\DEBUG\AutoGen.c(466):
> !EFI_ERROR (Status)
>
>
>While AutoGen.c(466) have the following code:
>
>
>  Status = HashInstanceLibSha1Constructor ();
>  ASSERT_EFI_ERROR (Status);
>  Status = HashInstanceLibSha1Constructor ();
>  ASSERT_EFI_ERROR (Status); <-asset here
>
>
>gEfiTpmDeviceInstanceTpm20DtpmGuid = { 0x286bf25a, 0xc2c3, 0x408c, { 0xb3, 
>0xb4, 0x25, 0xe6, 0x75, 0x8b, 0x73, 0x17 } }
>
>
>  So anyone meet the same assert before ?  Thanks in advance !
>
>___
>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-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 4/5] Nt32Pkg: exclude libssl functionality from OpensslLib if TLS_ENABLE=FALSE

[Ni, Ruiyu]

Jiaxin,
can you review this patch?

Regards,
Ray

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo 
>Ersek
>Sent: Friday, February 24, 2017 5:58 AM
>To: edk2-devel-01 
>Cc: Ni, Ruiyu ; Tomas Hoger 
>Subject: [edk2] [PATCH 4/5] Nt32Pkg: exclude libssl functionality from 
>OpensslLib if TLS_ENABLE=FALSE
>
>Ease security analsysis by excluding libssl functionality from the
>OpensslLib instance we use with TLS_ENABLE=FALSE.
>
>Cc: Ruiyu Ni 
>Cc: Tomas Hoger 
>Contributed-under: TianoCore Contribution Agreement 1.0
>Signed-off-by: Laszlo Ersek 
>---
>
>Notes:
>I can't build-test this.
>
> Nt32Pkg/Nt32Pkg.dsc | 4 
> 1 file changed, 4 insertions(+)
>
>diff --git a/Nt32Pkg/Nt32Pkg.dsc b/Nt32Pkg/Nt32Pkg.dsc
>index 47e37ecae134..c84bd71be408 100644
>--- a/Nt32Pkg/Nt32Pkg.dsc
>+++ b/Nt32Pkg/Nt32Pkg.dsc
>@@ -159,7 +159,11 @@ [LibraryClasses]
>   
> CpuExceptionHandlerLib|MdeModulePkg/Library/CpuExceptionHandlerLibNull/CpuExceptionHandlerLibNull.inf
>   LockBoxLib|MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.inf
>   IntrinsicLib|CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf
>+!if $(TLS_ENABLE) == TRUE
>   OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLib.inf
>+!else
>+  OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLibNoSsl.inf
>+!endif
>
> !if $(SECURE_BOOT_ENABLE) == TRUE
>   PlatformSecureLib|Nt32Pkg/Library/PlatformSecureLib/PlatformSecureLib.inf
>--
>2.9.3
>
>
>___
>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/3] ShellPkg UefiDpLib: Fixed GCC build failure caused by ef22403

[Ni, Ruiyu]

Reviewed-by: Ruiyu Ni 

Regards,
Ray

>-Original Message-
>From: Zeng, Star
>Sent: Friday, February 24, 2017 10:10 AM
>To: edk2-devel@lists.01.org
>Cc: Zeng, Star ; Kinney, Michael D 
>; Gao, Liming
>; Carsey, Jaben ; Ni, Ruiyu 
>
>Subject: [PATCH 3/3] ShellPkg UefiDpLib: Fixed GCC build failure caused by 
>ef22403
>
>Cc: Michael Kinney 
>Cc: Liming Gao 
>Cc: Jaben Carsey 
>Cc: Ruiyu Ni 
>Contributed-under: TianoCore Contribution Agreement 1.0
>Signed-off-by: Star Zeng 
>---
> ShellPkg/Library/UefiDpLib/Dp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/ShellPkg/Library/UefiDpLib/Dp.c b/ShellPkg/Library/UefiDpLib/Dp.c
>index 444c136ab188..33f69a0c145a 100644
>--- a/ShellPkg/Library/UefiDpLib/Dp.c
>+++ b/ShellPkg/Library/UefiDpLib/Dp.c
>@@ -271,7 +271,7 @@ ShellCommandRunDp (
>   //StartCount = Value loaded into the counter when it starts counting
>   //  EndCount = Value counter counts to before it needs to be reset
>   //
>-  Status = EfiGetSystemConfigurationTable (&gPerformanceProtocolGuid, 
>&PerformanceProperty);
>+  Status = EfiGetSystemConfigurationTable (&gPerformanceProtocolGuid, (VOID 
>**) &PerformanceProperty);
>   if (EFI_ERROR (Status)) {
> ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN 
> (STR_PERF_PROPERTY_NOT_FOUND), gDpHiiHandle);
> goto Done;
>--
>2.7.0.windows.1

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

Re: [edk2] [URGENT-ish PATCH 0/5] ArmVirt- Nt32- Ovmf- CryptoPkg: conditionalize libssl presence in OpensslLib

[Long, Qin]

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Friday, February 24, 2017 6:25 AM
> To: Laszlo Ersek
> Cc: edk2-devel-01; Gary Lin; Wu, Jiaxin; Justen, Jordan L; Long, Qin; Ni, 
> Ruiyu;
> Ye, Ting; Tomas Hoger
> Subject: Re: [URGENT-ish PATCH 0/5] ArmVirt- Nt32- Ovmf- CryptoPkg:
> conditionalize libssl presence in OpensslLib
> 
> On 23 February 2017 at 21:57, Laszlo Ersek  wrote:
> > In commit 32387e0081db ("CryptoPkg: Enable ssl build in OpensslLib
> > directly", 2016-12-14), we enabled libssl functionality in
> > CryptoPkg/OpensslLib unconditionally.
> >
> > While that's real convenient, it is also overkill for platforms (or
> > platform builds) that don't want TLS. The impact (beyond wasted build
> > time) is that when the next vulnerability comes out that affects the
> > libssl subset of OpenSSL, security teams all around will look at build
> > logs and INF files, see the libssl files being built, and get nervous
> > -- without a good reason for such builds that don't actually *use* TLS.
> >
> > Let's make this easier on them (and thereby on ourselves!), and
> > introduce an OpensslLibNoSsl instance, which excludes libssl.
> >
> 
> I think it would be nicer to align with OpenSSL more closely, and split the
> functionality into a libcrypto and a libssl library, and include the latter 
> only if
> TLS functionality is needed. However, I am not volunteering to do the work,
> and this approach comes down to the same thing, given that libssl depends
> on libcrypto, and so libcrypto and libcrypto+libssl are the only combinations
> that make any sense.

I agree.
In fact, we used the two separated library (crypto & ssl) aligned with OpenSSL 
before,
And received some comments to combine them together. :-)
Two libraries (libcryto and the combination of libcrypto and libssl) are good 
to me. But
I prefer to use the OpensslLibCrypto as the name, then we can have:
OpensslLibCrypto (libcrypto)
OpensslLib  (libcrypto + libssl)

OpensslLib may have more dependencies / usages in different module, we may need 
extra
Patches to update them.

LONG, Qin

> 
> > The edk2 integration script "process_files.sh" is updated to process
> > both INF files in the same invocation.
> >
> > If noone disagrees with the concept, I'd appreciate if we could review
> > & merge this series real fast. (Sorry about that, but a downstream
> > deadline looms close, and I consider this sort of a blocker for the
> > next
> > rebase.)
> >
> > I updated the following platform packages:
> > - ArmVirtPkg, because I know it never uses TLS (or HTTP boot for that
> >   matter),
> > - Nt32Pkg, because it exposes the TLS_ENABLE build flag,
> > - OvmfPkg, because it exposes the TLS_ENABLE build flag.
> >
> > I didn't touch other packages because they don't expose TLS_ENABLE,
> > and I don't have time to figure out if they want TLS built-in.
> >
> > I tested the new OpensslLibNoSsl instance with Secure Boot under OVMF.
> >
> > The series was formatted with "--find-copies-harder", which makes a
> > real difference for patch #2.
> >
> > Tomas: if you would like to comment on this series, please subscribe
> > to the edk2-devel list at
> > , and also wait for
> > your subscription request to complete, *before* responding.
> >
> > Cc: Ard Biesheuvel 
> > Cc: Gary Lin 
> > Cc: Jiaxin Wu 
> > Cc: Jordan Justen 
> > Cc: Qin Long 
> > Cc: Ruiyu Ni 
> > Cc: Ting Ye 
> > Cc: Tomas Hoger 
> >
> > Thanks!
> > Laszlo
> >
> > Laszlo Ersek (5):
> >   CryptoPkg/OpensslLib: refresh OpensslLib.inf, opensslconf.h after
> > 32387e00
> >   CryptoPkg/OpensslLib: introduce OpensslLibNoSsl instance
> >   ArmVirtPkg: resolve OpensslLib to OpensslLibNoSsl
> >   Nt32Pkg: exclude libssl functionality from OpensslLib if
> > TLS_ENABLE=FALSE
> >   OvmfPkg: exclude libssl functionality from OpensslLib if
> > TLS_ENABLE=FALSE
> >
> >  ArmVirtPkg/ArmVirt.dsc.inc   |  2 
> > +-
> >  Nt32Pkg/Nt32Pkg.dsc  |  4 
> > ++
> >  OvmfPkg/OvmfPkgIa32.dsc  |  4 
> > ++
> >  OvmfPkg/OvmfPkgIa32X64.dsc   |  4 
> > ++
> >  OvmfPkg/OvmfPkgX64.dsc   |  4 
> > ++
> >  CryptoPkg/Library/OpensslLib/OpensslLib.inf  |  1 +
> >  CryptoPkg/Library/OpensslLib/{OpensslLib.inf => OpensslLibNoSsl.inf} | 55
> ++--
> >  CryptoPkg/Library/OpensslLib/opensslconf.h   |  6 
> > ---
> >  CryptoPkg/Library/OpensslLib/{OpensslLib.uni => OpensslLibNoSsl.uni} |  8
> +--
> >  CryptoPkg/Library/OpensslLib/process_files.sh| 27 
> > +++---
> >  10 files changed, 46 insertions(+), 69 deletions(-)  copy
> > CryptoPkg/Library/OpensslLib/{OpensslLib.inf => OpensslLibNoSsl.inf}
> > (90%)  copy 

Re: [edk2] [PATCH] BaseTools: GCC: move most AutoGen.obj contents back to .data section

[Gao, Liming]

Reviewed-by: Liming Gao 

-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] 
Sent: Friday, February 24, 2017 6:29 AM
To: Laszlo Ersek 
Cc: edk2-devel@lists.01.org ; Gao, Liming 
; Zhu, Yonghong 
Subject: Re: [PATCH] BaseTools: GCC: move most AutoGen.obj contents back to 
.data section

On 23 February 2017 at 19:53, Laszlo Ersek  wrote:
> On 02/23/17 19:30, Ard Biesheuvel wrote:
>> The generated AutoGen.c files mostly contain read-only data, but due to
>> lacking annotations, all of it is emitted into the .data section by the
>> compiler.
>>
>> Given that GUIDs are UEFI's gaffer tape, having writable GUIDs is a
>> security hazard, and this was the main rationale for putting AutoGen.obj
>> in the .text section. However, as it turns out, patchable PCDs are emitted
>> there as well, which can legally be modified at runtime.
>>
>> So update the wildcard pattern to only match g...Guid sections, and move
>> everything else back to .data (Note that this relies on -fdata-sections,
>> without that option, everything is emitted into .data)
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel 
>> ---
>>  BaseTools/Scripts/GccBase.lds | 9 ++---
>>  1 file changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/BaseTools/Scripts/GccBase.lds b/BaseTools/Scripts/GccBase.lds
>> index 900848747144..41e5c0b4a769 100644
>> --- a/BaseTools/Scripts/GccBase.lds
>> +++ b/BaseTools/Scripts/GccBase.lds
>> @@ -32,11 +32,14 @@ SECTIONS {
>>  *(.got .got.*)
>>
>>  /*
>> - * The contents of AutoGen.c files are constant from the POV of the 
>> program,
>> - * but most of its contents end up in .data or .bss by default since 
>> few of
>> + * The contents of AutoGen.c files are mostly constant from the POV of 
>> the
>> + * program, but most of it ends up in .data or .bss by default since 
>> few of
>>   * the variable definitions that get emitted are declared as CONST.
>> + * Unfortunately, we cannot pull it into the .text section entirely, 
>> since
>> + * patchable PCDs are also emitted here, but we can at least move all 
>> of the
>> + * emitted GUIDs here.
>>   */
>> -*:AutoGen.obj(.data .data.* .bss .bss.*)
>> +*:AutoGen.obj(.data.g*Guid)
>>}
>>
>>/*
>>
>
> Do you agree to add:
>
> Fixes: 233bd25b000f92fc4bbe181fa48edcd72808de8e
>
> to the commit message, or to reference that commit in some other form?
>

Yes, that makes sense.

> Either way:
>
> Tested-by: Laszlo Ersek 
>
> Thank you very much for the quick fix!

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

Re: [edk2] [PATCH 0/3] DP: Fix GCC build failure

[Gao, Liming]

Reviewed-by: Liming Gao 
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Star Zeng
Sent: Friday, February 24, 2017 10:10 AM
To: edk2-devel@lists.01.org
Cc: Zeng, Star 
Subject: [edk2] [PATCH 0/3] DP: Fix GCC build failure

Fix GCC build failure caused by "Remove TimerLib dependency from DP" patch 
series.

Star Zeng (3):
  MdeModulePkg PerformanceLib: Fix GCC build failure caused by cfb0aba
  PerformancePkg Dp_App: Fixed GCC build failure caused by 1393510
  ShellPkg UefiDpLib: Fixed GCC build failure caused by ef22403

 MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c | 2 +-
 MdeModulePkg/Library/SmmCorePerformanceLib/SmmCorePerformanceLib.c | 4 ++--
 PerformancePkg/Dp_App/Dp.c | 2 +-
 ShellPkg/Library/UefiDpLib/Dp.c| 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

-- 
2.7.0.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] [RFC PATCH 0/4] RFC: increased memory protection

[Yao, Jiewen]

HI Ard
In X86 CPU driver - UefiCpuPkg\CpuDxe, we use a global variable – 
mIsFlushingGCD.

In RefreshGcdMemoryAttributes(), we set mIsFlushingGCD=TRUE.
In CpuSetMemoryAttributes(), we check mIsFlushingGCD. If mIsFlushingGCD is 
TRUE, CpuSetMemoryAttributes() returns immediately without touching cache 
attribute or memory attribute.

The reason is that RefreshGcdMemoryAttributes() just sync current CPU hardware 
setting to GCD software record.
No real need to set cache again.

Previous we purposely skip GCD setting on RO/XP, the reason is still 
compatibility concern.
We do not want to provide a different memory map to 3rd part code, just in case 
there is hidden assumption on memory map attributes.


Maybe ARM can use similar way in SyncCacheConfig() and do a simple check in 
CpuSetMemoryAttributes().

Thank you
Yao Jiewen

From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: Friday, February 24, 2017 3:33 AM
To: Yao, Jiewen 
Cc: edk2-devel@lists.01.org; af...@apple.com; leif.lindh...@linaro.org; Kinney, 
Michael D ; Gao, Liming ; 
ler...@redhat.com; Tian, Feng ; Zeng, Star 

Subject: Re: [RFC PATCH 0/4] RFC: increased memory protection

On 23 February 2017 at 11:45, Yao, Jiewen 
mailto:jiewen@intel.com>> wrote:
> Sounds great.
>
> I look forward to your V2.
>

Hello Jiewen,

What I am currently struggling with is the fact that we don't use the
GCD RO/XP permissions at all. This means that
RefreshGcdMemoryAttributes () (or SyncCacheConfig() on ARM) will
remove non-exec attributes if we add them in the CPU arch protocol
installation notifier callback.

So there are two approaches imo:
- introduce a way to call into the DXE core to mark all non-code
regions non-exec after RefreshGcdMemoryAttributes () has been called,
or
- add the RO/XP attributes to the GCD memory space map, and enable
them in the attributes.

Option #2 will require a change to CoreAddRange to prevent those RO/XP
attributes to leak into the UEFI memory map, because that results in
all regions have to RO/XP attributes set by default, which is
obviously not what we want.

Any thoughts?

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

[edk2] [PATCH 3/3] ShellPkg UefiDpLib: Fixed GCC build failure caused by ef22403

[Star Zeng]

Cc: Michael Kinney 
Cc: Liming Gao 
Cc: Jaben Carsey 
Cc: Ruiyu Ni 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
---
 ShellPkg/Library/UefiDpLib/Dp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ShellPkg/Library/UefiDpLib/Dp.c b/ShellPkg/Library/UefiDpLib/Dp.c
index 444c136ab188..33f69a0c145a 100644
--- a/ShellPkg/Library/UefiDpLib/Dp.c
+++ b/ShellPkg/Library/UefiDpLib/Dp.c
@@ -271,7 +271,7 @@ ShellCommandRunDp (
   //StartCount = Value loaded into the counter when it starts counting
   //  EndCount = Value counter counts to before it needs to be reset
   //
-  Status = EfiGetSystemConfigurationTable (&gPerformanceProtocolGuid, 
&PerformanceProperty);
+  Status = EfiGetSystemConfigurationTable (&gPerformanceProtocolGuid, (VOID 
**) &PerformanceProperty);
   if (EFI_ERROR (Status)) {
 ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_PERF_PROPERTY_NOT_FOUND), 
gDpHiiHandle);
 goto Done;
-- 
2.7.0.windows.1

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

[edk2] [PATCH 1/3] MdeModulePkg PerformanceLib: Fix GCC build failure caused by cfb0aba

[Star Zeng]

Cc: Ard Biesheuvel 
Cc: Liming Gao 
Cc: Feng Tian 
Cc: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
---
 MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c | 2 +-
 MdeModulePkg/Library/SmmCorePerformanceLib/SmmCorePerformanceLib.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c 
b/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c
index 1564514518d3..51f488af6c14 100644
--- a/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c
+++ b/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c
@@ -535,7 +535,7 @@ DxeCorePerformanceLibConstructor (
 
   InternalGetPeiPerformance ();
 
-  Status = EfiGetSystemConfigurationTable (&gPerformanceProtocolGuid, 
&PerformanceProperty);
+  Status = EfiGetSystemConfigurationTable (&gPerformanceProtocolGuid, (VOID 
**) &PerformanceProperty);
   if (EFI_ERROR (Status)) {
 //
 // Install configuration table for performance property.
diff --git a/MdeModulePkg/Library/SmmCorePerformanceLib/SmmCorePerformanceLib.c 
b/MdeModulePkg/Library/SmmCorePerformanceLib/SmmCorePerformanceLib.c
index a03a8c8dcc46..cd1f1a5d5f66 100644
--- a/MdeModulePkg/Library/SmmCorePerformanceLib/SmmCorePerformanceLib.c
+++ b/MdeModulePkg/Library/SmmCorePerformanceLib/SmmCorePerformanceLib.c
@@ -16,7 +16,7 @@
 
  SmmPerformanceHandlerEx(), SmmPerformanceHandler() will receive untrusted 
input and do basic validation.
 
-Copyright (c) 2011 - 2016, Intel Corporation. All rights reserved.
+Copyright (c) 2011 - 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
 which accompanies this distribution.  The full text of the license may be 
found at
@@ -729,7 +729,7 @@ InitializeSmmCorePerformanceLib (
   Status = gSmst->SmiHandlerRegister (SmmPerformanceHandlerEx, 
&gSmmPerformanceExProtocolGuid, &Handle);
   ASSERT_EFI_ERROR (Status);
 
-  Status = EfiGetSystemConfigurationTable (&gPerformanceProtocolGuid, 
&PerformanceProperty);
+  Status = EfiGetSystemConfigurationTable (&gPerformanceProtocolGuid, (VOID 
**) &PerformanceProperty);
   if (EFI_ERROR (Status)) {
 //
 // Install configuration table for performance property.
-- 
2.7.0.windows.1

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

[edk2] [PATCH 2/3] PerformancePkg Dp_App: Fixed GCC build failure caused by 1393510

[Star Zeng]

Cc: Michael Kinney 
Cc: Liming Gao 
Cc: Jaben Carsey 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
---
 PerformancePkg/Dp_App/Dp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/PerformancePkg/Dp_App/Dp.c b/PerformancePkg/Dp_App/Dp.c
index 389f3681e9f9..e2cb862364ab 100644
--- a/PerformancePkg/Dp_App/Dp.c
+++ b/PerformancePkg/Dp_App/Dp.c
@@ -399,7 +399,7 @@ InitializeDp (
   //StartCount = Value loaded into the counter when it starts counting
   //  EndCount = Value counter counts to before it needs to be reset
   //
-  Status = EfiGetSystemConfigurationTable (&gPerformanceProtocolGuid, 
&PerformanceProperty);
+  Status = EfiGetSystemConfigurationTable (&gPerformanceProtocolGuid, 
(VOID **) &PerformanceProperty);
   if (EFI_ERROR (Status)) {
 PrintToken (STRING_TOKEN (STR_PERF_PROPERTY_NOT_FOUND));
 goto Done;
-- 
2.7.0.windows.1

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

[edk2] [PATCH 0/3] DP: Fix GCC build failure

[Star Zeng]

Fix GCC build failure caused by "Remove TimerLib dependency from DP" patch 
series.

Star Zeng (3):
  MdeModulePkg PerformanceLib: Fix GCC build failure caused by cfb0aba
  PerformancePkg Dp_App: Fixed GCC build failure caused by 1393510
  ShellPkg UefiDpLib: Fixed GCC build failure caused by ef22403

 MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c | 2 +-
 MdeModulePkg/Library/SmmCorePerformanceLib/SmmCorePerformanceLib.c | 4 ++--
 PerformancePkg/Dp_App/Dp.c | 2 +-
 ShellPkg/Library/UefiDpLib/Dp.c| 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

-- 
2.7.0.windows.1

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

Re: [edk2] [PATCH] MdeModulePkg SmmSmiHandlerProfileLib: Fix GCC build failure

[Yao, Jiewen]

Thank you!
Reviewed-by: jiewen@intel.com



> -Original Message-
> From: Zeng, Star
> Sent: Friday, February 24, 2017 9:56 AM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star ; Tian, Feng ; Yao,
> Jiewen 
> Subject: [PATCH] MdeModulePkg SmmSmiHandlerProfileLib: Fix GCC build failure
> 
> Cc: Feng Tian 
> Cc: Jiewen Yao 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Star Zeng 
> ---
>  MdeModulePkg/Library/SmmSmiHandlerProfileLib/SmmSmiHandlerProfileLib.c
> | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git
> a/MdeModulePkg/Library/SmmSmiHandlerProfileLib/SmmSmiHandlerProfileLib.
> c
> b/MdeModulePkg/Library/SmmSmiHandlerProfileLib/SmmSmiHandlerProfileLib.
> c
> index 0191cdebbf12..2edc71be3efb 100644
> ---
> a/MdeModulePkg/Library/SmmSmiHandlerProfileLib/SmmSmiHandlerProfileLib.
> c
> +++
> b/MdeModulePkg/Library/SmmSmiHandlerProfileLib/SmmSmiHandlerProfileLib.
> c
> @@ -99,7 +99,7 @@ SmmSmiHandlerProfileLibConstructor (
>gSmst->SmmLocateProtocol (
> &gSmiHandlerProfileGuid,
> NULL,
> -   &mSmiHandlerProfile
> +   (VOID **) &mSmiHandlerProfile
> );
>return EFI_SUCCESS;
>  }
> --
> 2.7.0.windows.1

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

Re: [edk2] [PATCH] MdeModulePkg SmmSmiHandlerProfileLib: Fix GCC build failure

[Tian, Feng]

Reviewed-by: Feng Tian 

Thanks
Feng

-Original Message-
From: Zeng, Star 
Sent: Friday, February 24, 2017 9:56 AM
To: edk2-devel@lists.01.org
Cc: Zeng, Star ; Tian, Feng ; Yao, 
Jiewen 
Subject: [PATCH] MdeModulePkg SmmSmiHandlerProfileLib: Fix GCC build failure

Cc: Feng Tian 
Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
---
 MdeModulePkg/Library/SmmSmiHandlerProfileLib/SmmSmiHandlerProfileLib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/MdeModulePkg/Library/SmmSmiHandlerProfileLib/SmmSmiHandlerProfileLib.c 
b/MdeModulePkg/Library/SmmSmiHandlerProfileLib/SmmSmiHandlerProfileLib.c
index 0191cdebbf12..2edc71be3efb 100644
--- a/MdeModulePkg/Library/SmmSmiHandlerProfileLib/SmmSmiHandlerProfileLib.c
+++ b/MdeModulePkg/Library/SmmSmiHandlerProfileLib/SmmSmiHandlerProfileLib.c
@@ -99,7 +99,7 @@ SmmSmiHandlerProfileLibConstructor (
   gSmst->SmmLocateProtocol (
&gSmiHandlerProfileGuid,
NULL,
-   &mSmiHandlerProfile
+   (VOID **) &mSmiHandlerProfile
);
   return EFI_SUCCESS;
 }
-- 
2.7.0.windows.1

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

[edk2] [PATCH] MdeModulePkg SmmSmiHandlerProfileLib: Fix GCC build failure

[Star Zeng]

Cc: Feng Tian 
Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
---
 MdeModulePkg/Library/SmmSmiHandlerProfileLib/SmmSmiHandlerProfileLib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/MdeModulePkg/Library/SmmSmiHandlerProfileLib/SmmSmiHandlerProfileLib.c 
b/MdeModulePkg/Library/SmmSmiHandlerProfileLib/SmmSmiHandlerProfileLib.c
index 0191cdebbf12..2edc71be3efb 100644
--- a/MdeModulePkg/Library/SmmSmiHandlerProfileLib/SmmSmiHandlerProfileLib.c
+++ b/MdeModulePkg/Library/SmmSmiHandlerProfileLib/SmmSmiHandlerProfileLib.c
@@ -99,7 +99,7 @@ SmmSmiHandlerProfileLibConstructor (
   gSmst->SmmLocateProtocol (
&gSmiHandlerProfileGuid,
NULL,
-   &mSmiHandlerProfile
+   (VOID **) &mSmiHandlerProfile
);
   return EFI_SUCCESS;
 }
-- 
2.7.0.windows.1

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

Re: [edk2] [PATCH v4 1/3] MdeModulePkg: Add performance property configuration table

[Zeng, Star]

Agree, I will send patch for it ASAP.

Thanks,
Star
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] 
Sent: Friday, February 24, 2017 1:30 AM
To: Yao, Jiewen 
Cc: Kinney, Michael D ; edk2-devel@lists.01.org; 
Carsey, Jaben ; Zeng, Star ; 
Andrew Fish ; Gao, Liming 
Subject: Re: [edk2] [PATCH v4 1/3] MdeModulePkg: Add performance property 
configuration table

On 3 February 2017 at 05:32, Yao, Jiewen  wrote:
> Thank you Mike and Star.
>
> It is good idea to remove TimerLib dependency.
> Series Reviewed-by: jiewen@intel.com
>

This patch breaks the GCC build:

:
In function 'DxeCorePerformanceLibConstructor':
:538:3:
error: passing argument 2 of 'EfiGetSystemConfigurationTable' from incompatible 
pointer type [-Werror]
   Status = EfiGetSystemConfigurationTable (&gPerformanceProtocolGuid, 
&PerformanceProperty);
   ^
In file included from
:35:0,
 from
:26:
:135:1:
note: expected 'void **' but argument is of type 'struct PERFORMANCE_PROPERTY 
**'
 EfiGetSystemConfigurationTable (
 ^

This fixes it for me:

diff --git a/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c
b/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c
index 1564514518d3..5438bd086144 100644
--- a/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c
+++ b/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c
@@ -535,7 +535,7 @@ DxeCorePerformanceLibConstructor (

   InternalGetPeiPerformance ();

-  Status = EfiGetSystemConfigurationTable (&gPerformanceProtocolGuid, 
&PerformanceProperty);
+  Status = EfiGetSystemConfigurationTable (&gPerformanceProtocolGuid,
(VOID **)&PerformanceProperty);
   if (EFI_ERROR (Status)) {
 //
 // Install configuration table for performance property.


Thanks,
Ard,


>
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf 
>> Of Michael Kinney
>> Sent: Friday, February 3, 2017 12:56 PM
>> To: edk2-devel@lists.01.org
>> Cc: Andrew Fish ; Gao, Liming 
>> ; Yao, Jiewen ; Carsey, 
>> Jaben ; Zeng, Star 
>> Subject: [edk2] [PATCH v4 1/3] MdeModulePkg: Add performance property 
>> configuration table
>>
>> From: Star Zeng 
>>
>> Define PERFORMANCE_PROPERTY, and install performance property 
>> configuration table in DxeCorePerformanceLib and 
>> SmmCorePerformanceLib.
>>
>> Cc: Andrew Fish 
>> Cc: Michael Kinney 
>> Cc: Liming Gao 
>> Cc: Jiewen Yao 
>> Cc: Cinnamon Shia 
>> Cc: Jaben Carsey 
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Star Zeng 
>> ---
>>  MdeModulePkg/Include/Guid/Performance.h| 12 ++-
>>  .../DxeCorePerformanceLib/DxeCorePerformanceLib.c  | 23
>> --
>>  .../DxeCorePerformanceLib.inf  |  2 ++
>>  .../DxeCorePerformanceLibInternal.h|  3 ++-
>>  .../SmmCorePerformanceLib/SmmCorePerformanceLib.c  | 18
>> +
>>  .../SmmCorePerformanceLib.inf  |  5 -
>>  6 files changed, 58 insertions(+), 5 deletions(-)
>>
>> diff --git a/MdeModulePkg/Include/Guid/Performance.h
>> b/MdeModulePkg/Include/Guid/Performance.h
>> index c40046c..df40c6c 100644
>> --- a/MdeModulePkg/Include/Guid/Performance.h
>> +++ b/MdeModulePkg/Include/Guid/Performance.h
>> @@ -4,7 +4,7 @@
>>* performance protocol interfaces.
>>* performance variables.
>>
>> -Copyright (c) 2009 - 2013, Intel Corporation. All rights 
>> reserved.
>> +Copyright (c) 2009 - 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 @@ -18,6 +18,16 @@ 
>> WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
>> IMPLIED.
>>  #ifndef __PERFORMANCE_DATA_H__
>>  #define __PERFORMANCE_DATA_H__
>>
>> +#define PERFORMANCE_PROPERTY_REVISION 0x1
>> +
>> +typedef struct {
>> +  UINT32Revision;
>> +  UINT32Reserved;
>> +  UINT64Frequency;
>> +  UINT64TimerStartValue;
>> +  UINT64TimerEndValue;
>> +} PERFORMANCE_PROPERTY;
>> +
>>  //
>>  // PEI_PERFORMANCE_STRING_SIZE must b

Re: [edk2] Improvements to build system etc. for edk2-platforms devel-MinnowBoard3?

[Richardson, Brian]

One thing we can try is automating the right setting for 
MAX_CONCURRENT_THREAD_NUMBER. In Windows, there's a command line utility to 
return the number of logical processors.

C:\Users\sample>wmic cpu get numberoflogicalprocessors
NumberOfLogicalProcessors
4 

This could be used to set MAX_CONCURRENT_THREAD_NUMBER 
(NumberOfLogicalProcessors+1, so 5 in this case) automagically in target.txt 
(via edksetup.bat) or as a command line parameter (in BuildBios.bat). I'm sure 
there's an equivalent shell command in Linux that can be co-opted for our 
purposes.

Thoughts?

Thanks ... br
---
Brian Richardson, Senior Technical Marketing Engineer, Intel Software
brian.richard...@intel.com -- @intel_Brian (Twitter & WeChat)
https://software.intel.com/en-us/meet-the-developers/evangelists/team/brian-richardson
 

-Original Message-
From: Rebecca Cran [mailto:rebe...@bluestop.org] 
Sent: Thursday, February 23, 2017 2:10 PM
To: Brian J. Johnson ; Wei, David ; 
Richardson, Brian ; Gao, Liming 
; edk2-devel@lists.01.org
Cc: Lu, ShifeiX A ; Zimmer, Vincent 
; Andrew Fish 
Subject: Re: [edk2] Improvements to build system etc. for edk2-platforms 
devel-MinnowBoard3?

On 2/23/2017 11:53 AM, Brian J. Johnson wrote:

> Sorry if I'm bikeshedding...  NUMBER_OF_PROCESSORS isn't a good 
> default for those of us who build on servers with hundreds of threads 
> available.  The OS, disks, and build.exe/build.py become bottlenecks.
> Maybe we could put a cap (say, 20) on the default thread limit, so it 
> uses NUMBER_OF_PROCESSORS or 20 threads, whichever is less.
>
> Or just set a small, fixed number of threads by default and document 
> better how to change it, as others suggested.

Good point. I think the best approach will be to have a --setup parameter which 
configures defaults in Conf/target.txt, after which users can change 
MAX_CONCURRENT_THREAD_NUMBER - instead of the current method which involves 
figuring out which of files ends up running build.exe with '-n '.

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

Re: [edk2] [PATCH v2 0/7] ATAPI support on SiI SATA adapter

[Jeremy Linton]

Hi,

Please ignore this patch set, and rather look at the V3 version. I had a 
stale set of patches in the directory I sent v2 from.


Sorry about the noise.

Thanks,



On 02/23/2017 04:03 PM, Jeremy Linton wrote:

The SiI isn't an AHCI compatible adapter so it implements the EFI ATA
pass-through protocol directly. This works for fixed hard drives, but
not ATAPI attached devices (CDROM, DVDROM, TAPE, etc).

This patch adds read only ATAPI support via the EFI SCSI pass-through
protocol, allowing boot from attached CD/DVD. This patch also cleans
up, and tweaks recovery paths/etc in the original driver. When
combined with the ARM/PCI dma lib changes this allows us to relax the
IO alignment requirement that caused grub failures.

Finally, the OpenPlatformPkg/Juno must be updated, with another patch
to avoid build breaks now that the SiI has a dependency on the SCSI
libraries.

V1->V2:
  Formatting corrections per Ard's comments and Daniil's
  updated patch checker.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeremy Linton 

Jeremy Linton (7):
  EmbeddedPkg: SiI3132: Note that ARM is using this Dxe
  MdePkg IndustryStandard/Scsi.h: Add sense code macro
  EmbeddedPkg: SiI3132: Add ScsiProtocol callbacks
  EmbeddedPkg: SiI3132: Add SCSI protocol support to header
  EmbeddedPkg: SiI3132: Break out FIS command submission
  EmbeddedPkg: SiI3132: Cleanup device node creation
  EmbeddedPkg: SiI3132: Enable SCSI pass-through protocol

 EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.c   |  49 ++-
 EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.h   |  93 -
 .../Drivers/SataSiI3132Dxe/SataSiI3132Dxe.inf  |   2 +
 .../Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c| 268 -
 .../Drivers/SataSiI3132Dxe/SiI3132ScsiPassThru.c   | 431 +
 MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf   |   2 +-
 MdePkg/Include/IndustryStandard/Scsi.h |   2 +
 OpenPlatformPkg|   2 +-
 8 files changed, 721 insertions(+), 128 deletions(-)
 create mode 100644 EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132ScsiPassThru.c



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

[edk2] [PATCH] Platforms/ARM/Juno: Add SCSI pass-through protocol

[Jeremy Linton]

Now that the SiI adapter supports ATAPI add the SCSI
pass- through protocol.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeremy Linton 
---
 Platforms/ARM/Juno/ArmJuno.dsc | 3 +++
 Platforms/ARM/Juno/ArmJuno.fdf | 2 ++
 2 files changed, 5 insertions(+)

diff --git a/Platforms/ARM/Juno/ArmJuno.dsc b/Platforms/ARM/Juno/ArmJuno.dsc
index 4080c0b..1e3e551 100644
--- a/Platforms/ARM/Juno/ArmJuno.dsc
+++ b/Platforms/ARM/Juno/ArmJuno.dsc
@@ -49,6 +49,7 @@
 
   # USB Requirements
   UefiUsbLib|MdePkg/Library/UefiUsbLib/UefiUsbLib.inf
+  UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
 
 [LibraryClasses.common.SEC]
   PrePiLib|EmbeddedPkg/Library/PrePiLib/PrePiLib.inf
@@ -285,6 +286,8 @@
   # SATA Controller
   #
   MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
+  MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf
+  MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
   EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132Dxe.inf
 
   #
diff --git a/Platforms/ARM/Juno/ArmJuno.fdf b/Platforms/ARM/Juno/ArmJuno.fdf
index beee7af..b20367e 100644
--- a/Platforms/ARM/Juno/ArmJuno.fdf
+++ b/Platforms/ARM/Juno/ArmJuno.fdf
@@ -166,6 +166,8 @@ FvNameGuid = B73FE497-B92E-416e-8326-45AD0D270092
   # SATA Controller
   #
   INF MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
+  INF MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf
+  INF MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
   INF EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132Dxe.inf
 
   #
-- 
2.9.3

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

[edk2] [PATCH v3 2/7] MdePkg IndustryStandard/Scsi.h: Add sense code macro

[Jeremy Linton]

Add some definitions to mask the sense key from sense data,
and check the validity of the returned sense data.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeremy Linton 
---
 MdePkg/Include/IndustryStandard/Scsi.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MdePkg/Include/IndustryStandard/Scsi.h 
b/MdePkg/Include/IndustryStandard/Scsi.h
index 0d81314..802479e 100644
--- a/MdePkg/Include/IndustryStandard/Scsi.h
+++ b/MdePkg/Include/IndustryStandard/Scsi.h
@@ -369,6 +369,8 @@ typedef struct {
 //
 // Sense Key
 //
+#define EFI_SCSI_REQUEST_SENSE_ERROR  (0x70)
+#define EFI_SCSI_SK_VALUE(byte)   (byte&0x0F)
 #define EFI_SCSI_SK_NO_SENSE  (0x0)
 #define EFI_SCSI_SK_RECOVERY_ERROR(0x1)
 #define EFI_SCSI_SK_NOT_READY (0x2)
-- 
2.9.3

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

[edk2] [PATCH v3 3/7] EmbeddedPkg: SiI3132: Add ScsiProtocol callbacks

[Jeremy Linton]

Create a new module that adds the callbacks to support
the EFI SCSI pass-through protocol. These callbacks
wrap around the existing ATA pass-through callbacks.
In particular the SCSI command submission routine takes
the SCSI command and wraps it with an SATA FIS and
sets the protocol to ATAPI. It then forwards the FIS to
a new routine we will break out of the ATA pass-through
callback that manages the FIS submission to the adapter.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeremy Linton 
---
 .../Drivers/SataSiI3132Dxe/SiI3132ScsiPassThru.c   | 431 +
 1 file changed, 431 insertions(+)
 create mode 100644 EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132ScsiPassThru.c

diff --git a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132ScsiPassThru.c 
b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132ScsiPassThru.c
new file mode 100644
index 000..6858426
--- /dev/null
+++ b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132ScsiPassThru.c
@@ -0,0 +1,431 @@
+/** @file
+*  ATAPI support for the Silicon Image I3132
+*
+*  Copyright (c) 2016, 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 "SataSiI3132.h"
+
+#include 
+#include 
+#include 
+
+EFI_STATUS
+SiI3132IDiscoverAtapi (
+  IN EFI_EXT_SCSI_PASS_THRU_PROTOCOL *This,
+  IN INT32 Port
+  )
+{
+  SATA_SI3132_INSTANCE  *SataInstance;
+  SATA_SI3132_PORT  *SataPort;
+  EFI_ATA_PASS_THRU_COMMAND_PACKET Packet;
+  ATA_IDENTIFY_DATA *Data;
+  EFI_STATUSStatus;
+  EFI_ATA_STATUS_BLOCK  *Asb;
+  EFI_ATA_COMMAND_BLOCK *Acb;
+
+  SataInstance = INSTANCE_FROM_SCSIPASSTHRU_THIS (This);
+  SataPort = &SataInstance->Ports[Port];
+
+  Asb=AllocateAlignedPages (EFI_SIZE_TO_PAGES (sizeof (EFI_ATA_STATUS_BLOCK)), 
EFI_PAGE_SIZE);
+  Acb=AllocateAlignedPages (EFI_SIZE_TO_PAGES (sizeof 
(EFI_ATA_COMMAND_BLOCK)), EFI_PAGE_SIZE);
+  Data=AllocateAlignedPages (EFI_SIZE_TO_PAGES (sizeof (ATA_IDENTIFY_DATA)), 
EFI_PAGE_SIZE);
+  ZeroMem (Acb, sizeof (EFI_ATA_COMMAND_BLOCK));
+  Acb->AtaCommand = ATA_CMD_IDENTIFY_DEVICE;
+  Acb->AtaDeviceHead = (UINT8) (BIT7 | BIT6 | BIT5 );
+
+  ZeroMem (&Packet, sizeof (EFI_ATA_PASS_THRU_COMMAND_PACKET));
+  Packet.Acb=Acb;
+  Packet.Asb=Asb;
+  Packet.InDataBuffer = Data;
+  Packet.InTransferLength = sizeof (ATA_IDENTIFY_DATA);
+  Packet.Protocol = EFI_ATA_PASS_THRU_PROTOCOL_PIO_DATA_IN;
+  Packet.Length   = EFI_ATA_PASS_THRU_LENGTH_BYTES | 
EFI_ATA_PASS_THRU_LENGTH_SECTOR_COUNT;
+
+  Status = SiI3132AtaPassThruCommand (SataInstance, SataPort, 0, &Packet, 
NULL);
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_WARN, "SiI ATAPI IDENTIFY DEVICE FAILURE %d\n", Status));
+  }
+  else
+  {
+Data->ModelName[39]=0;
+  }
+
+  FreeAlignedPages (Data, EFI_SIZE_TO_PAGES (sizeof (ATA_IDENTIFY_DATA)));
+  FreeAlignedPages (Acb, EFI_SIZE_TO_PAGES (sizeof (EFI_ATA_COMMAND_BLOCK)));
+  FreeAlignedPages (Asb, EFI_SIZE_TO_PAGES (sizeof (EFI_ATA_STATUS_BLOCK)));
+
+  return Status;
+}
+
+EFI_STATUS
+SiI3132ScsiPassRead (
+  IN SATA_SI3132_INSTANCE *SataInstance,
+  IN SATA_SI3132_PORT *SataPort,
+  IN OUT EFI_EXT_SCSI_PASS_THRU_SCSI_REQUEST_PACKET *Packet)
+{
+  EFI_STATUS  Status;
+  EFI_PCI_IO_PROTOCOL *PciIo;
+  VOID*   PciAllocMapping;
+  EFI_PHYSICAL_ADDRESSPhysBuffer;
+  UINTN InDataBufferLength;
+  VOID *AtaSense;
+  BOOLEAN RequestSense;
+
+  Status = EFI_SUCCESS;
+  PciIo = SataInstance->PciIo;
+  PciAllocMapping = NULL;
+  InDataBufferLength = Packet->InTransferLength;
+  AtaSense = AllocateAlignedPages (EFI_SIZE_TO_PAGES (sizeof 
(EFI_ATA_STATUS_BLOCK)),
+EFI_PAGE_SIZE);;
+  RequestSense = FALSE;
+
+  DEBUG ((DEBUG_VERBOSE, "SiI3132ScsiPassRead() CDB[0]:%X len=%d\n",
+  ((UINT8*)Packet->Cdb)[0], Packet->InTransferLength));
+
+  if (AtaSense) {
+if (Packet->InTransferLength) {
+  Status = PciIo->Map (SataInstance->PciIo, EfiPciIoOperationBusMasterRead,
+   Packet->InDataBuffer, &InDataBufferLength,
+   &PhysBuffer, &PciAllocMapping);
+
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "SiI map() failure %d\n", Status));
+return Status;
+  }
+} else {
+  PhysBuffer=0;
+}
+do {
+  // SI "The host driver must populate the area normaly used for the first 
SGE
+  // with the desired ATAPI command". AKA, put the SCSI CDB itself (not 
the address)
+  // in the 12 bytes comprising the SGE[0].
+  ZeroMem (&SataPort->HostPRB->Sge[0], sizeof (SATA_SI3132_SGE));
+  CopyMem (&SataPort->HostPRB->S

[edk2] [PATCH v3 5/7] EmbeddedPkg: SiI3132: Break out FIS command submission

[Jeremy Linton]

The existing ATA pass-through routine builds the FIS and handles
submission to the hardware. Break out the FIS submission part
so that it can be utilized by the SCSI pass-through. Also,
tighten up the error handling a bit. Starting with removal
of the ASSERTs on errors. ATAPI like SCSI uses check
conditions to indicate device state changes. So these error
paths can get exercised on CD disk change/etc. Further
we want the clamp the timeouts within a range rather than
spinning forever if the port fails to become ready.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeremy Linton 
---
 .../Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c| 225 +
 OpenPlatformPkg|   2 +-
 2 files changed, 138 insertions(+), 89 deletions(-)

diff --git a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c 
b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c
index 2fb5fd6..601583d 100644
--- a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c
+++ b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c
@@ -22,7 +22,8 @@ GetSataDevice (
   IN  SATA_SI3132_INSTANCE* SataInstance,
   IN  UINT16 Port,
   IN  UINT16 PortMultiplierPort
-) {
+  )
+{
   LIST_ENTRY  *List;
   SATA_SI3132_PORT*SataPort;
   SATA_SI3132_DEVICE  *SataDevice;
@@ -44,6 +45,124 @@ GetSataDevice (
   return NULL;
 }
 
+UINT32
+SiI3231DeviceReady (
+  IN SATA_SI3132_PORT *SataPort,
+  IN EFI_PCI_IO_PROTOCOL *PciIo
+  )
+{
+  UINT32  Value32;
+  UINT32  Timeout;
+  Timeout = SI_DEFAULT_TIMEOUT;
+
+  do {
+SATA_PORT_READ32 (SataPort->RegBase + SII3132_PORT_STATUS_REG, &Value32);
+Timeout--;
+  } while (Timeout && !(Value32 & SII3132_PORT_STATUS_PORTREADY));
+  if (Timeout == 0) {
+DEBUG ((DEBUG_WARN, "SiI3132AtaPassThru() Device not ready, try 
anyway\n"));
+//Consider doing a device reset here.
+  }
+
+  return Timeout;
+}
+
+EFI_STATUS
+SiI3132IssueCommand (
+  IN SATA_SI3132_PORT *SataPort,
+  EFI_PCI_IO_PROTOCOL  *PciIo,
+  IN UINT32 Timeout,
+  VOID *StatusBlock
+  )
+{
+  UINT32   IrqMask;
+  UINT32   Value32, Error;
+  UINTNEmptySlot;
+  EFI_STATUS   Status;
+
+  IrqMask = (SII3132_PORT_INT_CMDCOMPL | SII3132_PORT_INT_CMDERR) << 16;
+  EmptySlot = 0;
+  SiI3231DeviceReady (SataPort, PciIo);
+  // Clear IRQ
+  SATA_PORT_WRITE32 (SataPort->RegBase + SII3132_PORT_INTSTATUS_REG, IrqMask);
+
+  if (!FeaturePcdGet (PcdSataSiI3132FeatureDirectCommandIssuing)) {
+// Indirect Command Issuance
+
+//TODO: Find which slot is free (maybe use the Cmd FIFO)
+//SATA_PORT_READ32 (SataPort->RegBase + SII3132_PORT_CMDEXECFIFO_REG, 
&EmptySlot);
+SATA_PORT_WRITE32 (SataPort->RegBase + SII3132_PORT_CMDACTIV_REG + 
(EmptySlot * 8),
+ (UINT32)(SataPort->PhysAddrHostPRB & 0x));
+SATA_PORT_WRITE32 (SataPort->RegBase + SII3132_PORT_CMDACTIV_REG + 
(EmptySlot * 8) + 4,
+ (UINT32)((SataPort->PhysAddrHostPRB >> 32) & 0x));
+  } else {
+// Direct Command Issuance
+DEBUG ((DEBUG_ERROR ,"SiI3132AtaPassThru() Untested path\n"));
+Status = PciIo->Mem.Write (PciIo, EfiPciIoWidthUint32, 1, // Bar 1
+SataPort->RegBase + (EmptySlot * 0x80),
+sizeof (SATA_SI3132_PRB) / 4,
+SataPort->HostPRB);
+ASSERT_EFI_ERROR (Status);
+
+SATA_PORT_WRITE32 (SataPort->RegBase + SII3132_PORT_CMDEXECFIFO_REG, 
EmptySlot);
+  }
+
+  // Clamp the timeout range
+  if (Timeout < 1) {
+Timeout = SI_DEFAULT_TIMEOUT;
+  } else if (Timeout > SI_DEFAULT_TIMEOUT) {
+Timeout = SI_DEFAULT_TIMEOUT;
+  }
+
+  SATA_PORT_READ32 (SataPort->RegBase + SII3132_PORT_INTSTATUS_REG, &Value32);
+  while (Timeout && !(Value32 & IrqMask)) {
+gBS->Stall (1);
+SATA_PORT_READ32 (SataPort->RegBase + SII3132_PORT_INTSTATUS_REG, 
&Value32);
+Timeout--;
+  }
+
+  // Fill Packet Ata Status Block
+  Status = PciIo->Mem.Read (PciIo, EfiPciIoWidthUint32, 1, // Bar 1
+SataPort->RegBase + 0x08,
+sizeof (EFI_ATA_STATUS_BLOCK) / 4,
+StatusBlock);
+
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "SiI3132AtaPassThru() status (%d) block %X 
%X\n",Status, SataPort->RegBase, StatusBlock));
+  }
+
+  if (Timeout == 0) {
+DEBUG ((DEBUG_ERROR, "SiI3132AtaPassThru() Err:Timeout\n"));
+// Flush the command, reinit port
+SATA_PORT_WRITE32 (SataPort->RegBase + SII3132_PORT_CONTROLSET_REG, 
SII3132_PORT_CONTROL_INT);
+SiI3231DeviceReady (SataPort, PciIo);
+Status = EFI_TIMEOUT;
+
+  } else if (Value32 & (SII3132_PORT_INT_CMDERR << 16)) {
+UINT32 Serror;
+
+SATA_PORT_READ32 (SataPort->RegBase + SII3132_PORT_CMDERROR_REG, &Error);
+SATA_PORT_READ32 (SataPort->RegBase + SII3132_PORT_SERROR_REG, &Serror);
+SATA_PORT_WRITE32 (SataPort->RegBase + SII3132_PORT_INTSTATUS_REG, Value32 
& 0xFF00); //clear error bits
+
+DEBUG ((DEBUG_INFO, "SiI3132AtaPassThru() CmdErr:0x%X (SiI3132 Err:0x%X) 
(STATUS: 

[edk2] [PATCH v3 4/7] EmbeddedPkg: SiI3132: Add SCSI protocol support to header

[Jeremy Linton]

Add EXT_SCSI_PASS_THRU structures to SI3132_PORT structure,
along with helpers and new entry points.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeremy Linton 
---
 EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.h | 93 ++--
 1 file changed, 88 insertions(+), 5 deletions(-)

diff --git a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.h 
b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.h
index a7bc956..4cfef29 100644
--- a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.h
+++ b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.h
@@ -20,6 +20,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -57,6 +58,7 @@
 #define SII3132_PORT_SLOTSTATUS_REG 0x1800
 #define SII3132_PORT_CMDACTIV_REG   0x1C00
 #define SII3132_PORT_SSTATUS_REG0x1F04
+#define SII3132_PORT_SERROR_REG 0x1F08
 
 #define SII3132_PORT_CONTROL_RESET  (1 << 0)
 #define SII3132_PORT_DEVICE_RESET   (1 << 1)
@@ -81,6 +83,7 @@
 #define PRB_CTRL_INT_MASK   0x40
 #define PRB_CTRL_SRST   0x80
 
+#define PRB_PROT_DEFAULT0x00
 #define PRB_PROT_PACKET 0x01
 #define PRB_PROT_LEGACY_QUEUE   0x02
 #define PRB_PROT_NATIVE_QUEUE   0x04
@@ -88,11 +91,18 @@
 #define PRB_PROT_WRITE  0x10
 #define PRB_PROT_TRANSPARENT0x20
 
+#define SII_FIS_REGISTER_H2D0x27  //Register FIS - Host to Device
+#define SII_FIS_CONTROL_CMD (1 << 7)  //Indicate FIS is a command
+
 #define SGE_XCF (1 << 28)
 #define SGE_DRD (1 << 29)
 #define SGE_LNK (1 << 30)
 #define SGE_TRM 0x8000
 
+#define SI_MAX_CDB 12  //MAX supported CDB
+#define SI_MAX_SENSE   256
+#define SI_DEFAULT_TIMEOUT 5
+
 typedef struct _SATA_SI3132_SGE {
 UINT32  DataAddressLow;
 UINT32  DataAddressHigh;
@@ -121,6 +131,8 @@ typedef struct _SATA_SI3132_DEVICE {
 UINTN   Index;
 struct _SATA_SI3132_PORT*Port;  //Parent Port
 UINT32  BlockSize;
+BOOLEAN Atapi; //ATAPI device
+BOOLEAN Cdb16; //Uses 16byte CDB transfers (or 12)
 } SATA_SI3132_DEVICE;
 
 typedef struct _SATA_SI3132_PORT {
@@ -140,14 +152,16 @@ typedef struct _SATA_SI3132_INSTANCE {
 UINTN   Signature;
 
 SATA_SI3132_PORTPorts[SATA_SII3132_MAXPORT];
-
-EFI_ATA_PASS_THRU_PROTOCOL  AtaPassThruProtocol;
-
+EFI_ATA_PASS_THRU_MODEAtaPassThruMode;
+EFI_ATA_PASS_THRU_PROTOCOLAtaPassThruProtocol;
+EFI_EXT_SCSI_PASS_THRU_MODE   ExtScsiPassThruMode;
+EFI_EXT_SCSI_PASS_THRU_PROTOCOL   ExtScsiPassThru;
 EFI_PCI_IO_PROTOCOL *PciIo;
 } SATA_SI3132_INSTANCE;
 
 #define SATA_SII3132_SIGNATURE  SIGNATURE_32('s', 'i', '3', '2')
-#define INSTANCE_FROM_ATAPASSTHRU_THIS(a)   CR(a, SATA_SI3132_INSTANCE, 
AtaPassThruProtocol, SATA_SII3132_SIGNATURE)
+#define INSTANCE_FROM_ATAPASSTHRU_THIS(a)   CR (a, SATA_SI3132_INSTANCE, 
AtaPassThruProtocol, SATA_SII3132_SIGNATURE)
+#define INSTANCE_FROM_SCSIPASSTHRU_THIS(a)  CR (a, SATA_SI3132_INSTANCE, 
ExtScsiPassThru, SATA_SII3132_SIGNATURE)
 
 #define SATA_GLOBAL_READ32(Offset, Value)  PciIo->Mem.Read (PciIo, 
EfiPciIoWidthUint32, 0, Offset, 1, Value)
 #define SATA_GLOBAL_WRITE32(Offset, Value) { UINT32 Value32 = Value; 
PciIo->Mem.Write (PciIo, EfiPciIoWidthUint32, 0, Offset, 1, &Value32); }
@@ -155,7 +169,7 @@ typedef struct _SATA_SI3132_INSTANCE {
 #define SATA_PORT_READ32(Offset, Value)  PciIo->Mem.Read (PciIo, 
EfiPciIoWidthUint32, 1, Offset, 1, Value)
 #define SATA_PORT_WRITE32(Offset, Value) { UINT32 Value32 = Value; 
PciIo->Mem.Write (PciIo, EfiPciIoWidthUint32, 1, Offset, 1, &Value32); }
 
-#define SATA_TRACE(txt)  DEBUG((EFI_D_VERBOSE, "ARM_SATA: " txt "\n"))
+#define SATA_TRACE(txt)  DEBUG ((DEBUG_VERBOSE, "ARM_SATA: " txt "\n"))
 
 extern EFI_COMPONENT_NAME_PROTOCOL  gSataSiI3132ComponentName;
 extern EFI_COMPONENT_NAME2_PROTOCOL gSataSiI3132ComponentName2;
@@ -266,4 +280,73 @@ EFI_STATUS SiI3132ResetDevice (
   IN UINT16 PortMultiplierPort
   );
 
+/**
+ * EFI ATA Pass Thru Entry points for SCSI Protocol
+ */
+SATA_SI3132_DEVICE* GetSataDevice (
+  IN  SATA_SI3132_INSTANCE *SataInstance,
+  IN  UINT16Port,
+  IN  UINT16PortMultiplierPort
+  );
+
+EFI_STATUS SiI3132IssueCommand (
+  IN SATA_SI3132_PORT *SataPort,
+  EFI_PCI_IO_PROTOCOL *PciIo,
+  IN UINT32Timeout,
+  VOID*StatusBlock
+  );
+
+/**
+ * EFI SCSI Pass Thru Protocol
+ */
+EFI_STATUS SiI3132ScsiPassThru (
+  IN EFI_EXT_SCSI_PASS_THRU_PROTOCOL *This,
+  IN UINT8 *Target,
+  IN UINT64 Lun,
+  IN OUT EFI_EXT_SCSI_PASS_THRU_SCSI_REQUEST_PACKET *Packet,
+  IN EFI_EVENT  Event OPTIONAL
+  );
+
+EFI_STATUS SiI3132GetNextTargetLun (
+  IN EFI_EXT_SCSI_PASS_THRU_PROTOCOL *This,
+  IN OUT UINT8 **Target,
+  IN OUT UINT64 *Lun
+);
+
+EFI_STATUS SiI3132GetNextT

[edk2] [PATCH v3 7/7] EmbeddedPkg: SiI3132: Enable SCSI pass-through protocol

[Jeremy Linton]

Now that everything is in place, lets export the protocol,
build the module, and remove the ATAPI unsupported flags.
Now when we detect an ATAPI device on a port we flag it
as such.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeremy Linton 
---
 EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.c   | 49 ++
 .../Drivers/SataSiI3132Dxe/SataSiI3132Dxe.inf  |  2 +
 2 files changed, 33 insertions(+), 18 deletions(-)

diff --git a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.c 
b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.c
index f494655..5bf8da0 100644
--- a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.c
+++ b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.c
@@ -1,7 +1,7 @@
 /** @file
 *  PCIe Sata support for the Silicon Image I3132
 *
-*  Copyright (c) 2011-2015, ARM Limited. All rights reserved.
+*  Copyright (c) 2011-2016, 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
@@ -16,6 +16,7 @@
 #include "SataSiI3132.h"
 
 #include 
+#include 
 
 #include 
 #include 
@@ -88,7 +89,6 @@ SataSiI3132Constructor (
   )
 {
   SATA_SI3132_INSTANCE*Instance;
-  EFI_ATA_PASS_THRU_MODE  *AtaPassThruMode;
 
   if (!SataSiI3132Instance) {
 return EFI_INVALID_PARAMETER;
@@ -102,16 +102,15 @@ SataSiI3132Constructor (
   Instance->Signature   = SATA_SII3132_SIGNATURE;
   Instance->PciIo   = PciIo;
 
-  AtaPassThruMode = (EFI_ATA_PASS_THRU_MODE*)AllocatePool (sizeof 
(EFI_ATA_PASS_THRU_MODE));
-  AtaPassThruMode->Attributes = EFI_ATA_PASS_THRU_ATTRIBUTES_PHYSICAL | 
EFI_ATA_PASS_THRU_ATTRIBUTES_LOGICAL;
-  AtaPassThruMode->IoAlign = 0x1000;
+  Instance->AtaPassThruMode.Attributes = EFI_ATA_PASS_THRU_ATTRIBUTES_PHYSICAL 
| EFI_ATA_PASS_THRU_ATTRIBUTES_LOGICAL;
+  Instance->AtaPassThruMode.IoAlign = 0x4;
 
   // Initialize SiI3132 ports
   SataSiI3132PortConstructor (Instance, 0);
   SataSiI3132PortConstructor (Instance, 1);
 
   // Set ATA Pass Thru Protocol
-  Instance->AtaPassThruProtocol.Mode= AtaPassThruMode;
+  Instance->AtaPassThruProtocol.Mode= &Instance->AtaPassThruMode;
   Instance->AtaPassThruProtocol.PassThru= SiI3132AtaPassThru;
   Instance->AtaPassThruProtocol.GetNextPort = SiI3132GetNextPort;
   Instance->AtaPassThruProtocol.GetNextDevice   = SiI3132GetNextDevice;
@@ -120,6 +119,20 @@ SataSiI3132Constructor (
   Instance->AtaPassThruProtocol.ResetPort   = SiI3132ResetPort;
   Instance->AtaPassThruProtocol.ResetDevice = SiI3132ResetDevice;
 
+  Instance->ExtScsiPassThruMode.Attributes = 
EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_PHYSICAL |
+ 
EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_LOGICAL;
+  Instance->ExtScsiPassThruMode.IoAlign = 0x4;
+
+  // Set SCSI Pass Thru Protocol
+  Instance->ExtScsiPassThru.Mode= 
&Instance->ExtScsiPassThruMode;
+  Instance->ExtScsiPassThru.PassThru= SiI3132ScsiPassThru;
+  Instance->ExtScsiPassThru.GetNextTargetLun= SiI3132GetNextTargetLun;
+  Instance->ExtScsiPassThru.BuildDevicePath = SiI3132ScsiBuildDevicePath;
+  Instance->ExtScsiPassThru.GetTargetLun= SiI3132GetTargetLun;
+  Instance->ExtScsiPassThru.ResetChannel= SiI3132ResetChannel;
+  Instance->ExtScsiPassThru.ResetTargetLun  = SiI3132ResetTargetLun;
+  Instance->ExtScsiPassThru.GetNextTarget   = SiI3132GetNextTarget;
+
   *SataSiI3132Instance = Instance;
 
   return EFI_SUCCESS;
@@ -165,6 +178,7 @@ SataSiI3132PortInitialization (
   UINT32  Signature;
   EFI_STATUS  Status;
   EFI_PCI_IO_PROTOCOL*PciIo;
+  BOOLEAN Atapi = FALSE;
 
   Status = SiI3132HwResetPort (Port);
   if (EFI_ERROR (Status)) {
@@ -177,24 +191,23 @@ SataSiI3132PortInitialization (
   Status = SATA_PORT_READ32 (Port->RegBase + SII3132_PORT_SSTATUS_REG, 
&Value32);
   if (!EFI_ERROR (Status) && (Value32 & 0x3)) {
 // Do a soft reset to see if it is a port multiplier
-SATA_TRACE ("SataSiI3132PortInitialization: soft reset - it is a port 
multiplier\n");
+SATA_TRACE ("SataSiI3132PortInitialization: soft reset - is it a port 
multiplier?\n");
 Status = SiI3132SoftResetCommand (Port, &Signature);
 if (!EFI_ERROR (Status)) {
   if (Signature == SII3132_PORT_SIGNATURE_PMP) {
-SATA_TRACE ("SataSiI3132PortInitialization(): a Port Multiplier is 
present");
+DEBUG ((DEBUG_ERROR, "SataSiI3132PortInitialization(): a Port 
Multiplier is present"));
 if (FeaturePcdGet (PcdSataSiI3132FeaturePMPSupport)) {
   ASSERT (0); // Not supported yet
 } else {
   return EFI_UNSUPPORTED;
 }
   } else if (Signature == SII3132_PORT_SIGNATURE_ATAPI) {
-ASSERT (0); // Not supported yet
 SATA_TRACE ("SataSiI3132PortInitialization(): an ATAPI device is 
present");
-return EFI_UNSUPPORTED;
+Atapi =

[edk2] [PATCH v3 6/7] EmbeddedPkg: SiI3132: Cleanup device node creation

[Jeremy Linton]

There can be either ATA or ATAPI devices connected to
each SATA port. We want to detect if the device is ATA
and create a SATA_DP path or a SCSI_DP for ATAPI devices.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeremy Linton 
---
 .../Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c| 43 ++
 1 file changed, 28 insertions(+), 15 deletions(-)

diff --git a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c 
b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c
index 601583d..3fb5f75 100644
--- a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c
+++ b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c
@@ -521,16 +521,19 @@ SiI3132GetNextDevice (
   SataPort = &(SataSiI3132Instance->Ports[Port]);
 
   if (*PortMultiplierPort == 0x) {
+SATA_TRACE ("SiI3132GetNextDevice() PortMultiplier");
 List = SataPort->Devices.ForwardLink;
-if (List != &SataPort->Devices) {
+if ((List != &SataPort->Devices) &&
+(((SATA_SI3132_DEVICE*)List)->Atapi == FALSE)) {
   // The list is not empty, return the first device
   *PortMultiplierPort = ((SATA_SI3132_DEVICE*)List)->Index;
 } else {
   Status = EFI_NOT_FOUND;
 }
   } else {
+SATA_TRACE ("SiI3132GetNextDevice()");
 SataDevice = GetSataDevice (SataSiI3132Instance, Port, 
*PortMultiplierPort);
-if (SataDevice != NULL) {
+if ((SataDevice != NULL) && (SataDevice->Atapi == FALSE)) {
   // We have found the previous port multiplier, return the next one
   List = SataDevice->Link.ForwardLink;
   if (List != &SataPort->Devices) {
@@ -601,20 +604,30 @@ SiI3132BuildDevicePath (
 return EFI_NOT_FOUND;
   }
 
-  SiI3132DevicePath = CreateDeviceNode (MESSAGING_DEVICE_PATH, MSG_SATA_DP, 
sizeof (SATA_DEVICE_PATH));
-  if (SiI3132DevicePath == NULL) {
-return EFI_OUT_OF_RESOURCES;
-  }
+  if (SataDevice->Atapi) {
+SiI3132DevicePath = CreateDeviceNode (MESSAGING_DEVICE_PATH, MSG_SCSI_DP, 
sizeof (SCSI_DEVICE_PATH));
+if (SiI3132DevicePath == NULL) {
+  return EFI_OUT_OF_RESOURCES;
+}
+((SCSI_DEVICE_PATH*)SiI3132DevicePath)->Pun = Port;
+((SCSI_DEVICE_PATH*)SiI3132DevicePath)->Lun = 0;
 
-  ((SATA_DEVICE_PATH*)SiI3132DevicePath)->HBAPortNumber = Port;
-  if (FeaturePcdGet (PcdSataSiI3132FeaturePMPSupport)) {
-((SATA_DEVICE_PATH*)SiI3132DevicePath)->PortMultiplierPortNumber = 
PortMultiplierPort;
-  } else {
-//Temp:((SATA_DEVICE_PATH*)SiI3132DevicePath)->PortMultiplierPortNumber = 
SATA_HBA_DIRECT_CONNECT_FLAG;
-((SATA_DEVICE_PATH*)SiI3132DevicePath)->PortMultiplierPortNumber = 0;
   }
-  ((SATA_DEVICE_PATH*)SiI3132DevicePath)->Lun = Port; //TODO: Search 
information how to define properly LUN (Logical Unit Number)
+  else {
+SiI3132DevicePath = CreateDeviceNode (MESSAGING_DEVICE_PATH, MSG_SATA_DP, 
sizeof (SATA_DEVICE_PATH));
+if (SiI3132DevicePath == NULL) {
+  return EFI_OUT_OF_RESOURCES;
+}
 
+((SATA_DEVICE_PATH*)SiI3132DevicePath)->HBAPortNumber = Port;
+if (FeaturePcdGet (PcdSataSiI3132FeaturePMPSupport)) {
+  ((SATA_DEVICE_PATH*)SiI3132DevicePath)->PortMultiplierPortNumber = 
PortMultiplierPort;
+} else {
+
//Temp:((SATA_DEVICE_PATH*)SiI3132DevicePath)->PortMultiplierPortNumber = 
SATA_HBA_DIRECT_CONNECT_FLAG;
+  ((SATA_DEVICE_PATH*)SiI3132DevicePath)->PortMultiplierPortNumber = 0;
+}
+((SATA_DEVICE_PATH*)SiI3132DevicePath)->Lun = 0; // Only support lun0 on 
ATA
+  }
   *DevicePath = SiI3132DevicePath;
   return EFI_SUCCESS;
 }
@@ -680,7 +693,7 @@ SiI3132GetDevice (
 return EFI_INVALID_PARAMETER;
   }
 
-  if (((SATA_DEVICE_PATH*)DevicePath)->Lun >= SATA_SII3132_MAXPORT) {
+  if (((SATA_DEVICE_PATH*)DevicePath)->HBAPortNumber >= SATA_SII3132_MAXPORT) {
 return EFI_NOT_FOUND;
   }
 
@@ -688,7 +701,7 @@ SiI3132GetDevice (
 ASSERT (0); //TODO: Implement me!
 return EFI_UNSUPPORTED;
   } else {
-*Port = ((SATA_DEVICE_PATH*)DevicePath)->Lun;
+*Port = ((SATA_DEVICE_PATH*)DevicePath)->HBAPortNumber;
 // Return the first Sata Sevice as there should be only one directly 
connected
 *PortMultiplierPort = 
((SATA_SI3132_DEVICE*)SataSiI3132Instance->Ports[*Port].Devices.ForwardLink)->Index;
 return EFI_SUCCESS;
-- 
2.9.3

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

[edk2] [PATCH v3 0/7] ATAPI support on SiI SATA adapter

[Jeremy Linton]

The SiI isn't an AHCI compatible adapter so it implements the EFI ATA
pass-through protocol directly. This works for fixed hard drives, but
not ATAPI attached devices (CDROM, DVDROM, TAPE, etc).

This patch adds read only ATAPI support via the EFI SCSI pass-through
protocol, allowing boot from attached CD/DVD. This patch also cleans
up, and tweaks recovery paths/etc in the original driver. When
combined with the ARM/PCI dma lib changes this allows us to relax the
IO alignment requirement that caused grub failures.

Finally, the OpenPlatformPkg/Juno must be updated, with another patch
to avoid build breaks now that the SiI has a dependency on the SCSI
libraries.

V2->V3:
  Send the correct patch, rather than the one I was running
  the patch checker against.

V1->V2:
  Formatting corrections per Ard's comments and Daniil's
  updated patch checker.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeremy Linton 

Jeremy Linton (7):
  EmbeddedPkg: SiI3132: Note that ARM is using this Dxe
  MdePkg IndustryStandard/Scsi.h: Add sense code macro
  EmbeddedPkg: SiI3132: Add ScsiProtocol callbacks
  EmbeddedPkg: SiI3132: Add SCSI protocol support to header
  EmbeddedPkg: SiI3132: Break out FIS command submission
  EmbeddedPkg: SiI3132: Cleanup device node creation
  EmbeddedPkg: SiI3132: Enable SCSI pass-through protocol

 EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.c   |  49 ++-
 EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.h   |  93 -
 .../Drivers/SataSiI3132Dxe/SataSiI3132Dxe.inf  |   2 +
 .../Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c| 268 -
 .../Drivers/SataSiI3132Dxe/SiI3132ScsiPassThru.c   | 431 +
 MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf   |   2 +-
 MdePkg/Include/IndustryStandard/Scsi.h |   2 +
 OpenPlatformPkg|   2 +-
 8 files changed, 721 insertions(+), 128 deletions(-)
 create mode 100644 EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132ScsiPassThru.c

-- 
2.9.3

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

[edk2] [PATCH v3 1/7] EmbeddedPkg: SiI3132: Note that ARM is using this Dxe

[Jeremy Linton]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeremy Linton 
---
 MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf 
b/MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
index 4aab75b..fcd2044 100644
--- a/MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
+++ b/MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
@@ -29,7 +29,7 @@
 #
 # The following information is for reference only and not required by the 
build tools.
 #
-#  VALID_ARCHITECTURES   = IA32 X64 IPF EBC
+#  VALID_ARCHITECTURES   = IA32 X64 IPF EBC ARM AARCH64
 #
 #  DRIVER_BINDING=  gAtaBusDriverBinding
 #  COMPONENT_NAME=  gAtaBusComponentName
-- 
2.9.3

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

Re: [edk2] [PATCH] BaseTools: GCC: move most AutoGen.obj contents back to .data section

[Ard Biesheuvel]

On 23 February 2017 at 19:53, Laszlo Ersek  wrote:
> On 02/23/17 19:30, Ard Biesheuvel wrote:
>> The generated AutoGen.c files mostly contain read-only data, but due to
>> lacking annotations, all of it is emitted into the .data section by the
>> compiler.
>>
>> Given that GUIDs are UEFI's gaffer tape, having writable GUIDs is a
>> security hazard, and this was the main rationale for putting AutoGen.obj
>> in the .text section. However, as it turns out, patchable PCDs are emitted
>> there as well, which can legally be modified at runtime.
>>
>> So update the wildcard pattern to only match g...Guid sections, and move
>> everything else back to .data (Note that this relies on -fdata-sections,
>> without that option, everything is emitted into .data)
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel 
>> ---
>>  BaseTools/Scripts/GccBase.lds | 9 ++---
>>  1 file changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/BaseTools/Scripts/GccBase.lds b/BaseTools/Scripts/GccBase.lds
>> index 900848747144..41e5c0b4a769 100644
>> --- a/BaseTools/Scripts/GccBase.lds
>> +++ b/BaseTools/Scripts/GccBase.lds
>> @@ -32,11 +32,14 @@ SECTIONS {
>>  *(.got .got.*)
>>
>>  /*
>> - * The contents of AutoGen.c files are constant from the POV of the 
>> program,
>> - * but most of its contents end up in .data or .bss by default since 
>> few of
>> + * The contents of AutoGen.c files are mostly constant from the POV of 
>> the
>> + * program, but most of it ends up in .data or .bss by default since 
>> few of
>>   * the variable definitions that get emitted are declared as CONST.
>> + * Unfortunately, we cannot pull it into the .text section entirely, 
>> since
>> + * patchable PCDs are also emitted here, but we can at least move all 
>> of the
>> + * emitted GUIDs here.
>>   */
>> -*:AutoGen.obj(.data .data.* .bss .bss.*)
>> +*:AutoGen.obj(.data.g*Guid)
>>}
>>
>>/*
>>
>
> Do you agree to add:
>
> Fixes: 233bd25b000f92fc4bbe181fa48edcd72808de8e
>
> to the commit message, or to reference that commit in some other form?
>

Yes, that makes sense.

> Either way:
>
> Tested-by: Laszlo Ersek 
>
> Thank you very much for the quick fix!

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

Re: [edk2] [PATCH 3/5] ArmVirtPkg: resolve OpensslLib to OpensslLibNoSsl

[Ard Biesheuvel]

On 23 February 2017 at 21:57, Laszlo Ersek  wrote:
> The OpensslLibNoSsl library instance (which does not contain libssl
> functions) is sufficient for the Secure Boot feature. It would not be
> sufficient for HTTPS booting (which requires TLS), but in ArmVirtPkg, we
> don't even enable plaintext HTTP booting for the time being.
>
> Ease security analsysis by excluding libssl functionality from the
> OpensslLib instance we use.
>
> Cc: Ard Biesheuvel 
> Cc: Tomas Hoger 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek 

Reviewed-by: Ard Biesheuvel 

> ---
>  ArmVirtPkg/ArmVirt.dsc.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
> index 43699cb9bdd6..407b9b66dfe6 100644
> --- a/ArmVirtPkg/ArmVirt.dsc.inc
> +++ b/ArmVirtPkg/ArmVirt.dsc.inc
> @@ -136,7 +136,7 @@ [LibraryClasses.common]
>#
>  !if $(SECURE_BOOT_ENABLE) == TRUE
>IntrinsicLib|CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf
> -  OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLib.inf
> +  OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLibNoSsl.inf
>
> TpmMeasurementLib|SecurityPkg/Library/DxeTpmMeasurementLib/DxeTpmMeasurementLib.inf
>AuthVariableLib|SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf
>BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
> --
> 2.9.3
>
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [URGENT-ish PATCH 0/5] ArmVirt- Nt32- Ovmf- CryptoPkg: conditionalize libssl presence in OpensslLib

[Ard Biesheuvel]

On 23 February 2017 at 21:57, Laszlo Ersek  wrote:
> In commit 32387e0081db ("CryptoPkg: Enable ssl build in OpensslLib
> directly", 2016-12-14), we enabled libssl functionality in
> CryptoPkg/OpensslLib unconditionally.
>
> While that's real convenient, it is also overkill for platforms (or
> platform builds) that don't want TLS. The impact (beyond wasted build
> time) is that when the next vulnerability comes out that affects the
> libssl subset of OpenSSL, security teams all around will look at build
> logs and INF files, see the libssl files being built, and get nervous --
> without a good reason for such builds that don't actually *use* TLS.
>
> Let's make this easier on them (and thereby on ourselves!), and
> introduce an OpensslLibNoSsl instance, which excludes libssl.
>

I think it would be nicer to align with OpenSSL more closely, and
split the functionality into a libcrypto and a libssl library, and
include the latter only if TLS functionality is needed. However, I am
not volunteering to do the work, and this approach comes down to the
same thing, given that libssl depends on libcrypto, and so libcrypto
and libcrypto+libssl are the only combinations that make any sense.

> The edk2 integration script "process_files.sh" is updated to process
> both INF files in the same invocation.
>
> If noone disagrees with the concept, I'd appreciate if we could review &
> merge this series real fast. (Sorry about that, but a downstream
> deadline looms close, and I consider this sort of a blocker for the next
> rebase.)
>
> I updated the following platform packages:
> - ArmVirtPkg, because I know it never uses TLS (or HTTP boot for that
>   matter),
> - Nt32Pkg, because it exposes the TLS_ENABLE build flag,
> - OvmfPkg, because it exposes the TLS_ENABLE build flag.
>
> I didn't touch other packages because they don't expose TLS_ENABLE, and
> I don't have time to figure out if they want TLS built-in.
>
> I tested the new OpensslLibNoSsl instance with Secure Boot under OVMF.
>
> The series was formatted with "--find-copies-harder", which makes a real
> difference for patch #2.
>
> Tomas: if you would like to comment on this series, please subscribe to
> the edk2-devel list at
> , and also wait for
> your subscription request to complete, *before* responding.
>
> Cc: Ard Biesheuvel 
> Cc: Gary Lin 
> Cc: Jiaxin Wu 
> Cc: Jordan Justen 
> Cc: Qin Long 
> Cc: Ruiyu Ni 
> Cc: Ting Ye 
> Cc: Tomas Hoger 
>
> Thanks!
> Laszlo
>
> Laszlo Ersek (5):
>   CryptoPkg/OpensslLib: refresh OpensslLib.inf, opensslconf.h after
> 32387e00
>   CryptoPkg/OpensslLib: introduce OpensslLibNoSsl instance
>   ArmVirtPkg: resolve OpensslLib to OpensslLibNoSsl
>   Nt32Pkg: exclude libssl functionality from OpensslLib if
> TLS_ENABLE=FALSE
>   OvmfPkg: exclude libssl functionality from OpensslLib if
> TLS_ENABLE=FALSE
>
>  ArmVirtPkg/ArmVirt.dsc.inc   |  2 +-
>  Nt32Pkg/Nt32Pkg.dsc  |  4 ++
>  OvmfPkg/OvmfPkgIa32.dsc  |  4 ++
>  OvmfPkg/OvmfPkgIa32X64.dsc   |  4 ++
>  OvmfPkg/OvmfPkgX64.dsc   |  4 ++
>  CryptoPkg/Library/OpensslLib/OpensslLib.inf  |  1 +
>  CryptoPkg/Library/OpensslLib/{OpensslLib.inf => OpensslLibNoSsl.inf} | 55 
> ++--
>  CryptoPkg/Library/OpensslLib/opensslconf.h   |  6 ---
>  CryptoPkg/Library/OpensslLib/{OpensslLib.uni => OpensslLibNoSsl.uni} |  8 +--
>  CryptoPkg/Library/OpensslLib/process_files.sh| 27 
> +++---
>  10 files changed, 46 insertions(+), 69 deletions(-)
>  copy CryptoPkg/Library/OpensslLib/{OpensslLib.inf => OpensslLibNoSsl.inf} 
> (90%)
>  copy CryptoPkg/Library/OpensslLib/{OpensslLib.uni => OpensslLibNoSsl.uni} 
> (71%)
>
> --
> 2.9.3
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2 7/7] EmbeddedPkg: SiI3132: Enable SCSI pass-through protocol

[Jeremy Linton]

Now that everything is in place, lets export the protocol,
build the module, and remove the ATAPI unsupported flags.
Now when we detect an ATAPI device on a port we flag it
as such.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeremy Linton 
---
 EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.c   | 49 ++
 .../Drivers/SataSiI3132Dxe/SataSiI3132Dxe.inf  |  2 +
 2 files changed, 33 insertions(+), 18 deletions(-)

diff --git a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.c 
b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.c
index f494655..5bf8da0 100644
--- a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.c
+++ b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.c
@@ -1,7 +1,7 @@
 /** @file
 *  PCIe Sata support for the Silicon Image I3132
 *
-*  Copyright (c) 2011-2015, ARM Limited. All rights reserved.
+*  Copyright (c) 2011-2016, 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
@@ -16,6 +16,7 @@
 #include "SataSiI3132.h"
 
 #include 
+#include 
 
 #include 
 #include 
@@ -88,7 +89,6 @@ SataSiI3132Constructor (
   )
 {
   SATA_SI3132_INSTANCE*Instance;
-  EFI_ATA_PASS_THRU_MODE  *AtaPassThruMode;
 
   if (!SataSiI3132Instance) {
 return EFI_INVALID_PARAMETER;
@@ -102,16 +102,15 @@ SataSiI3132Constructor (
   Instance->Signature   = SATA_SII3132_SIGNATURE;
   Instance->PciIo   = PciIo;
 
-  AtaPassThruMode = (EFI_ATA_PASS_THRU_MODE*)AllocatePool (sizeof 
(EFI_ATA_PASS_THRU_MODE));
-  AtaPassThruMode->Attributes = EFI_ATA_PASS_THRU_ATTRIBUTES_PHYSICAL | 
EFI_ATA_PASS_THRU_ATTRIBUTES_LOGICAL;
-  AtaPassThruMode->IoAlign = 0x1000;
+  Instance->AtaPassThruMode.Attributes = EFI_ATA_PASS_THRU_ATTRIBUTES_PHYSICAL 
| EFI_ATA_PASS_THRU_ATTRIBUTES_LOGICAL;
+  Instance->AtaPassThruMode.IoAlign = 0x4;
 
   // Initialize SiI3132 ports
   SataSiI3132PortConstructor (Instance, 0);
   SataSiI3132PortConstructor (Instance, 1);
 
   // Set ATA Pass Thru Protocol
-  Instance->AtaPassThruProtocol.Mode= AtaPassThruMode;
+  Instance->AtaPassThruProtocol.Mode= &Instance->AtaPassThruMode;
   Instance->AtaPassThruProtocol.PassThru= SiI3132AtaPassThru;
   Instance->AtaPassThruProtocol.GetNextPort = SiI3132GetNextPort;
   Instance->AtaPassThruProtocol.GetNextDevice   = SiI3132GetNextDevice;
@@ -120,6 +119,20 @@ SataSiI3132Constructor (
   Instance->AtaPassThruProtocol.ResetPort   = SiI3132ResetPort;
   Instance->AtaPassThruProtocol.ResetDevice = SiI3132ResetDevice;
 
+  Instance->ExtScsiPassThruMode.Attributes = 
EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_PHYSICAL |
+ 
EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_LOGICAL;
+  Instance->ExtScsiPassThruMode.IoAlign = 0x4;
+
+  // Set SCSI Pass Thru Protocol
+  Instance->ExtScsiPassThru.Mode= 
&Instance->ExtScsiPassThruMode;
+  Instance->ExtScsiPassThru.PassThru= SiI3132ScsiPassThru;
+  Instance->ExtScsiPassThru.GetNextTargetLun= SiI3132GetNextTargetLun;
+  Instance->ExtScsiPassThru.BuildDevicePath = SiI3132ScsiBuildDevicePath;
+  Instance->ExtScsiPassThru.GetTargetLun= SiI3132GetTargetLun;
+  Instance->ExtScsiPassThru.ResetChannel= SiI3132ResetChannel;
+  Instance->ExtScsiPassThru.ResetTargetLun  = SiI3132ResetTargetLun;
+  Instance->ExtScsiPassThru.GetNextTarget   = SiI3132GetNextTarget;
+
   *SataSiI3132Instance = Instance;
 
   return EFI_SUCCESS;
@@ -165,6 +178,7 @@ SataSiI3132PortInitialization (
   UINT32  Signature;
   EFI_STATUS  Status;
   EFI_PCI_IO_PROTOCOL*PciIo;
+  BOOLEAN Atapi = FALSE;
 
   Status = SiI3132HwResetPort (Port);
   if (EFI_ERROR (Status)) {
@@ -177,24 +191,23 @@ SataSiI3132PortInitialization (
   Status = SATA_PORT_READ32 (Port->RegBase + SII3132_PORT_SSTATUS_REG, 
&Value32);
   if (!EFI_ERROR (Status) && (Value32 & 0x3)) {
 // Do a soft reset to see if it is a port multiplier
-SATA_TRACE ("SataSiI3132PortInitialization: soft reset - it is a port 
multiplier\n");
+SATA_TRACE ("SataSiI3132PortInitialization: soft reset - is it a port 
multiplier?\n");
 Status = SiI3132SoftResetCommand (Port, &Signature);
 if (!EFI_ERROR (Status)) {
   if (Signature == SII3132_PORT_SIGNATURE_PMP) {
-SATA_TRACE ("SataSiI3132PortInitialization(): a Port Multiplier is 
present");
+DEBUG ((DEBUG_ERROR, "SataSiI3132PortInitialization(): a Port 
Multiplier is present"));
 if (FeaturePcdGet (PcdSataSiI3132FeaturePMPSupport)) {
   ASSERT (0); // Not supported yet
 } else {
   return EFI_UNSUPPORTED;
 }
   } else if (Signature == SII3132_PORT_SIGNATURE_ATAPI) {
-ASSERT (0); // Not supported yet
 SATA_TRACE ("SataSiI3132PortInitialization(): an ATAPI device is 
present");
-return EFI_UNSUPPORTED;
+Atapi =

[edk2] [PATCH] Platforms/ARM/Juno: Add SCSI pass-through protocol

[Jeremy Linton]

Now that the SiI adapter supports ATAPI add the SCSI
pass- through protocol.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeremy Linton 
---
 Platforms/ARM/Juno/ArmJuno.dsc | 3 +++
 Platforms/ARM/Juno/ArmJuno.fdf | 2 ++
 2 files changed, 5 insertions(+)

diff --git a/Platforms/ARM/Juno/ArmJuno.dsc b/Platforms/ARM/Juno/ArmJuno.dsc
index 4080c0b..1e3e551 100644
--- a/Platforms/ARM/Juno/ArmJuno.dsc
+++ b/Platforms/ARM/Juno/ArmJuno.dsc
@@ -49,6 +49,7 @@
 
   # USB Requirements
   UefiUsbLib|MdePkg/Library/UefiUsbLib/UefiUsbLib.inf
+  UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
 
 [LibraryClasses.common.SEC]
   PrePiLib|EmbeddedPkg/Library/PrePiLib/PrePiLib.inf
@@ -285,6 +286,8 @@
   # SATA Controller
   #
   MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
+  MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf
+  MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
   EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132Dxe.inf
 
   #
diff --git a/Platforms/ARM/Juno/ArmJuno.fdf b/Platforms/ARM/Juno/ArmJuno.fdf
index beee7af..b20367e 100644
--- a/Platforms/ARM/Juno/ArmJuno.fdf
+++ b/Platforms/ARM/Juno/ArmJuno.fdf
@@ -166,6 +166,8 @@ FvNameGuid = B73FE497-B92E-416e-8326-45AD0D270092
   # SATA Controller
   #
   INF MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
+  INF MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf
+  INF MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
   INF EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132Dxe.inf
 
   #
-- 
2.9.3

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

Re: [edk2] [URGENT-ish PATCH 0/5] ArmVirt- Nt32- Ovmf- CryptoPkg: conditionalize libssl presence in OpensslLib

[Laszlo Ersek]

On 02/23/17 22:57, Laszlo Ersek wrote:
> In commit 32387e0081db ("CryptoPkg: Enable ssl build in OpensslLib
> directly", 2016-12-14), we enabled libssl functionality in
> CryptoPkg/OpensslLib unconditionally.
> 
> While that's real convenient, it is also overkill for platforms (or
> platform builds) that don't want TLS. The impact (beyond wasted build
> time) is that when the next vulnerability comes out that affects the
> libssl subset of OpenSSL, security teams all around will look at build
> logs and INF files, see the libssl files being built, and get nervous --
> without a good reason for such builds that don't actually *use* TLS.
> 
> Let's make this easier on them (and thereby on ourselves!), and
> introduce an OpensslLibNoSsl instance, which excludes libssl.

Public repo and branch:
https://github.com/lersek/edk2.git conditionalize-ssl

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

[edk2] [PATCH v2 0/7] ATAPI support on SiI SATA adapter

[Jeremy Linton]

The SiI isn't an AHCI compatible adapter so it implements the EFI ATA
pass-through protocol directly. This works for fixed hard drives, but
not ATAPI attached devices (CDROM, DVDROM, TAPE, etc).

This patch adds read only ATAPI support via the EFI SCSI pass-through
protocol, allowing boot from attached CD/DVD. This patch also cleans
up, and tweaks recovery paths/etc in the original driver. When
combined with the ARM/PCI dma lib changes this allows us to relax the
IO alignment requirement that caused grub failures.

Finally, the OpenPlatformPkg/Juno must be updated, with another patch
to avoid build breaks now that the SiI has a dependency on the SCSI
libraries.

V1->V2:
  Formatting corrections per Ard's comments and Daniil's
  updated patch checker.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeremy Linton 

Jeremy Linton (7):
  EmbeddedPkg: SiI3132: Note that ARM is using this Dxe
  MdePkg IndustryStandard/Scsi.h: Add sense code macro
  EmbeddedPkg: SiI3132: Add ScsiProtocol callbacks
  EmbeddedPkg: SiI3132: Add SCSI protocol support to header
  EmbeddedPkg: SiI3132: Break out FIS command submission
  EmbeddedPkg: SiI3132: Cleanup device node creation
  EmbeddedPkg: SiI3132: Enable SCSI pass-through protocol

 EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.c   |  49 ++-
 EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.h   |  93 -
 .../Drivers/SataSiI3132Dxe/SataSiI3132Dxe.inf  |   2 +
 .../Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c| 268 -
 .../Drivers/SataSiI3132Dxe/SiI3132ScsiPassThru.c   | 431 +
 MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf   |   2 +-
 MdePkg/Include/IndustryStandard/Scsi.h |   2 +
 OpenPlatformPkg|   2 +-
 8 files changed, 721 insertions(+), 128 deletions(-)
 create mode 100644 EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132ScsiPassThru.c

-- 
2.9.3

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

[edk2] [PATCH v2 5/7] EmbeddedPkg: SiI3132: Break out FIS command submission

[Jeremy Linton]

The existing ATA pass-through routine builds the FIS and handles
submission to the hardware. Break out the FIS submission part
so that it can be utilized by the SCSI pass-through. Also,
tighten up the error handling a bit. Starting with removal
of the ASSERTs on errors. ATAPI like SCSI uses check
conditions to indicate device state changes. So these error
paths can get exercised on CD disk change/etc. Further
we want the clamp the timeouts within a range rather than
spinning forever if the port fails to become ready.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeremy Linton 
---
 .../Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c| 225 +
 OpenPlatformPkg|   2 +-
 2 files changed, 138 insertions(+), 89 deletions(-)

diff --git a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c 
b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c
index 2fb5fd6..b14a8aa 100644
--- a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c
+++ b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c
@@ -22,7 +22,8 @@ GetSataDevice (
   IN  SATA_SI3132_INSTANCE* SataInstance,
   IN  UINT16 Port,
   IN  UINT16 PortMultiplierPort
-) {
+  )
+{
   LIST_ENTRY  *List;
   SATA_SI3132_PORT*SataPort;
   SATA_SI3132_DEVICE  *SataDevice;
@@ -44,6 +45,124 @@ GetSataDevice (
   return NULL;
 }
 
+UINT32
+SiI3231DeviceReady (
+  IN SATA_SI3132_PORT *SataPort,
+  IN EFI_PCI_IO_PROTOCOL *PciIo
+  )
+{
+  UINT32  Value32;
+  UINT32  Timeout;
+  Timeout = SI_DEFAULT_TIMEOUT;
+
+  do {
+SATA_PORT_READ32 (SataPort->RegBase + SII3132_PORT_STATUS_REG, &Value32);
+Timeout--;
+  } while (Timeout && !(Value32 & SII3132_PORT_STATUS_PORTREADY));
+  if (Timeout == 0) {
+DEBUG ((DEBUG_WARN, "SiI3132AtaPassThru() Device not ready, try 
anyway\n"));
+//Consider doing a device reset here.
+  }
+
+  return Timeout;
+}
+
+EFI_STATUS
+SiI3132IssueCommand (
+  IN SATA_SI3132_PORT *SataPort,
+  EFI_PCI_IO_PROTOCOL  *PciIo,
+  IN UINT32 Timeout,
+  VOID *StatusBlock
+  )
+{
+  CONST UINT32 IrqMask;
+  UINT32   Value32, Error;
+  CONST UINTN  EmptySlot;
+  EFI_STATUS   Status;
+
+  IrqMask = (SII3132_PORT_INT_CMDCOMPL | SII3132_PORT_INT_CMDERR) << 16;
+  EmptySlot = 0;
+  SiI3231DeviceReady (SataPort, PciIo);
+  // Clear IRQ
+  SATA_PORT_WRITE32 (SataPort->RegBase + SII3132_PORT_INTSTATUS_REG, IrqMask);
+
+  if (!FeaturePcdGet (PcdSataSiI3132FeatureDirectCommandIssuing)) {
+// Indirect Command Issuance
+
+//TODO: Find which slot is free (maybe use the Cmd FIFO)
+//SATA_PORT_READ32 (SataPort->RegBase + SII3132_PORT_CMDEXECFIFO_REG, 
&EmptySlot);
+SATA_PORT_WRITE32 (SataPort->RegBase + SII3132_PORT_CMDACTIV_REG + 
(EmptySlot * 8),
+ (UINT32)(SataPort->PhysAddrHostPRB & 0x));
+SATA_PORT_WRITE32 (SataPort->RegBase + SII3132_PORT_CMDACTIV_REG + 
(EmptySlot * 8) + 4,
+ (UINT32)((SataPort->PhysAddrHostPRB >> 32) & 0x));
+  } else {
+// Direct Command Issuance
+DEBUG ((DEBUG_ERROR ,"SiI3132AtaPassThru() Untested path\n"));
+Status = PciIo->Mem.Write (PciIo, EfiPciIoWidthUint32, 1, // Bar 1
+SataPort->RegBase + (EmptySlot * 0x80),
+sizeof (SATA_SI3132_PRB) / 4,
+SataPort->HostPRB);
+ASSERT_EFI_ERROR (Status);
+
+SATA_PORT_WRITE32 (SataPort->RegBase + SII3132_PORT_CMDEXECFIFO_REG, 
EmptySlot);
+  }
+
+  // Clamp the timeout range
+  if (Timeout < 1) {
+Timeout = SI_DEFAULT_TIMEOUT;
+  } else if (Timeout > SI_DEFAULT_TIMEOUT) {
+Timeout = SI_DEFAULT_TIMEOUT;
+  }
+
+  SATA_PORT_READ32 (SataPort->RegBase + SII3132_PORT_INTSTATUS_REG, &Value32);
+  while (Timeout && !(Value32 & IrqMask)) {
+gBS->Stall (1);
+SATA_PORT_READ32 (SataPort->RegBase + SII3132_PORT_INTSTATUS_REG, 
&Value32);
+Timeout--;
+  }
+
+  // Fill Packet Ata Status Block
+  Status = PciIo->Mem.Read (PciIo, EfiPciIoWidthUint32, 1, // Bar 1
+SataPort->RegBase + 0x08,
+sizeof (EFI_ATA_STATUS_BLOCK) / 4,
+StatusBlock);
+
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "SiI3132AtaPassThru() status (%d) block %X 
%X\n",Status, SataPort->RegBase, StatusBlock));
+  }
+
+  if (Timeout == 0) {
+DEBUG ((DEBUG_ERROR, "SiI3132AtaPassThru() Err:Timeout\n"));
+// Flush the command, reinit port
+SATA_PORT_WRITE32 (SataPort->RegBase + SII3132_PORT_CONTROLSET_REG, 
SII3132_PORT_CONTROL_INT);
+SiI3231DeviceReady (SataPort, PciIo);
+Status = EFI_TIMEOUT;
+
+  } else if (Value32 & (SII3132_PORT_INT_CMDERR << 16)) {
+UINT32 Serror;
+
+SATA_PORT_READ32 (SataPort->RegBase + SII3132_PORT_CMDERROR_REG, &Error);
+SATA_PORT_READ32 (SataPort->RegBase + SII3132_PORT_SERROR_REG, &Serror);
+SATA_PORT_WRITE32 (SataPort->RegBase + SII3132_PORT_INTSTATUS_REG, Value32 
& 0xFF00); //clear error bits
+
+DEBUG ((DEBUG_INFO, "SiI3132AtaPassThru() CmdErr:0x%X (SiI3132 Err:0x%X) 
(STATUS: 

[edk2] [PATCH v2 1/7] EmbeddedPkg: SiI3132: Note that ARM is using this Dxe

[Jeremy Linton]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeremy Linton 
---
 MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf 
b/MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
index 4aab75b..fcd2044 100644
--- a/MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
+++ b/MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
@@ -29,7 +29,7 @@
 #
 # The following information is for reference only and not required by the 
build tools.
 #
-#  VALID_ARCHITECTURES   = IA32 X64 IPF EBC
+#  VALID_ARCHITECTURES   = IA32 X64 IPF EBC ARM AARCH64
 #
 #  DRIVER_BINDING=  gAtaBusDriverBinding
 #  COMPONENT_NAME=  gAtaBusComponentName
-- 
2.9.3

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

[edk2] [PATCH v2 2/7] MdePkg IndustryStandard/Scsi.h: Add sense code macro

[Jeremy Linton]

Add some definitions to mask the sense key from sense data,
and check the validity of the returned sense data.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeremy Linton 
---
 MdePkg/Include/IndustryStandard/Scsi.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MdePkg/Include/IndustryStandard/Scsi.h 
b/MdePkg/Include/IndustryStandard/Scsi.h
index 0d81314..802479e 100644
--- a/MdePkg/Include/IndustryStandard/Scsi.h
+++ b/MdePkg/Include/IndustryStandard/Scsi.h
@@ -369,6 +369,8 @@ typedef struct {
 //
 // Sense Key
 //
+#define EFI_SCSI_REQUEST_SENSE_ERROR  (0x70)
+#define EFI_SCSI_SK_VALUE(byte)   (byte&0x0F)
 #define EFI_SCSI_SK_NO_SENSE  (0x0)
 #define EFI_SCSI_SK_RECOVERY_ERROR(0x1)
 #define EFI_SCSI_SK_NOT_READY (0x2)
-- 
2.9.3

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

[edk2] [PATCH v2 4/7] EmbeddedPkg: SiI3132: Add SCSI protocol support to header

[Jeremy Linton]

Add EXT_SCSI_PASS_THRU structures to SI3132_PORT structure,
along with helpers and new entry points.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeremy Linton 
---
 EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.h | 93 ++--
 1 file changed, 88 insertions(+), 5 deletions(-)

diff --git a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.h 
b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.h
index a7bc956..4cfef29 100644
--- a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.h
+++ b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.h
@@ -20,6 +20,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -57,6 +58,7 @@
 #define SII3132_PORT_SLOTSTATUS_REG 0x1800
 #define SII3132_PORT_CMDACTIV_REG   0x1C00
 #define SII3132_PORT_SSTATUS_REG0x1F04
+#define SII3132_PORT_SERROR_REG 0x1F08
 
 #define SII3132_PORT_CONTROL_RESET  (1 << 0)
 #define SII3132_PORT_DEVICE_RESET   (1 << 1)
@@ -81,6 +83,7 @@
 #define PRB_CTRL_INT_MASK   0x40
 #define PRB_CTRL_SRST   0x80
 
+#define PRB_PROT_DEFAULT0x00
 #define PRB_PROT_PACKET 0x01
 #define PRB_PROT_LEGACY_QUEUE   0x02
 #define PRB_PROT_NATIVE_QUEUE   0x04
@@ -88,11 +91,18 @@
 #define PRB_PROT_WRITE  0x10
 #define PRB_PROT_TRANSPARENT0x20
 
+#define SII_FIS_REGISTER_H2D0x27  //Register FIS - Host to Device
+#define SII_FIS_CONTROL_CMD (1 << 7)  //Indicate FIS is a command
+
 #define SGE_XCF (1 << 28)
 #define SGE_DRD (1 << 29)
 #define SGE_LNK (1 << 30)
 #define SGE_TRM 0x8000
 
+#define SI_MAX_CDB 12  //MAX supported CDB
+#define SI_MAX_SENSE   256
+#define SI_DEFAULT_TIMEOUT 5
+
 typedef struct _SATA_SI3132_SGE {
 UINT32  DataAddressLow;
 UINT32  DataAddressHigh;
@@ -121,6 +131,8 @@ typedef struct _SATA_SI3132_DEVICE {
 UINTN   Index;
 struct _SATA_SI3132_PORT*Port;  //Parent Port
 UINT32  BlockSize;
+BOOLEAN Atapi; //ATAPI device
+BOOLEAN Cdb16; //Uses 16byte CDB transfers (or 12)
 } SATA_SI3132_DEVICE;
 
 typedef struct _SATA_SI3132_PORT {
@@ -140,14 +152,16 @@ typedef struct _SATA_SI3132_INSTANCE {
 UINTN   Signature;
 
 SATA_SI3132_PORTPorts[SATA_SII3132_MAXPORT];
-
-EFI_ATA_PASS_THRU_PROTOCOL  AtaPassThruProtocol;
-
+EFI_ATA_PASS_THRU_MODEAtaPassThruMode;
+EFI_ATA_PASS_THRU_PROTOCOLAtaPassThruProtocol;
+EFI_EXT_SCSI_PASS_THRU_MODE   ExtScsiPassThruMode;
+EFI_EXT_SCSI_PASS_THRU_PROTOCOL   ExtScsiPassThru;
 EFI_PCI_IO_PROTOCOL *PciIo;
 } SATA_SI3132_INSTANCE;
 
 #define SATA_SII3132_SIGNATURE  SIGNATURE_32('s', 'i', '3', '2')
-#define INSTANCE_FROM_ATAPASSTHRU_THIS(a)   CR(a, SATA_SI3132_INSTANCE, 
AtaPassThruProtocol, SATA_SII3132_SIGNATURE)
+#define INSTANCE_FROM_ATAPASSTHRU_THIS(a)   CR (a, SATA_SI3132_INSTANCE, 
AtaPassThruProtocol, SATA_SII3132_SIGNATURE)
+#define INSTANCE_FROM_SCSIPASSTHRU_THIS(a)  CR (a, SATA_SI3132_INSTANCE, 
ExtScsiPassThru, SATA_SII3132_SIGNATURE)
 
 #define SATA_GLOBAL_READ32(Offset, Value)  PciIo->Mem.Read (PciIo, 
EfiPciIoWidthUint32, 0, Offset, 1, Value)
 #define SATA_GLOBAL_WRITE32(Offset, Value) { UINT32 Value32 = Value; 
PciIo->Mem.Write (PciIo, EfiPciIoWidthUint32, 0, Offset, 1, &Value32); }
@@ -155,7 +169,7 @@ typedef struct _SATA_SI3132_INSTANCE {
 #define SATA_PORT_READ32(Offset, Value)  PciIo->Mem.Read (PciIo, 
EfiPciIoWidthUint32, 1, Offset, 1, Value)
 #define SATA_PORT_WRITE32(Offset, Value) { UINT32 Value32 = Value; 
PciIo->Mem.Write (PciIo, EfiPciIoWidthUint32, 1, Offset, 1, &Value32); }
 
-#define SATA_TRACE(txt)  DEBUG((EFI_D_VERBOSE, "ARM_SATA: " txt "\n"))
+#define SATA_TRACE(txt)  DEBUG ((DEBUG_VERBOSE, "ARM_SATA: " txt "\n"))
 
 extern EFI_COMPONENT_NAME_PROTOCOL  gSataSiI3132ComponentName;
 extern EFI_COMPONENT_NAME2_PROTOCOL gSataSiI3132ComponentName2;
@@ -266,4 +280,73 @@ EFI_STATUS SiI3132ResetDevice (
   IN UINT16 PortMultiplierPort
   );
 
+/**
+ * EFI ATA Pass Thru Entry points for SCSI Protocol
+ */
+SATA_SI3132_DEVICE* GetSataDevice (
+  IN  SATA_SI3132_INSTANCE *SataInstance,
+  IN  UINT16Port,
+  IN  UINT16PortMultiplierPort
+  );
+
+EFI_STATUS SiI3132IssueCommand (
+  IN SATA_SI3132_PORT *SataPort,
+  EFI_PCI_IO_PROTOCOL *PciIo,
+  IN UINT32Timeout,
+  VOID*StatusBlock
+  );
+
+/**
+ * EFI SCSI Pass Thru Protocol
+ */
+EFI_STATUS SiI3132ScsiPassThru (
+  IN EFI_EXT_SCSI_PASS_THRU_PROTOCOL *This,
+  IN UINT8 *Target,
+  IN UINT64 Lun,
+  IN OUT EFI_EXT_SCSI_PASS_THRU_SCSI_REQUEST_PACKET *Packet,
+  IN EFI_EVENT  Event OPTIONAL
+  );
+
+EFI_STATUS SiI3132GetNextTargetLun (
+  IN EFI_EXT_SCSI_PASS_THRU_PROTOCOL *This,
+  IN OUT UINT8 **Target,
+  IN OUT UINT64 *Lun
+);
+
+EFI_STATUS SiI3132GetNextT

[edk2] [PATCH v2 6/7] EmbeddedPkg: SiI3132: Cleanup device node creation

[Jeremy Linton]

There can be either ATA or ATAPI devices connected to
each SATA port. We want to detect if the device is ATA
and create a SATA_DP path or a SCSI_DP for ATAPI devices.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeremy Linton 
---
 .../Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c| 43 ++
 1 file changed, 28 insertions(+), 15 deletions(-)

diff --git a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c 
b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c
index b14a8aa..8c65a73 100644
--- a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c
+++ b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c
@@ -521,16 +521,19 @@ SiI3132GetNextDevice (
   SataPort = &(SataSiI3132Instance->Ports[Port]);
 
   if (*PortMultiplierPort == 0x) {
+SATA_TRACE ("SiI3132GetNextDevice() PortMultiplier");
 List = SataPort->Devices.ForwardLink;
-if (List != &SataPort->Devices) {
+if ((List != &SataPort->Devices) &&
+(((SATA_SI3132_DEVICE*)List)->Atapi == FALSE)) {
   // The list is not empty, return the first device
   *PortMultiplierPort = ((SATA_SI3132_DEVICE*)List)->Index;
 } else {
   Status = EFI_NOT_FOUND;
 }
   } else {
+SATA_TRACE ("SiI3132GetNextDevice()");
 SataDevice = GetSataDevice (SataSiI3132Instance, Port, 
*PortMultiplierPort);
-if (SataDevice != NULL) {
+if ((SataDevice != NULL) && (SataDevice->Atapi == FALSE)) {
   // We have found the previous port multiplier, return the next one
   List = SataDevice->Link.ForwardLink;
   if (List != &SataPort->Devices) {
@@ -601,20 +604,30 @@ SiI3132BuildDevicePath (
 return EFI_NOT_FOUND;
   }
 
-  SiI3132DevicePath = CreateDeviceNode (MESSAGING_DEVICE_PATH, MSG_SATA_DP, 
sizeof (SATA_DEVICE_PATH));
-  if (SiI3132DevicePath == NULL) {
-return EFI_OUT_OF_RESOURCES;
-  }
+  if (SataDevice->Atapi) {
+SiI3132DevicePath = CreateDeviceNode (MESSAGING_DEVICE_PATH, MSG_SCSI_DP, 
sizeof (SCSI_DEVICE_PATH));
+if (SiI3132DevicePath == NULL) {
+  return EFI_OUT_OF_RESOURCES;
+}
+((SCSI_DEVICE_PATH*)SiI3132DevicePath)->Pun = Port;
+((SCSI_DEVICE_PATH*)SiI3132DevicePath)->Lun = 0;
 
-  ((SATA_DEVICE_PATH*)SiI3132DevicePath)->HBAPortNumber = Port;
-  if (FeaturePcdGet (PcdSataSiI3132FeaturePMPSupport)) {
-((SATA_DEVICE_PATH*)SiI3132DevicePath)->PortMultiplierPortNumber = 
PortMultiplierPort;
-  } else {
-//Temp:((SATA_DEVICE_PATH*)SiI3132DevicePath)->PortMultiplierPortNumber = 
SATA_HBA_DIRECT_CONNECT_FLAG;
-((SATA_DEVICE_PATH*)SiI3132DevicePath)->PortMultiplierPortNumber = 0;
   }
-  ((SATA_DEVICE_PATH*)SiI3132DevicePath)->Lun = Port; //TODO: Search 
information how to define properly LUN (Logical Unit Number)
+  else {
+SiI3132DevicePath = CreateDeviceNode (MESSAGING_DEVICE_PATH, MSG_SATA_DP, 
sizeof (SATA_DEVICE_PATH));
+if (SiI3132DevicePath == NULL) {
+  return EFI_OUT_OF_RESOURCES;
+}
 
+((SATA_DEVICE_PATH*)SiI3132DevicePath)->HBAPortNumber = Port;
+if (FeaturePcdGet (PcdSataSiI3132FeaturePMPSupport)) {
+  ((SATA_DEVICE_PATH*)SiI3132DevicePath)->PortMultiplierPortNumber = 
PortMultiplierPort;
+} else {
+
//Temp:((SATA_DEVICE_PATH*)SiI3132DevicePath)->PortMultiplierPortNumber = 
SATA_HBA_DIRECT_CONNECT_FLAG;
+  ((SATA_DEVICE_PATH*)SiI3132DevicePath)->PortMultiplierPortNumber = 0;
+}
+((SATA_DEVICE_PATH*)SiI3132DevicePath)->Lun = 0; // Only support lun0 on 
ATA
+  }
   *DevicePath = SiI3132DevicePath;
   return EFI_SUCCESS;
 }
@@ -680,7 +693,7 @@ SiI3132GetDevice (
 return EFI_INVALID_PARAMETER;
   }
 
-  if (((SATA_DEVICE_PATH*)DevicePath)->Lun >= SATA_SII3132_MAXPORT) {
+  if (((SATA_DEVICE_PATH*)DevicePath)->HBAPortNumber >= SATA_SII3132_MAXPORT) {
 return EFI_NOT_FOUND;
   }
 
@@ -688,7 +701,7 @@ SiI3132GetDevice (
 ASSERT (0); //TODO: Implement me!
 return EFI_UNSUPPORTED;
   } else {
-*Port = ((SATA_DEVICE_PATH*)DevicePath)->Lun;
+*Port = ((SATA_DEVICE_PATH*)DevicePath)->HBAPortNumber;
 // Return the first Sata Sevice as there should be only one directly 
connected
 *PortMultiplierPort = 
((SATA_SI3132_DEVICE*)SataSiI3132Instance->Ports[*Port].Devices.ForwardLink)->Index;
 return EFI_SUCCESS;
-- 
2.9.3

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

[edk2] [PATCH v2 3/7] EmbeddedPkg: SiI3132: Add ScsiProtocol callbacks

[Jeremy Linton]

Create a new module that adds the callbacks to support
the EFI SCSI pass-through protocol. These callbacks
wrap around the existing ATA pass-through callbacks.
In particular the SCSI command submission routine takes
the SCSI command and wraps it with an SATA FIS and
sets the protocol to ATAPI. It then forwards the FIS to
a new routine we will break out of the ATA pass-through
callback that manages the FIS submission to the adapter.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeremy Linton 
---
 .../Drivers/SataSiI3132Dxe/SiI3132ScsiPassThru.c   | 431 +
 1 file changed, 431 insertions(+)
 create mode 100644 EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132ScsiPassThru.c

diff --git a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132ScsiPassThru.c 
b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132ScsiPassThru.c
new file mode 100644
index 000..5592947
--- /dev/null
+++ b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132ScsiPassThru.c
@@ -0,0 +1,431 @@
+/** @file
+*  ATAPI support for the Silicon Image I3132
+*
+*  Copyright (c) 2016, 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 "SataSiI3132.h"
+
+#include 
+#include 
+#include 
+
+EFI_STATUS
+SiI3132IDiscoverAtapi (
+  IN EFI_EXT_SCSI_PASS_THRU_PROTOCOL *This,
+  IN INT32 Port
+  )
+{
+  SATA_SI3132_INSTANCE  *SataInstance;
+  SATA_SI3132_PORT  *SataPort;
+  EFI_ATA_PASS_THRU_COMMAND_PACKET Packet;
+  ATA_IDENTIFY_DATA *Data;
+  EFI_STATUSStatus;
+  EFI_ATA_STATUS_BLOCK  *Asb;
+  EFI_ATA_COMMAND_BLOCK *Acb;
+
+  *SataInstance = INSTANCE_FROM_SCSIPASSTHRU_THIS (This);
+  *SataPort = &SataInstance->Ports[Port];
+
+  Asb=AllocateAlignedPages (EFI_SIZE_TO_PAGES (sizeof (EFI_ATA_STATUS_BLOCK)), 
EFI_PAGE_SIZE);
+  Acb=AllocateAlignedPages (EFI_SIZE_TO_PAGES (sizeof 
(EFI_ATA_COMMAND_BLOCK)), EFI_PAGE_SIZE);
+  Data=AllocateAlignedPages (EFI_SIZE_TO_PAGES (sizeof (ATA_IDENTIFY_DATA)), 
EFI_PAGE_SIZE);
+  ZeroMem (Acb, sizeof (EFI_ATA_COMMAND_BLOCK));
+  Acb->AtaCommand = ATA_CMD_IDENTIFY_DEVICE;
+  Acb->AtaDeviceHead = (UINT8) (BIT7 | BIT6 | BIT5 );
+
+  ZeroMem (&Packet, sizeof (EFI_ATA_PASS_THRU_COMMAND_PACKET));
+  Packet.Acb=Acb;
+  Packet.Asb=Asb;
+  Packet.InDataBuffer = Data;
+  Packet.InTransferLength = sizeof (ATA_IDENTIFY_DATA);
+  Packet.Protocol = EFI_ATA_PASS_THRU_PROTOCOL_PIO_DATA_IN;
+  Packet.Length   = EFI_ATA_PASS_THRU_LENGTH_BYTES | 
EFI_ATA_PASS_THRU_LENGTH_SECTOR_COUNT;
+
+  Status = SiI3132AtaPassThruCommand (SataInstance, SataPort, 0, &Packet, 
NULL);
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_WARN, "SiI ATAPI IDENTIFY DEVICE FAILURE %d\n", Status));
+  }
+  else
+  {
+Data->ModelName[39]=0;
+  }
+
+  FreeAlignedPages (Data, EFI_SIZE_TO_PAGES (sizeof (ATA_IDENTIFY_DATA)));
+  FreeAlignedPages (Acb, EFI_SIZE_TO_PAGES (sizeof (EFI_ATA_COMMAND_BLOCK)));
+  FreeAlignedPages (Asb, EFI_SIZE_TO_PAGES (sizeof (EFI_ATA_STATUS_BLOCK)));
+
+  return Status;
+}
+
+EFI_STATUS
+SiI3132ScsiPassRead (
+  IN SATA_SI3132_INSTANCE *SataInstance,
+  IN SATA_SI3132_PORT *SataPort,
+  IN OUT EFI_EXT_SCSI_PASS_THRU_SCSI_REQUEST_PACKET *Packet)
+{
+  EFI_STATUS  Status;
+  EFI_PCI_IO_PROTOCOL *PciIo;
+  VOID*   PciAllocMapping;
+  EFI_PHYSICAL_ADDRESSPhysBuffer;
+  UINTN InDataBufferLength;
+  VOID *AtaSense;
+  BOOLEAN RequestSense;
+
+  Status = EFI_SUCCESS;
+  PciIo = SataInstance->PciIo;
+  PciAllocMapping = NULL;
+  InDataBufferLength = Packet->InTransferLength;
+  AtaSense = AllocateAlignedPages (EFI_SIZE_TO_PAGES (sizeof 
(EFI_ATA_STATUS_BLOCK)),
+EFI_PAGE_SIZE);;
+  RequestSense = FALSE;
+
+  DEBUG ((DEBUG_VERBOSE, "SiI3132ScsiPassRead() CDB[0]:%X len=%d\n",
+  ((UINT8*)Packet->Cdb)[0], Packet->InTransferLength));
+
+  if (AtaSense) {
+if (Packet->InTransferLength) {
+  Status = PciIo->Map (SataInstance->PciIo, EfiPciIoOperationBusMasterRead,
+   Packet->InDataBuffer, &InDataBufferLength,
+   &PhysBuffer, &PciAllocMapping);
+
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "SiI map() failure %d\n", Status));
+return Status;
+  }
+} else {
+  PhysBuffer=0;
+}
+do {
+  // SI "The host driver must populate the area normaly used for the first 
SGE
+  // with the desired ATAPI command". AKA, put the SCSI CDB itself (not 
the address)
+  // in the 12 bytes comprising the SGE[0].
+  ZeroMem (&SataPort->HostPRB->Sge[0], sizeof (SATA_SI3132_SGE));
+  CopyMem (&SataPort->HostPRB-

[edk2] [PATCH 2/5] CryptoPkg/OpensslLib: introduce OpensslLibNoSsl instance

[Laszlo Ersek]

Commit 32387e0081db ("CryptoPkg: Enable ssl build in OpensslLib directly",
2016-12-14) pulls OpenSSL's libssl files into the "OpensslLib.inf" library
instance unconditionally.

If a platform doesn't include the TLS modules, such as

- CryptoPkg/Library/TlsLib/TlsLib.inf
- NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf
- NetworkPkg/TlsDxe/TlsDxe.inf

then the platform never actually uses the libssl functionality that gets
built into "OpensslLib.inf".

Tomas Hoger from Red Hat Product Security tells me that security
evaluation is less demanding if we can actually *exclude* the libssl files
from such OVMF builds that don't specify -D TLS_ENABLE (rather than just
trust modules not to call libssl functions if we don't specify -D
TLS_ENABLE).

This patch introduces a parallel OpensslLib instance called
"OpensslLibNoSsl" that is appropriate for platform builds without TLS
enablement. It does not build C source files in vain, and it eases
security review -- all libssl vulnerabilities can be excluded at once.

"OpensslLibNoSsl.inf" is created as a copy of "OpensslLib.inf", modifying
the BASE_NAME, MODULE_UNI_FILE and FILE_GUID defines.

"process_files.sh" is extended to auto-generate the list of OpenSSL files
for both library instances accordingly. This list is updated in
"OpensslLibNoSsl.inf" at once.

"OpensslLibNoSsl.uni" is introduced as a copy of "OpensslLib.uni",
highlighting the difference.

Cc: Ard Biesheuvel 
Cc: Gary Lin 
Cc: Jiaxin Wu 
Cc: Jordan Justen 
Cc: Qin Long 
Cc: Ruiyu Ni 
Cc: Ting Ye 
Cc: Tomas Hoger 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 CryptoPkg/Library/OpensslLib/{OpensslLib.inf => OpensslLibNoSsl.inf} | 56 
++--
 CryptoPkg/Library/OpensslLib/{OpensslLib.uni => OpensslLibNoSsl.uni} |  8 +--
 CryptoPkg/Library/OpensslLib/process_files.sh| 27 
+++---
 3 files changed, 28 insertions(+), 63 deletions(-)

diff --git a/CryptoPkg/Library/OpensslLib/OpensslLib.inf 
b/CryptoPkg/Library/OpensslLib/OpensslLibNoSsl.inf
similarity index 90%
copy from CryptoPkg/Library/OpensslLib/OpensslLib.inf
copy to CryptoPkg/Library/OpensslLib/OpensslLibNoSsl.inf
index 42f523a611e5..d106989b9521 100644
--- a/CryptoPkg/Library/OpensslLib/OpensslLib.inf
+++ b/CryptoPkg/Library/OpensslLib/OpensslLibNoSsl.inf
@@ -14,9 +14,9 @@
 
 [Defines]
   INF_VERSION= 0x00010005
-  BASE_NAME  = OpensslLib
-  MODULE_UNI_FILE= OpensslLib.uni
-  FILE_GUID  = C873A7D0-9824-409f-9B42-2C158B992E69
+  BASE_NAME  = OpensslLibNoSsl
+  MODULE_UNI_FILE= OpensslLibNoSsl.uni
+  FILE_GUID  = E29FC209-8B64-4500-BD20-AF4EAE47EA0E
   MODULE_TYPE= BASE
   VERSION_STRING = 1.0
   LIBRARY_CLASS  = OpensslLib
@@ -474,56 +474,6 @@ [Sources]
   $(OPENSSL_PATH)/crypto/cmac/cmac.c
   $(OPENSSL_PATH)/crypto/cmac/cm_ameth.c
   $(OPENSSL_PATH)/crypto/cmac/cm_pmeth.c
-  $(OPENSSL_PATH)/ssl/s2_meth.c
-  $(OPENSSL_PATH)/ssl/s2_srvr.c
-  $(OPENSSL_PATH)/ssl/s2_clnt.c
-  $(OPENSSL_PATH)/ssl/s2_lib.c
-  $(OPENSSL_PATH)/ssl/s2_enc.c
-  $(OPENSSL_PATH)/ssl/s2_pkt.c
-  $(OPENSSL_PATH)/ssl/s3_meth.c
-  $(OPENSSL_PATH)/ssl/s3_srvr.c
-  $(OPENSSL_PATH)/ssl/s3_clnt.c
-  $(OPENSSL_PATH)/ssl/s3_lib.c
-  $(OPENSSL_PATH)/ssl/s3_enc.c
-  $(OPENSSL_PATH)/ssl/s3_pkt.c
-  $(OPENSSL_PATH)/ssl/s3_both.c
-  $(OPENSSL_PATH)/ssl/s3_cbc.c
-  $(OPENSSL_PATH)/ssl/s23_meth.c
-  $(OPENSSL_PATH)/ssl/s23_srvr.c
-  $(OPENSSL_PATH)/ssl/s23_clnt.c
-  $(OPENSSL_PATH)/ssl/s23_lib.c
-  $(OPENSSL_PATH)/ssl/s23_pkt.c
-  $(OPENSSL_PATH)/ssl/t1_meth.c
-  $(OPENSSL_PATH)/ssl/t1_srvr.c
-  $(OPENSSL_PATH)/ssl/t1_clnt.c
-  $(OPENSSL_PATH)/ssl/t1_lib.c
-  $(OPENSSL_PATH)/ssl/t1_enc.c
-  $(OPENSSL_PATH)/ssl/t1_ext.c
-  $(OPENSSL_PATH)/ssl/d1_meth.c
-  $(OPENSSL_PATH)/ssl/d1_srvr.c
-  $(OPENSSL_PATH)/ssl/d1_clnt.c
-  $(OPENSSL_PATH)/ssl/d1_lib.c
-  $(OPENSSL_PATH)/ssl/d1_pkt.c
-  $(OPENSSL_PATH)/ssl/d1_both.c
-  $(OPENSSL_PATH)/ssl/d1_srtp.c
-  $(OPENSSL_PATH)/ssl/ssl_lib.c
-  $(OPENSSL_PATH)/ssl/ssl_err2.c
-  $(OPENSSL_PATH)/ssl/ssl_cert.c
-  $(OPENSSL_PATH)/ssl/ssl_sess.c
-  $(OPENSSL_PATH)/ssl/ssl_ciph.c
-  $(OPENSSL_PATH)/ssl/ssl_stat.c
-  $(OPENSSL_PATH)/ssl/ssl_rsa.c
-  $(OPENSSL_PATH)/ssl/ssl_asn1.c
-  $(OPENSSL_PATH)/ssl/ssl_txt.c
-  $(OPENSSL_PATH)/ssl/ssl_algs.c
-  $(OPENSSL_PATH)/ssl/ssl_conf.c
-  $(OPENSSL_PATH)/ssl/bio_ssl.c
-  $(OPENSSL_PATH)/ssl/ssl_err.c
-  $(OPENSSL_PATH)/ssl/kssl.c
-  $(OPENSSL_PATH)/ssl/t1_reneg.c
-  $(OPENSSL_PATH)/ssl/tls_srp.c
-  $(OPENSSL_PATH)/ssl/t1_trce.c
-  $(OPENSSL_PATH)/ssl/ssl_utst.c
 
 # Autogenerated files list ends here
 
diff --git a/CryptoPkg/Library/OpensslLib/OpensslLib.uni 
b/CryptoPkg/Library/OpensslLib/OpensslLibNoSsl.uni
similarity index 71%
copy from CryptoPkg/Library/OpensslLib/OpensslLib.uni
copy to CryptoPkg/Library/OpensslLib/OpensslLibNoSsl.uni
index 0dffec1c98a3..52dfb

[edk2] [PATCH 4/5] Nt32Pkg: exclude libssl functionality from OpensslLib if TLS_ENABLE=FALSE

[Laszlo Ersek]

Ease security analsysis by excluding libssl functionality from the
OpensslLib instance we use with TLS_ENABLE=FALSE.

Cc: Ruiyu Ni 
Cc: Tomas Hoger 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
I can't build-test this.

 Nt32Pkg/Nt32Pkg.dsc | 4 
 1 file changed, 4 insertions(+)

diff --git a/Nt32Pkg/Nt32Pkg.dsc b/Nt32Pkg/Nt32Pkg.dsc
index 47e37ecae134..c84bd71be408 100644
--- a/Nt32Pkg/Nt32Pkg.dsc
+++ b/Nt32Pkg/Nt32Pkg.dsc
@@ -159,7 +159,11 @@ [LibraryClasses]
   
CpuExceptionHandlerLib|MdeModulePkg/Library/CpuExceptionHandlerLibNull/CpuExceptionHandlerLibNull.inf
   LockBoxLib|MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.inf
   IntrinsicLib|CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf
+!if $(TLS_ENABLE) == TRUE
   OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLib.inf
+!else
+  OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLibNoSsl.inf
+!endif
   
 !if $(SECURE_BOOT_ENABLE) == TRUE
   PlatformSecureLib|Nt32Pkg/Library/PlatformSecureLib/PlatformSecureLib.inf
-- 
2.9.3


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

[edk2] [PATCH 5/5] OvmfPkg: exclude libssl functionality from OpensslLib if TLS_ENABLE=FALSE

[Laszlo Ersek]

The OpensslLibNoSsl library instance (which does not contain libssl
functions) is sufficient for the Secure Boot feature.

Ease security analsysis by excluding libssl functionality from the
OpensslLib instance we use with TLS_ENABLE=FALSE.

Cc: Gary Lin 
Cc: Jordan Justen 
Cc: Tomas Hoger 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/OvmfPkgIa32.dsc| 4 
 OvmfPkg/OvmfPkgIa32X64.dsc | 4 
 OvmfPkg/OvmfPkgX64.dsc | 4 
 3 files changed, 12 insertions(+)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 993547d4859e..44c74c2674e3 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -143,7 +143,11 @@ [LibraryClasses]
   
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/OpensslLibNoSsl.inf
+!endif
 
 !if $(SECURE_BOOT_ENABLE) == TRUE
   PlatformSecureLib|OvmfPkg/Library/PlatformSecureLib/PlatformSecureLib.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index f36604ecb4d8..41ae1d88495b 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -148,7 +148,11 @@ [LibraryClasses]
   
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/OpensslLibNoSsl.inf
+!endif
 
 !if $(SECURE_BOOT_ENABLE) == TRUE
   PlatformSecureLib|OvmfPkg/Library/PlatformSecureLib/PlatformSecureLib.inf
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index c5bf1a672b1e..fa4fdc81b44f 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -148,7 +148,11 @@ [LibraryClasses]
   
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/OpensslLibNoSsl.inf
+!endif
 
 !if $(SECURE_BOOT_ENABLE) == TRUE
   PlatformSecureLib|OvmfPkg/Library/PlatformSecureLib/PlatformSecureLib.inf
-- 
2.9.3

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

[edk2] [PATCH 3/5] ArmVirtPkg: resolve OpensslLib to OpensslLibNoSsl

[Laszlo Ersek]

The OpensslLibNoSsl library instance (which does not contain libssl
functions) is sufficient for the Secure Boot feature. It would not be
sufficient for HTTPS booting (which requires TLS), but in ArmVirtPkg, we
don't even enable plaintext HTTP booting for the time being.

Ease security analsysis by excluding libssl functionality from the
OpensslLib instance we use.

Cc: Ard Biesheuvel 
Cc: Tomas Hoger 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 ArmVirtPkg/ArmVirt.dsc.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
index 43699cb9bdd6..407b9b66dfe6 100644
--- a/ArmVirtPkg/ArmVirt.dsc.inc
+++ b/ArmVirtPkg/ArmVirt.dsc.inc
@@ -136,7 +136,7 @@ [LibraryClasses.common]
   #
 !if $(SECURE_BOOT_ENABLE) == TRUE
   IntrinsicLib|CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf
-  OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLib.inf
+  OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLibNoSsl.inf
   
TpmMeasurementLib|SecurityPkg/Library/DxeTpmMeasurementLib/DxeTpmMeasurementLib.inf
   AuthVariableLib|SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf
   BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
-- 
2.9.3


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

[edk2] [URGENT-ish PATCH 0/5] ArmVirt- Nt32- Ovmf- CryptoPkg: conditionalize libssl presence in OpensslLib

[Laszlo Ersek]

In commit 32387e0081db ("CryptoPkg: Enable ssl build in OpensslLib
directly", 2016-12-14), we enabled libssl functionality in
CryptoPkg/OpensslLib unconditionally.

While that's real convenient, it is also overkill for platforms (or
platform builds) that don't want TLS. The impact (beyond wasted build
time) is that when the next vulnerability comes out that affects the
libssl subset of OpenSSL, security teams all around will look at build
logs and INF files, see the libssl files being built, and get nervous --
without a good reason for such builds that don't actually *use* TLS.

Let's make this easier on them (and thereby on ourselves!), and
introduce an OpensslLibNoSsl instance, which excludes libssl.

The edk2 integration script "process_files.sh" is updated to process
both INF files in the same invocation.

If noone disagrees with the concept, I'd appreciate if we could review &
merge this series real fast. (Sorry about that, but a downstream
deadline looms close, and I consider this sort of a blocker for the next
rebase.)

I updated the following platform packages:
- ArmVirtPkg, because I know it never uses TLS (or HTTP boot for that
  matter),
- Nt32Pkg, because it exposes the TLS_ENABLE build flag,
- OvmfPkg, because it exposes the TLS_ENABLE build flag.

I didn't touch other packages because they don't expose TLS_ENABLE, and
I don't have time to figure out if they want TLS built-in.

I tested the new OpensslLibNoSsl instance with Secure Boot under OVMF.

The series was formatted with "--find-copies-harder", which makes a real
difference for patch #2.

Tomas: if you would like to comment on this series, please subscribe to
the edk2-devel list at
, and also wait for
your subscription request to complete, *before* responding.

Cc: Ard Biesheuvel 
Cc: Gary Lin 
Cc: Jiaxin Wu 
Cc: Jordan Justen 
Cc: Qin Long 
Cc: Ruiyu Ni 
Cc: Ting Ye 
Cc: Tomas Hoger 

Thanks!
Laszlo

Laszlo Ersek (5):
  CryptoPkg/OpensslLib: refresh OpensslLib.inf, opensslconf.h after
32387e00
  CryptoPkg/OpensslLib: introduce OpensslLibNoSsl instance
  ArmVirtPkg: resolve OpensslLib to OpensslLibNoSsl
  Nt32Pkg: exclude libssl functionality from OpensslLib if
TLS_ENABLE=FALSE
  OvmfPkg: exclude libssl functionality from OpensslLib if
TLS_ENABLE=FALSE

 ArmVirtPkg/ArmVirt.dsc.inc   |  2 +-
 Nt32Pkg/Nt32Pkg.dsc  |  4 ++
 OvmfPkg/OvmfPkgIa32.dsc  |  4 ++
 OvmfPkg/OvmfPkgIa32X64.dsc   |  4 ++
 OvmfPkg/OvmfPkgX64.dsc   |  4 ++
 CryptoPkg/Library/OpensslLib/OpensslLib.inf  |  1 +
 CryptoPkg/Library/OpensslLib/{OpensslLib.inf => OpensslLibNoSsl.inf} | 55 
++--
 CryptoPkg/Library/OpensslLib/opensslconf.h   |  6 ---
 CryptoPkg/Library/OpensslLib/{OpensslLib.uni => OpensslLibNoSsl.uni} |  8 +--
 CryptoPkg/Library/OpensslLib/process_files.sh| 27 
+++---
 10 files changed, 46 insertions(+), 69 deletions(-)
 copy CryptoPkg/Library/OpensslLib/{OpensslLib.inf => OpensslLibNoSsl.inf} (90%)
 copy CryptoPkg/Library/OpensslLib/{OpensslLib.uni => OpensslLibNoSsl.uni} (71%)

-- 
2.9.3

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

[edk2] [PATCH 1/5] CryptoPkg/OpensslLib: refresh OpensslLib.inf, opensslconf.h after 32387e00

[Laszlo Ersek]

Commit 32387e0081db ("CryptoPkg: Enable ssl build in OpensslLib directly",
2016-12-14) removed the "no-queue" configuration option in
"process_files.sh", plus it enabled "process_files.sh" to place all libssl
source files into "OpensslLib.inf".

However, the patch apparently failed to capture two changes originating
from the above actions:
- the definitions of the OPENSSL_NO_PQUEUE and NO_PQUEUE macros were not
  removed from "opensslconf.h",
- "ssl/ssl_conf.c" was not added to "OpensslLib.inf".

Refresh these files, completing commit 32387e0081db.

I built OVMF with -D SECURE_BOOT_ENABLE -D TLS_ENABLE, and ArmVirtQemu
with -D SECURE_BOOT_ENABLE, after this fix, and experienced no regression.

Cc: Ard Biesheuvel 
Cc: Gary Lin 
Cc: Jiaxin Wu 
Cc: Jordan Justen 
Cc: Qin Long 
Cc: Ruiyu Ni 
Cc: Ting Ye 
Cc: Tomas Hoger 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 CryptoPkg/Library/OpensslLib/OpensslLib.inf | 1 +
 CryptoPkg/Library/OpensslLib/opensslconf.h  | 6 --
 2 files changed, 1 insertion(+), 6 deletions(-)

diff --git a/CryptoPkg/Library/OpensslLib/OpensslLib.inf 
b/CryptoPkg/Library/OpensslLib/OpensslLib.inf
index c14e36d341f7..42f523a611e5 100644
--- a/CryptoPkg/Library/OpensslLib/OpensslLib.inf
+++ b/CryptoPkg/Library/OpensslLib/OpensslLib.inf
@@ -516,6 +516,7 @@ [Sources]
   $(OPENSSL_PATH)/ssl/ssl_asn1.c
   $(OPENSSL_PATH)/ssl/ssl_txt.c
   $(OPENSSL_PATH)/ssl/ssl_algs.c
+  $(OPENSSL_PATH)/ssl/ssl_conf.c
   $(OPENSSL_PATH)/ssl/bio_ssl.c
   $(OPENSSL_PATH)/ssl/ssl_err.c
   $(OPENSSL_PATH)/ssl/kssl.c
diff --git a/CryptoPkg/Library/OpensslLib/opensslconf.h 
b/CryptoPkg/Library/OpensslLib/opensslconf.h
index adcaa01d6b1d..e0054a45fc5f 100644
--- a/CryptoPkg/Library/OpensslLib/opensslconf.h
+++ b/CryptoPkg/Library/OpensslLib/opensslconf.h
@@ -92,9 +92,6 @@ extern "C" {
 #ifndef OPENSSL_NO_POSIX_IO
 # define OPENSSL_NO_POSIX_IO
 #endif
-#ifndef OPENSSL_NO_PQUEUE
-# define OPENSSL_NO_PQUEUE
-#endif
 #ifndef OPENSSL_NO_RC2
 # define OPENSSL_NO_RC2
 #endif
@@ -263,9 +260,6 @@ extern "C" {
 # if defined(OPENSSL_NO_POSIX_IO) && !defined(NO_POSIX_IO)
 #  define NO_POSIX_IO
 # endif
-# if defined(OPENSSL_NO_PQUEUE) && !defined(NO_PQUEUE)
-#  define NO_PQUEUE
-# endif
 # if defined(OPENSSL_NO_RC2) && !defined(NO_RC2)
 #  define NO_RC2
 # endif
-- 
2.9.3


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

Re: [edk2] [PATCH] BaseTools: GCC: move most AutoGen.obj contents back to .data section

[Laszlo Ersek]

On 02/23/17 19:30, Ard Biesheuvel wrote:
> The generated AutoGen.c files mostly contain read-only data, but due to
> lacking annotations, all of it is emitted into the .data section by the
> compiler.
> 
> Given that GUIDs are UEFI's gaffer tape, having writable GUIDs is a
> security hazard, and this was the main rationale for putting AutoGen.obj
> in the .text section. However, as it turns out, patchable PCDs are emitted
> there as well, which can legally be modified at runtime.
> 
> So update the wildcard pattern to only match g...Guid sections, and move
> everything else back to .data (Note that this relies on -fdata-sections,
> without that option, everything is emitted into .data)
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  BaseTools/Scripts/GccBase.lds | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/BaseTools/Scripts/GccBase.lds b/BaseTools/Scripts/GccBase.lds
> index 900848747144..41e5c0b4a769 100644
> --- a/BaseTools/Scripts/GccBase.lds
> +++ b/BaseTools/Scripts/GccBase.lds
> @@ -32,11 +32,14 @@ SECTIONS {
>  *(.got .got.*)
>  
>  /*
> - * The contents of AutoGen.c files are constant from the POV of the 
> program,
> - * but most of its contents end up in .data or .bss by default since few 
> of
> + * The contents of AutoGen.c files are mostly constant from the POV of 
> the
> + * program, but most of it ends up in .data or .bss by default since few 
> of
>   * the variable definitions that get emitted are declared as CONST.
> + * Unfortunately, we cannot pull it into the .text section entirely, 
> since
> + * patchable PCDs are also emitted here, but we can at least move all of 
> the
> + * emitted GUIDs here.
>   */
> -*:AutoGen.obj(.data .data.* .bss .bss.*)
> +*:AutoGen.obj(.data.g*Guid)
>}
>  
>/*
> 

Do you agree to add:

Fixes: 233bd25b000f92fc4bbe181fa48edcd72808de8e

to the commit message, or to reference that commit in some other form?

Either way:

Tested-by: Laszlo Ersek 

Thank you very much for the quick fix!
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC PATCH 0/4] RFC: increased memory protection

[Ard Biesheuvel]

On 23 February 2017 at 11:45, Yao, Jiewen  wrote:
> Sounds great.
>
> I look forward to your V2.
>

Hello Jiewen,

What I am currently struggling with is the fact that we don't use the
GCD RO/XP permissions at all. This means that
RefreshGcdMemoryAttributes () (or SyncCacheConfig() on ARM) will
remove non-exec attributes if we add them in the CPU arch protocol
installation notifier callback.

So there are two approaches imo:
- introduce a way to call into the DXE core to mark all non-code
regions non-exec after RefreshGcdMemoryAttributes () has been called,
or
- add the RO/XP attributes to the GCD memory space map, and enable
them in the attributes.

Option #2 will require a change to CoreAddRange to prevent those RO/XP
attributes to leak into the UEFI memory map, because that results in
all regions have to RO/XP attributes set by default, which is
obviously not what we want.

Any thoughts?

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

Re: [edk2] Improvements to build system etc. for edk2-platforms devel-MinnowBoard3?

[Rebecca Cran]

On 2/23/2017 11:53 AM, Brian J. Johnson wrote:

Sorry if I'm bikeshedding...  NUMBER_OF_PROCESSORS isn't a good 
default for those of us who build on servers with hundreds of threads 
available.  The OS, disks, and build.exe/build.py become bottlenecks.  
Maybe we could put a cap (say, 20) on the default thread limit, so it 
uses NUMBER_OF_PROCESSORS or 20 threads, whichever is less.


Or just set a small, fixed number of threads by default and document 
better how to change it, as others suggested.


Good point. I think the best approach will be to have a --setup 
parameter which configures defaults in Conf/target.txt, after which 
users can change MAX_CONCURRENT_THREAD_NUMBER - instead of the current 
method which involves figuring out which of files ends up running 
build.exe with '-n '.


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

Re: [edk2] Improvements to build system etc. for edk2-platforms devel-MinnowBoard3?

[Brian J. Johnson]

Sorry if I'm bikeshedding...  NUMBER_OF_PROCESSORS isn't a good default 
for those of us who build on servers with hundreds of threads available. 
 The OS, disks, and build.exe/build.py become bottlenecks.  Maybe we 
could put a cap (say, 20) on the default thread limit, so it uses 
NUMBER_OF_PROCESSORS or 20 threads, whichever is less.


Or just set a small, fixed number of threads by default and document 
better how to change it, as others suggested.


Brian

On 02/22/2017 08:49 PM, Wei, David wrote:

Yes, as Brian said, at this stage,  patches are welcomed, including the python 
script.  You can also file bugs on https://bugzilla.tianocore.org/ for issue 
track and discussion.  Please remember to CC stakeholders.

Specifically for the multi-thread building , I think maybe  
NUMBER_OF_PROCESSORS Windows environment variable could be used as the proper 
thread number.

Thanks,
David  Wei


-Original Message-
From: Richardson, Brian
Sent: Thursday, February 23, 2017 3:10 AM
To: Rebecca Cran ; Gao, Liming ; 
edk2-devel@lists.01.org
Cc: Lu, ShifeiX A ; Zimmer, Vincent ; 
Andrew Fish ; Wei, David 
Subject: RE: [edk2] Improvements to build system etc. for edk2-platforms 
devel-MinnowBoard3?

We're ok with help fixing issues (yay open source), so thanks for the help. 
Patches are welcome at this time. But we do track them in Bugzilla, so opening 
an issue there is the first step to a solution.

For the processor thread setting, note that we have historically disabled 
processor threading by default because we don't know the build system 
configuration. While we at Intel prefer everyone own an Intel(R) Core(TM) i7 or 
Intel(R) Xeon processor, we know that's not the case ... so keeping it disabled 
has been seen as a safe option. We should definitely do a better job of 
documenting that setting change, but I think we need to consider generically 
changing that setting by default in target.txt (which requires a Bugzilla 
entry).

The .bat/.sh files are required to trigger post-build tools, which are OS 
dependent. Even if the build was triggered by a Python script, we still need to 
do some verification to make sure there are no functional differences when we 
build in a Windows environment versus Linux (work in progress).

Thanks ... br
---
Brian Richardson, Senior Technical Marketing Engineer, Intel Software
brian.richard...@intel.com -- @intel_Brian (Twitter & WeChat)
https://software.intel.com/en-us/meet-the-developers/evangelists/team/brian-richardson

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Rebecca 
Cran
Sent: Wednesday, February 22, 2017 11:53 AM
To: Richardson, Brian ; Gao, Liming 
; edk2-devel@lists.01.org
Cc: Lu, ShifeiX A ; Zimmer, Vincent ; 
Andrew Fish ; Wei, David 
Subject: Re: [edk2] Improvements to build system etc. for edk2-platforms 
devel-MinnowBoard3?

On 2/22/2017 9:34 AM, Richardson, Brian wrote:

Thanks for the input. For future reference, you can use the TianoCore
Bugzilla to report issues on any EDK II feature/platform.
https://github.com/tianocore/tianocore.github.io/wiki/Reporting-Issues

I agree the readme.md should be present, and use markup instead of plain text 
to work better in github. You can open an issue on this in Bugzilla.

Normally, we ask folks to change the number of processor threads based on their 
system configuration. We don't add a larger thread number by default, but it 
might be good to set it '5' by default (assuming a dual core processor with 
hyperthreading) instead of '1' (assuming a single core system w/o threading). I 
don't know if this will cause any compatibility issues on older systems, but 
it's worth a check.

At this time, MinnowBoard 3 build is only validated in Windows. That's why 
there is no equivalent .sh file for BuildBIOS yet, but it will be added once 
Linux build is verified and checked in.


I'm more about _fixing_ issues I find rather than reporting them! Are you 
saying that patches wouldn't be welcome just now?  Is there a reason why you 
don't want to make full use of the CPU while building? And I understand that 
MinnowBoard 3 only builds under Windows at the moment, but if more of it built 
using python (and python is already listed as a prerequisite in the ReadMe 
file) the porting might be simpler.

--
Rebecca
___
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




--
Brian J. Johnson
Enterprise X86 Lab

Hewlett Packard Enterprise

brian.john...@hpe.com
+1 651 683 7521  Office

Eagan, MN
hpe.com
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] BaseTools: GCC: move most AutoGen.obj contents back to .data section

[Ard Biesheuvel]

The generated AutoGen.c files mostly contain read-only data, but due to
lacking annotations, all of it is emitted into the .data section by the
compiler.

Given that GUIDs are UEFI's gaffer tape, having writable GUIDs is a
security hazard, and this was the main rationale for putting AutoGen.obj
in the .text section. However, as it turns out, patchable PCDs are emitted
there as well, which can legally be modified at runtime.

So update the wildcard pattern to only match g...Guid sections, and move
everything else back to .data (Note that this relies on -fdata-sections,
without that option, everything is emitted into .data)

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 BaseTools/Scripts/GccBase.lds | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/BaseTools/Scripts/GccBase.lds b/BaseTools/Scripts/GccBase.lds
index 900848747144..41e5c0b4a769 100644
--- a/BaseTools/Scripts/GccBase.lds
+++ b/BaseTools/Scripts/GccBase.lds
@@ -32,11 +32,14 @@ SECTIONS {
 *(.got .got.*)
 
 /*
- * The contents of AutoGen.c files are constant from the POV of the 
program,
- * but most of its contents end up in .data or .bss by default since few of
+ * The contents of AutoGen.c files are mostly constant from the POV of the
+ * program, but most of it ends up in .data or .bss by default since few of
  * the variable definitions that get emitted are declared as CONST.
+ * Unfortunately, we cannot pull it into the .text section entirely, since
+ * patchable PCDs are also emitted here, but we can at least move all of 
the
+ * emitted GUIDs here.
  */
-*:AutoGen.obj(.data .data.* .bss .bss.*)
+*:AutoGen.obj(.data.g*Guid)
   }
 
   /*
-- 
2.7.4

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

Re: [edk2] [PATCH 1/2] ArmPkg: remove DebugUncachedMemoryAllocationLib

[Ard Biesheuvel]

On 23 February 2017 at 17:49, Leif Lindholm  wrote:
> On Thu, Feb 23, 2017 at 03:48:04PM +, Ard Biesheuvel wrote:
>> The debug implementation of the UncachedMemoryAllocationLib library
>> class relies on the creation of an uncached alias of a memory range,
>> while keeping the original cached mapping, but with read-only attributes
>> to trap inadvertent write accesses.
>>
>> This is not a terribly good idea, given that the ARM architecture does
>> not allow mismatched attributes, and so creating them deliberately is
>> not something we should encourage by doing it in reference code.
>
> Agreed.
> One comment near the end:
>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel 
>> ---
>>  ArmPkg/ArmPkg.dsc   
>>  |   1 -
>>  
>> ArmPkg/Library/DebugUncachedMemoryAllocationLib/DebugUncachedMemoryAllocationLib.c
>>| 656 
>>  
>> ArmPkg/Library/DebugUncachedMemoryAllocationLib/DebugUncachedMemoryAllocationLib.inf
>>  |  47 --
>>  ArmVirtPkg/ArmVirt.dsc.inc  
>>  |   2 -
>>  BeagleBoardPkg/BeagleBoardPkg.dsc   
>>  |   1 -
>>  Omap35xxPkg/Omap35xxPkg.dsc 
>>  |   3 +-
>>  6 files changed, 1 insertion(+), 709 deletions(-)
>>
>> diff --git a/ArmPkg/ArmPkg.dsc b/ArmPkg/ArmPkg.dsc
>> index 0db33eb865b1..1a490d23f7b5 100644
>> --- a/ArmPkg/ArmPkg.dsc
>> +++ b/ArmPkg/ArmPkg.dsc
>> @@ -112,7 +112,6 @@ [Components.common]
>>ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
>>ArmPkg/Library/DebugAgentSymbolsBaseLib/DebugAgentSymbolsBaseLib.inf
>>ArmPkg/Library/DebugPeCoffExtraActionLib/DebugPeCoffExtraActionLib.inf
>> -  
>> ArmPkg/Library/DebugUncachedMemoryAllocationLib/DebugUncachedMemoryAllocationLib.inf
>>ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLib.inf
>>ArmPkg/Library/RvdPeCoffExtraActionLib/RvdPeCoffExtraActionLib.inf
>>ArmPkg/Library/SemiHostingDebugLib/SemiHostingDebugLib.inf
>> diff --git 
>> a/ArmPkg/Library/DebugUncachedMemoryAllocationLib/DebugUncachedMemoryAllocationLib.c
>>  
>> b/ArmPkg/Library/DebugUncachedMemoryAllocationLib/DebugUncachedMemoryAllocationLib.c
>> deleted file mode 100644
>> index 00e01a905c85..
>> --- 
>> a/ArmPkg/Library/DebugUncachedMemoryAllocationLib/DebugUncachedMemoryAllocationLib.c
>> +++ /dev/null
>> @@ -1,656 +0,0 @@
>> -/** @file
>> -  Debug version of the UncachedMemoryAllocation lib that uses the 
>> VirtualUncachedPages
>> -  protocol, produced by the DXE CPU driver, to produce debuggable uncached 
>> memory buffers.
>> -
>> -  The DMA rules for EFI contain the concept of a PCI (DMA master) address 
>> for memory and
>> -  a CPU (C code) address for the memory buffer that don't have to be the 
>> same.  There seem to
>> -  be common errors out there with folks mixing up the two addresses.  This 
>> library causes
>> -  the PCI (DMA master) address to not be mapped into system memory so if 
>> the CPU (C code)
>> -  uses the wrong pointer it will generate a page fault. The CPU (C code) 
>> version of the buffer
>> -  has a virtual address that does not match the physical address. The 
>> virtual address has
>> -  PcdArmUncachedMemoryMask ored into the physical address.
>> -
>> -  Copyright (c) 2008 - 2010, Apple Inc. 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 
>> -#include 
>> -#include 
>> -#include 
>> -#include 
>> -#include 
>> -#include 
>> -#include 
>> -#include 
>> -
>> -#include 
>> -#include 
>> -
>> -VOID *
>> -UncachedInternalAllocatePages (
>> -  IN EFI_MEMORY_TYPE  MemoryType,
>> -  IN UINTNPages
>> -  );
>> -
>> -VOID *
>> -UncachedInternalAllocateAlignedPages (
>> -  IN EFI_MEMORY_TYPE  MemoryType,
>> -  IN UINTNPages,
>> -  IN UINTNAlignment
>> -  );
>> -
>> -
>> -
>> -EFI_CPU_ARCH_PROTOCOL   *gDebugUncachedCpu;
>> -VIRTUAL_UNCACHED_PAGES_PROTOCOL *gVirtualUncachedPages;
>> -
>> -//
>> -// Assume all of memory has the same cache attributes, unless we do our 
>> magic
>> -//
>> -UINT64  gAttributes;
>> -
>> -typedef struct {
>> -  VOID*Buffer;
>> -  VOID*Allocation;
>> -  UINTN   Pages;
>> -  LIST_ENTRY  Link;
>> -} FREE_PAGE_NODE;
>> -
>> -LIST_ENTRY  mPageList = INITIALIZE_LIST_HEAD_VARIABLE (mPageList);
>> -
>> -VOID
>> -AddPagesToList (
>> -  IN VOID   *Buffer,
>> -  IN VO

Re: [edk2] [PATCH 1/2] ArmPkg: remove DebugUncachedMemoryAllocationLib

[Leif Lindholm]

On Thu, Feb 23, 2017 at 03:48:04PM +, Ard Biesheuvel wrote:
> The debug implementation of the UncachedMemoryAllocationLib library
> class relies on the creation of an uncached alias of a memory range,
> while keeping the original cached mapping, but with read-only attributes
> to trap inadvertent write accesses.
> 
> This is not a terribly good idea, given that the ARM architecture does
> not allow mismatched attributes, and so creating them deliberately is
> not something we should encourage by doing it in reference code.

Agreed.
One comment near the end:

> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmPkg/ArmPkg.dsc
> |   1 -
>  
> ArmPkg/Library/DebugUncachedMemoryAllocationLib/DebugUncachedMemoryAllocationLib.c
>| 656 
>  
> ArmPkg/Library/DebugUncachedMemoryAllocationLib/DebugUncachedMemoryAllocationLib.inf
>  |  47 --
>  ArmVirtPkg/ArmVirt.dsc.inc   
> |   2 -
>  BeagleBoardPkg/BeagleBoardPkg.dsc
> |   1 -
>  Omap35xxPkg/Omap35xxPkg.dsc  
> |   3 +-
>  6 files changed, 1 insertion(+), 709 deletions(-)
> 
> diff --git a/ArmPkg/ArmPkg.dsc b/ArmPkg/ArmPkg.dsc
> index 0db33eb865b1..1a490d23f7b5 100644
> --- a/ArmPkg/ArmPkg.dsc
> +++ b/ArmPkg/ArmPkg.dsc
> @@ -112,7 +112,6 @@ [Components.common]
>ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
>ArmPkg/Library/DebugAgentSymbolsBaseLib/DebugAgentSymbolsBaseLib.inf
>ArmPkg/Library/DebugPeCoffExtraActionLib/DebugPeCoffExtraActionLib.inf
> -  
> ArmPkg/Library/DebugUncachedMemoryAllocationLib/DebugUncachedMemoryAllocationLib.inf
>ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLib.inf
>ArmPkg/Library/RvdPeCoffExtraActionLib/RvdPeCoffExtraActionLib.inf
>ArmPkg/Library/SemiHostingDebugLib/SemiHostingDebugLib.inf
> diff --git 
> a/ArmPkg/Library/DebugUncachedMemoryAllocationLib/DebugUncachedMemoryAllocationLib.c
>  
> b/ArmPkg/Library/DebugUncachedMemoryAllocationLib/DebugUncachedMemoryAllocationLib.c
> deleted file mode 100644
> index 00e01a905c85..
> --- 
> a/ArmPkg/Library/DebugUncachedMemoryAllocationLib/DebugUncachedMemoryAllocationLib.c
> +++ /dev/null
> @@ -1,656 +0,0 @@
> -/** @file
> -  Debug version of the UncachedMemoryAllocation lib that uses the 
> VirtualUncachedPages
> -  protocol, produced by the DXE CPU driver, to produce debuggable uncached 
> memory buffers.
> -
> -  The DMA rules for EFI contain the concept of a PCI (DMA master) address 
> for memory and
> -  a CPU (C code) address for the memory buffer that don't have to be the 
> same.  There seem to
> -  be common errors out there with folks mixing up the two addresses.  This 
> library causes
> -  the PCI (DMA master) address to not be mapped into system memory so if the 
> CPU (C code)
> -  uses the wrong pointer it will generate a page fault. The CPU (C code) 
> version of the buffer
> -  has a virtual address that does not match the physical address. The 
> virtual address has
> -  PcdArmUncachedMemoryMask ored into the physical address.
> -
> -  Copyright (c) 2008 - 2010, Apple Inc. 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 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -
> -#include 
> -#include 
> -
> -VOID *
> -UncachedInternalAllocatePages (
> -  IN EFI_MEMORY_TYPE  MemoryType,
> -  IN UINTNPages
> -  );
> -
> -VOID *
> -UncachedInternalAllocateAlignedPages (
> -  IN EFI_MEMORY_TYPE  MemoryType,
> -  IN UINTNPages,
> -  IN UINTNAlignment
> -  );
> -
> -
> -
> -EFI_CPU_ARCH_PROTOCOL   *gDebugUncachedCpu;
> -VIRTUAL_UNCACHED_PAGES_PROTOCOL *gVirtualUncachedPages;
> -
> -//
> -// Assume all of memory has the same cache attributes, unless we do our magic
> -//
> -UINT64  gAttributes;
> -
> -typedef struct {
> -  VOID*Buffer;
> -  VOID*Allocation;
> -  UINTN   Pages;
> -  LIST_ENTRY  Link;
> -} FREE_PAGE_NODE;
> -
> -LIST_ENTRY  mPageList = INITIALIZE_LIST_HEAD_VARIABLE (mPageList);
> -
> -VOID
> -AddPagesToList (
> -  IN VOID   *Buffer,
> -  IN VOID   *Allocation,
> -  UINTN Pages
> -  )
> -{
> -  FREE_PAGE_NODE  *NewNode;
> -
> -  NewNode = AllocatePool (sizeof (LIST_ENTRY));
> -  if (NewNode == NULL) {
> -ASSERT (FALSE);
> -r

Re: [edk2] DxeCore assert during initialization

[Ard Biesheuvel]

On 23 February 2017 at 17:51, Laszlo Ersek  wrote:
> On 02/23/17 18:38, Ard Biesheuvel wrote:
>> On 23 February 2017 at 17:33, Laszlo Ersek  wrote:
>>> On 02/23/17 18:29, Laszlo Ersek wrote:
>>>
 This is with ArmVirtQemu @ c5c9e7e298ed, running on QEMU 
 v2.8.0-1290-gc3618551719b, using TCG.
>>>
>>> Hm, I have some patches in QEMU, so that hash will likely not resolve on
>>> your side. The first upstream ancestor is e295a154c2a9.
>>>
>>
>> Could you please double check?
>>
>> $ git show e295a154c2a9
>> fatal: ambiguous argument 'e295a154c2a9': unknown revision or path not
>> in the working tree.
>
> That's the QEMU git hash:
>
> e295a154c2a9 ("Merge remote-tracking branch 
> 'remotes/dgilbert/tags/pull-hmp-20170221' into staging", 2017-02-21)
>
> http://git.qemu-project.org/?p=qemu.git;a=commit;h=e295a154c2a9
>
>>
>> In any case, it faults on address 0x1383C6E94 with a data abort due to
>> permissions, which can only be caused by a store to read-only region.
>>
>> This is at the end of the .text segment of UiApp.dll
>>
>> Could you open the .dll in GDB (you may need to do 'set architecture
>> aarch64'), and paste the output of
>>
>> disas *0x3070
>
> I don't have an aarch64 GDB on my laptop, but I have addr2line:
>
> $ aarch64-linux-gnu-addr2line \
>   -e 
> Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/AARCH64/MdeModulePkg/Application/UiApp/UiApp/DEBUG/UiApp.debug
>  \
>   0x3070
> .../MdeModulePkg/Application/UiApp/FrontPage.c:834
>
> This looks reasonable, because the crash hit after I pressed ESC on the 
> splash screen, and was about to get in the menu.
>
>826//
>827// Set PCD to Inform GraphicsConsole to change video resolution.
>828// Set PCD to Inform Consplitter to change text mode.
>829//
>830Status = PcdSet32S (PcdVideoHorizontalResolution, 
> NewHorizontalResolution);
>831ASSERT_EFI_ERROR (Status);
>832Status = PcdSet32S (PcdVideoVerticalResolution, 
> NewVerticalResolution);
>833ASSERT_EFI_ERROR (Status);
>834Status = PcdSet32S (PcdConOutColumn, NewColumns); <-- here
>835ASSERT_EFI_ERROR (Status);
>836Status = PcdSet32S (PcdConOutRow, NewRows);
>837ASSERT_EFI_ERROR (Status);
>
> Disassembly with objdump:
>
>   Status = PcdSet32S (PcdConOutColumn, NewColumns);
> 3064:   f1a0adrpx0, 3a000 
> 
> 3068:   913a5000add x0, x0, #0xe94
> 306c:   b9407ba1ldr w1, [x29,#120]
> 3070:   b901str w1, [x0]  <- here
> 3074:   f90033bfstr xzr, [x29,#96]
>
> Does this help?
>

Yes, it does.

This bit, from BaseTools/Scripts/GccBase.lds

/*
 * The contents of AutoGen.c files are constant from the POV of the program,
 * but most of its contents end up in .data or .bss by default since few of
 * the variable definitions that get emitted are declared as CONST.
 */
*:AutoGen.obj(.data .data.* .bss .bss.*)

turns out to be inaccurate: AutoGen.c also contains (in this case),

.data._gPcd_BinaryPatch_PcdSetupConOutColumn

which is set by the PcdSet32S() call above.

Let me try if I can find a nice fix for this, but simply removing the
line should solve the issue for you.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] DxeCore assert during initialization

[Laszlo Ersek]

On 02/23/17 18:38, Ard Biesheuvel wrote:
> On 23 February 2017 at 17:33, Laszlo Ersek  wrote:
>> On 02/23/17 18:29, Laszlo Ersek wrote:
>>
>>> This is with ArmVirtQemu @ c5c9e7e298ed, running on QEMU 
>>> v2.8.0-1290-gc3618551719b, using TCG.
>>
>> Hm, I have some patches in QEMU, so that hash will likely not resolve on
>> your side. The first upstream ancestor is e295a154c2a9.
>>
> 
> Could you please double check?
> 
> $ git show e295a154c2a9
> fatal: ambiguous argument 'e295a154c2a9': unknown revision or path not
> in the working tree.

That's the QEMU git hash:

e295a154c2a9 ("Merge remote-tracking branch 
'remotes/dgilbert/tags/pull-hmp-20170221' into staging", 2017-02-21)

http://git.qemu-project.org/?p=qemu.git;a=commit;h=e295a154c2a9

> 
> In any case, it faults on address 0x1383C6E94 with a data abort due to
> permissions, which can only be caused by a store to read-only region.
> 
> This is at the end of the .text segment of UiApp.dll
> 
> Could you open the .dll in GDB (you may need to do 'set architecture
> aarch64'), and paste the output of
> 
> disas *0x3070

I don't have an aarch64 GDB on my laptop, but I have addr2line:

$ aarch64-linux-gnu-addr2line \
  -e 
Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/AARCH64/MdeModulePkg/Application/UiApp/UiApp/DEBUG/UiApp.debug
 \
  0x3070
.../MdeModulePkg/Application/UiApp/FrontPage.c:834

This looks reasonable, because the crash hit after I pressed ESC on the splash 
screen, and was about to get in the menu.

   826//
   827// Set PCD to Inform GraphicsConsole to change video resolution.
   828// Set PCD to Inform Consplitter to change text mode.
   829//
   830Status = PcdSet32S (PcdVideoHorizontalResolution, 
NewHorizontalResolution);
   831ASSERT_EFI_ERROR (Status);
   832Status = PcdSet32S (PcdVideoVerticalResolution, 
NewVerticalResolution);
   833ASSERT_EFI_ERROR (Status);
   834Status = PcdSet32S (PcdConOutColumn, NewColumns); <-- here
   835ASSERT_EFI_ERROR (Status);
   836Status = PcdSet32S (PcdConOutRow, NewRows);
   837ASSERT_EFI_ERROR (Status);

Disassembly with objdump:

  Status = PcdSet32S (PcdConOutColumn, NewColumns);
3064:   f1a0adrpx0, 3a000 

3068:   913a5000add x0, x0, #0xe94
306c:   b9407ba1ldr w1, [x29,#120]
3070:   b901str w1, [x0]  <- here
3074:   f90033bfstr xzr, [x29,#96]

Does this help?

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

Re: [edk2] [PATCH 2/2] ArmPkg/CpuDxe: remove VirtualUncachedPages protocol and implementation

[Leif Lindholm]

On Thu, Feb 23, 2017 at 03:48:05PM +, Ard Biesheuvel wrote:
> Virtual uncached pages are simply pages that are aliased using mismatched
> attributes, which is not allowed by the ARM architecture. So remove the
> protocol and its implementation.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 

Nuke it from orbit:
Reviewed-by: Leif Lindholm 

> ---
>  ArmPkg/ArmPkg.dec  |  3 -
>  ArmPkg/Drivers/CpuDxe/CpuDxe.c |  1 -
>  ArmPkg/Drivers/CpuDxe/CpuDxe.h |  3 -
>  ArmPkg/Drivers/CpuDxe/CpuDxe.inf   |  1 -
>  ArmPkg/Drivers/CpuDxe/CpuMmuCommon.c   | 70 
>  ArmPkg/Include/Protocol/VirtualUncachedPages.h | 60 -
>  6 files changed, 138 deletions(-)
> 
> diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec
> index 8e9cf199becc..4fd7a5be5158 100644
> --- a/ArmPkg/ArmPkg.dec
> +++ b/ArmPkg/ArmPkg.dec
> @@ -52,9 +52,6 @@ [Ppis]
>## Include/Ppi/ArmMpCoreInfo.h
>gArmMpCoreInfoPpiGuid = { 0x6847cc74, 0xe9ec, 0x4f8f, {0xa2, 0x9d, 0xab, 
> 0x44, 0xe7, 0x54, 0xa8, 0xfc} }
>  
> -[Protocols.common]
> -  gVirtualUncachedPagesProtocolGuid = { 0xAD651C7D, 0x3C22, 0x4DBF, { 0x92, 
> 0xe8, 0x38, 0xa7, 0xcd, 0xae, 0x87, 0xb2 } }
> -
>  [PcdsFeatureFlag.common]
>gArmTokenSpaceGuid.PcdCpuDxeProduceDebugSupport|FALSE|BOOLEAN|0x0001
>  
> diff --git a/ArmPkg/Drivers/CpuDxe/CpuDxe.c b/ArmPkg/Drivers/CpuDxe/CpuDxe.c
> index 7d328d096b1e..5aa5b874144a 100644
> --- a/ArmPkg/Drivers/CpuDxe/CpuDxe.c
> +++ b/ArmPkg/Drivers/CpuDxe/CpuDxe.c
> @@ -253,7 +253,6 @@ CpuDxeInitialize (
>Status = gBS->InstallMultipleProtocolInterfaces (
>  &mCpuHandle,
>  &gEfiCpuArchProtocolGuid,   &mCpu,
> -&gVirtualUncachedPagesProtocolGuid, &gVirtualUncachedPages,
>  NULL
>  );
>  
> diff --git a/ArmPkg/Drivers/CpuDxe/CpuDxe.h b/ArmPkg/Drivers/CpuDxe/CpuDxe.h
> index 80c305d53dd1..a00fc3064362 100644
> --- a/ArmPkg/Drivers/CpuDxe/CpuDxe.h
> +++ b/ArmPkg/Drivers/CpuDxe/CpuDxe.h
> @@ -35,7 +35,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  
>  
> @@ -169,6 +168,4 @@ SetGcdMemorySpaceAttributes (
>IN UINT64  Attributes
>);
>  
> -extern VIRTUAL_UNCACHED_PAGES_PROTOCOL  gVirtualUncachedPages;
> -
>  #endif // __CPU_DXE_ARM_EXCEPTION_H__
> diff --git a/ArmPkg/Drivers/CpuDxe/CpuDxe.inf 
> b/ArmPkg/Drivers/CpuDxe/CpuDxe.inf
> index b31c994f43e2..d068e06803ed 100644
> --- a/ArmPkg/Drivers/CpuDxe/CpuDxe.inf
> +++ b/ArmPkg/Drivers/CpuDxe/CpuDxe.inf
> @@ -61,7 +61,6 @@ [LibraryClasses]
>  [Protocols]
>gEfiCpuArchProtocolGuid
>gEfiDebugSupportPeriodicCallbackProtocolGuid
> -  gVirtualUncachedPagesProtocolGuid
>  
>  [Guids]
>gEfiDebugImageInfoTableGuid
> diff --git a/ArmPkg/Drivers/CpuDxe/CpuMmuCommon.c 
> b/ArmPkg/Drivers/CpuDxe/CpuMmuCommon.c
> index 54d9b0163331..ebe593d1c325 100644
> --- a/ArmPkg/Drivers/CpuDxe/CpuMmuCommon.c
> +++ b/ArmPkg/Drivers/CpuDxe/CpuMmuCommon.c
> @@ -211,73 +211,3 @@ CpuSetMemoryAttributes (
>  return EFI_SUCCESS;
>}
>  }
> -
> -EFI_STATUS
> -EFIAPI
> -CpuConvertPagesToUncachedVirtualAddress (
> -  IN  VIRTUAL_UNCACHED_PAGES_PROTOCOL  *This,
> -  IN  EFI_PHYSICAL_ADDRESS  Address,
> -  IN  UINTN Length,
> -  IN  EFI_PHYSICAL_ADDRESS  VirtualMask,
> -  OUT UINT64   *Attributes OPTIONAL
> -  )
> -{
> -  EFI_STATUS  Status;
> -  EFI_GCD_MEMORY_SPACE_DESCRIPTOR GcdDescriptor;
> -
> -  if (Attributes != NULL) {
> -Status = gDS->GetMemorySpaceDescriptor (Address, &GcdDescriptor);
> -if (!EFI_ERROR (Status)) {
> -  *Attributes = GcdDescriptor.Attributes;
> -}
> -  }
> -
> -  //
> -  // Make this address range page fault if accessed. If it is a DMA buffer 
> than this would
> -  // be the PCI address. Code should always use the CPU address, and we will 
> or in VirtualMask
> -  // to that address.
> -  //
> -  Status = SetMemoryAttributes (Address, Length, EFI_MEMORY_RO, 0);
> -  if (!EFI_ERROR (Status)) {
> -Status = SetMemoryAttributes (Address | VirtualMask, Length, 
> EFI_MEMORY_UC, VirtualMask);
> -  }
> -
> -  DEBUG ((DEBUG_INFO | DEBUG_LOAD, 
> "CpuConvertPagesToUncachedVirtualAddress()\nUnmapped 0x%08lx Mapped 
> 0x%08lx 0x%x bytes\n", Address, Address | VirtualMask, Length));
> -
> -  return Status;
> -}
> -
> -
> -EFI_STATUS
> -EFIAPI
> -CpuReconvertPages (
> -  IN  VIRTUAL_UNCACHED_PAGES_PROTOCOL  *This,
> -  IN  EFI_PHYSICAL_ADDRESS  Address,
> -  IN  UINTN Length,
> -  IN  EFI_PHYSICAL_ADDRESS  VirtualMask,
> -  IN  UINT64Attributes
> -  )
> -{
> -  EFI_STATUS  Status;
> -
> -  DEBUG ((DEBUG_INFO | DEBUG_LOAD, "CpuReconvertPages(%lx, %x, %lx, %lx)\n", 
> Address, Length, VirtualMask, Attrib

Re: [edk2] DxeCore assert during initialization

[Ard Biesheuvel]

On 23 February 2017 at 17:33, Laszlo Ersek  wrote:
> On 02/23/17 18:29, Laszlo Ersek wrote:
>
>> This is with ArmVirtQemu @ c5c9e7e298ed, running on QEMU 
>> v2.8.0-1290-gc3618551719b, using TCG.
>
> Hm, I have some patches in QEMU, so that hash will likely not resolve on
> your side. The first upstream ancestor is e295a154c2a9.
>

Could you please double check?

$ git show e295a154c2a9
fatal: ambiguous argument 'e295a154c2a9': unknown revision or path not
in the working tree.

In any case, it faults on address 0x1383C6E94 with a data abort due to
permissions, which can only be caused by a store to read-only region.

This is at the end of the .text segment of UiApp.dll

Could you open the .dll in GDB (you may need to do 'set architecture
aarch64'), and paste the output of

disas *0x3070

?

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

Re: [edk2] DxeCore assert during initialization

[Marcin Wojtas]

Hi Ard,

2017-02-23 18:17 GMT+01:00 Ard Biesheuvel :
> On 23 February 2017 at 17:16, Marcin Wojtas  wrote:
>> Hi,
>>
>> I use Marvell Armada70x0 from mainline OpenPlatformPkg. After updating
>> baseline to newest tianocore master branch it turned out that the
>> platform fail to boot due to following assert:
>>
>> /home/mw/git/edk2/Build/Armada70x0/DEBUG_GCC48/AARCH64/ArmPlatformPkg/PrePi/PeiMPCore/DEBUG/ArmPlatformPrePiMPCore.dll
>> 0x1800
>> add-symbol-file
>> /home/mw/git/edk2/Build/Armada70x0/DEBUG_GCC48/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll
>> 0x3F534800
>> Loading DxeCore at 0x003F534000 EntryPoint=0x003F534800
>>
>> ASSERT_EFI_ERROR (Status = Invalid Parameter)
>> ASSERT [DxeCore]
>> /home/mw/git/edk2/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c(523):
>> !EFI_ERROR (Status)
>>
>> I bisected edk2 master branch and confirmed that the problem appeared
>> with commit dc4c770763d0 ("BaseTools: add error check for Macro usage
>> in the INF file").
>>
>> There are no errors, nor warnings during BaseTool and platform builds.
>> Is it a known problem? Any idea about possible root cause?
>>
>
> Already fixed in
> 1d8cebf91040 BaseTools: Fix the regression issue caused by commit dc4c77

Thank you for very fast response. The fix indeed helps. Just for the
notice top of the master fails to build due to commit cfb0aba7934b
("MdeModulePkg: Add performance property configuration table").


/home/mw/git/edk2/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c:
In function ‘DxeCorePerformanceLibConstructor’:
/home/mw/git/edk2/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c:538:3:
error: passing argument 2 of ‘EfiGetSystemConfigurationTable’ from
incompatible pointer type [-Werror]
   Status = EfiGetSystemConfigurationTable (&gPerformanceProtocolGuid,
&PerformanceProperty);
   ^
In file included from
/home/mw/git/edk2/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLibInternal.h:35:0,
 from
/home/mw/git/edk2/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c:26:
/home/mw/git/edk2/MdePkg/Include/Library/UefiLib.h:135:1: note:
expected ‘void **’ but argument is of type ‘struct
PERFORMANCE_PROPERTY **’
 EfiGetSystemConfigurationTable (
 ^
cc1: all warnings being treated as errors
make: *** 
[/home/mw/git/edk2/Build/Armada70x0/DEBUG_GCC48/AARCH64/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib/OUTPUT/DxeCorePerformanceLib.obj]
Error 1

I'll stick to one revision and won't move from now on:)

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

Re: [edk2] DxeCore assert during initialization

[Laszlo Ersek]

On 02/23/17 18:29, Laszlo Ersek wrote:

> This is with ArmVirtQemu @ c5c9e7e298ed, running on QEMU 
> v2.8.0-1290-gc3618551719b, using TCG.

Hm, I have some patches in QEMU, so that hash will likely not resolve on
your side. The first upstream ancestor is e295a154c2a9.

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

Re: [edk2] DxeCore assert during initialization

[Laszlo Ersek]

On 02/23/17 18:17, Ard Biesheuvel wrote:
> On 23 February 2017 at 17:16, Marcin Wojtas  wrote:
>> Hi,
>>
>> I use Marvell Armada70x0 from mainline OpenPlatformPkg. After updating
>> baseline to newest tianocore master branch it turned out that the
>> platform fail to boot due to following assert:
>>
>> /home/mw/git/edk2/Build/Armada70x0/DEBUG_GCC48/AARCH64/ArmPlatformPkg/PrePi/PeiMPCore/DEBUG/ArmPlatformPrePiMPCore.dll
>> 0x1800
>> add-symbol-file
>> /home/mw/git/edk2/Build/Armada70x0/DEBUG_GCC48/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll
>> 0x3F534800
>> Loading DxeCore at 0x003F534000 EntryPoint=0x003F534800
>>
>> ASSERT_EFI_ERROR (Status = Invalid Parameter)
>> ASSERT [DxeCore]
>> /home/mw/git/edk2/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c(523):
>> !EFI_ERROR (Status)
>>
>> I bisected edk2 master branch and confirmed that the problem appeared
>> with commit dc4c770763d0 ("BaseTools: add error check for Macro usage
>> in the INF file").
>>
>> There are no errors, nor warnings during BaseTool and platform builds.
>> Is it a known problem? Any idea about possible root cause?
>>
> 
> Already fixed in
> 1d8cebf91040 BaseTools: Fix the regression issue caused by commit dc4c77

Yes, it is.

However, I'm seeing another problem (perhaps I should have started a separate 
thread with this):

> [Bds]=Begin Load Options Dumping ...=
>   Driver Options:
>   SysPrep Options:
>   Boot Options:
> Boot0005: Red Hat Enterprise Linux 0x0001
> Boot0001: UEFI QEMU QEMU CD-ROM0x0001
> Boot: UiApp0x0109
> Boot0002: UEFI Misc Device 0x0001
> Boot0003: UEFI Misc Device 2   0x0001
> Boot0006: EFI Internal Shell   0x0001
>   PlatformRecovery Options:
> PlatformRecovery: Default PlatformRecovery 0x0001
> [Bds]=End Load Options Dumping=
> [Bds]BdsWait ...Zzzz...
> [Bds]BdsWait(5)..Zzzz...
> InstallProtocolInterface: 41D94CD2-35B6-455A-8258-D4E51334AADD 139389420
> InstallProtocolInterface: 3AD9DF29-4501-478D-B1F8-7F7FE70E50F3 139389EB8
> InstallProtocolInterface: F4B427BB-BA21-4F16-BC4E-43E416AB619C 139388030
> InstallProtocolInterface: F4B427BB-BA21-4F16-BC4E-43E416AB619C 13939A2B0
> [Bds]BdsWait(4)..Zzzz...
> [Bds]BmHotkeyCallback: 0017:
> [Bds]Hotkey for Boot pressed - Success
> [Bds]Exit the waiting!
> [Bds] Booting Boot Manager Menu.
> [Bds]Stop Hotkey Service!
> [Bds]UnregisterKeyNotify: 000C/ Success
> [Bds]UnregisterKeyNotify: 0017/ Success
> [Bds]UnregisterKeyNotify: /000D Success
> Memory  Previous  CurrentNext
>  TypePages Pages Pages
> ==      
>   09  0080  00A0
>   0A  0020  0028
>   00  0004  0005
>   060258  0410  0514
>   050190  02C0  0370
>   0305DC  056E  05DC
>   042EE0  2CF1  2EE0
>   010014    0014
>   02    
> Memory Type Information settings change.
> [Bds]Booting UiApp
> InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 1393E05C0
> add-symbol-file 
> .../Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/AARCH64/MdeModulePkg/Application/UiApp/UiApp/DEBUG/UiApp.dll
>  0x13838D000
> Loading driver at 0x0013838C000 EntryPoint=0x0013838D000 UiApp.efi
> InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 138D1B498
> ProtectUefiImageCommon - 0x393E05C0
>   - 0x00013838C000 - 0x00044000
>   Image - 
> .../Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/AARCH64/MdeModulePkg/Application/UiApp/UiApp/DEBUG/UiApp.dll
>   Section - '.text   '
>   VirtualSize  - 0x0003D000
>   VirtualAddress   - 0x1000
>   SizeOfRawData- 0x0003D000
>   PointerToRawData - 0x1000
>   PointerToRelocations - 0x
>   PointerToLinenumbers - 0x
>   NumberOfRelocations  - 0x
>   NumberOfLinenumbers  - 0x
>   Characteristics  - 0x6020
> ImageCode: 0x00013838D000 - 0x0003D000
>   Section - '.data   '
>   Section - '.reloc  '
> ImageCode SegmentCount - 0x1
> SetUefiImageMemoryAttributes - 0x00013838C000 - 0x1000 
> (0x4008)
> SetUefiImageMemoryAttributes - 0x00013838D000 - 0x0003D000 
> (0x00020008)
> SetUefiImageMemoryAttributes - 0x0001383CA000 - 0x6000 
> (0x4008)
> InstallProtocolInterface: 09576E91-6D3F-11D2-8E39-00A0C969723B 13A690F98
> InstallProtocolInterface: 330D4706-F2A0-4E4F-A369-B66FA8D54385 1383CB150
> InstallProtocolInterface: 09576E91-6D3F-11D2-8E39-00A0C969723B 1383CB300
> InstallProtocolInterface: 330D4706-F2A0-4E4F-A369-B66FA8D54385 1383CB2D0
> InstallProtocolInterface: 09576E91-6D3F-11D2-8E39-00A0C969723B 1383CB498
> InstallProtocolInterface: 330D4706-F2A0-4E4F-A369-B66FA8D54385 1383CB4C8
> InstallProtocolInterfa

Re: [edk2] [PATCH v4 1/3] MdeModulePkg: Add performance property configuration table

[Ard Biesheuvel]

On 3 February 2017 at 05:32, Yao, Jiewen  wrote:
> Thank you Mike and Star.
>
> It is good idea to remove TimerLib dependency.
> Series Reviewed-by: jiewen@intel.com
>

This patch breaks the GCC build:

:
In function 'DxeCorePerformanceLibConstructor':
:538:3:
error: passing argument 2 of 'EfiGetSystemConfigurationTable' from
incompatible pointer type [-Werror]
   Status = EfiGetSystemConfigurationTable (&gPerformanceProtocolGuid,
&PerformanceProperty);
   ^
In file included from
:35:0,
 from
:26:
:135:1:
note: expected 'void **' but argument is of type 'struct
PERFORMANCE_PROPERTY **'
 EfiGetSystemConfigurationTable (
 ^

This fixes it for me:

diff --git a/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c
b/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c
index 1564514518d3..5438bd086144 100644
--- a/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c
+++ b/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c
@@ -535,7 +535,7 @@ DxeCorePerformanceLibConstructor (

   InternalGetPeiPerformance ();

-  Status = EfiGetSystemConfigurationTable (&gPerformanceProtocolGuid,
&PerformanceProperty);
+  Status = EfiGetSystemConfigurationTable (&gPerformanceProtocolGuid,
(VOID **)&PerformanceProperty);
   if (EFI_ERROR (Status)) {
 //
 // Install configuration table for performance property.


Thanks,
Ard,


>
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Michael Kinney
>> Sent: Friday, February 3, 2017 12:56 PM
>> To: edk2-devel@lists.01.org
>> Cc: Andrew Fish ; Gao, Liming ; Yao,
>> Jiewen ; Carsey, Jaben ; Zeng,
>> Star 
>> Subject: [edk2] [PATCH v4 1/3] MdeModulePkg: Add performance property
>> configuration table
>>
>> From: Star Zeng 
>>
>> Define PERFORMANCE_PROPERTY, and install performance property
>> configuration
>> table in DxeCorePerformanceLib and SmmCorePerformanceLib.
>>
>> Cc: Andrew Fish 
>> Cc: Michael Kinney 
>> Cc: Liming Gao 
>> Cc: Jiewen Yao 
>> Cc: Cinnamon Shia 
>> Cc: Jaben Carsey 
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Star Zeng 
>> ---
>>  MdeModulePkg/Include/Guid/Performance.h| 12 ++-
>>  .../DxeCorePerformanceLib/DxeCorePerformanceLib.c  | 23
>> --
>>  .../DxeCorePerformanceLib.inf  |  2 ++
>>  .../DxeCorePerformanceLibInternal.h|  3 ++-
>>  .../SmmCorePerformanceLib/SmmCorePerformanceLib.c  | 18
>> +
>>  .../SmmCorePerformanceLib.inf  |  5 -
>>  6 files changed, 58 insertions(+), 5 deletions(-)
>>
>> diff --git a/MdeModulePkg/Include/Guid/Performance.h
>> b/MdeModulePkg/Include/Guid/Performance.h
>> index c40046c..df40c6c 100644
>> --- a/MdeModulePkg/Include/Guid/Performance.h
>> +++ b/MdeModulePkg/Include/Guid/Performance.h
>> @@ -4,7 +4,7 @@
>>* performance protocol interfaces.
>>* performance variables.
>>
>> -Copyright (c) 2009 - 2013, Intel Corporation. All rights reserved.
>> +Copyright (c) 2009 - 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
>> @@ -18,6 +18,16 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY
>> KIND, EITHER EXPRESS OR IMPLIED.
>>  #ifndef __PERFORMANCE_DATA_H__
>>  #define __PERFORMANCE_DATA_H__
>>
>> +#define PERFORMANCE_PROPERTY_REVISION 0x1
>> +
>> +typedef struct {
>> +  UINT32Revision;
>> +  UINT32Reserved;
>> +  UINT64Frequency;
>> +  UINT64TimerStartValue;
>> +  UINT64TimerEndValue;
>> +} PERFORMANCE_PROPERTY;
>> +
>>  //
>>  // PEI_PERFORMANCE_STRING_SIZE must be a multiple of 8.
>>  //
>> diff --git
>> a/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c
>> b/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c
>> index 4739bb8..1564514 100644
>> ---
>> a/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c
>> +++
>> b/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c
>> @@ -10,7 +10,7 @@
>>This library 

Re: [edk2] [PATCH 00/12] ArmVirtPkg, OvmfPkg: factor out QemuFwCfgS3Lib

[Laszlo Ersek]

On 02/23/17 17:59, Jordan Justen wrote:
> On 2017-02-22 17:48:02, Laszlo Ersek wrote:
>> The new QemuFwCfgS3Lib class has two goals:
>>
>> (a) to query whether S3 support was enabled on the QEMU command line,
>>
>> (b) to save fw_cfg DMA operations that are to be replayed at S3 resume
>> time, and more easily for the programmer than hacking Boot Script
>> opcodes manually.
>>
>> Patches #1 through #5 introduce the new library class, with Base Null,
>> PEI fw_cfg, and DXE fw_cfg instances, covering goal (a) in both
>> ArmVirtPkg and OvmfPkg.
>>
>> Patch #6 retires QemuFwCfgS3Enabled() from QemuFwCfgLib (including
>> library class and all instances), and switches all client modules to
>> QemuFwCfgS3Lib. This separates S3 concerns from QemuFwCfgLib.
> 
> 1-6 Reviewed-by: Jordan Justen 

Thank you!

... Because goal (b) is mentioned in some of the commit messages and
source files of patches #1 through #6, I think it best if we only commit
these patches all together, once they are fully reviewed. I'm in no rush
with this :) (Unlike with WRITE_POINTER.)

Cheers!
Laszlo

> 
>> Patches #7 through #10 cover goal (b) for all three library instances
>> (at levels of support that are appropriate for each, of course).
>>
>> Patches #11 and #12 put the new library class to use in
>> OvmfPkg/SmmControl2Dxe and OvmfPkg/AcpiPlatformDxe, eliminating such
>> ACPI S3 Boot Script opcode hacking that is related to fw_cfg. (For
>> OvmfPkg/SmmControl2Dxe, that's "most of it", for
>> OvmfPkg/AcpiPlatformDxe, it's "all of it".)
>>
>> I tested:
>> - ArmVirtQemu boot,
>> - OVMF boot without SMM, with S3 enabled and disabled, using a Linux
>>   guest (and when S3 was enabled, I exercised it),
>> - OVMF boot with SMM, with S3 enabled and disabled, using Linux and
>>   Windows guests,
>>   - and whenever S3 was enabled, I exercised it
>>   - and in the Windows guest, I tested VMGENID / WRITE_POINTER too.
>>
>> The diffstat looks scary, but it's due to comments, I promise.
>>
>> Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=394
>> Repo: https://github.com/lersek/edk2.git
>> Branch:   fw_cfg_s3
>>
>> NOTE: if you want to fetch & test the branch, you'll have to revert
>> recent commit dc4c770763d0 ("BaseTools: add error check for Macro usage
>> in the INF file", 2017-02-20) on top. It causes BaseTools to mis-build
>> OVMF. I reported the regression on the list already, in that patch's
>> thread.
>>
>> Cc: Ard Biesheuvel 
>> Cc: Jordan Justen 
>>
>> Thanks
>> Laszlo
>>
>> Laszlo Ersek (12):
>>   OvmfPkg: introduce QemuFwCfgS3Lib class
>>   OvmfPkg/QemuFwCfgS3Lib: add initial Base Null library instance
>>   OvmfPkg/QemuFwCfgS3Lib: add initial PEI and DXE fw_cfg library
>> instances
>>   ArmVirtPkg: resolve QemuFwCfgS3Lib
>>   OvmfPkg: resolve QemuFwCfgS3Lib
>>   ArmVirtPkg, OvmfPkg: retire QemuFwCfgS3Enabled() from QemuFwCfgLib
>>   OvmfPkg/QemuFwCfgS3Lib: add boot script opcode generation APIs to
>> libclass
>>   OvmfPkg/QemuFwCfgS3Lib: implement opcode APIs for Base Null instance
>>   OvmfPkg/QemuFwCfgS3Lib: implement opcode APIs for PEI fw_cfg instance
>>   OvmfPkg/QemuFwCfgS3Lib: implement opcode APIs for DXE fw_cfg instance
>>   OvmfPkg/SmmControl2Dxe: save fw_cfg boot script with QemuFwCfgS3Lib
>>   OvmfPkg/AcpiPlatformDxe: save fw_cfg boot script with QemuFwCfgS3Lib
>>
>>  ArmVirtPkg/ArmVirtQemu.dsc|   1 +
>>  ArmVirtPkg/ArmVirtQemuKernel.dsc  |   1 +
>>  ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c|  17 -
>>  OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h|   2 +-
>>  OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf   |   2 +-
>>  OvmfPkg/AcpiPlatformDxe/BootScript.c  | 262 
>> ++-
>>  OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c   |   8 +
>>  OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpiPlatformDxe.inf  |   2 +-
>>  OvmfPkg/Include/Library/QemuFwCfgLib.h|  14 -
>>  OvmfPkg/Include/Library/QemuFwCfgS3Lib.h  | 357 
>> +
>>  OvmfPkg/Library/LockBoxLib/LockBoxDxe.c   |   1 +
>>  OvmfPkg/Library/LockBoxLib/LockBoxDxeLib.inf  |   1 +
>>  OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h  |   1 +
>>  OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf |   1 +
>>  OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c   |  28 -
>>  OvmfPkg/Library/QemuFwCfgS3Lib/BaseQemuFwCfgS3LibNull.inf |  43 ++
>>  OvmfPkg/Library/QemuFwCfgS3Lib/DxeQemuFwCfgS3LibFwCfg.inf |  46 ++
>>  OvmfPkg/Library/QemuFwCfgS3Lib/PeiQemuFwCfgS3LibFwCfg.inf |  44 ++
>>  OvmfPkg/Library/QemuFwCfgS3Lib/QemuFwCfgS3Base.c  | 109 +++
>>  OvmfPkg/Library/QemuFwCfgS3Lib/QemuFwCfgS3BasePei.c   | 227 
>> ++
>>  OvmfPkg/Library/QemuFwCfgS3Lib/QemuFwCfgS3Dxe.c 

Re: [edk2] DxeCore assert during initialization

[Ard Biesheuvel]

On 23 February 2017 at 17:16, Marcin Wojtas  wrote:
> Hi,
>
> I use Marvell Armada70x0 from mainline OpenPlatformPkg. After updating
> baseline to newest tianocore master branch it turned out that the
> platform fail to boot due to following assert:
>
> /home/mw/git/edk2/Build/Armada70x0/DEBUG_GCC48/AARCH64/ArmPlatformPkg/PrePi/PeiMPCore/DEBUG/ArmPlatformPrePiMPCore.dll
> 0x1800
> add-symbol-file
> /home/mw/git/edk2/Build/Armada70x0/DEBUG_GCC48/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll
> 0x3F534800
> Loading DxeCore at 0x003F534000 EntryPoint=0x003F534800
>
> ASSERT_EFI_ERROR (Status = Invalid Parameter)
> ASSERT [DxeCore]
> /home/mw/git/edk2/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c(523):
> !EFI_ERROR (Status)
>
> I bisected edk2 master branch and confirmed that the problem appeared
> with commit dc4c770763d0 ("BaseTools: add error check for Macro usage
> in the INF file").
>
> There are no errors, nor warnings during BaseTool and platform builds.
> Is it a known problem? Any idea about possible root cause?
>

Already fixed in
1d8cebf91040 BaseTools: Fix the regression issue caused by commit dc4c77

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

[edk2] DxeCore assert during initialization

[Marcin Wojtas]

Hi,

I use Marvell Armada70x0 from mainline OpenPlatformPkg. After updating
baseline to newest tianocore master branch it turned out that the
platform fail to boot due to following assert:

/home/mw/git/edk2/Build/Armada70x0/DEBUG_GCC48/AARCH64/ArmPlatformPkg/PrePi/PeiMPCore/DEBUG/ArmPlatformPrePiMPCore.dll
0x1800
add-symbol-file
/home/mw/git/edk2/Build/Armada70x0/DEBUG_GCC48/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll
0x3F534800
Loading DxeCore at 0x003F534000 EntryPoint=0x003F534800

ASSERT_EFI_ERROR (Status = Invalid Parameter)
ASSERT [DxeCore]
/home/mw/git/edk2/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c(523):
!EFI_ERROR (Status)

I bisected edk2 master branch and confirmed that the problem appeared
with commit dc4c770763d0 ("BaseTools: add error check for Macro usage
in the INF file").

There are no errors, nor warnings during BaseTool and platform builds.
Is it a known problem? Any idea about possible root cause?

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

Re: [edk2] [PATCH 00/12] ArmVirtPkg, OvmfPkg: factor out QemuFwCfgS3Lib

[Jordan Justen]

On 2017-02-22 17:48:02, Laszlo Ersek wrote:
> The new QemuFwCfgS3Lib class has two goals:
> 
> (a) to query whether S3 support was enabled on the QEMU command line,
> 
> (b) to save fw_cfg DMA operations that are to be replayed at S3 resume
> time, and more easily for the programmer than hacking Boot Script
> opcodes manually.
> 
> Patches #1 through #5 introduce the new library class, with Base Null,
> PEI fw_cfg, and DXE fw_cfg instances, covering goal (a) in both
> ArmVirtPkg and OvmfPkg.
> 
> Patch #6 retires QemuFwCfgS3Enabled() from QemuFwCfgLib (including
> library class and all instances), and switches all client modules to
> QemuFwCfgS3Lib. This separates S3 concerns from QemuFwCfgLib.

1-6 Reviewed-by: Jordan Justen 

> Patches #7 through #10 cover goal (b) for all three library instances
> (at levels of support that are appropriate for each, of course).
> 
> Patches #11 and #12 put the new library class to use in
> OvmfPkg/SmmControl2Dxe and OvmfPkg/AcpiPlatformDxe, eliminating such
> ACPI S3 Boot Script opcode hacking that is related to fw_cfg. (For
> OvmfPkg/SmmControl2Dxe, that's "most of it", for
> OvmfPkg/AcpiPlatformDxe, it's "all of it".)
> 
> I tested:
> - ArmVirtQemu boot,
> - OVMF boot without SMM, with S3 enabled and disabled, using a Linux
>   guest (and when S3 was enabled, I exercised it),
> - OVMF boot with SMM, with S3 enabled and disabled, using Linux and
>   Windows guests,
>   - and whenever S3 was enabled, I exercised it
>   - and in the Windows guest, I tested VMGENID / WRITE_POINTER too.
> 
> The diffstat looks scary, but it's due to comments, I promise.
> 
> Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=394
> Repo: https://github.com/lersek/edk2.git
> Branch:   fw_cfg_s3
> 
> NOTE: if you want to fetch & test the branch, you'll have to revert
> recent commit dc4c770763d0 ("BaseTools: add error check for Macro usage
> in the INF file", 2017-02-20) on top. It causes BaseTools to mis-build
> OVMF. I reported the regression on the list already, in that patch's
> thread.
> 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> 
> Thanks
> Laszlo
> 
> Laszlo Ersek (12):
>   OvmfPkg: introduce QemuFwCfgS3Lib class
>   OvmfPkg/QemuFwCfgS3Lib: add initial Base Null library instance
>   OvmfPkg/QemuFwCfgS3Lib: add initial PEI and DXE fw_cfg library
> instances
>   ArmVirtPkg: resolve QemuFwCfgS3Lib
>   OvmfPkg: resolve QemuFwCfgS3Lib
>   ArmVirtPkg, OvmfPkg: retire QemuFwCfgS3Enabled() from QemuFwCfgLib
>   OvmfPkg/QemuFwCfgS3Lib: add boot script opcode generation APIs to
> libclass
>   OvmfPkg/QemuFwCfgS3Lib: implement opcode APIs for Base Null instance
>   OvmfPkg/QemuFwCfgS3Lib: implement opcode APIs for PEI fw_cfg instance
>   OvmfPkg/QemuFwCfgS3Lib: implement opcode APIs for DXE fw_cfg instance
>   OvmfPkg/SmmControl2Dxe: save fw_cfg boot script with QemuFwCfgS3Lib
>   OvmfPkg/AcpiPlatformDxe: save fw_cfg boot script with QemuFwCfgS3Lib
> 
>  ArmVirtPkg/ArmVirtQemu.dsc|   1 +
>  ArmVirtPkg/ArmVirtQemuKernel.dsc  |   1 +
>  ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c|  17 -
>  OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h|   2 +-
>  OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf   |   2 +-
>  OvmfPkg/AcpiPlatformDxe/BootScript.c  | 262 
> ++-
>  OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c   |   8 +
>  OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpiPlatformDxe.inf  |   2 +-
>  OvmfPkg/Include/Library/QemuFwCfgLib.h|  14 -
>  OvmfPkg/Include/Library/QemuFwCfgS3Lib.h  | 357 
> +
>  OvmfPkg/Library/LockBoxLib/LockBoxDxe.c   |   1 +
>  OvmfPkg/Library/LockBoxLib/LockBoxDxeLib.inf  |   1 +
>  OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h  |   1 +
>  OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf |   1 +
>  OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c   |  28 -
>  OvmfPkg/Library/QemuFwCfgS3Lib/BaseQemuFwCfgS3LibNull.inf |  43 ++
>  OvmfPkg/Library/QemuFwCfgS3Lib/DxeQemuFwCfgS3LibFwCfg.inf |  46 ++
>  OvmfPkg/Library/QemuFwCfgS3Lib/PeiQemuFwCfgS3LibFwCfg.inf |  44 ++
>  OvmfPkg/Library/QemuFwCfgS3Lib/QemuFwCfgS3Base.c  | 109 +++
>  OvmfPkg/Library/QemuFwCfgS3Lib/QemuFwCfgS3BasePei.c   | 227 
> ++
>  OvmfPkg/Library/QemuFwCfgS3Lib/QemuFwCfgS3Dxe.c   | 791 
> 
>  OvmfPkg/Library/QemuFwCfgS3Lib/QemuFwCfgS3Pei.c   |  85 +++
>  OvmfPkg/Library/QemuFwCfgS3Lib/QemuFwCfgS3PeiDxe.c|  48 ++
>  OvmfPkg/OvmfPkg.dec   |   4 +
>  OvmfPkg/OvmfPkgIa32.dsc   |   3 +
>  OvmfPkg/OvmfPkgIa32X64.dsc|

Re: [edk2] [PATCH 1/2] ArmPkg: remove DebugUncachedMemoryAllocationLib

[Laszlo Ersek]

On 02/23/17 16:48, Ard Biesheuvel wrote:
> The debug implementation of the UncachedMemoryAllocationLib library
> class relies on the creation of an uncached alias of a memory range,
> while keeping the original cached mapping, but with read-only attributes
> to trap inadvertent write accesses.
> 
> This is not a terribly good idea, given that the ARM architecture does
> not allow mismatched attributes, and so creating them deliberately is
> not something we should encourage by doing it in reference code.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmPkg/ArmPkg.dsc
> |   1 -
>  
> ArmPkg/Library/DebugUncachedMemoryAllocationLib/DebugUncachedMemoryAllocationLib.c
>| 656 
>  
> ArmPkg/Library/DebugUncachedMemoryAllocationLib/DebugUncachedMemoryAllocationLib.inf
>  |  47 --
>  ArmVirtPkg/ArmVirt.dsc.inc   
> |   2 -
>  BeagleBoardPkg/BeagleBoardPkg.dsc
> |   1 -
>  Omap35xxPkg/Omap35xxPkg.dsc  
> |   3 +-
>  6 files changed, 1 insertion(+), 709 deletions(-)

Acked-by: Laszlo Ersek 


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

Re: [edk2] [PATCH] OvmfPkg/XenBusDxe: Use EFIAPI for XenStoreVSPrint

[Laszlo Ersek]

On 02/23/17 13:57, Gao, Liming wrote:
> Reviewed-by: Liming Gao 

Reviewed-by: Laszlo Ersek 

Committed & pushed as c5c9e7e298ed.

Thanks!
Laszlo

> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Anthony PERARD
> Sent: Thursday, February 23, 2017 8:42 PM
> To: edk2-devel@lists.01.org
> Cc: Anthony PERARD ; Justen, Jordan L 
> ; Laszlo Ersek 
> Subject: [edk2] [PATCH] OvmfPkg/XenBusDxe: Use EFIAPI for XenStoreVSPrint
> 
> ... because this function use VA_COPY.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Anthony PERARD 
> ---
>  OvmfPkg/XenBusDxe/XenStore.h | 1 +
>  OvmfPkg/XenBusDxe/XenStore.c | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/OvmfPkg/XenBusDxe/XenStore.h b/OvmfPkg/XenBusDxe/XenStore.h
> index c9d4c6509a..33bb647f66 100644
> --- a/OvmfPkg/XenBusDxe/XenStore.h
> +++ b/OvmfPkg/XenBusDxe/XenStore.h
> @@ -209,6 +209,7 @@ XenStoreSPrint (
> indicating the type of write failure.
>  **/
>  XENSTORE_STATUS
> +EFIAPI
>  XenStoreVSPrint (
>IN CONST XENSTORE_TRANSACTION *Transaction,
>IN CONST CHAR8   *DirectoryPath,
> diff --git a/OvmfPkg/XenBusDxe/XenStore.c b/OvmfPkg/XenBusDxe/XenStore.c
> index 76b6e297ef..6812e1078c 100644
> --- a/OvmfPkg/XenBusDxe/XenStore.c
> +++ b/OvmfPkg/XenBusDxe/XenStore.c
> @@ -1304,6 +1304,7 @@ XenStoreTransactionEnd (
>  }
>  
>  XENSTORE_STATUS
> +EFIAPI
>  XenStoreVSPrint (
>IN CONST XENSTORE_TRANSACTION *Transaction,
>IN CONST CHAR8   *DirectoryPath,
> 

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

[edk2] [PATCH 2/2] ArmPkg/CpuDxe: remove VirtualUncachedPages protocol and implementation

[Ard Biesheuvel]

Virtual uncached pages are simply pages that are aliased using mismatched
attributes, which is not allowed by the ARM architecture. So remove the
protocol and its implementation.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmPkg/ArmPkg.dec  |  3 -
 ArmPkg/Drivers/CpuDxe/CpuDxe.c |  1 -
 ArmPkg/Drivers/CpuDxe/CpuDxe.h |  3 -
 ArmPkg/Drivers/CpuDxe/CpuDxe.inf   |  1 -
 ArmPkg/Drivers/CpuDxe/CpuMmuCommon.c   | 70 
 ArmPkg/Include/Protocol/VirtualUncachedPages.h | 60 -
 6 files changed, 138 deletions(-)

diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec
index 8e9cf199becc..4fd7a5be5158 100644
--- a/ArmPkg/ArmPkg.dec
+++ b/ArmPkg/ArmPkg.dec
@@ -52,9 +52,6 @@ [Ppis]
   ## Include/Ppi/ArmMpCoreInfo.h
   gArmMpCoreInfoPpiGuid = { 0x6847cc74, 0xe9ec, 0x4f8f, {0xa2, 0x9d, 0xab, 
0x44, 0xe7, 0x54, 0xa8, 0xfc} }
 
-[Protocols.common]
-  gVirtualUncachedPagesProtocolGuid = { 0xAD651C7D, 0x3C22, 0x4DBF, { 0x92, 
0xe8, 0x38, 0xa7, 0xcd, 0xae, 0x87, 0xb2 } }
-
 [PcdsFeatureFlag.common]
   gArmTokenSpaceGuid.PcdCpuDxeProduceDebugSupport|FALSE|BOOLEAN|0x0001
 
diff --git a/ArmPkg/Drivers/CpuDxe/CpuDxe.c b/ArmPkg/Drivers/CpuDxe/CpuDxe.c
index 7d328d096b1e..5aa5b874144a 100644
--- a/ArmPkg/Drivers/CpuDxe/CpuDxe.c
+++ b/ArmPkg/Drivers/CpuDxe/CpuDxe.c
@@ -253,7 +253,6 @@ CpuDxeInitialize (
   Status = gBS->InstallMultipleProtocolInterfaces (
 &mCpuHandle,
 &gEfiCpuArchProtocolGuid,   &mCpu,
-&gVirtualUncachedPagesProtocolGuid, &gVirtualUncachedPages,
 NULL
 );
 
diff --git a/ArmPkg/Drivers/CpuDxe/CpuDxe.h b/ArmPkg/Drivers/CpuDxe/CpuDxe.h
index 80c305d53dd1..a00fc3064362 100644
--- a/ArmPkg/Drivers/CpuDxe/CpuDxe.h
+++ b/ArmPkg/Drivers/CpuDxe/CpuDxe.h
@@ -35,7 +35,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 
@@ -169,6 +168,4 @@ SetGcdMemorySpaceAttributes (
   IN UINT64  Attributes
   );
 
-extern VIRTUAL_UNCACHED_PAGES_PROTOCOL  gVirtualUncachedPages;
-
 #endif // __CPU_DXE_ARM_EXCEPTION_H__
diff --git a/ArmPkg/Drivers/CpuDxe/CpuDxe.inf b/ArmPkg/Drivers/CpuDxe/CpuDxe.inf
index b31c994f43e2..d068e06803ed 100644
--- a/ArmPkg/Drivers/CpuDxe/CpuDxe.inf
+++ b/ArmPkg/Drivers/CpuDxe/CpuDxe.inf
@@ -61,7 +61,6 @@ [LibraryClasses]
 [Protocols]
   gEfiCpuArchProtocolGuid
   gEfiDebugSupportPeriodicCallbackProtocolGuid
-  gVirtualUncachedPagesProtocolGuid
 
 [Guids]
   gEfiDebugImageInfoTableGuid
diff --git a/ArmPkg/Drivers/CpuDxe/CpuMmuCommon.c 
b/ArmPkg/Drivers/CpuDxe/CpuMmuCommon.c
index 54d9b0163331..ebe593d1c325 100644
--- a/ArmPkg/Drivers/CpuDxe/CpuMmuCommon.c
+++ b/ArmPkg/Drivers/CpuDxe/CpuMmuCommon.c
@@ -211,73 +211,3 @@ CpuSetMemoryAttributes (
 return EFI_SUCCESS;
   }
 }
-
-EFI_STATUS
-EFIAPI
-CpuConvertPagesToUncachedVirtualAddress (
-  IN  VIRTUAL_UNCACHED_PAGES_PROTOCOL  *This,
-  IN  EFI_PHYSICAL_ADDRESS  Address,
-  IN  UINTN Length,
-  IN  EFI_PHYSICAL_ADDRESS  VirtualMask,
-  OUT UINT64   *Attributes OPTIONAL
-  )
-{
-  EFI_STATUS  Status;
-  EFI_GCD_MEMORY_SPACE_DESCRIPTOR GcdDescriptor;
-
-  if (Attributes != NULL) {
-Status = gDS->GetMemorySpaceDescriptor (Address, &GcdDescriptor);
-if (!EFI_ERROR (Status)) {
-  *Attributes = GcdDescriptor.Attributes;
-}
-  }
-
-  //
-  // Make this address range page fault if accessed. If it is a DMA buffer 
than this would
-  // be the PCI address. Code should always use the CPU address, and we will 
or in VirtualMask
-  // to that address.
-  //
-  Status = SetMemoryAttributes (Address, Length, EFI_MEMORY_RO, 0);
-  if (!EFI_ERROR (Status)) {
-Status = SetMemoryAttributes (Address | VirtualMask, Length, 
EFI_MEMORY_UC, VirtualMask);
-  }
-
-  DEBUG ((DEBUG_INFO | DEBUG_LOAD, 
"CpuConvertPagesToUncachedVirtualAddress()\nUnmapped 0x%08lx Mapped 0x%08lx 
0x%x bytes\n", Address, Address | VirtualMask, Length));
-
-  return Status;
-}
-
-
-EFI_STATUS
-EFIAPI
-CpuReconvertPages (
-  IN  VIRTUAL_UNCACHED_PAGES_PROTOCOL  *This,
-  IN  EFI_PHYSICAL_ADDRESS  Address,
-  IN  UINTN Length,
-  IN  EFI_PHYSICAL_ADDRESS  VirtualMask,
-  IN  UINT64Attributes
-  )
-{
-  EFI_STATUS  Status;
-
-  DEBUG ((DEBUG_INFO | DEBUG_LOAD, "CpuReconvertPages(%lx, %x, %lx, %lx)\n", 
Address, Length, VirtualMask, Attributes));
-
-  //
-  // Unmap the aliased Address
-  //
-  Status = SetMemoryAttributes (Address | VirtualMask, Length, EFI_MEMORY_RO, 
0);
-  if (!EFI_ERROR (Status)) {
-//
-// Restore atttributes
-//
-Status = SetMemoryAttributes (Address, Length, Attributes, 0);
-  }
-
-  return Status;
-}
-
-
-VIRTUAL_UNCACHED_PAGES_PROTOCOL  gVirtualUncachedPages = {
-  CpuConvertPagesToUnc

[edk2] [PATCH 1/2] ArmPkg: remove DebugUncachedMemoryAllocationLib

[Ard Biesheuvel]

The debug implementation of the UncachedMemoryAllocationLib library
class relies on the creation of an uncached alias of a memory range,
while keeping the original cached mapping, but with read-only attributes
to trap inadvertent write accesses.

This is not a terribly good idea, given that the ARM architecture does
not allow mismatched attributes, and so creating them deliberately is
not something we should encourage by doing it in reference code.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmPkg/ArmPkg.dsc  
  |   1 -
 
ArmPkg/Library/DebugUncachedMemoryAllocationLib/DebugUncachedMemoryAllocationLib.c
   | 656 
 
ArmPkg/Library/DebugUncachedMemoryAllocationLib/DebugUncachedMemoryAllocationLib.inf
 |  47 --
 ArmVirtPkg/ArmVirt.dsc.inc 
  |   2 -
 BeagleBoardPkg/BeagleBoardPkg.dsc  
  |   1 -
 Omap35xxPkg/Omap35xxPkg.dsc
  |   3 +-
 6 files changed, 1 insertion(+), 709 deletions(-)

diff --git a/ArmPkg/ArmPkg.dsc b/ArmPkg/ArmPkg.dsc
index 0db33eb865b1..1a490d23f7b5 100644
--- a/ArmPkg/ArmPkg.dsc
+++ b/ArmPkg/ArmPkg.dsc
@@ -112,7 +112,6 @@ [Components.common]
   ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
   ArmPkg/Library/DebugAgentSymbolsBaseLib/DebugAgentSymbolsBaseLib.inf
   ArmPkg/Library/DebugPeCoffExtraActionLib/DebugPeCoffExtraActionLib.inf
-  
ArmPkg/Library/DebugUncachedMemoryAllocationLib/DebugUncachedMemoryAllocationLib.inf
   ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLib.inf
   ArmPkg/Library/RvdPeCoffExtraActionLib/RvdPeCoffExtraActionLib.inf
   ArmPkg/Library/SemiHostingDebugLib/SemiHostingDebugLib.inf
diff --git 
a/ArmPkg/Library/DebugUncachedMemoryAllocationLib/DebugUncachedMemoryAllocationLib.c
 
b/ArmPkg/Library/DebugUncachedMemoryAllocationLib/DebugUncachedMemoryAllocationLib.c
deleted file mode 100644
index 00e01a905c85..
--- 
a/ArmPkg/Library/DebugUncachedMemoryAllocationLib/DebugUncachedMemoryAllocationLib.c
+++ /dev/null
@@ -1,656 +0,0 @@
-/** @file
-  Debug version of the UncachedMemoryAllocation lib that uses the 
VirtualUncachedPages
-  protocol, produced by the DXE CPU driver, to produce debuggable uncached 
memory buffers.
-
-  The DMA rules for EFI contain the concept of a PCI (DMA master) address for 
memory and
-  a CPU (C code) address for the memory buffer that don't have to be the same. 
 There seem to
-  be common errors out there with folks mixing up the two addresses.  This 
library causes
-  the PCI (DMA master) address to not be mapped into system memory so if the 
CPU (C code)
-  uses the wrong pointer it will generate a page fault. The CPU (C code) 
version of the buffer
-  has a virtual address that does not match the physical address. The virtual 
address has
-  PcdArmUncachedMemoryMask ored into the physical address.
-
-  Copyright (c) 2008 - 2010, Apple Inc. 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 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-#include 
-
-VOID *
-UncachedInternalAllocatePages (
-  IN EFI_MEMORY_TYPE  MemoryType,
-  IN UINTNPages
-  );
-
-VOID *
-UncachedInternalAllocateAlignedPages (
-  IN EFI_MEMORY_TYPE  MemoryType,
-  IN UINTNPages,
-  IN UINTNAlignment
-  );
-
-
-
-EFI_CPU_ARCH_PROTOCOL   *gDebugUncachedCpu;
-VIRTUAL_UNCACHED_PAGES_PROTOCOL *gVirtualUncachedPages;
-
-//
-// Assume all of memory has the same cache attributes, unless we do our magic
-//
-UINT64  gAttributes;
-
-typedef struct {
-  VOID*Buffer;
-  VOID*Allocation;
-  UINTN   Pages;
-  LIST_ENTRY  Link;
-} FREE_PAGE_NODE;
-
-LIST_ENTRY  mPageList = INITIALIZE_LIST_HEAD_VARIABLE (mPageList);
-
-VOID
-AddPagesToList (
-  IN VOID   *Buffer,
-  IN VOID   *Allocation,
-  UINTN Pages
-  )
-{
-  FREE_PAGE_NODE  *NewNode;
-
-  NewNode = AllocatePool (sizeof (LIST_ENTRY));
-  if (NewNode == NULL) {
-ASSERT (FALSE);
-return;
-  }
-
-  NewNode->Buffer = Buffer;
-  NewNode->Allocation = Allocation;
-  NewNode->Pages  = Pages;
-
-  InsertTailList (&mPageList, &NewNode->Link);
-}
-
-
-VOID
-RemovePagesFromList (
-  IN VOID   *Buffer,
-  OUT VOID  **Allocation,
-  OUT UINTN *Pages
-  )
-{
-  LIST_ENTRY  *Link;
-  FREE_PAGE_NODE  *OldNode;
-
-  *Allocation = NULL;
-  *Pages = 0;
-
-  for (Li

Re: [edk2] Tcg2Pei.efi assert after sync to latest trunk

[Gao, Liming]

This is BaseTools regression issue. It is fixed today. Please try it on 
tomorrow. 

Thanks
Liming
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of wang 
xiaofeng
Sent: Thursday, February 23, 2017 7:21 PM
To: edk2-devel@lists.01.org
Subject: [edk2] Tcg2Pei.efi assert after sync to latest trunk

Hi All,
   I just updated to latest edk2 trunk this afternoon , and meet the following 
error:


Loading PEIM at 0x8FB1000 EntryPoint=0x8FB13CF Tcg2Pei.efi
PROGRESS CODE: V03020002 I0
WARNING: Tpm2RegisterTpm2DeviceLib - does not support 
286BF25A-C2C3-408C-B3B4-25E6758B7317 registration
WARNING: Tpm2RegisterTpm2DeviceLib - does not support 
286BF25A-C2C3-408C-B3B4-25E6758B7317 registration
Hash Interface (2AE9D80F-3FB2-4095-B7B1-E93157B946B6) has been registered
ASSERT_EFI_ERROR (Status = Already started)
ASSERT [Tcg2Pei] 
e:\code\cl819sync\Build\SariPlatformPkg\DEBUG_VS2013x86\IA32\SecurityPkg\Tcg\Tcg2Pei\Tcg2Pei\DEBUG\AutoGen.c(466):
 !EFI_ERROR (Status)


While AutoGen.c(466) have the following code:


  Status = HashInstanceLibSha1Constructor ();
  ASSERT_EFI_ERROR (Status);
  Status = HashInstanceLibSha1Constructor ();
  ASSERT_EFI_ERROR (Status); <-asset here


gEfiTpmDeviceInstanceTpm20DtpmGuid = { 0x286bf25a, 0xc2c3, 0x408c, { 0xb3, 
0xb4, 0x25, 0xe6, 0x75, 0x8b, 0x73, 0x17 } }


  So anyone meet the same assert before ?  Thanks in advance !

___
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 0/4] Fix runtime issue in XenBusDxe when compiled with GCC5

[Gao, Liming]

Laszlo:
  
- VariableGetBestLanguage() 
[SecurityPkg/VariableAuthenticated/EsalVariableDxeSal/Variable.c]
[Liming] It is for IPF arch only. We don't support IPF any longer. So, keep it 
as-is
- SmmBootScriptWrite()  [Vlv2TbltDevicePkg/PlatformSmm/SmmScriptSave.c]
[Liming] I am not sure MinnowMax platform supports GCC build or not. If it 
supports GCC build, I agree to fix it. 

Thanks
Liming
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo 
Ersek
Sent: Thursday, February 23, 2017 6:19 PM
To: Gao, Liming ; Anthony PERARD 
; Zhang, Chao B ; Wei, David 
; Guo, Mang 
Cc: Justen, Jordan L ; edk2-de...@ml01.01.org; Ard 
Biesheuvel 
Subject: Re: [edk2] [PATCH 0/4] Fix runtime issue in XenBusDxe when compiled 
with GCC5

On 02/22/17 09:54, Gao, Liming wrote:
> Laszlo:
> In edk2, I find the several functions with VA_LIST have no EFIAPI.
> They may use VA_ARG() or call other functions, but they don't use
> VA_COPY(). In Base.h, VA_ARG() is defined as __builtin_va_arg(),
> which is same to native one.

You are right; apparently __builtin_va_arg() works with __builtin_ms_va_list 
and __builtin_va_list alike.

However, as you say,

> VA_COPY() is defined as
> __builtin_ms_va_copy(). So, I also think this is MS ABI request. That
> means only if the function implementation uses VA_START(),VA_END() or
> VA_COPY(), it must be declared with EFIAPI.

- __builtin_va_start / __builtin_ms_va_start,
- __builtin_va_end / __builtin_ms_va_end,
- __builtin_va_copy / __builtin_ms_va_copy

must be matched to __builtin_va_list vs. __builtin_ms_va_list.

> 
> MdePkg\Library\BasePrintLib\PrintLibInternal.c BasePrintLibSPrintMarker()
> ShellPkg\Library\UefiShellLib\UefiShellLib.c InternalShellPrintWorker()

Yes, you are right -- when looking for functions that should be made EFIAPI, we 
shouldn't search for VA_LIST, but VA_START|VA_END|VA_COPY.

Thanks for the correction.

The following command is a good start:

  git grep -E -n '\<(VA_START|VA_END|VA_COPY)\>|^[A-Za-z0-9_]' \
  | grep -E -B 3 '\<(VA_START|VA_END|VA_COPY)\>'

I just went over the output (it was gruesome), and -- outside of 
EdkCompatibilityPkg -- I indeed found only a handful of affected functions:

- XenStoreVSPrint() [OvmfPkg/XenBusDxe/XenStore.c]
- VariableGetBestLanguage() 
[SecurityPkg/VariableAuthenticated/EsalVariableDxeSal/Variable.c]
- SmmBootScriptWrite()  [Vlv2TbltDevicePkg/PlatformSmm/SmmScriptSave.c]

Anthony, can you please submit the patch for XenStoreVSPrint()?

Chao Zhang, can you please submit a patch for VariableGetBestLanguage()?

David Wei or Mang Guo, can one of you guys please submit a patch for 
SmmBootScriptWrite()?

Thanks,
Laszlo


> 
> Thanks
> Liming
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Laszlo Ersek
>> Sent: Wednesday, February 22, 2017 3:03 AM
>> To: Anthony PERARD 
>> Cc: Ard Biesheuvel ; Justen, Jordan L
>> ; edk2-de...@ml01.01.org; Gao, Liming
>> 
>> Subject: Re: [edk2] [PATCH 0/4] Fix runtime issue in XenBusDxe when
>> compiled with GCC5
>>
>> On 02/21/17 18:53, Anthony PERARD wrote:
>>> On Tue, Feb 21, 2017 at 06:07:15PM +0100, Laszlo Ersek wrote:
 CC Rebecca & Konrad

 On 02/21/17 17:39, Anthony PERARD wrote:
>>
>> [snip]
>>
> So, should I add EFIAPI to XenStoreVSPrint, as it is using VA_COPY?
>

 Hm, please help me jog my memory...

 If I remember correctly, this is still a GCC bug, one that we suppressed 
 for
>> gcc-6.2 with your patch as follows:
>>>
>>> Yes.
>>>
> commit 432f1d83f77acf92d52ef18d2cee6dbf7c5b9b86
> Author: Anthony PERARD 
> Date:   Tue Dec 6 12:03:25 2016 +
>
> OvmfPkg/build.sh: Use GCC49 toolchains with GCC 6.[0-2]
>
> The goal of the patch is to avoid using -flto with GCC 6.0 to 6.2.
>
> This is to workaround a GCC bug:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70955
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Anthony PERARD 
> Reviewed-by: Laszlo Ersek 
> Regression-tested-by: Laszlo Ersek 
>
> diff --git a/OvmfPkg/build.sh b/OvmfPkg/build.sh
> index 95fe8fb07647..b6e936056ca0 100755
> --- a/OvmfPkg/build.sh
> +++ b/OvmfPkg/build.sh
> @@ -102,7 +102,7 @@ case `uname` in
>4.8.*)
>  TARGET_TOOLS=GCC48
>  ;;
> -  4.9.*)
> +  4.9.*|6.[0-2].*)
>  TARGET_TOOLS=GCC49
>  ;;
>*)

 Do I understand correctly that the gcc bug has not been fixed in
 gcc-6.3, and -- because we don't suppress it for gcc-6.3 as the
 above expression does not match -- it causes problems again?
>>>
>>> The bug describe in the GCC bugzilla is probably fix, but the
>>> test-case does not make use of __builtin_ms_va_copy.
>>
>> :/
>>
>>>
 You also mention gcc-5.4 as problematic. I think we haven't
 received s

Re: [edk2] [PATCH] OvmfPkg/XenBusDxe: Use EFIAPI for XenStoreVSPrint

[Gao, Liming]

Reviewed-by: Liming Gao 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Anthony 
PERARD
Sent: Thursday, February 23, 2017 8:42 PM
To: edk2-devel@lists.01.org
Cc: Anthony PERARD ; Justen, Jordan L 
; Laszlo Ersek 
Subject: [edk2] [PATCH] OvmfPkg/XenBusDxe: Use EFIAPI for XenStoreVSPrint

... because this function use VA_COPY.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD 
---
 OvmfPkg/XenBusDxe/XenStore.h | 1 +
 OvmfPkg/XenBusDxe/XenStore.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/OvmfPkg/XenBusDxe/XenStore.h b/OvmfPkg/XenBusDxe/XenStore.h
index c9d4c6509a..33bb647f66 100644
--- a/OvmfPkg/XenBusDxe/XenStore.h
+++ b/OvmfPkg/XenBusDxe/XenStore.h
@@ -209,6 +209,7 @@ XenStoreSPrint (
indicating the type of write failure.
 **/
 XENSTORE_STATUS
+EFIAPI
 XenStoreVSPrint (
   IN CONST XENSTORE_TRANSACTION *Transaction,
   IN CONST CHAR8   *DirectoryPath,
diff --git a/OvmfPkg/XenBusDxe/XenStore.c b/OvmfPkg/XenBusDxe/XenStore.c
index 76b6e297ef..6812e1078c 100644
--- a/OvmfPkg/XenBusDxe/XenStore.c
+++ b/OvmfPkg/XenBusDxe/XenStore.c
@@ -1304,6 +1304,7 @@ XenStoreTransactionEnd (
 }
 
 XENSTORE_STATUS
+EFIAPI
 XenStoreVSPrint (
   IN CONST XENSTORE_TRANSACTION *Transaction,
   IN CONST CHAR8   *DirectoryPath,
-- 
Anthony PERARD

___
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 0/4] Fix runtime issue in XenBusDxe when compiled with GCC5

[Anthony PERARD]

On Thu, Feb 23, 2017 at 11:19:03AM +0100, Laszlo Ersek wrote:
> On 02/22/17 09:54, Gao, Liming wrote:
> > Laszlo:
> > In edk2, I find the several functions with VA_LIST have no EFIAPI.
> > They may use VA_ARG() or call other functions, but they don't use
> > VA_COPY(). In Base.h, VA_ARG() is defined as __builtin_va_arg(),
> > which is same to native one.
> 
> You are right; apparently __builtin_va_arg() works with __builtin_ms_va_list 
> and __builtin_va_list alike.
> 
> However, as you say,
> 
> > VA_COPY() is defined as
> > __builtin_ms_va_copy(). So, I also think this is MS ABI request. That
> > means only if the function implementation uses VA_START(),VA_END() or
> > VA_COPY(), it must be declared with EFIAPI.
> 
> - __builtin_va_start / __builtin_ms_va_start,
> - __builtin_va_end / __builtin_ms_va_end,
> - __builtin_va_copy / __builtin_ms_va_copy
> 
> must be matched to __builtin_va_list vs. __builtin_ms_va_list.
> 
> > 
> > MdePkg\Library\BasePrintLib\PrintLibInternal.c BasePrintLibSPrintMarker()
> > ShellPkg\Library\UefiShellLib\UefiShellLib.c InternalShellPrintWorker()
> 
> Yes, you are right -- when looking for functions that should be made EFIAPI, 
> we shouldn't search for VA_LIST, but VA_START|VA_END|VA_COPY.
> 
> Thanks for the correction.
> 
> The following command is a good start:
> 
>   git grep -E -n '\<(VA_START|VA_END|VA_COPY)\>|^[A-Za-z0-9_]' \
>   | grep -E -B 3 '\<(VA_START|VA_END|VA_COPY)\>'
> 
> I just went over the output (it was gruesome), and -- outside of 
> EdkCompatibilityPkg -- I indeed found only a handful of affected functions:
> 
> - XenStoreVSPrint() [OvmfPkg/XenBusDxe/XenStore.c]
> - VariableGetBestLanguage() 
> [SecurityPkg/VariableAuthenticated/EsalVariableDxeSal/Variable.c]
> - SmmBootScriptWrite()  [Vlv2TbltDevicePkg/PlatformSmm/SmmScriptSave.c]
> 
> Anthony, can you please submit the patch for XenStoreVSPrint()?

Done.

Thanks,

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

[edk2] [PATCH] OvmfPkg/XenBusDxe: Use EFIAPI for XenStoreVSPrint

[Anthony PERARD]

... because this function use VA_COPY.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD 
---
 OvmfPkg/XenBusDxe/XenStore.h | 1 +
 OvmfPkg/XenBusDxe/XenStore.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/OvmfPkg/XenBusDxe/XenStore.h b/OvmfPkg/XenBusDxe/XenStore.h
index c9d4c6509a..33bb647f66 100644
--- a/OvmfPkg/XenBusDxe/XenStore.h
+++ b/OvmfPkg/XenBusDxe/XenStore.h
@@ -209,6 +209,7 @@ XenStoreSPrint (
indicating the type of write failure.
 **/
 XENSTORE_STATUS
+EFIAPI
 XenStoreVSPrint (
   IN CONST XENSTORE_TRANSACTION *Transaction,
   IN CONST CHAR8   *DirectoryPath,
diff --git a/OvmfPkg/XenBusDxe/XenStore.c b/OvmfPkg/XenBusDxe/XenStore.c
index 76b6e297ef..6812e1078c 100644
--- a/OvmfPkg/XenBusDxe/XenStore.c
+++ b/OvmfPkg/XenBusDxe/XenStore.c
@@ -1304,6 +1304,7 @@ XenStoreTransactionEnd (
 }
 
 XENSTORE_STATUS
+EFIAPI
 XenStoreVSPrint (
   IN CONST XENSTORE_TRANSACTION *Transaction,
   IN CONST CHAR8   *DirectoryPath,
-- 
Anthony PERARD

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

Re: [edk2] [RFC PATCH 0/4] RFC: increased memory protection

[Yao, Jiewen]

Sounds great.
I look forward to your V2.

Thank you
Yao Jiewen

From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: Thursday, February 23, 2017 7:39 PM
To: Yao, Jiewen 
Cc: edk2-devel@lists.01.org; af...@apple.com; leif.lindh...@linaro.org; Kinney, 
Michael D ; Gao, Liming ; 
ler...@redhat.com; Tian, Feng ; Zeng, Star 

Subject: Re: [RFC PATCH 0/4] RFC: increased memory protection

On 23 February 2017 at 08:52, Yao, Jiewen 
mailto:jiewen@intel.com>> wrote:
> HI Ard
>
> Thanks to protect more. :-)
>

Of course! This is a very important topic for me.

> We did consider the idea to remove EXEC attribute for Data page before. But
> we got compatibility issue.
>
>
>
> We documented some gaps in white paper -
>
> https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Memory_Map_And_Practices_in_UEFI_BIOS_V2.pdf
>

Thanks for the link.

> I am glad that some limitation is already resolved or we have solution to
> mitigate it. But there is still some other need consideration.
>
>
>
> 1)  We observe some 3rd part code allocating data page for code. – That
> is hardest part. (OS limitation #12)
>
> We might also need consider ReservedMemory/AcpiNvs. There might be code
> there, too. (Firmware limitation #6 and #7).
>

OK

> If we want to apply the protection, we might need define a new PCD to
> disable the data protection for compatibility consideration.
>
>
>
> 2)  About DxeCore in data page. (Firmware limitation #4)
>
> I am thinking if we can fix LoadFile implementation in PeiCore.
>
>
>
> MdeModulePkg\Core\Pei\Image\Image.c:
>
> LoadAndRelocatePeCoffImage()
>
> {
>
> ImageContext.ImageAddress = (EFI_PHYSICAL_ADDRESS)(UINTN) AllocatePages
> (EFI_SIZE_TO_PAGES ((UINT32) AlignImageSize));
>
> }
>
>
>
> AllocatePages means to allocate data page.
>
> I think we should use PeiAllocatePages(EfiBootServicesCode,
> EFI_SIZE_TO_PAGES ((UINT32) AlignImageSize), &ImageContext.ImageAddress);
>
>
>
> Does that fix the problem?
>

Using PeiServicesAllocatePage() in the way that you describe does
indeed remove the problem, so I will use that instead.

> 3)  I am not worried about EBC. That can be handled separately.
>

OK


> 4)  I did not find patch 4/4 in my mail box. Maybe it is lost due to
> some unknown reason. Would you please send it again?
>

https://lists.01.org/pipermail/edk2-devel/2017-February/007685.html

I will send out a v2 shortly which, as you suggest, moves the handling
to DXE core. The only problem is that ARM's SyncCacheConfig() removes
the noexec attributes again, so I need to fix that first. Then, the
arch CPU protocol installation event can iterate over the memory map
to set the permissions according to a policy PCD

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

Re: [edk2] [RFC PATCH 0/4] RFC: increased memory protection

[Ard Biesheuvel]

On 23 February 2017 at 08:52, Yao, Jiewen  wrote:
> HI Ard
>
> Thanks to protect more. :-)
>

Of course! This is a very important topic for me.

> We did consider the idea to remove EXEC attribute for Data page before. But
> we got compatibility issue.
>
>
>
> We documented some gaps in white paper -
>
> https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Memory_Map_And_Practices_in_UEFI_BIOS_V2.pdf
>

Thanks for the link.

> I am glad that some limitation is already resolved or we have solution to
> mitigate it. But there is still some other need consideration.
>
>
>
> 1)  We observe some 3rd part code allocating data page for code. – That
> is hardest part. (OS limitation #12)
>
> We might also need consider ReservedMemory/AcpiNvs. There might be code
> there, too. (Firmware limitation #6 and #7).
>

OK

> If we want to apply the protection, we might need define a new PCD to
> disable the data protection for compatibility consideration.
>
>
>
> 2)  About DxeCore in data page. (Firmware limitation #4)
>
> I am thinking if we can fix LoadFile implementation in PeiCore.
>
>
>
> MdeModulePkg\Core\Pei\Image\Image.c:
>
> LoadAndRelocatePeCoffImage()
>
> {
>
> ImageContext.ImageAddress = (EFI_PHYSICAL_ADDRESS)(UINTN) AllocatePages
> (EFI_SIZE_TO_PAGES ((UINT32) AlignImageSize));
>
> }
>
>
>
> AllocatePages means to allocate data page.
>
> I think we should use PeiAllocatePages(EfiBootServicesCode,
> EFI_SIZE_TO_PAGES ((UINT32) AlignImageSize), &ImageContext.ImageAddress);
>
>
>
> Does that fix the problem?
>

Using PeiServicesAllocatePage() in the way that you describe does
indeed remove the problem, so I will use that instead.

> 3)  I am not worried about EBC. That can be handled separately.
>

OK


> 4)  I did not find patch 4/4 in my mail box. Maybe it is lost due to
> some unknown reason. Would you please send it again?
>

https://lists.01.org/pipermail/edk2-devel/2017-February/007685.html

I will send out a v2 shortly which, as you suggest, moves the handling
to DXE core. The only problem is that ARM's SyncCacheConfig() removes
the noexec attributes again, so I need to fix that first. Then, the
arch CPU protocol installation event can iterate over the memory map
to set the permissions according to a policy PCD

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

Re: [edk2] [RFC PATCH 0/4] RFC: increased memory protection

[Yao, Jiewen]

One thing I am not clear is that why we choose Cpu driver to set the attribute, 
instead of DxeCore.

I think DxeCore might be a better place to perform such protection.

Thank you
Yao Jiewen


From: Yao, Jiewen
Sent: Thursday, February 23, 2017 4:52 PM
To: Ard Biesheuvel ; edk2-devel@lists.01.org; 
af...@apple.com; leif.lindh...@linaro.org; Kinney, Michael D 
; Gao, Liming 
Cc: ler...@redhat.com; Tian, Feng ; Zeng, Star 
; Yao, Jiewen 
Subject: RE: [RFC PATCH 0/4] RFC: increased memory protection

HI Ard
Thanks to protect more. :-)
We did consider the idea to remove EXEC attribute for Data page before. But we 
got compatibility issue.

We documented some gaps in white paper -
https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Memory_Map_And_Practices_in_UEFI_BIOS_V2.pdf

I am glad that some limitation is already resolved or we have solution to 
mitigate it. But there is still some other need consideration.


1)  We observe some 3rd part code allocating data page for code. - That is 
hardest part. (OS limitation #12)
We might also need consider ReservedMemory/AcpiNvs. There might be code there, 
too. (Firmware limitation #6 and #7).

If we want to apply the protection, we might need define a new PCD to disable 
the data protection for compatibility consideration.


2)  About DxeCore in data page. (Firmware limitation #4)
I am thinking if we can fix LoadFile implementation in PeiCore.

MdeModulePkg\Core\Pei\Image\Image.c:
LoadAndRelocatePeCoffImage()
{
ImageContext.ImageAddress = (EFI_PHYSICAL_ADDRESS)(UINTN) AllocatePages 
(EFI_SIZE_TO_PAGES ((UINT32) AlignImageSize));
}

AllocatePages means to allocate data page.
I think we should use PeiAllocatePages(EfiBootServicesCode, EFI_SIZE_TO_PAGES 
((UINT32) AlignImageSize), &ImageContext.ImageAddress);

Does that fix the problem?



3)  I am not worried about EBC. That can be handled separately.


4)  I did not find patch 4/4 in my mail box. Maybe it is lost due to some 
unknown reason. Would you please send it again?


Thank you
Yao Jiewen


> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Thursday, February 23, 2017 2:25 AM
> To: edk2-devel@lists.01.org; 
> af...@apple.com; 
> leif.lindh...@linaro.org; Kinney,
> Michael D mailto:michael.d.kin...@intel.com>>; 
> Gao, Liming mailto:liming@intel.com>>;
> Yao, Jiewen mailto:jiewen@intel.com>>
> Cc: ler...@redhat.com; Tian, Feng 
> mailto:feng.t...@intel.com>>; Zeng, Star
> mailto:star.z...@intel.com>>; Ard Biesheuvel 
> mailto:ard.biesheu...@linaro.org>>
> Subject: [RFC PATCH 0/4] RFC: increased memory protection
>
> Hello all,
>
> This is a proof of concept implementation that removes all executable
> permissions from writable memory regions, which greatly enhances security.
> It is based on Jiewen's recent work, which is a step in the right direction,
> but still leaves most of memory exploitable due to the default R+W+X
> permissions.
>
> The idea is that the implementation of the CPU arch protocol goes over the
> memory map and removes exec permissions from all regions that are not already
> marked as 'code. This requires some preparatory work to ensure that the
> DxeCore
> itself is covered by a BootServicesCode region, not a BootServicesData region.
> Exec permissions are re-granted selectively, when the PE/COFF loader allocates
> the space for it. Combined with Jiewen's code/data split, this removes all
> RWX mapped regions.
>
> There is a caveat, though (and there are likely more of that kind): the EBC
> driver will need some work to ensure the thunk buffers have the noexec
> restriction lifted. This could be done in the EBC driver, but perhaps it is
> better to either
> a) modify the DXE core so it always removes noexec restrictions when 
> allocating
>code pages, or
> b) add AllocateExecPages/AllocateExecPool() functions to the
> MemoryAllocationLib
>API
>
> Comments please!
>
> Ard Biesheuvel (4):
>   MdeModulePkg/DxeCore: allow BootServicesData->BootServicesCode
> conversion
>   MdeModulePkg/DxeCore: convert the DxeCore memory region to
> BootServicesCode
>   MdeModulePkg/DxeCore: lift non-exec permissions on loaded images
>   ArmPkg/CpuDxe: remap all data regions non-executable
>
>  ArmPkg/Drivers/CpuDxe/CpuDxe.c  | 76 
>  MdeModulePkg/Core/Dxe/DxeMain.h |  8 +++
>  MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c |  2 +
>  MdeModulePkg/Core/Dxe/Image/Image.c |  8 +++
>  MdeModulePkg/Core/Dxe/Mem/Page.c| 18 -
>  5 files changed, 111 insertions(+), 1 deletion(-)
>
> --
> 2.7.4
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Tcg2Pei.efi assert after sync to latest trunk

[wang xiaofeng]

Hi All,
   I just updated to latest edk2 trunk this afternoon , and meet the following 
error:


Loading PEIM at 0x8FB1000 EntryPoint=0x8FB13CF Tcg2Pei.efi
PROGRESS CODE: V03020002 I0
WARNING: Tpm2RegisterTpm2DeviceLib - does not support 
286BF25A-C2C3-408C-B3B4-25E6758B7317 registration
WARNING: Tpm2RegisterTpm2DeviceLib - does not support 
286BF25A-C2C3-408C-B3B4-25E6758B7317 registration
Hash Interface (2AE9D80F-3FB2-4095-B7B1-E93157B946B6) has been registered
ASSERT_EFI_ERROR (Status = Already started)
ASSERT [Tcg2Pei] 
e:\code\cl819sync\Build\SariPlatformPkg\DEBUG_VS2013x86\IA32\SecurityPkg\Tcg\Tcg2Pei\Tcg2Pei\DEBUG\AutoGen.c(466):
 !EFI_ERROR (Status)


While AutoGen.c(466) have the following code:


  Status = HashInstanceLibSha1Constructor ();
  ASSERT_EFI_ERROR (Status);
  Status = HashInstanceLibSha1Constructor ();
  ASSERT_EFI_ERROR (Status); <-asset here


gEfiTpmDeviceInstanceTpm20DtpmGuid = { 0x286bf25a, 0xc2c3, 0x408c, { 0xb3, 
0xb4, 0x25, 0xe6, 0x75, 0x8b, 0x73, 0x17 } }


  So anyone meet the same assert before ?  Thanks in advance !

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

Re: [edk2] [PATCH 06/12] ArmVirtPkg, OvmfPkg: retire QemuFwCfgS3Enabled() from QemuFwCfgLib

[Ard Biesheuvel]

On 23 February 2017 at 01:48, Laszlo Ersek  wrote:
> At this point we're ready to retire QemuFwCfgS3Enabled() from the
> QemuFwCfgLib class, together with its implementations in:
>
> - ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
> - OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
>
> Extend all modules that call the function with a new QemuFwCfgS3Lib class
> dependency. Thanks to the previously added library class, instances, and
> class resolutions, we can do this switch now as tightly as possible.
>
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek 

Reviewed-by: Ard Biesheuvel 

> ---
>  OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf   |  1 +
>  OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpiPlatformDxe.inf  |  1 +
>  OvmfPkg/Library/LockBoxLib/LockBoxDxeLib.inf  |  1 +
>  OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf |  1 +
>  OvmfPkg/PlatformPei/PlatformPei.inf   |  1 +
>  OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf |  1 +
>  OvmfPkg/Include/Library/QemuFwCfgLib.h| 14 
> --
>  OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h  |  1 +
>  ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c| 17 
> 
>  OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c   |  1 +
>  OvmfPkg/Library/LockBoxLib/LockBoxDxe.c   |  1 +
>  OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c   | 28 
> 
>  OvmfPkg/PlatformPei/Platform.c|  1 +
>  OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.c   |  1 +
>  14 files changed, 11 insertions(+), 59 deletions(-)
>
> diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf 
> b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
> index bb5f14e0fc7a..42edc97b3da2 100644
> --- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
> +++ b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
> @@ -52,6 +52,7 @@ [LibraryClasses]
>UefiDriverEntryPoint
>HobLib
>QemuFwCfgLib
> +  QemuFwCfgS3Lib
>MemoryAllocationLib
>BaseLib
>DxeServicesTableLib
> diff --git a/OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpiPlatformDxe.inf 
> b/OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpiPlatformDxe.inf
> index e550ff5a4714..a9350540215d 100644
> --- a/OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpiPlatformDxe.inf
> +++ b/OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpiPlatformDxe.inf
> @@ -44,6 +44,7 @@ [LibraryClasses]
>MemoryAllocationLib
>OrderedCollectionLib
>QemuFwCfgLib
> +  QemuFwCfgS3Lib
>UefiBootServicesTableLib
>UefiDriverEntryPoint
>
> diff --git a/OvmfPkg/Library/LockBoxLib/LockBoxDxeLib.inf 
> b/OvmfPkg/Library/LockBoxLib/LockBoxDxeLib.inf
> index bedf1811e0b2..eb03f4f546bc 100644
> --- a/OvmfPkg/Library/LockBoxLib/LockBoxDxeLib.inf
> +++ b/OvmfPkg/Library/LockBoxLib/LockBoxDxeLib.inf
> @@ -40,6 +40,7 @@ [LibraryClasses]
>DebugLib
>UefiBootServicesTableLib
>QemuFwCfgLib
> +  QemuFwCfgS3Lib
>
>  [Protocols]
>gEfiLockBoxProtocolGuid## SOMETIMES_PRODUCES
> diff --git 
> a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf 
> b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> index f9e35c955d4d..27789b7377bc 100644
> --- a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> +++ b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> @@ -52,6 +52,7 @@ [LibraryClasses]
>PciLib
>NvVarsFileLib
>QemuFwCfgLib
> +  QemuFwCfgS3Lib
>LoadLinuxLib
>QemuBootOrderLib
>UefiLib
> diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf 
> b/OvmfPkg/PlatformPei/PlatformPei.inf
> index fbaed3182dcf..53c6dd445a0e 100644
> --- a/OvmfPkg/PlatformPei/PlatformPei.inf
> +++ b/OvmfPkg/PlatformPei/PlatformPei.inf
> @@ -58,6 +58,7 @@ [LibraryClasses]
>PeiServicesTablePointerLib
>PeimEntryPoint
>QemuFwCfgLib
> +  QemuFwCfgS3Lib
>MtrrLib
>PcdLib
>
> diff --git a/OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf 
> b/OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
> index 31c80bd4448c..04b1ed0e4eb3 100644
> --- a/OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
> +++ b/OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
> @@ -56,6 +56,7 @@ [LibraryClasses]
>PcdLib
>PciLib
>QemuFwCfgLib
> +  QemuFwCfgS3Lib
>UefiBootServicesTableLib
>UefiDriverEntryPoint
>
> diff --git a/OvmfPkg/Include/Library/QemuFwCfgLib.h 
> b/OvmfPkg/Include/Library/QemuFwCfgLib.h
> index 2a1261327b01..596e3f25d5fe 100644
> --- a/OvmfPkg/Include/Library/QemuFwCfgLib.h
> +++ b/OvmfPkg/Include/Library/QemuFwCfgLib.h
> @@ -179,19 +179,5 @@ QemuFwCfgFindFile (
>OUT  UINTN *Size
>);
>
> -
> -/**
> -  Determine if S3 support is explicitly enabled.
> -
> -  @retval  TRUE   if S3 support is explicitly enabled.
> - 

Re: [edk2] [PATCH 04/12] ArmVirtPkg: resolve QemuFwCfgS3Lib

[Ard Biesheuvel]

On 23 February 2017 at 01:48, Laszlo Ersek  wrote:
> QemuFwCfgS3Enabled() in "ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c"
> returns constant FALSE.
>
> The same implementation is now available factored-out in
> "OvmfPkg/Library/QemuFwCfgS3Lib/QemuFwCfgS3Base.c".
>
> Resolve QemuFwCfgS3Lib to BaseQemuFwCfgS3LibNull.
>
> Cc: Ard Biesheuvel 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek 

Reviewed-by: Ard Biesheuvel 

> ---
>  ArmVirtPkg/ArmVirtQemu.dsc   | 1 +
>  ArmVirtPkg/ArmVirtQemuKernel.dsc | 1 +
>  2 files changed, 2 insertions(+)
>
> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
> index 8fe3c3816961..9c8a2d977a8a 100644
> --- a/ArmVirtPkg/ArmVirtQemu.dsc
> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
> @@ -52,6 +52,7 @@ [LibraryClasses.common]
>VirtioLib|OvmfPkg/Library/VirtioLib/VirtioLib.inf
>
> VirtioMmioDeviceLib|OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf
>QemuFwCfgLib|ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.inf
> +  QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/BaseQemuFwCfgS3LibNull.inf
>
>ArmPlatformLib|ArmVirtPkg/Library/ArmVirtPlatformLib/ArmVirtPlatformLib.inf
>
> ArmPlatformSysConfigLib|ArmPlatformPkg/Library/ArmPlatformSysConfigLibNull/ArmPlatformSysConfigLibNull.inf
> diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc 
> b/ArmVirtPkg/ArmVirtQemuKernel.dsc
> index aa40374745af..6afc10e69ef5 100644
> --- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
> +++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
> @@ -51,6 +51,7 @@ [LibraryClasses.common]
>VirtioLib|OvmfPkg/Library/VirtioLib/VirtioLib.inf
>
> VirtioMmioDeviceLib|OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf
>QemuFwCfgLib|ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.inf
> +  QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/BaseQemuFwCfgS3LibNull.inf
>
>
> ArmPlatformLib|ArmVirtPkg/Library/ArmQemuRelocatablePlatformLib/ArmQemuRelocatablePlatformLib.inf
>
> ArmPlatformSysConfigLib|ArmPlatformPkg/Library/ArmPlatformSysConfigLibNull/ArmPlatformSysConfigLibNull.inf
> --
> 2.9.3
>
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] BaseTools: Fix the regression issue caused by commit dc4c77

[Laszlo Ersek]

On 02/22/17 17:03, Yonghong Zhu wrote:
> In the last commit dc4c77, the _GetHeaderInfo will be called more than
> once, which cause the self._ConstructorList.append(Value) append some
> duplicate value.
> 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Yonghong Zhu 
> ---
>  BaseTools/Source/Python/Workspace/WorkspaceDatabase.py | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

I see that this patch has been committed. It fixes the issue for me as well.

Tested-by: Laszlo Ersek 

Thanks!
Laszlo

> diff --git a/BaseTools/Source/Python/Workspace/WorkspaceDatabase.py 
> b/BaseTools/Source/Python/Workspace/WorkspaceDatabase.py
> index 0686721..c1af5c7 100644
> --- a/BaseTools/Source/Python/Workspace/WorkspaceDatabase.py
> +++ b/BaseTools/Source/Python/Workspace/WorkspaceDatabase.py
> @@ -1828,12 +1828,10 @@ class InfBuildData(ModuleBuildClassObject):
>  self.__Macros = {}
>  # EDK_GLOBAL defined macros can be applied to EDK module
>  if self.AutoGenVersion < 0x00010005:
>  self.__Macros.update(GlobalData.gEdkGlobal)
>  self.__Macros.update(GlobalData.gGlobalDefines)
> -else:
> -self.__Macros.update(self.Defines)
>  return self.__Macros
>  
>  ## Get architecture
>  def _GetArch(self):
>  return self._Arch
> @@ -1894,10 +1892,11 @@ class InfBuildData(ModuleBuildClassObject):
>  if Name in self:
>  self[Name] = Value
>  if self._Defs == None:
>  self._Defs = sdict()
>  self._Defs[Name] = Value
> +self._Macros[Name] = Value
>  # some special items in [Defines] section need special treatment
>  elif Name in ('EFI_SPECIFICATION_VERSION', 
> 'UEFI_SPECIFICATION_VERSION', 'EDK_RELEASE_VERSION', 
> 'PI_SPECIFICATION_VERSION'):
>  if Name in ('EFI_SPECIFICATION_VERSION', 
> 'UEFI_SPECIFICATION_VERSION'):
>  Name = 'UEFI_SPECIFICATION_VERSION'
>  if self._Specification == None:
> @@ -1954,10 +1953,11 @@ class InfBuildData(ModuleBuildClassObject):
>  self._CustomMakefile[TokenList[0]] = TokenList[1]
>  else:
>  if self._Defs == None:
>  self._Defs = sdict()
>  self._Defs[Name] = Value
> +self._Macros[Name] = Value
>  
>  #
>  # Retrieve information in sections specific to Edk.x modules
>  #
>  if self.AutoGenVersion >= 0x00010005:
> 

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

Re: [edk2] [RFC PATCH 0/4] RFC: increased memory protection

[Laszlo Ersek]

Hi,

On 02/22/17 19:24, Ard Biesheuvel wrote:
> Hello all,
> 
> This is a proof of concept implementation that removes all executable
> permissions from writable memory regions, which greatly enhances security.
> It is based on Jiewen's recent work, which is a step in the right direction,
> but still leaves most of memory exploitable due to the default R+W+X
> permissions.
> 
> The idea is that the implementation of the CPU arch protocol goes over the
> memory map and removes exec permissions from all regions that are not already
> marked as 'code. This requires some preparatory work to ensure that the 
> DxeCore
> itself is covered by a BootServicesCode region, not a BootServicesData region.
> Exec permissions are re-granted selectively, when the PE/COFF loader allocates
> the space for it. Combined with Jiewen's code/data split, this removes all
> RWX mapped regions.
> 
> There is a caveat, though (and there are likely more of that kind): the EBC
> driver will need some work to ensure the thunk buffers have the noexec
> restriction lifted. This could be done in the EBC driver, but perhaps it is
> better to either
> a) modify the DXE core so it always removes noexec restrictions when 
> allocating
>code pages, or
> b) add AllocateExecPages/AllocateExecPool() functions to the 
> MemoryAllocationLib
>API
> 
> Comments please!

My only comment is "good idea, as long as it doesn't regress anything". :)

I haven't done any testing with this; once you think the series is
mature enough for that, I could run my usual tests. Feel free to ping me
for that whenever.

Thanks!
Laszlo

> Ard Biesheuvel (4):
>   MdeModulePkg/DxeCore: allow BootServicesData->BootServicesCode
> conversion
>   MdeModulePkg/DxeCore: convert the DxeCore memory region to
> BootServicesCode
>   MdeModulePkg/DxeCore: lift non-exec permissions on loaded images
>   ArmPkg/CpuDxe: remap all data regions non-executable
> 
>  ArmPkg/Drivers/CpuDxe/CpuDxe.c  | 76 
>  MdeModulePkg/Core/Dxe/DxeMain.h |  8 +++
>  MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c |  2 +
>  MdeModulePkg/Core/Dxe/Image/Image.c |  8 +++
>  MdeModulePkg/Core/Dxe/Mem/Page.c| 18 -
>  5 files changed, 111 insertions(+), 1 deletion(-)
> 

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

Re: [edk2] [Patch 0/2] Ignore duplicated DNS address check

[Subramanian, Sriram]

Looks ok to me. Nagaraj will also test with these changes and provide feedback.

Series Reviewed-by: Sriram Subramanian 

-Original Message-
From: Jiaxin Wu [mailto:jiaxin...@intel.com] 
Sent: Thursday, February 23, 2017 11:01 AM
To: edk2-devel@lists.01.org
Cc: Hegde, Nagaraj P ; Subramanian, Sriram 
; Ye Ting ; Fu Siyuan 
; Wu Jiaxin 
Subject: [Patch 0/2] Ignore duplicated DNS address check

Having duplicated DNS server IPs specified is not an ideal
configuration, but not an error condition. This patch is to
remove the duplicated DNS address check to allow the same DNS
address setting in SetData().

Cc: Hegde Nagaraj P 
Cc: Subramanian Sriram 
Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin 

Jiaxin Wu (2):
  MdeModulePkg/Ip4Dxe: Ignore duplicated DNS address check
  NetworkPkg/Ip6Dxe: Ignore duplicated DNS address check

 MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c | 10 --
 NetworkPkg/Ip6Dxe/Ip6ConfigImpl.c  | 10 --
 2 files changed, 20 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] BaseTools: add error check for Macro usage in the INF file

[Laszlo Ersek]

On 02/23/17 02:14, Gao, Liming wrote:
> Laszlo:
>   Yonghong has sent the another patch to its regression issue. Could you 
> verify it?

Yes, thanks, I'll check that out soon.

(Also, I'm sorry about reporting this after Ard's report; I was very
busy last night and sort of looked at Thunderbird in write-only mode...)

Thanks
Laszlo



> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com] 
> Sent: Thursday, February 23, 2017 9:12 AM
> To: Zhu, Yonghong ; edk2-de...@ml01.01.org
> Cc: Gao, Liming 
> Subject: Re: [edk2] [Patch] BaseTools: add error check for Macro usage in the 
> INF file
> 
> On 02/23/17 02:02, Laszlo Ersek wrote:
>> Hi,
>>
>> On 02/21/17 02:18, Yonghong Zhu wrote:
>>> Use of MACRO statements in the EDK II INF files is limited to local
>>> usage only; global or external macros are not permitted. This patch
>>> add the check for not defined macros.
>>>
>>> Cc: Liming Gao 
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Yonghong Zhu 
>>> ---
>>>  BaseTools/Source/Python/Workspace/MetaFileParser.py| 9 -
>>>  BaseTools/Source/Python/Workspace/WorkspaceDatabase.py | 4 +++-
>>>  2 files changed, 11 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/BaseTools/Source/Python/Workspace/MetaFileParser.py 
>>> b/BaseTools/Source/Python/Workspace/MetaFileParser.py
>>> index 1a5fdf5..37a7f5d 100644
>>> --- a/BaseTools/Source/Python/Workspace/MetaFileParser.py
>>> +++ b/BaseTools/Source/Python/Workspace/MetaFileParser.py
>>> @@ -1,9 +1,9 @@
>>>  ## @file
>>>  # This file is used to parse meta files
>>>  #
>>> -# Copyright (c) 2008 - 2016, Intel Corporation. All rights reserved.
>>> +# Copyright (c) 2008 - 2017, Intel Corporation. All rights reserved.
>>>  # (C) Copyright 2015-2016 Hewlett Packard Enterprise Development LP
>>>  # 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
>>> @@ -349,10 +349,17 @@ class MetaFileParser(object):
>>>  EdkLogger.error('Parser', FORMAT_INVALID, "No value specified",
>>>  ExtraData=self._CurrentLine, 
>>> File=self.MetaFile, Line=self._LineIndex + 1)
>>>  
>>>  self._ValueList = [ReplaceMacro(Value, self._Macros) for Value in 
>>> self._ValueList]
>>>  Name, Value = self._ValueList[1], self._ValueList[2]
>>> +MacroUsed = GlobalData.gMacroRefPattern.findall(Value)
>>> +if len(MacroUsed) != 0:
>>> +for Macro in MacroUsed:
>>> +if Macro in GlobalData.gGlobalDefines:
>>> +EdkLogger.error("Parser", FORMAT_INVALID, "Global 
>>> macro %s is not permitted." % (Macro), ExtraData=self._CurrentLine, 
>>> File=self.MetaFile, Line=self._LineIndex + 1)
>>> +else:
>>> +EdkLogger.error("Parser", FORMAT_INVALID, "%s not defined" 
>>> % (Macro), ExtraData=self._CurrentLine, File=self.MetaFile, 
>>> Line=self._LineIndex + 1)
>>>  # Sometimes, we need to make differences between EDK and EDK2 
>>> modules 
>>>  if Name == 'INF_VERSION':
>>>  if re.match(r'0[xX][\da-f-A-F]{5,8}', Value):
>>>  self._Version = int(Value, 0)   
>>>  elif re.match(r'\d+\.\d+', Value):
>>> diff --git a/BaseTools/Source/Python/Workspace/WorkspaceDatabase.py 
>>> b/BaseTools/Source/Python/Workspace/WorkspaceDatabase.py
>>> index e7bc87d..0686721 100644
>>> --- a/BaseTools/Source/Python/Workspace/WorkspaceDatabase.py
>>> +++ b/BaseTools/Source/Python/Workspace/WorkspaceDatabase.py
>>> @@ -1,9 +1,9 @@
>>>  ## @file
>>>  # This file is used to create a database used by build tool
>>>  #
>>> -# Copyright (c) 2008 - 2016, Intel Corporation. All rights reserved.
>>> +# Copyright (c) 2008 - 2017, Intel Corporation. All rights reserved.
>>>  # (C) Copyright 2016 Hewlett Packard Enterprise Development LP
>>>  # 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
>>> @@ -1828,10 +1828,12 @@ class InfBuildData(ModuleBuildClassObject):
>>>  self.__Macros = {}
>>>  # EDK_GLOBAL defined macros can be applied to EDK module
>>>  if self.AutoGenVersion < 0x00010005:
>>>  self.__Macros.update(GlobalData.gEdkGlobal)
>>>  self.__Macros.update(GlobalData.gGlobalDefines)
>>> +else:
>>> +self.__Macros.update(self.Defines)
>>>  return self.__Macros
>>>  
>>>  ## Get architecture
>>>  def _GetArch(self):
>>>  return self._Arch
>>>
>>
>> I don't understand how, but this patch (commit dc4c770763d0) 

Re: [edk2] [PATCH 0/4] Fix runtime issue in XenBusDxe when compiled with GCC5

[Laszlo Ersek]

On 02/22/17 09:54, Gao, Liming wrote:
> Laszlo:
> In edk2, I find the several functions with VA_LIST have no EFIAPI.
> They may use VA_ARG() or call other functions, but they don't use
> VA_COPY(). In Base.h, VA_ARG() is defined as __builtin_va_arg(),
> which is same to native one.

You are right; apparently __builtin_va_arg() works with __builtin_ms_va_list 
and __builtin_va_list alike.

However, as you say,

> VA_COPY() is defined as
> __builtin_ms_va_copy(). So, I also think this is MS ABI request. That
> means only if the function implementation uses VA_START(),VA_END() or
> VA_COPY(), it must be declared with EFIAPI.

- __builtin_va_start / __builtin_ms_va_start,
- __builtin_va_end / __builtin_ms_va_end,
- __builtin_va_copy / __builtin_ms_va_copy

must be matched to __builtin_va_list vs. __builtin_ms_va_list.

> 
> MdePkg\Library\BasePrintLib\PrintLibInternal.c BasePrintLibSPrintMarker()
> ShellPkg\Library\UefiShellLib\UefiShellLib.c InternalShellPrintWorker()

Yes, you are right -- when looking for functions that should be made EFIAPI, we 
shouldn't search for VA_LIST, but VA_START|VA_END|VA_COPY.

Thanks for the correction.

The following command is a good start:

  git grep -E -n '\<(VA_START|VA_END|VA_COPY)\>|^[A-Za-z0-9_]' \
  | grep -E -B 3 '\<(VA_START|VA_END|VA_COPY)\>'

I just went over the output (it was gruesome), and -- outside of 
EdkCompatibilityPkg -- I indeed found only a handful of affected functions:

- XenStoreVSPrint() [OvmfPkg/XenBusDxe/XenStore.c]
- VariableGetBestLanguage() 
[SecurityPkg/VariableAuthenticated/EsalVariableDxeSal/Variable.c]
- SmmBootScriptWrite()  [Vlv2TbltDevicePkg/PlatformSmm/SmmScriptSave.c]

Anthony, can you please submit the patch for XenStoreVSPrint()?

Chao Zhang, can you please submit a patch for VariableGetBestLanguage()?

David Wei or Mang Guo, can one of you guys please submit a patch for 
SmmBootScriptWrite()?

Thanks,
Laszlo


> 
> Thanks
> Liming
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Laszlo Ersek
>> Sent: Wednesday, February 22, 2017 3:03 AM
>> To: Anthony PERARD 
>> Cc: Ard Biesheuvel ; Justen, Jordan L
>> ; edk2-de...@ml01.01.org; Gao, Liming
>> 
>> Subject: Re: [edk2] [PATCH 0/4] Fix runtime issue in XenBusDxe when
>> compiled with GCC5
>>
>> On 02/21/17 18:53, Anthony PERARD wrote:
>>> On Tue, Feb 21, 2017 at 06:07:15PM +0100, Laszlo Ersek wrote:
 CC Rebecca & Konrad

 On 02/21/17 17:39, Anthony PERARD wrote:
>>
>> [snip]
>>
> So, should I add EFIAPI to XenStoreVSPrint, as it is using VA_COPY?
>

 Hm, please help me jog my memory...

 If I remember correctly, this is still a GCC bug, one that we suppressed 
 for
>> gcc-6.2 with your patch as follows:
>>>
>>> Yes.
>>>
> commit 432f1d83f77acf92d52ef18d2cee6dbf7c5b9b86
> Author: Anthony PERARD 
> Date:   Tue Dec 6 12:03:25 2016 +
>
> OvmfPkg/build.sh: Use GCC49 toolchains with GCC 6.[0-2]
>
> The goal of the patch is to avoid using -flto with GCC 6.0 to 6.2.
>
> This is to workaround a GCC bug:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70955
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Anthony PERARD 
> Reviewed-by: Laszlo Ersek 
> Regression-tested-by: Laszlo Ersek 
>
> diff --git a/OvmfPkg/build.sh b/OvmfPkg/build.sh
> index 95fe8fb07647..b6e936056ca0 100755
> --- a/OvmfPkg/build.sh
> +++ b/OvmfPkg/build.sh
> @@ -102,7 +102,7 @@ case `uname` in
>4.8.*)
>  TARGET_TOOLS=GCC48
>  ;;
> -  4.9.*)
> +  4.9.*|6.[0-2].*)
>  TARGET_TOOLS=GCC49
>  ;;
>*)

 Do I understand correctly that the gcc bug has not been fixed in
 gcc-6.3, and -- because we don't suppress it for gcc-6.3 as the
 above expression does not match -- it causes problems again?
>>>
>>> The bug describe in the GCC bugzilla is probably fix, but the
>>> test-case does not make use of __builtin_ms_va_copy.
>>
>> :/
>>
>>>
 You also mention gcc-5.4 as problematic. I think we haven't
 received such reports about gcc-5 versions up to and including
 gcc-5.3 (that's why GCC5 is the default selection in
 "OvmfPkg/build.sh"). Do you mean that the gcc bug has now been
 "backported" from the gcc-6 series to the gcc-5 series (starting
 with gcc-5.4)?
>>
>>>
>>> I don't know the state of gcc-5.0 to gcc-5.3, I have never tested -flto
>>> with gcc-5.x (until now), I would say they are also problematic until
>>> proven otherwise.
>>
>> When we enabled GCC5, it definitely worked for at least one gcc release,
>> with -flto. (-flto is the default for DEBUG and RELEASE builds with
>> GCC5; NOOPT disables -Os and -flto.)
>>
>>>
 If that's the case, then I suggest flipping "OvmfPkg/build.sh" from
 black-listing gcc versions for -flto to white-listing. In ot

Re: [edk2] [PATCH] ArmVirtPkg/ArmVirt.dsc.inc: AARCH64: enable DXE image protection feature

[Laszlo Ersek]

On 02/22/17 12:54, Ard Biesheuvel wrote:
> Enable the new DXE image protection for all image, i.e., FV images but
> also external images that originate from disk or the network, such as
> OS loaders.
> 
> This complements work that is underway on the arm64/Linux kernel side,
> to emit the OS loader with 4 KB section alignment, and a suitable split
> between code and data.
> 
> http://marc.info/?l=linux-arm-kernel&m=14867227819
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmVirtPkg/ArmVirt.dsc.inc | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
> index dbd6678accde..c0d5e7c6aa6d 100644
> --- a/ArmVirtPkg/ArmVirt.dsc.inc
> +++ b/ArmVirtPkg/ArmVirt.dsc.inc
> @@ -17,6 +17,9 @@ [Defines]
>DEFINE DEBUG_PRINT_ERROR_LEVEL = 0x804F
>DEFINE TTY_TERMINAL= FALSE
>  
> +[BuildOptions.common.EDKII.DXE_DRIVER,BuildOptions.common.EDKII.UEFI_DRIVER,BuildOptions.common.EDKII.UEFI_APPLICATION]
> +  GCC:*_*_AARCH64_DLINK_FLAGS = -z common-page-size=0x1000
> +
>  [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
>GCC:*_*_ARM_DLINK_FLAGS = -z common-page-size=0x1000
>GCC:*_*_AARCH64_DLINK_FLAGS = -z common-page-size=0x1
> @@ -380,6 +383,13 @@ [PcdsFixedAtBuild.common]
>  [PcdsFixedAtBuild.ARM]
>gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize|40
>  
> +[PcdsFixedAtBuild.AARCH64]
> +  #
> +  # Enable strict image permissions for all images. (This applies
> +  # only to images that were built with >= 4 KB section alignment.)
> +  #
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdImageProtectionPolicy|0x3
> +
>  [Components.common]
>#
># Networking stack
> 

So, if I understand correctly, setting BIT0 will not break external
images with unaligned sections, they just won't be protected, and
they'll trigger loud warnings. OK.

Reviewed-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] UefiCpuPkg/CpuDxe: Replace EFI_D_xxx with DEBUG_xxx in DEBUG()

[Laszlo Ersek]

On 02/22/17 08:55, Jeff Fan wrote:
> Cc: Laszlo Ersek 
> Cc: Feng Tian 
> Cc: Michael D Kinney 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jeff Fan 
> ---
>  UefiCpuPkg/CpuDxe/CpuDxe.c | 8 
>  UefiCpuPkg/CpuDxe/CpuMp.c  | 6 +++---
>  2 files changed, 7 insertions(+), 7 deletions(-)

Reviewed-by: Laszlo Ersek 

Thanks
Laszlo

> 
> diff --git a/UefiCpuPkg/CpuDxe/CpuDxe.c b/UefiCpuPkg/CpuDxe/CpuDxe.c
> index 1a5a725..2fd2f31 100644
> --- a/UefiCpuPkg/CpuDxe/CpuDxe.c
> +++ b/UefiCpuPkg/CpuDxe/CpuDxe.c
> @@ -403,7 +403,7 @@ CpuSetMemoryAttributes (
>// to avoid unnecessary computing.
>//
>if (mIsFlushingGCD) {
> -DEBUG((EFI_D_INFO, "  Flushing GCD\n"));
> +DEBUG((DEBUG_INFO, "  Flushing GCD\n"));
>  return EFI_SUCCESS;
>}
>  
> @@ -979,13 +979,13 @@ IntersectMemoryDescriptor (
>  IntersectionBase, IntersectionEnd - IntersectionBase,
>  Capabilities);
>  
> -DEBUG ((EFI_ERROR (Status) ? EFI_D_ERROR : EFI_D_VERBOSE,
> +DEBUG ((EFI_ERROR (Status) ? DEBUG_ERROR : DEBUG_VERBOSE,
>"%a: %a: add [%Lx, %Lx): %r\n", gEfiCallerBaseName, __FUNCTION__,
>IntersectionBase, IntersectionEnd, Status));
>  return Status;
>}
>  
> -  DEBUG ((EFI_D_ERROR, "%a: %a: desc [%Lx, %Lx) type %u cap %Lx conflicts "
> +  DEBUG ((DEBUG_ERROR, "%a: %a: desc [%Lx, %Lx) type %u cap %Lx conflicts "
>  "with aperture [%Lx, %Lx) cap %Lx\n", gEfiCallerBaseName, __FUNCTION__,
>  Descriptor->BaseAddress, Descriptor->BaseAddress + Descriptor->Length,
>  (UINT32)Descriptor->GcdMemoryType, Descriptor->Capabilities,
> @@ -1018,7 +1018,7 @@ AddMemoryMappedIoSpace (
>  
>Status = gDS->GetMemorySpaceMap (&NumberOfDescriptors, &MemorySpaceMap);
>if (EFI_ERROR (Status)) {
> -DEBUG ((EFI_D_ERROR, "%a: %a: GetMemorySpaceMap(): %r\n",
> +DEBUG ((DEBUG_ERROR, "%a: %a: GetMemorySpaceMap(): %r\n",
>gEfiCallerBaseName, __FUNCTION__, Status));
>  return Status;
>}
> diff --git a/UefiCpuPkg/CpuDxe/CpuMp.c b/UefiCpuPkg/CpuDxe/CpuMp.c
> index 9659bd2..4456946 100644
> --- a/UefiCpuPkg/CpuDxe/CpuMp.c
> +++ b/UefiCpuPkg/CpuDxe/CpuMp.c
> @@ -1,7 +1,7 @@
>  /** @file
>CPU DXE Module to produce CPU MP Protocol.
>  
> -  Copyright (c) 2008 - 2016, Intel Corporation. All rights reserved.
> +  Copyright (c) 2008 - 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
>which accompanies this distribution.  The full text of the license may be 
> found at
> @@ -571,7 +571,7 @@ CollectBistDataFromHob (
>BspCpuInstance.InfoRecord.IA32HealthFlags.Uint32  = 
> SecPlatformInformation->IA32HealthFlags.Uint32;
>CpuInstance = &BspCpuInstance;
>  } else {
> -  DEBUG ((EFI_D_INFO, "Does not find any HOB stored CPU BIST 
> information!\n"));
> +  DEBUG ((DEBUG_INFO, "Does not find any HOB stored CPU BIST 
> information!\n"));
>//
>// Does not find any HOB stored BIST information
>//
> @@ -622,7 +622,7 @@ InitializeMpSupport (
>  
>MpInitLibGetNumberOfProcessors (&NumberOfProcessors, 
> &NumberOfEnabledProcessors);
>mNumberOfProcessors = NumberOfProcessors;
> -  DEBUG ((EFI_D_ERROR, "Detect CPU count: %d\n", mNumberOfProcessors));
> +  DEBUG ((DEBUG_ERROR, "Detect CPU count: %d\n", mNumberOfProcessors));
>  
>//
>// Update CPU healthy information from Guided HOB
> 

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