date:20181015

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Star Zeng 
---
 MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c 
b/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c
index 0b35cbacf0..c35c7bdc12 100644
--- a/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c
+++ b/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c
@@ -736,6 +736,13 @@ UsbBootDetectMedia (
 return Status;
   }
 
+  //
+  // Simply reject device whose block size is unacceptable small (==0) or 
large (>64K).
+  //
+  if ((Media->BlockSize == 0) || (Media->BlockSize > USB_BOOT_MAX_CARRY_SIZE)) 
{
+return EFI_DEVICE_ERROR;
+  }
+
   //
   // Detect whether it is necessary to reinstall the Block I/O Protocol.
   //
-- 
2.16.1.windows.1

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

[edk2] [PATCH v2 10/12] MdeModulePkg/UsbBus: Deny when the string descriptor length is odd

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Jiewen Yao 
Cc: Star Zeng 
---
 MdeModulePkg/Bus/Usb/UsbBusDxe/UsbDesc.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbDesc.c 
b/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbDesc.c
index 9fc6422ab1..22b6a9d661 100644
--- a/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbDesc.c
+++ b/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbDesc.c
@@ -655,7 +655,13 @@ UsbGetOneString (
   //
   Status = UsbCtrlGetDesc (UsbDev, USB_DESC_TYPE_STRING, Index, LangId, , 
2);
 
-  if (EFI_ERROR (Status)) {
+  //
+  // Reject if Length even cannot cover itself, or odd because Unicode string 
byte length should be even.
+  //
+  if (EFI_ERROR (Status) || 
+  (Desc.Length < OFFSET_OF (EFI_USB_STRING_DESCRIPTOR, Length) + sizeof 
(Desc.Length)) ||
+  (Desc.Length % 2 != 0)
+) {
 return NULL;
   }
 
-- 
2.16.1.windows.1

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

[edk2] [PATCH v2 11/12] MdeModulePkg/Bus/Ufs: Ensure device not return more data than expected

From: Hao Wu 

This commit adds checks to make sure the UFS devices do not return more
data than the driver expected.

Cc: Ruiyu Ni 
Cc: Jiewen Yao 
Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
Reviewed-by: Star Zeng 
---
 MdeModulePkg/Bus/Ufs/UfsBlockIoPei/UfsHci.c| 19 --
 .../Bus/Ufs/UfsPassThruDxe/UfsPassThruHci.c| 30 +++---
 2 files changed, 43 insertions(+), 6 deletions(-)

diff --git a/MdeModulePkg/Bus/Ufs/UfsBlockIoPei/UfsHci.c 
b/MdeModulePkg/Bus/Ufs/UfsBlockIoPei/UfsHci.c
index 936f25da5e..9b87835ed8 100644
--- a/MdeModulePkg/Bus/Ufs/UfsBlockIoPei/UfsHci.c
+++ b/MdeModulePkg/Bus/Ufs/UfsBlockIoPei/UfsHci.c
@@ -857,6 +857,14 @@ UfsRwDeviceDesc (
 SwapLittleEndianToBigEndian ((UINT8*), sizeof (UINT16));
 
 if (Read) {
+  //
+  // Make sure the hardware device does not return more data than expected.
+  //
+  if (ReturnDataSize > Packet.InTransferLength) {
+Status = EFI_DEVICE_ERROR;
+goto Exit;
+  }
+
   CopyMem (Packet.InDataBuffer, (QueryResp + 1), ReturnDataSize);
   Packet.InTransferLength = ReturnDataSize;
 } else {
@@ -1170,8 +1178,15 @@ UfsExecScsiCmds (
   SwapLittleEndianToBigEndian ((UINT8*), sizeof (UINT16));
 
   if ((Packet->SenseDataLength != 0) && (Packet->SenseData != NULL)) {
-CopyMem (Packet->SenseData, Response->SenseData, SenseDataLen);
-Packet->SenseDataLength = (UINT8)SenseDataLen;
+//
+// Make sure the hardware device does not return more data than expected.
+//
+if (SenseDataLen <= Packet->SenseDataLength) {
+  CopyMem (Packet->SenseData, Response->SenseData, SenseDataLen);
+  Packet->SenseDataLength = (UINT8)SenseDataLen;
+} else {
+  Packet->SenseDataLength = 0;
+}
   }
 
   //
diff --git a/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThruHci.c 
b/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThruHci.c
index 5756f637fd..0238264878 100644
--- a/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThruHci.c
+++ b/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThruHci.c
@@ -833,6 +833,7 @@ UfsStopExecCmd (
   @param[in] QueryResp  Pointer to the query response.
 
   @retval EFI_INVALID_PARAMETER Packet or QueryResp are empty or opcode is 
invalid.
+  @retval EFI_DEVICE_ERROR  Data returned from device is invalid.
   @retval EFI_SUCCESS   Data extracted.
 
 **/
@@ -853,6 +854,13 @@ UfsGetReturnDataFromQueryResponse (
 case UtpQueryFuncOpcodeRdDesc:
   ReturnDataSize = QueryResp->Tsf.Length;
   SwapLittleEndianToBigEndian ((UINT8*), sizeof (UINT16));
+  //
+  // Make sure the hardware device does not return more data than expected.
+  //
+  if (ReturnDataSize > Packet->TransferLength) {
+return EFI_DEVICE_ERROR;
+  }
+
   CopyMem (Packet->DataBuffer, (QueryResp + 1), ReturnDataSize);
   Packet->TransferLength = ReturnDataSize;
   break;
@@ -1469,8 +1477,15 @@ UfsExecScsiCmds (
   SwapLittleEndianToBigEndian ((UINT8*), sizeof (UINT16));
 
   if ((Packet->SenseDataLength != 0) && (Packet->SenseData != NULL)) {
-CopyMem (Packet->SenseData, Response->SenseData, SenseDataLen);
-Packet->SenseDataLength = (UINT8)SenseDataLen;
+//
+// Make sure the hardware device does not return more data than expected.
+//
+if (SenseDataLen <= Packet->SenseDataLength) {
+  CopyMem (Packet->SenseData, Response->SenseData, SenseDataLen);
+  Packet->SenseDataLength = (UINT8)SenseDataLen;
+} else {
+  Packet->SenseDataLength = 0;
+}
   }
 
   //
@@ -2226,8 +2241,15 @@ ProcessAsyncTaskList (
 SwapLittleEndianToBigEndian ((UINT8*), sizeof (UINT16));
 
 if ((Packet->SenseDataLength != 0) && (Packet->SenseData != NULL)) {
-  CopyMem (Packet->SenseData, Response->SenseData, SenseDataLen);
-  Packet->SenseDataLength = (UINT8)SenseDataLen;
+  //
+  // Make sure the hardware device does not return more data than 
expected.
+  //
+  if (SenseDataLen <= Packet->SenseDataLength) {
+CopyMem (Packet->SenseData, Response->SenseData, SenseDataLen);
+Packet->SenseDataLength = (UINT8)SenseDataLen;
+  } else {
+Packet->SenseDataLength = 0;
+  }
 }
 
 //
-- 
2.16.1.windows.1

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

[edk2] [PATCH v2 03/12] MdeModulePkg/UsbBus: Fix out-of-bound read access to descriptors

Today's implementation reads the Type/Length field in the USB
descriptors data without checking whether the offset to read is
beyond the data boundary.

The patch fixes this issue.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Star Zeng 
Cc: Jiewen Yao 
---
 MdeModulePkg/Bus/Usb/UsbBusDxe/UsbDesc.c | 55 +---
 1 file changed, 43 insertions(+), 12 deletions(-)

diff --git a/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbDesc.c 
b/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbDesc.c
index 061e4622e8..70442c57da 100644
--- a/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbDesc.c
+++ b/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbDesc.c
@@ -177,6 +177,18 @@ UsbCreateDesc (
 DescLen = sizeof (EFI_USB_ENDPOINT_DESCRIPTOR);
 CtrlLen = sizeof (USB_ENDPOINT_DESC);
 break;
+
+  default:
+ASSERT (FALSE);
+return NULL;
+  }
+
+  //
+  // Total length is too small that cannot hold the single descriptor header 
plus data. 
+  //
+  if (Len <= sizeof (USB_DESC_HEAD)) {
+DEBUG ((DEBUG_ERROR, "UsbCreateDesc: met mal-format descriptor, total 
length = %d!\n", Len));
+return NULL;
   }
 
   //
@@ -184,24 +196,43 @@ UsbCreateDesc (
   // format. Skip the descriptor that isn't of this Type
   //
   Offset = 0;
-  Head   = (USB_DESC_HEAD*)DescBuf;
+  Head   = (USB_DESC_HEAD *)DescBuf;
+  while (Offset < Len - sizeof (USB_DESC_HEAD)) {
+//
+// Above condition make sure Head->Len and Head->Type are safe to access
+//
+Head = (USB_DESC_HEAD *)[Offset];
 
-  while ((Offset < Len) && (Head->Type != Type)) {
-Offset += Head->Len;
-if (Len <= Offset) {
-  DEBUG (( EFI_D_ERROR, "UsbCreateDesc: met mal-format descriptor, Beyond 
boundary!\n"));
+if (Head->Len == 0) {
+  DEBUG ((DEBUG_ERROR, "UsbCreateDesc: met mal-format descriptor, 
Head->Len = 0!\n"));
   return NULL;
 }
-Head= (USB_DESC_HEAD*)(DescBuf + Offset);
-if (Head->Len == 0) {
-  DEBUG (( EFI_D_ERROR, "UsbCreateDesc: met mal-format descriptor, 
Head->Len = 0!\n"));
+
+//
+// Make sure no overflow when adding Head->Len to Offset.
+//
+if (Head->Len > MAX_UINTN - Offset) {
+  DEBUG ((DEBUG_ERROR, "UsbCreateDesc: met mal-format descriptor, 
Head->Len = %d!\n", Head->Len));
   return NULL;
 }
+
+Offset += Head->Len;
+
+if (Head->Type == Type) {
+  break;
+}
+  }
+
+  //
+  // Head->Len is invalid resulting data beyond boundary, or
+  // Descriptor cannot be found: No such type.
+  //
+  if (Len < Offset) {
+DEBUG ((DEBUG_ERROR, "UsbCreateDesc: met mal-format descriptor, Offset/Len 
= %d/%d!\n", Offset, Len));
   }
 
-  if ((Len <= Offset)  || (Len < Offset + Head->Len) ||
-  (Head->Type != Type) || (Head->Len < DescLen)) {
-DEBUG (( EFI_D_ERROR, "UsbCreateDesc: met mal-format descriptor\n"));
+  if ((Head->Type != Type) || (Head->Len < DescLen)) {
+DEBUG ((DEBUG_ERROR, "UsbCreateDesc: descriptor cannot be found, 
Header(T/L) = %d/%d!\n", Head->Type, Head->Len));
 return NULL;
   }
 
@@ -212,7 +243,7 @@ UsbCreateDesc (
 
   CopyMem (Desc, Head, (UINTN) DescLen);
 
-  *Consumed = Offset + Head->Len;
+  *Consumed = Offset;
 
   return Desc;
 }
-- 
2.16.1.windows.1

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

[edk2] [PATCH v2 00/12] Need to validate data from HW

The patches contain logic to check the data from HW before using.
It can avoid corrupted data from HW causes software behave abnormally.

V2: adopt all comments from Star. The block size 0/64K handle is in a
separate patch
"MdeModulePkg/UsbMass: Reject device whose block size is 0 or > 64K"

Hao Wu (1):
  MdeModulePkg/Bus/Ufs: Ensure device not return more data than expected

Ruiyu Ni (11):
  MdeModulePkg/UsbMass: Merge UsbBoot(Read|Write)Blocks(16)
  MdeModulePkg/UsbMass: Fix integer overflow when BlockSize is 1
  MdeModulePkg/UsbBus: Fix out-of-bound read access to descriptors
  MdeModulePkg/UsbBus: Reject descriptor whose length is bad
  MdeModulePkg/Usb: Make sure data from HW is no more than expected
  SourceLevelDebugPkg/Usb3: Make sure data from HW can fit in buffer
  MdeModulePkg/UsbKb: Don't access key codes when length is wrong
  MdeModulePkg/AbsPointer: Don't access key codes when length is wrong
  MdeModulePkg/UsbMouse: Don't access key codes when length is wrong
  MdeModulePkg/UsbBus: Deny when the string descriptor length is odd
  MdeModulePkg/UsbMass: Reject device whose block size is 0 or > 64K

 MdeModulePkg/Bus/Pci/EhciDxe/EhciSched.c   |   9 +-
 MdeModulePkg/Bus/Pci/UhciDxe/UhciSched.c   |   7 +-
 MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c   |   9 +-
 MdeModulePkg/Bus/Ufs/UfsBlockIoPei/UfsHci.c|  19 +-
 .../Bus/Ufs/UfsPassThruDxe/UfsPassThruHci.c|  30 ++-
 MdeModulePkg/Bus/Usb/UsbBusDxe/UsbDesc.c   |  70 +-
 MdeModulePkg/Bus/Usb/UsbKbDxe/KeyBoard.c   |   4 +
 .../Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c| 276 ++---
 .../Bus/Usb/UsbMassStorageDxe/UsbMassBoot.h|  76 ++
 .../Bus/Usb/UsbMassStorageDxe/UsbMassImpl.c|   8 +-
 .../UsbMouseAbsolutePointer.c  |   8 +-
 MdeModulePkg/Bus/Usb/UsbMouseDxe/UsbMouse.c|   8 +-
 .../DebugCommunicationLibUsb3Transfer.c|   7 +
 13 files changed, 237 insertions(+), 294 deletions(-)

-- 
2.16.1.windows.1

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

[edk2] [PATCH v2 02/12] MdeModulePkg/UsbMass: Fix integer overflow when BlockSize is 1

UsbBootReadWriteBlocks() and UsbBootReadWriteBlocks16() use a UINT16
local variable to hold the value of
USB_BOOT_MAX_CARRY_SIZE (=0x1) / BlockSize.
When BlockSize is 1, the UINT16 local variable is set to 0x1
but the high-16 bits are truncated resulting the final value be 0.

It causes the while-loop in the two functions accesses 0 block in
each loop, resulting the loop never ends.

The patch fixes the two functions to make sure no integer overflow
happens.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Star Zeng 
Cc: Steven Shi 
---
 .../Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c| 27 +++---
 1 file changed, 14 insertions(+), 13 deletions(-)

diff --git a/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c 
b/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c
index 07a376440c..0b35cbacf0 100644
--- a/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c
+++ b/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c
@@ -815,14 +815,14 @@ UsbBootReadWriteBlocks (
 {
   USB_BOOT_READ_WRITE_10_CMD Cmd;
   EFI_STATUS Status;
-  UINT16 Count;
-  UINT16 CountMax;
+  UINT32 Count;
+  UINT32 CountMax;
   UINT32 BlockSize;
   UINT32 ByteSize;
   UINT32 Timeout;
 
   BlockSize = UsbMass->BlockIoMedia.BlockSize;
-  CountMax = (UINT16)(USB_BOOT_MAX_CARRY_SIZE / BlockSize);
+  CountMax  = USB_BOOT_MAX_CARRY_SIZE / BlockSize;
   Status= EFI_SUCCESS;
 
   while (TotalBlock > 0) {
@@ -831,8 +831,9 @@ UsbBootReadWriteBlocks (
 // on the device. We must split the total block because the READ10
 // command only has 16 bit transfer length (in the unit of block).
 //
-Count = (UINT16)((TotalBlock < CountMax) ? TotalBlock : CountMax);
-ByteSize  = (UINT32)Count * BlockSize;
+Count= (UINT32)MIN (TotalBlock, CountMax);
+Count= MIN (MAX_UINT16, Count);
+ByteSize = Count * BlockSize;
 
 //
 // USB command's upper limit timeout is 5s. [USB2.0-9.2.6.1]
@@ -847,7 +848,7 @@ UsbBootReadWriteBlocks (
 Cmd.OpCode  = Write ? USB_BOOT_WRITE10_OPCODE : USB_BOOT_READ10_OPCODE;
 Cmd.Lun = (UINT8) (USB_BOOT_LUN (UsbMass->Lun));
 WriteUnaligned32 ((UINT32 *) Cmd.Lba, SwapBytes32 (Lba));
-WriteUnaligned16 ((UINT16 *) Cmd.TransferLen, SwapBytes16 (Count));
+WriteUnaligned16 ((UINT16 *) Cmd.TransferLen, SwapBytes16 ((UINT16)Count));
 
 Status = UsbBootExecCmdWithRetry (
UsbMass,
@@ -867,7 +868,7 @@ UsbBootReadWriteBlocks (
   Lba, Count
   ));
 Lba+= Count;
-Buffer += Count * BlockSize;
+Buffer += ByteSize;
 TotalBlock -= Count;
   }
 
@@ -897,22 +898,22 @@ UsbBootReadWriteBlocks16 (
 {
   UINT8 Cmd[16];
   EFI_STATUSStatus;
-  UINT16Count;
-  UINT16CountMax;
+  UINT32Count;
+  UINT32CountMax;
   UINT32BlockSize;
   UINT32ByteSize;
   UINT32Timeout;
 
   BlockSize = UsbMass->BlockIoMedia.BlockSize;
-  CountMax = (UINT16)(USB_BOOT_MAX_CARRY_SIZE / BlockSize);
+  CountMax  = USB_BOOT_MAX_CARRY_SIZE / BlockSize;
   Status= EFI_SUCCESS;
 
   while (TotalBlock > 0) {
 //
 // Split the total blocks into smaller pieces.
 //
-Count = (UINT16)((TotalBlock < CountMax) ? TotalBlock : CountMax);
-ByteSize  = (UINT32)Count * BlockSize;
+Count= (UINT32)MIN (TotalBlock, CountMax);
+ByteSize = Count * BlockSize;
 
 //
 // USB command's upper limit timeout is 5s. [USB2.0-9.2.6.1]
@@ -947,7 +948,7 @@ UsbBootReadWriteBlocks16 (
   Lba, Count
   ));
 Lba+= Count;
-Buffer += Count * BlockSize;
+Buffer += ByteSize;
 TotalBlock -= Count;
   }
 
-- 
2.16.1.windows.1

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

[edk2] [PATCH v2 05/12] MdeModulePkg/Usb: Make sure data from HW is no more than expected

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Jiewen Yao 
Cc: Star Zeng 
Cc: Hao A Wu 
Reviewed-by: Hao Wu 
Reviewed-by: Star Zeng 
---
 MdeModulePkg/Bus/Pci/EhciDxe/EhciSched.c | 9 ++---
 MdeModulePkg/Bus/Pci/UhciDxe/UhciSched.c | 7 ---
 MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c | 9 ++---
 3 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/EhciDxe/EhciSched.c 
b/MdeModulePkg/Bus/Pci/EhciDxe/EhciSched.c
index fea6f47f4c..168280be81 100644
--- a/MdeModulePkg/Bus/Pci/EhciDxe/EhciSched.c
+++ b/MdeModulePkg/Bus/Pci/EhciDxe/EhciSched.c
@@ -1009,9 +1009,12 @@ EhcMonitorAsyncRequests (
 ProcBuf = NULL;
 
 if (Urb->Result == EFI_USB_NOERROR) {
-  ASSERT (Urb->Completed <= Urb->DataLen);
-
-  ProcBuf = AllocatePool (Urb->Completed);
+  //
+  // Make sure the data received from HW is no more than expected.
+  //
+  if (Urb->Completed <= Urb->DataLen) {
+ProcBuf = AllocatePool (Urb->Completed);
+  }
 
   if (ProcBuf == NULL) {
 EhcUpdateAsyncRequest (Ehc, Urb);
diff --git a/MdeModulePkg/Bus/Pci/UhciDxe/UhciSched.c 
b/MdeModulePkg/Bus/Pci/UhciDxe/UhciSched.c
index 90f010c998..f7510f3ec0 100644
--- a/MdeModulePkg/Bus/Pci/UhciDxe/UhciSched.c
+++ b/MdeModulePkg/Bus/Pci/UhciDxe/UhciSched.c
@@ -2,7 +2,7 @@
 
   The EHCI register operation routines.
 
-Copyright (c) 2007 - 2013, Intel Corporation. All rights reserved.
+Copyright (c) 2007 - 2018, 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
@@ -1001,11 +1001,12 @@ UhciMonitorAsyncReqList (
 
 //
 // Copy the data to temporary buffer if there are some
-// data transferred. We may have zero-length packet
+// data transferred. We may have zero-length packet.
+// Make sure the data received from HW is no more than expected.
 //
 Data = NULL;
 
-if (QhResult.Complete != 0) {
+if ((QhResult.Complete != 0) && (QhResult.Complete <= AsyncReq->DataLen)) {
   Data = AllocatePool (QhResult.Complete);
 
   if (Data == NULL) {
diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c 
b/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c
index 6a2ef4cd5d..166c44bf5e 100644
--- a/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c
+++ b/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c
@@ -1556,9 +1556,12 @@ XhcMonitorAsyncRequests (
 //
 ProcBuf = NULL;
 if (Urb->Result == EFI_USB_NOERROR) {
-  ASSERT (Urb->Completed <= Urb->DataLen);
-
-  ProcBuf = AllocateZeroPool (Urb->Completed);
+  //
+  // Make sure the data received from HW is no more than expected.
+  //
+  if (Urb->Completed <= Urb->DataLen) {
+ProcBuf = AllocateZeroPool (Urb->Completed);
+  }
 
   if (ProcBuf == NULL) {
 XhcUpdateAsyncRequest (Xhc, Urb);
-- 
2.16.1.windows.1

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

[edk2] [PATCH v2 06/12] SourceLevelDebugPkg/Usb3: Make sure data from HW can fit in buffer

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Hao A Wu 
Reviewed-by: Hao Wu 
---
 .../DebugCommunicationLibUsb3/DebugCommunicationLibUsb3Transfer.c  | 7 +++
 1 file changed, 7 insertions(+)

diff --git 
a/SourceLevelDebugPkg/Library/DebugCommunicationLibUsb3/DebugCommunicationLibUsb3Transfer.c
 
b/SourceLevelDebugPkg/Library/DebugCommunicationLibUsb3/DebugCommunicationLibUsb3Transfer.c
index fb48010a9a..fda43279a3 100644
--- 
a/SourceLevelDebugPkg/Library/DebugCommunicationLibUsb3/DebugCommunicationLibUsb3Transfer.c
+++ 
b/SourceLevelDebugPkg/Library/DebugCommunicationLibUsb3/DebugCommunicationLibUsb3Transfer.c
@@ -556,6 +556,13 @@ XhcDataTransfer (
 
   XhcExecTransfer (Handle, Urb, Timeout);
 
+  //
+  // Make sure the data received from HW can fit in the received buffer.
+  //
+  if (Urb->Completed > *DataLength) {
+return EFI_DEVICE_ERROR;
+  }
+
   *DataLength = Urb->Completed;
 
   Status = EFI_TIMEOUT;
-- 
2.16.1.windows.1

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

[edk2] [PATCH v2 09/12] MdeModulePkg/UsbMouse: Don't access key codes when length is wrong

Per USB HID spec, the buffer holding key codes should at least 3-byte
long.
Today's code assumes that the key codes buffer length is longer than
3-byte and unconditionally accesses the key codes buffer.
It's incorrect.
The patch fixes the issue by returning Device Error when the
length is less than 3-byte.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Star Zeng 
Cc: Jiewen Yao 
Cc: Steven Shi 
---
 MdeModulePkg/Bus/Usb/UsbMouseDxe/UsbMouse.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Bus/Usb/UsbMouseDxe/UsbMouse.c 
b/MdeModulePkg/Bus/Usb/UsbMouseDxe/UsbMouse.c
index 9324994975..f4448bffe6 100644
--- a/MdeModulePkg/Bus/Usb/UsbMouseDxe/UsbMouse.c
+++ b/MdeModulePkg/Bus/Usb/UsbMouseDxe/UsbMouse.c
@@ -811,8 +811,6 @@ OnMouseInterruptComplete (
 return EFI_SUCCESS;
   }
 
-  UsbMouseDevice->StateChanged = TRUE;
-
   //
   // Check mouse Data
   // USB HID Specification specifies following data format:
@@ -825,6 +823,12 @@ OnMouseInterruptComplete (
   // 2   0 to 7  Y displacement
   // 3 to n  0 to 7  Device specific (optional)
   //
+  if (DataLength < 3) {
+return EFI_DEVICE_ERROR;
+  }
+
+  UsbMouseDevice->StateChanged = TRUE;
+
   UsbMouseDevice->State.LeftButton  = (BOOLEAN) ((*(UINT8 *) Data & BIT0) != 
0);
   UsbMouseDevice->State.RightButton = (BOOLEAN) ((*(UINT8 *) Data & BIT1) != 
0);
   UsbMouseDevice->State.RelativeMovementX += *((INT8 *) Data + 1);
-- 
2.16.1.windows.1

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

[edk2] [PATCH v2 08/12] MdeModulePkg/AbsPointer: Don't access key codes when length is wrong

Per USB HID spec, the buffer holding key codes should at least 3-byte
long.
Today's code assumes that the key codes buffer length is longer than
3-byte and unconditionally accesses the key codes buffer.
It's incorrect.
The patch fixes the issue by returning Device Error when the
length is less than 3-byte.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Star Zeng 
Cc: Jiewen Yao 
Cc: Steven Shi 
---
 .../Bus/Usb/UsbMouseAbsolutePointerDxe/UsbMouseAbsolutePointer.c  | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git 
a/MdeModulePkg/Bus/Usb/UsbMouseAbsolutePointerDxe/UsbMouseAbsolutePointer.c 
b/MdeModulePkg/Bus/Usb/UsbMouseAbsolutePointerDxe/UsbMouseAbsolutePointer.c
index 965195ca34..42b9147ad8 100644
--- a/MdeModulePkg/Bus/Usb/UsbMouseAbsolutePointerDxe/UsbMouseAbsolutePointer.c
+++ b/MdeModulePkg/Bus/Usb/UsbMouseAbsolutePointerDxe/UsbMouseAbsolutePointer.c
@@ -813,8 +813,6 @@ OnMouseInterruptComplete (
 return EFI_SUCCESS;
   }
 
-  UsbMouseAbsolutePointerDevice->StateChanged = TRUE;
-
   //
   // Check mouse Data
   // USB HID Specification specifies following data format:
@@ -827,6 +825,12 @@ OnMouseInterruptComplete (
   // 2   0 to 7  Y displacement
   // 3 to n  0 to 7  Device specific (optional)
   //
+  if (DataLength < 3) {
+return EFI_DEVICE_ERROR;
+  }
+
+  UsbMouseAbsolutePointerDevice->StateChanged = TRUE;
+
   UsbMouseAbsolutePointerDevice->State.ActiveButtons = *(UINT8 *) Data & (BIT0 
| BIT1 | BIT2);
 
   UsbMouseAbsolutePointerDevice->State.CurrentX =
-- 
2.16.1.windows.1

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

[edk2] [PATCH v2 01/12] MdeModulePkg/UsbMass: Merge UsbBoot(Read|Write)Blocks(16)

The change doesn't have functionality impact.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Star Zeng 
---
 .../Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c| 248 +
 .../Bus/Usb/UsbMassStorageDxe/UsbMassBoot.h|  76 ++-
 .../Bus/Usb/UsbMassStorageDxe/UsbMassImpl.c|   8 +-
 3 files changed, 80 insertions(+), 252 deletions(-)

diff --git a/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c 
b/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c
index dd5950c54c..07a376440c 100644
--- a/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c
+++ b/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c
@@ -792,32 +792,34 @@ UsbBootDetectMedia (
 
 
 /**
-  Read some blocks from the device.
+  Read or write some blocks from the device.
 
-  @param  UsbMassThe USB mass storage device to read from
+  @param  UsbMassThe USB mass storage device to access
+  @param  Write  TRUE for write operation.
   @param  LbaThe start block number
-  @param  TotalBlock Total block number to read
-  @param  Buffer The buffer to read to
+  @param  TotalBlock Total block number to read or write
+  @param  Buffer The buffer to read to or write from
 
-  @retval EFI_SUCCESSData are read into the buffer
-  @retval Others Failed to read all the data
+  @retval EFI_SUCCESSData are read into the buffer or writen into 
the device.
+  @retval Others Failed to read or write all the data
 
 **/
 EFI_STATUS
-UsbBootReadBlocks (
+UsbBootReadWriteBlocks (
   IN  USB_MASS_DEVICE   *UsbMass,
+  IN  BOOLEAN   Write,
   IN  UINT32Lba,
   IN  UINTN TotalBlock,
-  OUT UINT8 *Buffer
+  IN OUT UINT8  *Buffer
   )
 {
-  USB_BOOT_READ10_CMD   ReadCmd;
-  EFI_STATUSStatus;
-  UINT16Count;
-  UINT16CountMax;
-  UINT32BlockSize;
-  UINT32ByteSize;
-  UINT32Timeout;
+  USB_BOOT_READ_WRITE_10_CMD Cmd;
+  EFI_STATUS Status;
+  UINT16 Count;
+  UINT16 CountMax;
+  UINT32 BlockSize;
+  UINT32 ByteSize;
+  UINT32 Timeout;
 
   BlockSize = UsbMass->BlockIoMedia.BlockSize;
   CountMax = (UINT16)(USB_BOOT_MAX_CARRY_SIZE / BlockSize);
@@ -840,17 +842,17 @@ UsbBootReadBlocks (
 //
 // Fill in the command then execute
 //
-ZeroMem (, sizeof (USB_BOOT_READ10_CMD));
+ZeroMem (, sizeof (USB_BOOT_READ_WRITE_10_CMD));
 
-ReadCmd.OpCode  = USB_BOOT_READ10_OPCODE;
-ReadCmd.Lun = (UINT8) (USB_BOOT_LUN (UsbMass->Lun));
-WriteUnaligned32 ((UINT32 *) ReadCmd.Lba, SwapBytes32 (Lba));
-WriteUnaligned16 ((UINT16 *) ReadCmd.TransferLen, SwapBytes16 (Count));
+Cmd.OpCode  = Write ? USB_BOOT_WRITE10_OPCODE : USB_BOOT_READ10_OPCODE;
+Cmd.Lun = (UINT8) (USB_BOOT_LUN (UsbMass->Lun));
+WriteUnaligned32 ((UINT32 *) Cmd.Lba, SwapBytes32 (Lba));
+WriteUnaligned16 ((UINT16 *) Cmd.TransferLen, SwapBytes16 (Count));
 
 Status = UsbBootExecCmdWithRetry (
UsbMass,
-   ,
-   (UINT8) sizeof (USB_BOOT_READ10_CMD),
+   ,
+   (UINT8) sizeof (USB_BOOT_READ_WRITE_10_CMD),
EfiUsbDataIn,
Buffer,
ByteSize,
@@ -859,86 +861,11 @@ UsbBootReadBlocks (
 if (EFI_ERROR (Status)) {
   return Status;
 }
-DEBUG ((EFI_D_BLKIO, "UsbBootReadBlocks: LBA (0x%x), Blk (0x%x)\n", Lba, 
Count));
-Lba+= Count;
-Buffer += Count * BlockSize;
-TotalBlock -= Count;
-  }
-
-  return Status;
-}
-
-
-/**
-  Write some blocks to the device.
-
-  @param  UsbMassThe USB mass storage device to write to
-  @param  LbaThe start block number
-  @param  TotalBlock Total block number to write
-  @param  Buffer Pointer to the source buffer for the data.
-
-  @retval EFI_SUCCESSData are written into the buffer
-  @retval Others Failed to write all the data
-
-**/
-EFI_STATUS
-UsbBootWriteBlocks (
-  IN  USB_MASS_DEVICE *UsbMass,
-  IN  UINT32  Lba,
-  IN  UINTN   TotalBlock,
-  IN  UINT8   *Buffer
-  )
-{
-  USB_BOOT_WRITE10_CMD  WriteCmd;
-  EFI_STATUSStatus;
-  UINT16Count;
-  UINT16CountMax;
-  UINT32BlockSize;
-  UINT32ByteSize;
-  UINT32Timeout;
-
-  BlockSize = UsbMass->BlockIoMedia.BlockSize;
-  CountMax = (UINT16)(USB_BOOT_MAX_CARRY_SIZE / BlockSize);
-  Status= EFI_SUCCESS;
-
-  while (TotalBlock > 0) {
-//
-// Split

[edk2] [PATCH v2 07/12] MdeModulePkg/UsbKb: Don't access key codes when length is wrong

Per USB HID spec, the buffer holding key codes should be 8-byte
long.
Today's code assumes that the key codes buffer length is 8-byte
long and unconditionally accesses the key codes buffer.
It's incorrect.
The patch fixes the issue by returning Device Error when the
length is less than 8-byte.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Star Zeng 
Cc: Jiewen Yao 
Cc: Steven Shi 
---
 MdeModulePkg/Bus/Usb/UsbKbDxe/KeyBoard.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/MdeModulePkg/Bus/Usb/UsbKbDxe/KeyBoard.c 
b/MdeModulePkg/Bus/Usb/UsbKbDxe/KeyBoard.c
index 9cb4b5db6b..7505951c82 100644
--- a/MdeModulePkg/Bus/Usb/UsbKbDxe/KeyBoard.c
+++ b/MdeModulePkg/Bus/Usb/UsbKbDxe/KeyBoard.c
@@ -1059,6 +1059,10 @@ KeyboardHandler (
   // Byte 1 is reserved.
   // Bytes 2 to 7 are keycodes.
   //
+  if (DataLength < 8) {
+return EFI_DEVICE_ERROR;
+  }
+
   CurKeyCodeBuffer  = (UINT8 *) Data;
   OldKeyCodeBuffer  = UsbKeyboardDevice->LastKeyCodeArray;
 
-- 
2.16.1.windows.1

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

[edk2] [PATCH v2 04/12] MdeModulePkg/UsbBus: Reject descriptor whose length is bad

Today's implementation doesn't check whether the length of
descriptor is valid before using it.

The patch fixes this issue.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Star Zeng 
Cc: Jiewen Yao 
Reviewed-by: Star Zeng 
---
 MdeModulePkg/Bus/Usb/UsbBusDxe/UsbDesc.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbDesc.c 
b/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbDesc.c
index 70442c57da..9fc6422ab1 100644
--- a/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbDesc.c
+++ b/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbDesc.c
@@ -772,6 +772,13 @@ UsbGetOneConfig (
 
   DEBUG (( EFI_D_INFO, "UsbGetOneConfig: total length is %d\n", 
Desc.TotalLength));
 
+  //
+  // Reject if TotalLength even cannot cover itself.
+  //
+  if (Desc.TotalLength < OFFSET_OF (EFI_USB_CONFIG_DESCRIPTOR, TotalLength) + 
sizeof (Desc.TotalLength)) {
+return NULL;
+  }
+
   Buf = AllocateZeroPool (Desc.TotalLength);
 
   if (Buf == NULL) {
-- 
2.16.1.windows.1

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

[edk2] [Patch] NetworkPkg: Correct the time stamp and fix the integer overflow issue.

2018-10-15 Thread Jiaxin Wu

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

Cc: Fu Siyuan 
Cc: Ye Ting 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Wu Jiaxin 
---
 NetworkPkg/Dhcp6Dxe/Dhcp6Utility.c | 18 +-
 NetworkPkg/UefiPxeBcDxe/PxeBcSupport.c | 16 
 2 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/NetworkPkg/Dhcp6Dxe/Dhcp6Utility.c 
b/NetworkPkg/Dhcp6Dxe/Dhcp6Utility.c
index 10a99a00d4..9c7459c332 100644
--- a/NetworkPkg/Dhcp6Dxe/Dhcp6Utility.c
+++ b/NetworkPkg/Dhcp6Dxe/Dhcp6Utility.c
@@ -121,11 +121,11 @@ Dhcp6GenerateClientId (
 // Generate a time stamp of the seconds from 2000/1/1, assume 30day/month.
 //
 gRT->GetTime (, NULL);
 Stamp = (UINT32)
   (
-(Time.Year - 2000) * 360 + (Time.Month - 1)) * 30 + (Time.Day - 
1)) * 24 + Time.Hour) * 60 + Time.Minute) *
+UINT32)(Time.Year - 2000) * 360 + (Time.Month - 1) * 30 + 
(Time.Day - 1)) * 24 + Time.Hour) * 60 + Time.Minute) *
 60 +
 Time.Second
   );
 
 //
@@ -879,18 +879,18 @@ SetElapsedTime (
 
   //
   // Generate a time stamp of the centiseconds from 2000/1/1, assume 
30day/month.
   //
   gRT->GetTime (, NULL);
-  CurrentStamp = (UINT64)
-(
-  ((Time.Year - 2000) * 360 +
-   (Time.Month - 1)) * 30 +
-   (Time.Day - 1)) * 24 + Time.Hour) * 60 +
-   Time.Minute) * 60 + Time.Second) * 100
-   + DivU64x32(Time.Nanosecond, 1000)
-);
+  CurrentStamp = MultU64x32 (
+   UINT32)(Time.Year - 2000) * 360 + (Time.Month - 1) * 30 
+ (Time.Day - 1)) * 24 + Time.Hour) * 60 + Time.Minute) * 60 + Time.Second,
+   100
+   ) +
+ DivU64x32(
+   Time.Nanosecond,
+   1000
+   );
 
   //
   // Sentinel value of 0 means that this is the first DHCP packet that we are
   // sending and that we need to initialize the value.  First DHCP message
   // gets 0 elapsed-time.  Otherwise, calculate based on StartTime.
diff --git a/NetworkPkg/UefiPxeBcDxe/PxeBcSupport.c 
b/NetworkPkg/UefiPxeBcDxe/PxeBcSupport.c
index 60509fc9e6..7ab09e0367 100644
--- a/NetworkPkg/UefiPxeBcDxe/PxeBcSupport.c
+++ b/NetworkPkg/UefiPxeBcDxe/PxeBcSupport.c
@@ -1508,18 +1508,18 @@ CalcElapsedTime (
   //
   // Generate a time stamp of the centiseconds from 1900/1/1, assume 
30day/month.
   //
   ZeroMem (, sizeof (EFI_TIME));
   gRT->GetTime (, NULL);
-  CurrentStamp = (UINT64)
-(
-  ((Time.Year - 1900) * 360 +
-   (Time.Month - 1)) * 30 +
-   (Time.Day - 1)) * 24 + Time.Hour) * 60 +
-   Time.Minute) * 60 + Time.Second) * 100
-   + DivU64x32(Time.Nanosecond, 1000)
-);
+  CurrentStamp = MultU64x32 (
+   UINT32)(Time.Year - 1900) * 360 + (Time.Month - 1) * 30 
+ (Time.Day - 1)) * 24 + Time.Hour) * 60 + Time.Minute) * 60 + Time.Second,
+   100
+   ) +
+ DivU64x32 (
+   Time.Nanosecond,
+   1000
+   );
 
   //
   // Sentinel value of 0 means that this is the first DHCP packet that we are
   // sending and that we need to initialize the value.  First DHCP Solicit
   // gets 0 elapsed-time.  Otherwise, calculate based on StartTime.
-- 
2.17.1.windows.2

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

Re: [edk2] PACKAGES_PATH in !include path in Dsc files

Hi, 
  You can directly include it. BaseTools will search it from WORKSPACE and 
PACKAGES_PATH. So, you only need to set edk2-platforms directory into 
PACKAGES_PATH env. 

!include Silicon/NXP/.dsc

Thanks
Liming
>-Original Message-
>From: Pankaj Bansal [mailto:pankaj.ban...@nxp.com]
>Sent: Tuesday, October 16, 2018 1:24 PM
>To: Ard Biesheuvel 
>Cc: Gao, Liming ; Zhu, Yonghong
>; Leif Lindholm ; Kinney,
>Michael D ; edk2-devel@lists.01.org; Udit
>Kumar ; Varun Sethi 
>Subject: RE: PACKAGES_PATH in !include path in Dsc files
>
>
>
>> -Original Message-
>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>> Sent: Tuesday, October 16, 2018 8:41 AM
>> To: Pankaj Bansal 
>> Cc: Gao, Liming ; Zhu, Yonghong
>> ; Leif Lindholm ;
>Michael
>> D Kinney ; edk2-devel@lists.01.org; Udit
>Kumar
>> ; Varun Sethi 
>> Subject: Re: PACKAGES_PATH in !include path in Dsc files
>>
>> On 16 October 2018 at 10:40, Pankaj Bansal 
>wrote:
>> > +edk2-platforms maintainers in To list
>> >
>> >
>> >
>> > Thank you Liming for replying.
>> >
>> >
>> >
>> > Our entire code is in edk2-platforms
>> >
>(https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
>> > thub.com%2Ftianocore%2Fedk2-
>>
>platformsdata=02%7C01%7Cpankaj.bansal%40nxp.com%7C552da3f22b
>5
>> 84b7fac6008d63315ec8b%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0
>> %7C636752566592695047sdata=JJWbAcZkj%2FtFaZC0bWONPb7ulCcj1
>L2
>> 4VKwCDGDx9OE%3Dreserved=0) which is denoted by
>PACKAGES_PATH.
>> >
>> > The PACKAGES_PATH directory can be anywhere in WORKSPACE
>depending on
>> > the sync directory defined by user.
>> >
>> > i.e. it can be $(WORKSPACE)/edk2-platforms or $(WORKSPACE)/> > directory name that user can define during git sync>
>> >
>> > As our dsc files are relative to PACKAGES_PATH, I want to specify
>> > their path in dsc file like this:
>> >
>> >
>> >
>> > !include $(PACKAGES_PATH)/Silicon/NXP/.dsc
>> >
>> >
>> >
>> > Using $(WORKSPACE), I cannot specify above path, as it can be at place
>> > other than $(WORKSPACE)/edk2-platforms
>> >
>>
>> But why do you need to !include things in the first place?
>>
>> Can you explain how you are trying to organize the files, and which file
>includes
>> which?
>
>I am trying to keep Silicon (SOC) specific dsc file in Silicon/NXP/Name>/
>This silicon can be used in multiple Boards (Platforms).
>All these Platforms are present in Platform/NXP/
>fd/fv binaries would be created for each platform.
>The chassis dsc file has description of components/PCDs that are specific to
>chassis to which the silicon belongs. It would be same for all silicons that
>belong to same chassis.
>The Silicon dsc file has description of components/PCDs that are specific to
>silicon and would be same for all platforms that use this silicon. It would
>include chassis dsc file
>The Platform dsc file would include the silicon dsc file.
>
>___
>| Platform (in Platform/NXP)|
>|_  |
>|   | Silicon (in Silicon/NXP/) | |
>|   |   ___| |
>|   |  | Chassis  (in Silicon/NXP) |   ||
>|   |  |__|   | |
>|   || |
>|_|
>
>Regards,
>Pankaj Bansal
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 11/11] MdeModulePkg/Bus/Ufs: Ensure device not return more data than expected


On 2018/10/15 14:38, Ruiyu Ni wrote:

From: Hao Wu 

This commit adds checks to make sure the UFS devices do not return more
data than the driver expected.

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


Thanks for the patch.
Reviewed-by: Star Zeng 

Star


---
  MdeModulePkg/Bus/Ufs/UfsBlockIoPei/UfsHci.c| 19 --
  .../Bus/Ufs/UfsPassThruDxe/UfsPassThruHci.c| 30 +++---
  2 files changed, 43 insertions(+), 6 deletions(-)

diff --git a/MdeModulePkg/Bus/Ufs/UfsBlockIoPei/UfsHci.c 
b/MdeModulePkg/Bus/Ufs/UfsBlockIoPei/UfsHci.c
index 936f25da5e..9b87835ed8 100644
--- a/MdeModulePkg/Bus/Ufs/UfsBlockIoPei/UfsHci.c
+++ b/MdeModulePkg/Bus/Ufs/UfsBlockIoPei/UfsHci.c
@@ -857,6 +857,14 @@ UfsRwDeviceDesc (
  SwapLittleEndianToBigEndian ((UINT8*), sizeof (UINT16));
  
  if (Read) {

+  //
+  // Make sure the hardware device does not return more data than expected.
+  //
+  if (ReturnDataSize > Packet.InTransferLength) {
+Status = EFI_DEVICE_ERROR;
+goto Exit;
+  }
+
CopyMem (Packet.InDataBuffer, (QueryResp + 1), ReturnDataSize);
Packet.InTransferLength = ReturnDataSize;
  } else {
@@ -1170,8 +1178,15 @@ UfsExecScsiCmds (
SwapLittleEndianToBigEndian ((UINT8*), sizeof (UINT16));
  
if ((Packet->SenseDataLength != 0) && (Packet->SenseData != NULL)) {

-CopyMem (Packet->SenseData, Response->SenseData, SenseDataLen);
-Packet->SenseDataLength = (UINT8)SenseDataLen;
+//
+// Make sure the hardware device does not return more data than expected.
+//
+if (SenseDataLen <= Packet->SenseDataLength) {
+  CopyMem (Packet->SenseData, Response->SenseData, SenseDataLen);
+  Packet->SenseDataLength = (UINT8)SenseDataLen;
+} else {
+  Packet->SenseDataLength = 0;
+}
}
  
//

diff --git a/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThruHci.c 
b/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThruHci.c
index 5756f637fd..0238264878 100644
--- a/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThruHci.c
+++ b/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThruHci.c
@@ -833,6 +833,7 @@ UfsStopExecCmd (
@param[in] QueryResp  Pointer to the query response.
  
@retval EFI_INVALID_PARAMETER Packet or QueryResp are empty or opcode is invalid.

+  @retval EFI_DEVICE_ERROR  Data returned from device is invalid.
@retval EFI_SUCCESS   Data extracted.
  
  **/

@@ -853,6 +854,13 @@ UfsGetReturnDataFromQueryResponse (
  case UtpQueryFuncOpcodeRdDesc:
ReturnDataSize = QueryResp->Tsf.Length;
SwapLittleEndianToBigEndian ((UINT8*), sizeof (UINT16));
+  //
+  // Make sure the hardware device does not return more data than expected.
+  //
+  if (ReturnDataSize > Packet->TransferLength) {
+return EFI_DEVICE_ERROR;
+  }
+
CopyMem (Packet->DataBuffer, (QueryResp + 1), ReturnDataSize);
Packet->TransferLength = ReturnDataSize;
break;
@@ -1469,8 +1477,15 @@ UfsExecScsiCmds (
SwapLittleEndianToBigEndian ((UINT8*), sizeof (UINT16));
  
if ((Packet->SenseDataLength != 0) && (Packet->SenseData != NULL)) {

-CopyMem (Packet->SenseData, Response->SenseData, SenseDataLen);
-Packet->SenseDataLength = (UINT8)SenseDataLen;
+//
+// Make sure the hardware device does not return more data than expected.
+//
+if (SenseDataLen <= Packet->SenseDataLength) {
+  CopyMem (Packet->SenseData, Response->SenseData, SenseDataLen);
+  Packet->SenseDataLength = (UINT8)SenseDataLen;
+} else {
+  Packet->SenseDataLength = 0;
+}
}
  
//

@@ -2226,8 +2241,15 @@ ProcessAsyncTaskList (
  SwapLittleEndianToBigEndian ((UINT8*), sizeof (UINT16));
  
  if ((Packet->SenseDataLength != 0) && (Packet->SenseData != NULL)) {

-  CopyMem (Packet->SenseData, Response->SenseData, SenseDataLen);
-  Packet->SenseDataLength = (UINT8)SenseDataLen;
+  //
+  // Make sure the hardware device does not return more data than 
expected.
+  //
+  if (SenseDataLen <= Packet->SenseDataLength) {
+CopyMem (Packet->SenseData, Response->SenseData, SenseDataLen);
+Packet->SenseDataLength = (UINT8)SenseDataLen;
+  } else {
+Packet->SenseDataLength = 0;
+  }
  }
  
  //




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

Re: [edk2] [Patch 1/4] UefiCpuPkg/Include/AcpiCpuData.h: Add Semaphore related Information.

2018-10-15 Thread Dong, Eric

Hi Ruiyu,

> -Original Message-
> From: Ni, Ruiyu
> Sent: Tuesday, October 16, 2018 10:27 AM
> To: Dong, Eric ; edk2-devel@lists.01.org
> Cc: Laszlo Ersek 
> Subject: Re: [Patch 1/4] UefiCpuPkg/Include/AcpiCpuData.h: Add
> Semaphore related Information.
> 
> On 10/15/2018 10:49 AM, Eric Dong wrote:
> > In order to support semaphore related logic, add new definition for it.
> >
> > Cc: Ruiyu Ni 
> > Cc: Laszlo Ersek 
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Eric Dong 
> > ---
> >   UefiCpuPkg/Include/AcpiCpuData.h | 23 ++-
> >   1 file changed, 22 insertions(+), 1 deletion(-)
> >
> > diff --git a/UefiCpuPkg/Include/AcpiCpuData.h
> > b/UefiCpuPkg/Include/AcpiCpuData.h
> > index 9e51145c08..b3cf2f664a 100644
> > --- a/UefiCpuPkg/Include/AcpiCpuData.h
> > +++ b/UefiCpuPkg/Include/AcpiCpuData.h
> > @@ -15,6 +15,8 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF
> ANY KIND, EITHER EXPRESS OR IMPLIED.
> >   #ifndef _ACPI_CPU_DATA_H_
> >   #define _ACPI_CPU_DATA_H_
> >
> > +#include 
> > +
> >   //
> >   // Register types in register table
> >   //
> > @@ -22,9 +24,20 @@ typedef enum {
> > Msr,
> > ControlRegister,
> > MemoryMapped,
> > -  CacheControl
> > +  CacheControl, > +  Semaphore
> I assume the REGISTER_TYPE definition will be move to internal
> (non-public) in phase 2.
> 

Yes.

> >   } REGISTER_TYPE;
> >
> > +//
> > +// CPU information.
> > +//
> > +typedef struct {
> > +  UINT32PackageCount; // Packages in this CPU.
> > +  UINT32CoreCount;// Max Core count in the 
> > packages.
> > +  UINT32ThreadCount;  // MAx thread count in the cores.
> > +  UINT32*ValidCoresInPackages;// Valid cores in each package.
> 
> Can you please add more comments to describe each field above?

Will add more comments in the next version.

> PackageCount is easy to understand.
> But CoreCount is not. Maybe different packages have different number of
> cores. In this case, what value will CoreCount be?
> Similar question to ThreadCount.

CoreCount means the max core count in the CPU.  ThreadCount means max thread 
count in the CPU. Will add comments in next version change.

> 
> What does ValidCoresInPackages mean? Does it hold the valid (non-dead)
> core numbers for each package? So it's a UINT32 array with PackageCount
> elements?

Yes.

> How about using name ValidCoreCountPerPackage?
> How about using MaxCoreCount/MaxThreadCount for CoreCount and
> ThreadCount?
> 

Ok, will use these names in next version.

> > +} CPU_STATUS_INFORMATION;
> > +
> >   //
> >   // Element of register table entry
> >   //
> > @@ -147,6 +160,14 @@ typedef struct {
> > // provided.
> > //
> > UINT32ApMachineCheckHandlerSize;
> > +  //
> > +  // CPU information which is required when set the register table.
> > +  //
> > +  CPU_STATUS_INFORMATION CpuStatus;
> > +  //
> > +  // Location info for each ap.
> > +  //
> > +  EFI_CPU_PHYSICAL_LOCATION  *ApLocation;
> 
> Please use EFI_PHYSICAL_ADDRESS for ApLocation. It's ok now. But if there
> are more fields below ApLocation, the offset of those fields differs between
> PEI and DXE. That will cause bugs.
> 

Yes,  update code in next version.

> >   } ACPI_CPU_DATA;
> >
> >   #endif
> >
> 
> 
> --
> Thanks,
> Ray
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] PACKAGES_PATH in !include path in Dsc files

2018-10-15 Thread Pankaj Bansal




> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Tuesday, October 16, 2018 8:41 AM
> To: Pankaj Bansal 
> Cc: Gao, Liming ; Zhu, Yonghong
> ; Leif Lindholm ; Michael
> D Kinney ; edk2-devel@lists.01.org; Udit Kumar
> ; Varun Sethi 
> Subject: Re: PACKAGES_PATH in !include path in Dsc files
> 
> On 16 October 2018 at 10:40, Pankaj Bansal  wrote:
> > +edk2-platforms maintainers in To list
> >
> >
> >
> > Thank you Liming for replying.
> >
> >
> >
> > Our entire code is in edk2-platforms
> > (https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
> > thub.com%2Ftianocore%2Fedk2-
> platformsdata=02%7C01%7Cpankaj.bansal%40nxp.com%7C552da3f22b5
> 84b7fac6008d63315ec8b%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0
> %7C636752566592695047sdata=JJWbAcZkj%2FtFaZC0bWONPb7ulCcj1L2
> 4VKwCDGDx9OE%3Dreserved=0) which is denoted by PACKAGES_PATH.
> >
> > The PACKAGES_PATH directory can be anywhere in WORKSPACE depending on
> > the sync directory defined by user.
> >
> > i.e. it can be $(WORKSPACE)/edk2-platforms or $(WORKSPACE)/ > directory name that user can define during git sync>
> >
> > As our dsc files are relative to PACKAGES_PATH, I want to specify
> > their path in dsc file like this:
> >
> >
> >
> > !include $(PACKAGES_PATH)/Silicon/NXP/.dsc
> >
> >
> >
> > Using $(WORKSPACE), I cannot specify above path, as it can be at place
> > other than $(WORKSPACE)/edk2-platforms
> >
> 
> But why do you need to !include things in the first place?
> 
> Can you explain how you are trying to organize the files, and which file 
> includes
> which?

I am trying to keep Silicon (SOC) specific dsc file in Silicon/NXP//
This silicon can be used in multiple Boards (Platforms).
All these Platforms are present in Platform/NXP/
fd/fv binaries would be created for each platform.
The chassis dsc file has description of components/PCDs that are specific to 
chassis to which the silicon belongs. It would be same for all silicons that 
belong to same chassis.
The Silicon dsc file has description of components/PCDs that are specific to 
silicon and would be same for all platforms that use this silicon. It would 
include chassis dsc file
The Platform dsc file would include the silicon dsc file.

___
| Platform (in Platform/NXP)|
|_  |
|   | Silicon (in Silicon/NXP/) | |
|   |   ___| |
|   |  | Chassis  (in Silicon/NXP) |   ||
|   |  |__|   | |
|   || |
|_|

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

Re: [edk2] [PATCH 10/11] MdeModulePkg/UsbBus: Deny when the string descriptor length is odd


On 2018/10/15 14:38, Ruiyu Ni wrote:

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Jiewen Yao 
Cc: Star Zeng 
---
  MdeModulePkg/Bus/Usb/UsbBusDxe/UsbDesc.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbDesc.c 
b/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbDesc.c
index d9bc1f9e28..182a3f97c9 100644
--- a/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbDesc.c
+++ b/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbDesc.c
@@ -650,7 +650,7 @@ UsbGetOneString (
//
Status = UsbCtrlGetDesc (UsbDev, USB_DESC_TYPE_STRING, Index, LangId, 
, 2);
  
-  if (EFI_ERROR (Status)) {

+  if (EFI_ERROR (Status) || (Desc.Length % 2 != 0)) {


Ray,

Thanks for the patch.

Does the code need check (Desc.Length < 2) first as Desc.Length may be 0 
or 1, right?



Thanks,
Star


  return NULL;
}
  



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

Re: [edk2] [PATCH 09/11] MdeModulePkg/UsbMouse: Don't access key codes when length is wrong


On 2018/10/15 14:38, Ruiyu Ni wrote:

Per USB HID spec, the buffer holding key codes should at least 3-byte
long.
Today's code assumes that the key codes buffer length is longer than
3-byte and unconditionally accesses the key codes buffer.
It's incorrect.
The patch fixes the issue by returning Device Error when the
length is less than 3-byte.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Star Zeng 
Cc: Jiewen Yao 
Cc: Steven Shi 
---
  MdeModulePkg/Bus/Usb/UsbMouseDxe/UsbMouse.c | 8 ++--
  1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Bus/Usb/UsbMouseDxe/UsbMouse.c 
b/MdeModulePkg/Bus/Usb/UsbMouseDxe/UsbMouse.c
index 9324994975..d4bcf15929 100644
--- a/MdeModulePkg/Bus/Usb/UsbMouseDxe/UsbMouse.c
+++ b/MdeModulePkg/Bus/Usb/UsbMouseDxe/UsbMouse.c
@@ -811,8 +811,6 @@ OnMouseInterruptComplete (
  return EFI_SUCCESS;
}
  
-  UsbMouseDevice->StateChanged = TRUE;

-
//
// Check mouse Data
// USB HID Specification specifies following data format:
@@ -825,6 +823,12 @@ OnMouseInterruptComplete (
// 2   0 to 7  Y displacement
// 3 to n  0 to 7  Device specific (optional)
//
+  if ((Data != NULL) && (DataLength < 3)) {
+return EFI_DEVICE_ERROR;
+  }


Ray,

Thanks for the patch.
Data is impossible to be NULL here as the NULL check to Data has been 
done by code piece


   //
   // If no error and no data, just return EFI_SUCCESS.
   //
   if (DataLength == 0 || Data == NULL) {
 return EFI_SUCCESS;
   }

Thanks,
Star


+
+  UsbMouseDevice->StateChanged = TRUE;
+
UsbMouseDevice->State.LeftButton  = (BOOLEAN) ((*(UINT8 *) Data & BIT0) != 
0);
UsbMouseDevice->State.RightButton = (BOOLEAN) ((*(UINT8 *) Data & BIT1) != 
0);
UsbMouseDevice->State.RelativeMovementX += *((INT8 *) Data + 1);



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

Re: [edk2] [PATCH 08/11] MdeModulePkg/AbsPointer: Don't access key codes when length is wrong


On 2018/10/15 14:38, Ruiyu Ni wrote:

Per USB HID spec, the buffer holding key codes should at least 3-byte
long.
Today's code assumes that the key codes buffer length is longer than
3-byte and unconditionally accesses the key codes buffer.
It's incorrect.
The patch fixes the issue by returning Device Error when the
length is less than 3-byte.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Star Zeng 
Cc: Jiewen Yao 
Cc: Steven Shi 
---
  .../Bus/Usb/UsbMouseAbsolutePointerDxe/UsbMouseAbsolutePointer.c  | 8 ++--
  1 file changed, 6 insertions(+), 2 deletions(-)

diff --git 
a/MdeModulePkg/Bus/Usb/UsbMouseAbsolutePointerDxe/UsbMouseAbsolutePointer.c 
b/MdeModulePkg/Bus/Usb/UsbMouseAbsolutePointerDxe/UsbMouseAbsolutePointer.c
index 965195ca34..b4638961d9 100644
--- a/MdeModulePkg/Bus/Usb/UsbMouseAbsolutePointerDxe/UsbMouseAbsolutePointer.c
+++ b/MdeModulePkg/Bus/Usb/UsbMouseAbsolutePointerDxe/UsbMouseAbsolutePointer.c
@@ -813,8 +813,6 @@ OnMouseInterruptComplete (
  return EFI_SUCCESS;
}
  
-  UsbMouseAbsolutePointerDevice->StateChanged = TRUE;

-
//
// Check mouse Data
// USB HID Specification specifies following data format:
@@ -827,6 +825,12 @@ OnMouseInterruptComplete (
// 2   0 to 7  Y displacement
// 3 to n  0 to 7  Device specific (optional)
//
+  if ((Data != NULL) && (DataLength < 3)) {
+return EFI_DEVICE_ERROR;
+  }


Ray,

Thanks for the patch.
Data is impossible to be NULL here as the NULL check to Data has been 
done by code piece


   //
   // If no error and no data, just return EFI_SUCCESS.
   //
   if (DataLength == 0 || Data == NULL) {
 return EFI_SUCCESS;
   }

Thanks,
Star


+
+  UsbMouseAbsolutePointerDevice->StateChanged = TRUE;
+
UsbMouseAbsolutePointerDevice->State.ActiveButtons = *(UINT8 *) Data & 
(BIT0 | BIT1 | BIT2);
  
UsbMouseAbsolutePointerDevice->State.CurrentX =




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

Re: [edk2] [PATCH 07/11] MdeModulePkg/UsbKb: Don't access key codes when length is wrong


On 2018/10/15 14:38, Ruiyu Ni wrote:

Per USB HID spec, the buffer holding key codes should be 8-byte
long.
Today's code assumes that the key codes buffer length is 8-byte
long and unconditionally accesses the key codes buffer.
It's incorrect.
The patch fixes the issue by returning Device Error when the
length is less than 8-byte.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Star Zeng 
Cc: Jiewen Yao 
Cc: Steven Shi 
---
  MdeModulePkg/Bus/Usb/UsbKbDxe/KeyBoard.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/MdeModulePkg/Bus/Usb/UsbKbDxe/KeyBoard.c 
b/MdeModulePkg/Bus/Usb/UsbKbDxe/KeyBoard.c
index 9cb4b5db6b..384d7e2f07 100644
--- a/MdeModulePkg/Bus/Usb/UsbKbDxe/KeyBoard.c
+++ b/MdeModulePkg/Bus/Usb/UsbKbDxe/KeyBoard.c
@@ -1059,6 +1059,10 @@ KeyboardHandler (
// Byte 1 is reserved.
// Bytes 2 to 7 are keycodes.
//
+  if ((Data != NULL) && (DataLength < 8)) {
+return EFI_DEVICE_ERROR;
+  }


Ray,

Thanks for the patch.
The NULL check to Data has been done by code piece

  //
  // If no error and no data, just return EFI_SUCCESS.
  //
  if (DataLength == 0 || Data == NULL) {
return EFI_SUCCESS;
  }

And do you think whether the code can use DataLength != 8 instead of 
DataLength < 8?


Thanks,
Star


+
CurKeyCodeBuffer  = (UINT8 *) Data;
OldKeyCodeBuffer  = UsbKeyboardDevice->LastKeyCodeArray;
  



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

Re: [edk2] [PATCH 05/11] MdeModulePkg/Usb: Make sure data from HW is no more than expected


On 2018/10/15 14:38, Ruiyu Ni wrote:

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Jiewen Yao 
Cc: Star Zeng 
Cc: Hao A Wu 


Ray,

Thanks for the patch.
Reviewed-by: Star Zeng 

Star


---
  MdeModulePkg/Bus/Pci/EhciDxe/EhciSched.c | 9 ++---
  MdeModulePkg/Bus/Pci/UhciDxe/UhciSched.c | 7 ---
  MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c | 9 ++---
  3 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/EhciDxe/EhciSched.c 
b/MdeModulePkg/Bus/Pci/EhciDxe/EhciSched.c
index fea6f47f4c..168280be81 100644
--- a/MdeModulePkg/Bus/Pci/EhciDxe/EhciSched.c
+++ b/MdeModulePkg/Bus/Pci/EhciDxe/EhciSched.c
@@ -1009,9 +1009,12 @@ EhcMonitorAsyncRequests (
  ProcBuf = NULL;
  
  if (Urb->Result == EFI_USB_NOERROR) {

-  ASSERT (Urb->Completed <= Urb->DataLen);
-
-  ProcBuf = AllocatePool (Urb->Completed);
+  //
+  // Make sure the data received from HW is no more than expected.
+  //
+  if (Urb->Completed <= Urb->DataLen) {
+ProcBuf = AllocatePool (Urb->Completed);
+  }
  
if (ProcBuf == NULL) {

  EhcUpdateAsyncRequest (Ehc, Urb);
diff --git a/MdeModulePkg/Bus/Pci/UhciDxe/UhciSched.c 
b/MdeModulePkg/Bus/Pci/UhciDxe/UhciSched.c
index 90f010c998..f7510f3ec0 100644
--- a/MdeModulePkg/Bus/Pci/UhciDxe/UhciSched.c
+++ b/MdeModulePkg/Bus/Pci/UhciDxe/UhciSched.c
@@ -2,7 +2,7 @@
  
The EHCI register operation routines.
  
-Copyright (c) 2007 - 2013, Intel Corporation. All rights reserved.

+Copyright (c) 2007 - 2018, 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
@@ -1001,11 +1001,12 @@ UhciMonitorAsyncReqList (
  
  //

  // Copy the data to temporary buffer if there are some
-// data transferred. We may have zero-length packet
+// data transferred. We may have zero-length packet.
+// Make sure the data received from HW is no more than expected.
  //
  Data = NULL;
  
-if (QhResult.Complete != 0) {

+if ((QhResult.Complete != 0) && (QhResult.Complete <= AsyncReq->DataLen)) {
Data = AllocatePool (QhResult.Complete);
  
if (Data == NULL) {

diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c 
b/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c
index 6a2ef4cd5d..166c44bf5e 100644
--- a/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c
+++ b/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c
@@ -1556,9 +1556,12 @@ XhcMonitorAsyncRequests (
  //
  ProcBuf = NULL;
  if (Urb->Result == EFI_USB_NOERROR) {
-  ASSERT (Urb->Completed <= Urb->DataLen);
-
-  ProcBuf = AllocateZeroPool (Urb->Completed);
+  //
+  // Make sure the data received from HW is no more than expected.
+  //
+  if (Urb->Completed <= Urb->DataLen) {
+ProcBuf = AllocateZeroPool (Urb->Completed);
+  }
  
if (ProcBuf == NULL) {

  XhcUpdateAsyncRequest (Xhc, Urb);



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

Re: [edk2] [Patch 1/4] UefiCpuPkg/Include/AcpiCpuData.h: Add Semaphore related Information.

2018-10-15 Thread Dong, Eric

Hi Laszlo,

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Tuesday, October 16, 2018 12:03 AM
> To: Dong, Eric ; edk2-devel@lists.01.org
> Cc: Ni, Ruiyu 
> Subject: Re: [Patch 1/4] UefiCpuPkg/Include/AcpiCpuData.h: Add
> Semaphore related Information.
> 
> On 10/15/18 04:49, Eric Dong wrote:
> > In order to support semaphore related logic, add new definition for it.
> >
> > Cc: Ruiyu Ni 
> > Cc: Laszlo Ersek 
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Eric Dong 
> > ---
> >  UefiCpuPkg/Include/AcpiCpuData.h | 23 ++-
> >  1 file changed, 22 insertions(+), 1 deletion(-)
> 
> (1) If it's possible, I suggest moving the (very nice) description from the 
> 0/4
> cover letter to this patch. The cover letter is not captured in the git commit
> history.
> 
> I don't insist, but it would be a nice touch, IMO.

Code change for this patch can't show all the information for the description. 
I add this description in 3/4 change.  
But this change is the first one for this serial, I think it's ok to add 
description here. Will add it in V2 change.

> 
> >
> > diff --git a/UefiCpuPkg/Include/AcpiCpuData.h
> > b/UefiCpuPkg/Include/AcpiCpuData.h
> > index 9e51145c08..b3cf2f664a 100644
> > --- a/UefiCpuPkg/Include/AcpiCpuData.h
> > +++ b/UefiCpuPkg/Include/AcpiCpuData.h
> > @@ -15,6 +15,8 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF
> ANY KIND, EITHER EXPRESS OR IMPLIED.
> >  #ifndef _ACPI_CPU_DATA_H_
> >  #define _ACPI_CPU_DATA_H_
> >
> > +#include 
> > +
> >  //
> >  // Register types in register table
> >  //
> > @@ -22,9 +24,20 @@ typedef enum {
> >Msr,
> >ControlRegister,
> >MemoryMapped,
> > -  CacheControl
> > +  CacheControl,
> > +  Semaphore
> >  } REGISTER_TYPE;
> >
> > +//
> > +// CPU information.
> > +//
> > +typedef struct {
> > +  UINT32PackageCount; // Packages in this CPU.
> 
> (2) Is it possible to have multiple packages in a single CPU? If not, then 
> please
> clean up the comment.
> 
> Did you perhaps mean "number of sockets in the system"?

Yes, I means sockets in the system, i think socket == package. Just like below 
definition in MdePkg\Include\Protocol\MpService.h file, it use package instead 
of socket.
///
/// Structure that describes the pyhiscal location of a logical CPU.
///
typedef struct {
  ///
  /// Zero-based physical package number that identifies the cartridge 
of the processor.
  ///
  UINT32  Package;
  ///
  /// Zero-based physical core number within package of the processor.
  ///
  UINT32  Core;
  ///
  /// Zero-based logical thread number within core of the processor.
  ///
  UINT32  Thread;
} EFI_CPU_PHYSICAL_LOCATION;


> 
> > +  UINT32CoreCount;// Max Core count in the 
> > packages.
> > +  UINT32ThreadCount;  // MAx thread count in the cores.
> 
> (3) The word "MAx" should be "Max", I think.

Yes, will update it in next version.

> 
> > +  UINT32*ValidCoresInPackages;// Valid cores in each package.
> 
> (4) Is it possible to document the structure of this array (?) in some detail?
> Other parts of "UefiCpuPkg/Include/AcpiCpuData.h" are very well
> documented.

Yes, will add description in next version.

> 
> > +} CPU_STATUS_INFORMATION;
> > +
> >  //
> >  // Element of register table entry
> >  //
> > @@ -147,6 +160,14 @@ typedef struct {
> >// provided.
> >//
> >UINT32ApMachineCheckHandlerSize;
> > +  //
> > +  // CPU information which is required when set the register table.
> > +  //
> > +  CPU_STATUS_INFORMATION CpuStatus;
> > +  //
> > +  // Location info for each ap.
> 
> (5) This header file spells "AP" in upper case elsewhere.

Ok, will update it in next version

> 
> > +  //
> > +  EFI_CPU_PHYSICAL_LOCATION  *ApLocation;
> 
> (6) Is this supposed to be an array? If so, what is the structure of the 
> array?
> What is the size?

Yes, it's point to an array.  Will add comments in this definition in next 
version.

> 
> (7) This is the first field in ACPI_CPU_DATA that has pointer type.
> Other pointers are represented as EFI_PHYSICAL_ADDRESS.
> 
> What justifies this difference?

Yes, here I should use EFI_PHYSICAL_ADDRESS instead of pointer type. Will 
update it in my next change.

> >  } ACPI_CPU_DATA;
> >
> >  #endif
> >
> 
> (8) "UefiCpuPkg/CpuS3DataDxe/CpuS3Data.c" will zero-fill the new fields.
> Is that safe?

It's not safe, I missed code change in CpuS3DataDxe, it should keep these data 
if OldAcpiCpuData already exist. Will update it in the next version.

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

Re: [edk2] [PATCH 04/11] MdeModulePkg/UsbBus: Reject descriptor whose length is bad


On 2018/10/15 14:38, Ruiyu Ni wrote:

Today's implementation doesn't check whether the length of
descriptor is valid before using it.

The patch fixes this issue.

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


Ray,

Thanks for the patch.
Reviewed-by: Star Zeng 

Star


---
  MdeModulePkg/Bus/Usb/UsbBusDxe/UsbDesc.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbDesc.c 
b/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbDesc.c
index a93060deea..d9bc1f9e28 100644
--- a/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbDesc.c
+++ b/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbDesc.c
@@ -767,6 +767,13 @@ UsbGetOneConfig (
  
DEBUG (( EFI_D_INFO, "UsbGetOneConfig: total length is %d\n", Desc.TotalLength));
  
+  //

+  // Reject if TotalLength even cannot cover itself.
+  //
+  if (Desc.TotalLength < OFFSET_OF (EFI_USB_CONFIG_DESCRIPTOR, TotalLength) + 
sizeof (Desc.TotalLength)) {
+return NULL;
+  }
+
Buf = AllocateZeroPool (Desc.TotalLength);
  
if (Buf == NULL) {




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

[edk2] [PATCH] Edk2Platforms: Replace FatBinPkg with FatPkg

2018-10-15 Thread shenglei

In order to remove FatBinPkg, relationships depend on
FatBinPkg need to be replaced by FatPkg in fdf. And
FatPkg needs to be added in dsc.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang 
---
 Platform/ARM/JunoPkg/ArmJuno.dsc | 1 +
 Platform/ARM/JunoPkg/ArmJuno.fdf | 2 +-
 Platform/ARM/SgiPkg/SgiPlatform.dsc  | 1 +
 Platform/ARM/SgiPkg/SgiPlatform.fdf  | 2 +-
 Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc| 2 +-
 Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.fdf| 2 +-
 Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc | 1 +
 Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.fdf | 2 +-
 Platform/Hisilicon/D03/D03.dsc   | 1 +
 Platform/Hisilicon/D03/D03.fdf   | 2 +-
 Platform/Hisilicon/D05/D05.dsc   | 1 +
 Platform/Hisilicon/D05/D05.fdf   | 2 +-
 Platform/Hisilicon/HiKey/HiKey.dsc   | 1 +
 Platform/Hisilicon/HiKey/HiKey.fdf   | 2 +-
 Platform/Hisilicon/HiKey960/HiKey960.dsc | 1 +
 Platform/Hisilicon/HiKey960/HiKey960.fdf | 2 +-
 Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc| 1 +
 Silicon/Marvell/Armada7k8k/Armada7k8k.fdf| 2 +-
 18 files changed, 18 insertions(+), 10 deletions(-)

diff --git a/Platform/ARM/JunoPkg/ArmJuno.dsc b/Platform/ARM/JunoPkg/ArmJuno.dsc
index 8d6dd0207d..ac3d63bd4d 100644
--- a/Platform/ARM/JunoPkg/ArmJuno.dsc
+++ b/Platform/ARM/JunoPkg/ArmJuno.dsc
@@ -293,6 +293,7 @@
   MdeModulePkg/Universal/Disk/DiskIoDxe/DiskIoDxe.inf
   MdeModulePkg/Universal/Disk/PartitionDxe/PartitionDxe.inf
   MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf
+  FatPkg/EnhancedFatDxe/Fat.inf
 
   # Required by PCI
   ArmPkg/Drivers/ArmPciCpuIo2Dxe/ArmPciCpuIo2Dxe.inf
diff --git a/Platform/ARM/JunoPkg/ArmJuno.fdf b/Platform/ARM/JunoPkg/ArmJuno.fdf
index c538a9b754..0a8b636d0e 100644
--- a/Platform/ARM/JunoPkg/ArmJuno.fdf
+++ b/Platform/ARM/JunoPkg/ArmJuno.fdf
@@ -142,7 +142,7 @@ FvNameGuid = B73FE497-B92E-416e-8326-45AD0D270092
   #
   INF MdeModulePkg/Universal/Disk/DiskIoDxe/DiskIoDxe.inf
   INF MdeModulePkg/Universal/Disk/PartitionDxe/PartitionDxe.inf
-  INF FatBinPkg/EnhancedFatDxe/Fat.inf
+  INF FatPkg/EnhancedFatDxe/Fat.inf
   INF MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf
 
   # Required by PCI
diff --git a/Platform/ARM/SgiPkg/SgiPlatform.dsc 
b/Platform/ARM/SgiPkg/SgiPlatform.dsc
index 2d8dcff94d..3f0ca9872e 100644
--- a/Platform/ARM/SgiPkg/SgiPlatform.dsc
+++ b/Platform/ARM/SgiPkg/SgiPlatform.dsc
@@ -264,6 +264,7 @@
   MdeModulePkg/Universal/Disk/DiskIoDxe/DiskIoDxe.inf
   MdeModulePkg/Universal/Disk/PartitionDxe/PartitionDxe.inf
   MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf
+  FatPkg/EnhancedFatDxe/Fat.inf
 
   #
   # Bds
diff --git a/Platform/ARM/SgiPkg/SgiPlatform.fdf 
b/Platform/ARM/SgiPkg/SgiPlatform.fdf
index 161ff92bbd..fd87563246 100644
--- a/Platform/ARM/SgiPkg/SgiPlatform.fdf
+++ b/Platform/ARM/SgiPkg/SgiPlatform.fdf
@@ -150,7 +150,7 @@ READ_LOCK_STATUS   = TRUE
   #
   INF MdeModulePkg/Universal/Disk/DiskIoDxe/DiskIoDxe.inf
   INF MdeModulePkg/Universal/Disk/PartitionDxe/PartitionDxe.inf
-  INF FatBinPkg/EnhancedFatDxe/Fat.inf
+  INF FatPkg/EnhancedFatDxe/Fat.inf
   INF MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf
 
   # FV FileSystem
diff --git a/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc 
b/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc
index 6405d955f1..617164d42a 100644
--- a/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc
+++ b/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc
@@ -265,7 +265,7 @@
   MdeModulePkg/Universal/Disk/DiskIoDxe/DiskIoDxe.inf
   MdeModulePkg/Universal/Disk/PartitionDxe/PartitionDxe.inf
   MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf
-
+  FatPkg/EnhancedFatDxe/Fat.inf
   MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
 
   #
diff --git a/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.fdf 
b/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.fdf
index 5786f117ea..ecd57f3a3e 100644
--- a/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.fdf
+++ b/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.fdf
@@ -123,7 +123,7 @@ FvNameGuid = 73dcb643-3862-4904-9076-a94af1890243
   #
   INF MdeModulePkg/Universal/Disk/DiskIoDxe/DiskIoDxe.inf
   INF MdeModulePkg/Universal/Disk/PartitionDxe/PartitionDxe.inf
-  INF FatBinPkg/EnhancedFatDxe/Fat.inf
+  INF FatPkg/EnhancedFatDxe/Fat.inf
   INF MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf
 
   # Versatile Express FileSystem
diff --git a/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc 
b/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc
index ca19fd6526..d20f1a7387 100644
--- a/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc
+++

Re: [edk2] [PATCH 03/11] MdeModulePkg/UsbBus: Fix out-of-bound read access to descriptors


On 2018/10/15 14:38, Ruiyu Ni wrote:

Today's implementation reads the Type/Length field in the USB
descriptors data without checking whether the offset to read is
beyond the data boundary.

The patch fixes this issue.

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


Ray,

Thanks for the patch.
I have two minor comments.
You can take them as you wish as I have no strong opinion for them. :)
Reviewed-by: Star Zeng 


---
  MdeModulePkg/Bus/Usb/UsbBusDxe/UsbDesc.c | 50 
  1 file changed, 38 insertions(+), 12 deletions(-)

diff --git a/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbDesc.c 
b/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbDesc.c
index 061e4622e8..a93060deea 100644
--- a/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbDesc.c
+++ b/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbDesc.c
@@ -177,6 +177,17 @@ UsbCreateDesc (
  DescLen = sizeof (EFI_USB_ENDPOINT_DESCRIPTOR);
  CtrlLen = sizeof (USB_ENDPOINT_DESC);
  break;
+
+  default:
+ASSERT (FALSE);
+return NULL;
+  }
+
+  //
+  // Total length is too small that cannot hold the single descriptor header 
plus data.
+  //
+  if (Len <= sizeof (USB_DESC_HEAD)) {


Add debug message here like others below for error cases?


+return NULL;
}
  
//

@@ -184,24 +195,39 @@ UsbCreateDesc (
// format. Skip the descriptor that isn't of this Type
//
Offset = 0;
-  Head   = (USB_DESC_HEAD*)DescBuf;
+  Head   = (USB_DESC_HEAD *)DescBuf;
+  while (Offset < Len - sizeof (USB_DESC_HEAD)) {
+//
+// Above condition make sure Head->Len and Head->Type are safe to access
+//
+Head = (USB_DESC_HEAD *)[Offset];
  
-  while ((Offset < Len) && (Head->Type != Type)) {

-Offset += Head->Len;
-if (Len <= Offset) {
-  DEBUG (( EFI_D_ERROR, "UsbCreateDesc: met mal-format descriptor, Beyond 
boundary!\n"));
+if (Head->Len == 0) {
+  DEBUG ((DEBUG_ERROR, "UsbCreateDesc: met mal-format descriptor, Head->Len = 
0!\n"));
return NULL;
  }
-Head= (USB_DESC_HEAD*)(DescBuf + Offset);
-if (Head->Len == 0) {
-  DEBUG (( EFI_D_ERROR, "UsbCreateDesc: met mal-format descriptor, Head->Len = 
0!\n"));
+
+//
+// Make sure no overflow when adding Head->Len to Offset.
+//
+if (Head->Len > MAX_UINTN - Offset) {
+  DEBUG ((DEBUG_ERROR, "UsbCreateDesc: met mal-format descriptor, Head->Len = 
%d!\n", Head->Len));
return NULL;
  }
+
+Offset += Head->Len;
+
+if (Head->Type == Type) {
+  break;
+}
}
  
-  if ((Len <= Offset)  || (Len < Offset + Head->Len) ||

-  (Head->Type != Type) || (Head->Len < DescLen)) {
-DEBUG (( EFI_D_ERROR, "UsbCreateDesc: met mal-format descriptor\n"));
+  //
+  // Head->Len is invalid resulting data beyond boundary, or
+  // Descriptor cannot be found: No such type.
+  //
+  if ((Len < Offset) || (Head->Type != Type) || (Head->Len < DescLen)) {
+DEBUG (( EFI_D_ERROR, "UsbCreateDesc: met mal-format descriptor. Offset/Len = %d/%d, 
Header(T/L) = %d/%d\n", Offset, Len, Head->Type, Head->Len));


How about splitting the condition check and debug message to two? :)

if (Len < Offset) { // It is boundary check.

if ((Head->Type != Type) || (Head->Len < DescLen)) { // It is content check.


Thanks,
Star


  return NULL;
}
  
@@ -212,7 +238,7 @@ UsbCreateDesc (
  
CopyMem (Desc, Head, (UINTN) DescLen);
  
-  *Consumed = Offset + Head->Len;

+  *Consumed = Offset;
  
return Desc;

  }



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

Re: [edk2] [PATCH 02/11] MdeModulePkg/UsbMass: Fix integer overflow when BlockSize is 1


On 10/16/2018 11:19 AM, Zeng, Star wrote:

On 2018/10/15 14:38, Ruiyu Ni wrote:

UsbBootReadWriteBlocks() and UsbBootReadWriteBlocks16() use a UINT16
local variable to hold the value of
USB_BOOT_MAX_CARRY_SIZE (=0x1) / BlockSize.
When BlockSize is 1, the UINT16 local variable is set to 0x1


Ray,

Thanks for the patch.
Is it possible that the BlockSize == 0 or > USB_BOOT_MAX_CARRY_SIZE?


With a buggy HW, everything is possible:(

I will re-post V2 patch to handle this case.




Thanks,
Star



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



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

Re: [edk2] [PATCH 02/11] MdeModulePkg/UsbMass: Fix integer overflow when BlockSize is 1


On 2018/10/15 14:38, Ruiyu Ni wrote:

UsbBootReadWriteBlocks() and UsbBootReadWriteBlocks16() use a UINT16
local variable to hold the value of
USB_BOOT_MAX_CARRY_SIZE (=0x1) / BlockSize.
When BlockSize is 1, the UINT16 local variable is set to 0x1


Ray,

Thanks for the patch.
Is it possible that the BlockSize == 0 or > USB_BOOT_MAX_CARRY_SIZE?


Thanks,
Star



but the high-16 bits are truncated resulting the final value be 0.

It causes the while-loop in the two functions accesses 0 block in
each loop, resulting the loop never ends.

The patch fixes the two functions to make sure no integer overflow
happens.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Star Zeng 
Cc: Steven Shi 
---
  .../Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c| 27 +++---
  1 file changed, 14 insertions(+), 13 deletions(-)

diff --git a/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c 
b/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c
index 581571ab45..37fbeedbeb 100644
--- a/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c
+++ b/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c
@@ -815,14 +815,14 @@ UsbBootReadWriteBlocks (
  {
USB_BOOT_READ_WRITE_10_CMD Cmd;
EFI_STATUS Status;
-  UINT16 Count;
-  UINT16 CountMax;
+  UINT32 Count;
+  UINT32 CountMax;
UINT32 BlockSize;
UINT32 ByteSize;
UINT32 Timeout;
  
BlockSize = UsbMass->BlockIoMedia.BlockSize;

-  CountMax = (UINT16)(USB_BOOT_MAX_CARRY_SIZE / BlockSize);
+  CountMax  = USB_BOOT_MAX_CARRY_SIZE / BlockSize;
Status= EFI_SUCCESS;
  
while (TotalBlock > 0) {

@@ -831,8 +831,9 @@ UsbBootReadWriteBlocks (
  // on the device. We must split the total block because the READ10
  // command only has 16 bit transfer length (in the unit of block).
  //
-Count = (UINT16)((TotalBlock < CountMax) ? TotalBlock : CountMax);
-ByteSize  = (UINT32)Count * BlockSize;
+Count= (UINT32)MIN (TotalBlock, CountMax);
+Count= MIN (MAX_UINT16, Count);
+ByteSize = Count * BlockSize;
  
  //

  // USB command's upper limit timeout is 5s. [USB2.0-9.2.6.1]
@@ -847,7 +848,7 @@ UsbBootReadWriteBlocks (
  Cmd.OpCode  = Write ? USB_BOOT_WRITE10_OPCODE : USB_BOOT_READ10_OPCODE;
  Cmd.Lun = (UINT8) (USB_BOOT_LUN (UsbMass->Lun));
  WriteUnaligned32 ((UINT32 *) Cmd.Lba, SwapBytes32 (Lba));
-WriteUnaligned16 ((UINT16 *) Cmd.TransferLen, SwapBytes16 (Count));
+WriteUnaligned16 ((UINT16 *) Cmd.TransferLen, SwapBytes16 ((UINT16)Count));
  
  Status = UsbBootExecCmdWithRetry (

 UsbMass,
@@ -867,7 +868,7 @@ UsbBootReadWriteBlocks (
Lba, Count
));
  Lba+= Count;
-Buffer += Count * BlockSize;
+Buffer += ByteSize;
  TotalBlock -= Count;
}
  
@@ -897,22 +898,22 @@ UsbBootReadWriteBlocks16 (

  {
UINT8 Cmd[16];
EFI_STATUSStatus;
-  UINT16Count;
-  UINT16CountMax;
+  UINT32Count;
+  UINT32CountMax;
UINT32BlockSize;
UINT32ByteSize;
UINT32Timeout;
  
BlockSize = UsbMass->BlockIoMedia.BlockSize;

-  CountMax = (UINT16)(USB_BOOT_MAX_CARRY_SIZE / BlockSize);
+  CountMax  = USB_BOOT_MAX_CARRY_SIZE / BlockSize;
Status= EFI_SUCCESS;
  
while (TotalBlock > 0) {

  //
  // Split the total blocks into smaller pieces.
  //
-Count = (UINT16)((TotalBlock < CountMax) ? TotalBlock : CountMax);
-ByteSize  = (UINT32)Count * BlockSize;
+Count= (UINT32)MIN (TotalBlock, CountMax);
+ByteSize = Count * BlockSize;
  
  //

  // USB command's upper limit timeout is 5s. [USB2.0-9.2.6.1]
@@ -947,7 +948,7 @@ UsbBootReadWriteBlocks16 (
Lba, Count
));
  Lba+= Count;
-Buffer += Count * BlockSize;
+Buffer += ByteSize;
  TotalBlock -= Count;
}
  



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

Re: [edk2] [Patch 4/4] UefiCpuPkg/PiSmmCpuDxeSmm: Add logic to support semaphore type.


On 10/15/2018 10:49 AM, Eric Dong wrote:

Because this driver needs to set MSRs saved in normal boot phase, sync semaphore
logic from RegisterCpuFeaturesLib code which used for normal boot phase.

Detail see change SHA-1: dcdf1774212d87e2d7feb36286a408ea7475fd7b for
RegisterCpuFeaturesLib.

Cc: Ruiyu Ni 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong 
---
  UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c  | 316 -
  UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c  |   3 -
  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h |   3 +-
  3 files changed, 180 insertions(+), 142 deletions(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c
index 52ff9679d5..5a35f7a634 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c
@@ -38,9 +38,12 @@ typedef struct {
  } MP_ASSEMBLY_ADDRESS_MAP;
  
  //

-// Spin lock used to serialize MemoryMapped operation
+// Flags used when program the register.
  //
-SPIN_LOCK*mMemoryMappedLock = NULL;
+typedef struct {
+  volatile UINTN   MemoryMappedLock; // Spinlock used to program 
mmio
+  volatile UINT32  *SemaphoreCount;  // Semaphore used to program 
semaphore.
+} PROGRAM_CPU_REGISTER_FLAGS;
  
  //

  // Signal that SMM BASE relocation is complete.
@@ -62,13 +65,11 @@ AsmGetAddressMap (
  #define LEGACY_REGION_SIZE(2 * 0x1000)
  #define LEGACY_REGION_BASE(0xA - LEGACY_REGION_SIZE)
  
+PROGRAM_CPU_REGISTER_FLAGS   mCpuFlags;

  ACPI_CPU_DATAmAcpiCpuData;
  volatile UINT32  mNumberToFinish;
  MP_CPU_EXCHANGE_INFO *mExchangeInfo;
  BOOLEAN  mRestoreSmmConfigurationInS3 = FALSE;
-MP_MSR_LOCK  *mMsrSpinLocks = NULL;
-UINTNmMsrSpinLockCount;
-UINTNmMsrCount = 0;
  
  //

  // S3 boot flag
@@ -91,89 +92,6 @@ UINT8mApHltLoopCodeTemplate[] = {
 0xEB, 0xFC   // jmp $-2
 };
  
-/**

-  Get MSR spin lock by MSR index.
-
-  @param  MsrIndex   MSR index value.
-
-  @return Pointer to MSR spin lock.
-
-**/
-SPIN_LOCK *
-GetMsrSpinLockByIndex (
-  IN UINT32  MsrIndex
-  )
-{
-  UINTN Index;
-  for (Index = 0; Index < mMsrCount; Index++) {
-if (MsrIndex == mMsrSpinLocks[Index].MsrIndex) {
-  return mMsrSpinLocks[Index].SpinLock;
-}
-  }
-  return NULL;
-}
-
-/**
-  Initialize MSR spin lock by MSR index.
-
-  @param  MsrIndex   MSR index value.
-
-**/
-VOID
-InitMsrSpinLockByIndex (
-  IN UINT32  MsrIndex
-  )
-{
-  UINTNMsrSpinLockCount;
-  UINTNNewMsrSpinLockCount;
-  UINTNIndex;
-  UINTNAddedSize;
-
-  if (mMsrSpinLocks == NULL) {
-MsrSpinLockCount = mSmmCpuSemaphores.SemaphoreMsr.AvailableCounter;
-mMsrSpinLocks = (MP_MSR_LOCK *) AllocatePool (sizeof (MP_MSR_LOCK) * 
MsrSpinLockCount);
-ASSERT (mMsrSpinLocks != NULL);
-for (Index = 0; Index < MsrSpinLockCount; Index++) {
-  mMsrSpinLocks[Index].SpinLock =
-   (SPIN_LOCK *)((UINTN)mSmmCpuSemaphores.SemaphoreMsr.Msr + Index * 
mSemaphoreSize);
-  mMsrSpinLocks[Index].MsrIndex = (UINT32)-1;
-}
-mMsrSpinLockCount = MsrSpinLockCount;
-mSmmCpuSemaphores.SemaphoreMsr.AvailableCounter = 0;
-  }
-  if (GetMsrSpinLockByIndex (MsrIndex) == NULL) {
-//
-// Initialize spin lock for MSR programming
-//
-mMsrSpinLocks[mMsrCount].MsrIndex = MsrIndex;
-InitializeSpinLock (mMsrSpinLocks[mMsrCount].SpinLock);
-mMsrCount ++;
-if (mMsrCount == mMsrSpinLockCount) {
-  //
-  // If MSR spin lock buffer is full, enlarge it
-  //
-  AddedSize = SIZE_4KB;
-  mSmmCpuSemaphores.SemaphoreMsr.Msr =
-AllocatePages (EFI_SIZE_TO_PAGES(AddedSize));
-  ASSERT (mSmmCpuSemaphores.SemaphoreMsr.Msr != NULL);
-  NewMsrSpinLockCount = mMsrSpinLockCount + AddedSize / mSemaphoreSize;
-  mMsrSpinLocks = ReallocatePool (
-sizeof (MP_MSR_LOCK) * mMsrSpinLockCount,
-sizeof (MP_MSR_LOCK) * NewMsrSpinLockCount,
-mMsrSpinLocks
-);
-  ASSERT (mMsrSpinLocks != NULL);
-  mMsrSpinLockCount = NewMsrSpinLockCount;
-  for (Index = mMsrCount; Index < mMsrSpinLockCount; Index++) {
-mMsrSpinLocks[Index].SpinLock =
- (SPIN_LOCK *)((UINTN)mSmmCpuSemaphores.SemaphoreMsr.Msr +
- (Index - mMsrCount)  * mSemaphoreSize);
-mMsrSpinLocks[Index].MsrIndex = (UINT32)-1;
-  }
-}
-  }
-}
-
  /**
Sync up the MTRR values for all processors.
  
@@ -204,42 +122,89 @@ Returns:

  }
  
  /**

-  Programs registers for the calling processor.
+  Increment semaphore by 1.
  
-  This function programs registers for the calling processor.

+  @param  SemIN:  32-bit unsigned

Re: [edk2] PACKAGES_PATH in !include path in Dsc files

2018-10-15 Thread Ard Biesheuvel

On 16 October 2018 at 10:40, Pankaj Bansal  wrote:
> +edk2-platforms maintainers in To list
>
>
>
> Thank you Liming for replying.
>
>
>
> Our entire code is in edk2-platforms
> (https://github.com/tianocore/edk2-platforms) which is denoted by
> PACKAGES_PATH.
>
> The PACKAGES_PATH directory can be anywhere in WORKSPACE depending on the
> sync directory defined by user.
>
> i.e. it can be $(WORKSPACE)/edk2-platforms or $(WORKSPACE)/ name that user can define during git sync>
>
> As our dsc files are relative to PACKAGES_PATH, I want to specify their path
> in dsc file like this:
>
>
>
> !include $(PACKAGES_PATH)/Silicon/NXP/.dsc
>
>
>
> Using $(WORKSPACE), I cannot specify above path, as it can be at place other
> than $(WORKSPACE)/edk2-platforms
>

But why do you need to !include things in the first place?

Can you explain how you are trying to organize the files, and which
file includes which?
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 01/11] MdeModulePkg/UsbMass: Merge UsbBoot(Read|Write)Blocks(16)


On 2018/10/15 14:38, Ruiyu Ni wrote:

The change doesn't have functionality impact.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Star Zeng 


Ray,

Thanks for the patch.
I have a very very minor comment below.
Reviewed-by: Star Zeng .



---
  .../Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c| 248 +
  .../Bus/Usb/UsbMassStorageDxe/UsbMassBoot.h|  76 ++-
  .../Bus/Usb/UsbMassStorageDxe/UsbMassImpl.c|   8 +-
  3 files changed, 80 insertions(+), 252 deletions(-)

diff --git a/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c 
b/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c
index dd5950c54c..581571ab45 100644
--- a/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c
+++ b/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c
@@ -792,32 +792,34 @@ UsbBootDetectMedia (
  
  
  /**

-  Read some blocks from the device.
+  Read or write some blocks from the device.
  
-  @param  UsbMassThe USB mass storage device to read from

+  @param  UsbMassThe USB mass storage device to access
+  @param  Write  TRUE for write operation.
@param  LbaThe start block number
-  @param  TotalBlock Total block number to read
-  @param  Buffer The buffer to read to
+  @param  TotalBlock Total block number to read or write
+  @param  Buffer The buffer to read to or write from
  
-  @retval EFI_SUCCESSData are read into the buffer

-  @retval Others Failed to read all the data
+  @retval EFI_SUCCESSData are read into the buffer or writen into 
the device.
+  @retval Others Failed to read or write all the data
  
  **/

  EFI_STATUS
-UsbBootReadBlocks (
+UsbBootReadWriteBlocks (
IN  USB_MASS_DEVICE   *UsbMass,
+  IN  BOOLEAN   Write,
IN  UINT32Lba,
IN  UINTN TotalBlock,
-  OUT UINT8 *Buffer
+  IN OUT UINT8  *Buffer
)
  {
-  USB_BOOT_READ10_CMD   ReadCmd;
-  EFI_STATUSStatus;
-  UINT16Count;
-  UINT16CountMax;
-  UINT32BlockSize;
-  UINT32ByteSize;
-  UINT32Timeout;
+  USB_BOOT_READ_WRITE_10_CMD Cmd;
+  EFI_STATUS Status;
+  UINT16 Count;
+  UINT16 CountMax;
+  UINT32 BlockSize;
+  UINT32 ByteSize;
+  UINT32 Timeout;
  
BlockSize = UsbMass->BlockIoMedia.BlockSize;

CountMax = (UINT16)(USB_BOOT_MAX_CARRY_SIZE / BlockSize);
@@ -840,17 +842,17 @@ UsbBootReadBlocks (
  //
  // Fill in the command then execute
  //
-ZeroMem (, sizeof (USB_BOOT_READ10_CMD));
+ZeroMem (, sizeof (USB_BOOT_READ_WRITE_10_CMD));
  
-ReadCmd.OpCode  = USB_BOOT_READ10_OPCODE;

-ReadCmd.Lun = (UINT8) (USB_BOOT_LUN (UsbMass->Lun));
-WriteUnaligned32 ((UINT32 *) ReadCmd.Lba, SwapBytes32 (Lba));
-WriteUnaligned16 ((UINT16 *) ReadCmd.TransferLen, SwapBytes16 (Count));
+Cmd.OpCode  = Write ? USB_BOOT_WRITE10_OPCODE : USB_BOOT_READ10_OPCODE;
+Cmd.Lun = (UINT8) (USB_BOOT_LUN (UsbMass->Lun));
+WriteUnaligned32 ((UINT32 *) Cmd.Lba, SwapBytes32 (Lba));
+WriteUnaligned16 ((UINT16 *) Cmd.TransferLen, SwapBytes16 (Count));
  
  Status = UsbBootExecCmdWithRetry (

 UsbMass,
-   ,
-   (UINT8) sizeof (USB_BOOT_READ10_CMD),
+   ,
+   (UINT8) sizeof (USB_BOOT_READ_WRITE_10_CMD),
 EfiUsbDataIn,
 Buffer,
 ByteSize,
@@ -859,86 +861,11 @@ UsbBootReadBlocks (
  if (EFI_ERROR (Status)) {
return Status;
  }
-DEBUG ((EFI_D_BLKIO, "UsbBootReadBlocks: LBA (0x%x), Blk (0x%x)\n", Lba, 
Count));
-Lba+= Count;
-Buffer += Count * BlockSize;
-TotalBlock -= Count;
-  }
-
-  return Status;
-}
-
-
-/**
-  Write some blocks to the device.
-
-  @param  UsbMassThe USB mass storage device to write to
-  @param  LbaThe start block number
-  @param  TotalBlock Total block number to write
-  @param  Buffer Pointer to the source buffer for the data.
-
-  @retval EFI_SUCCESSData are written into the buffer
-  @retval Others Failed to write all the data
-
-**/
-EFI_STATUS
-UsbBootWriteBlocks (
-  IN  USB_MASS_DEVICE *UsbMass,
-  IN  UINT32  Lba,
-  IN  UINTN   TotalBlock,
-  IN  UINT8   *Buffer
-  )
-{
-  USB_BOOT_WRITE10_CMD  WriteCmd;
-  EFI_STATUSStatus;
-  UINT16Count;
-  UINT16CountMax;
-  UINT32BlockSize;
-  UINT32ByteSize;
-  UINT32Timeout;
-
-

Re: [edk2] [Patch 3/4] UefiCpuPkg/RegisterCpuFeaturesLib: Add logic to support semaphore type.


On 10/15/2018 10:49 AM, Eric Dong wrote:

In a system which has multiple cores, current set register value task costs 
huge times.
After investigation, current set MSR task costs most of the times. Current 
logic uses
SpinLock to let set MSR task as an single thread task for all cores. Because 
MSR has
scope attribute which may cause GP fault if multiple APs set MSR at the same 
time,
current logic use an easiest solution (use SpinLock) to avoid this issue, but 
it will
cost huge times.

In order to fix this performance issue, new solution will set MSRs base on 
their scope
attribute. After this, the SpinLock will not needed. Without SpinLock, new 
issue raised
which is caused by MSR dependence. For example, MSR A depends on MSR B which 
means MSR A
must been set after MSR B has been set. Also MSR B is package scope level and 
MSR A is
thread scope level. If system has multiple threads, Thread 1 needs to set the 
thread level
MSRs and thread 2 needs to set thread and package level MSRs. Set MSRs task for 
thread 1
and thread 2 like below:

 Thread 1 Thread 2
MSR B  NY
MSR A  YY

If driver don't control execute MSR order, for thread 1, it will execute MSR A 
first, but
at this time, MSR B not been executed yet by thread 2. system may trig 
exception at this
time.

In order to fix the above issue, driver introduces semaphore logic to control 
the MSR
execute sequence. For the above case, a semaphore will be add between MSR A and 
B for
all threads. Semaphore has scope info for it. The possible scope value is core 
or package.
For each thread, when it meets a semaphore during it set registers, it will 1) 
release
semaphore (+1) for each threads in this core or package(based on the scope info 
for this
semaphore) 2) acquire semaphore (-1) for all the threads in this core or 
package(based
on the scope info for this semaphore). With these two steps, driver can control 
MSR
sequence. Sample code logic like below:

   //
   // First increase semaphore count by 1 for processors in this package.
   //
   for (ProcessorIndex = 0; ProcessorIndex < PackageThreadsCount ; 
ProcessorIndex ++) {
 LibReleaseSemaphore ((UINT32 *) [PackageOffset + 
ProcessorIndex]);
   }
   //
   // Second, check whether the count has reach the check number.
   //
   for (ProcessorIndex = 0; ProcessorIndex < ValidApCount; ProcessorIndex ++) {
 LibWaitForSemaphore ([ApOffset]);
   }

Platform Requirement:
1. This change requires register MSR setting base on MSR scope info. If still 
register MSR
for all threads, exception may raised.

Known limitation:
1. Current CpuFeatures driver supports DXE instance and PEI instance. But 
semaphore logic
requires Aps execute in async mode which is not supported by PEI driver. So 
CpuFeature
PEI instance not works after this change. We plan to support async mode for 
PEI in phase
2 for this task.

Cc: Ruiyu Ni 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong 
---
  .../RegisterCpuFeaturesLib/CpuFeaturesInitialize.c | 324 ---
  .../DxeRegisterCpuFeaturesLib.c|  71 +++-
  .../DxeRegisterCpuFeaturesLib.inf  |   3 +
  .../PeiRegisterCpuFeaturesLib.c|  55 ++-
  .../PeiRegisterCpuFeaturesLib.inf  |   1 +
  .../RegisterCpuFeaturesLib/RegisterCpuFeatures.h   |  51 ++-
  .../RegisterCpuFeaturesLib.c   | 452 ++---
  7 files changed, 840 insertions(+), 117 deletions(-)

diff --git a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c 
b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
index ba3fb3250f..f820b4fed7 100644
--- a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
+++ b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
@@ -145,6 +145,20 @@ CpuInitDataInitialize (
CPU_FEATURES_INIT_ORDER  *InitOrder;
CPU_FEATURES_DATA*CpuFeaturesData;
LIST_ENTRY   *Entry;
+  UINT32   Core;
+  UINT32   Package;
+  UINT32   Thread;
+  EFI_CPU_PHYSICAL_LOCATION*Location;
+  UINT32   *CoreArray;
+  UINTNIndex;
+  UINT32   ValidCount;
+  UINTNCoreIndex;
+  ACPI_CPU_DATA*AcpiCpuData;
+  CPU_STATUS_INFORMATION   *CpuStatus;
+
+  Core= 0;
+  Package = 0;
+  Thread  = 0;
  
CpuFeaturesData = GetCpuFeaturesData ();

CpuFeaturesData->InitOrder = AllocateZeroPool (sizeof 
(CPU_FEATURES_INIT_ORDER) * NumberOfCpus);
@@ -163,6 +177,16 @@ CpuInitDataInitialize (
  Entry = Entry->ForwardLink;
}
  
+  CpuFeaturesData->NumberOfCpus = (UINT32) NumberOfCpus;

+
+

Re: [edk2] [PATCH 0/6] Add kvmtool emulated platform support for ARM

2018-10-15 Thread Leif Lindholm

On Sat, Oct 13, 2018 at 11:42:00PM +0200, Laszlo Ersek wrote:
> On 10/12/18 16:40, Sami Mujawar wrote:
> > Kvmtool is a virtual machine manager that enables hosting KVM
> > guests. ARM is working to enhance kvmtool support to enable 
> > launching of KVM guest with UEFI support.
> 
> Why is QEMU not good enough? (With or without KVM.)
> 
> Another platform I've recently learned about (for QEMU) is the SBSA
> reference machine type. I'm concerned that this kind of divergence will
> be hard to maintain in a common firmware package. Here's my understanding:
> 
> - ArmVirtQemu: supposed to run data center / cloud workloads
> - SBSA reference machine: supposed to emulate physical machines as
>   closely as possible; primarily intended as a development environment
>   for physical machines

If it helps - try to not think of SBSA QEMU as a QEMU target.
It's pretending to be a hardware platform and should be treated as
such. While we may have started the firmware port from ArmVirtPkg (as
the qemu machine was being developed), I don't expect it to ultimately
end up there when it goes upstream.

Regards,

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

[edk2] [PATCH] MdeModulePkg Variable: Fix Timestamp zeroing issue on APPEND_WRITE

2018-10-15 Thread Star Zeng

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

When SetVariable() to a time based auth variable with APPEND_WRITE
attribute, and if the EFI_VARIABLE_AUTHENTICATION_2.TimeStamp in
the input Data is earlier than current value, it will cause timestamp
zeroing.

This issue may bring time based auth variable downgrade problem.
For example:
A vendor released three certs at 2014, 2015, and 2016, and system
integrated the 2016 cert. User can SetVariable() with 2015 cert and
APPEND_WRITE attribute to cause timestamp zeroing first, then
SetVariable() with 2014 cert to downgrade the cert.

This patch fixes this issue.

Cc: Jiewen Yao 
Cc: Chao Zhang 
Cc: Jian J Wang 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng 
---
 MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c 
b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
index a2d61c8cd618..8e8db71bd201 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
@@ -2462,6 +2462,8 @@ UpdateVariable (
 if (Variable->CurrPtr != NULL) {
   if (VariableCompareTimeStampInternal 
(&(((AUTHENTICATED_VARIABLE_HEADER *) CacheVariable->CurrPtr)->TimeStamp), 
TimeStamp)) {
 CopyMem (>TimeStamp, TimeStamp, sizeof (EFI_TIME));
+  } else {
+CopyMem (>TimeStamp, 
&(((AUTHENTICATED_VARIABLE_HEADER *) CacheVariable->CurrPtr)->TimeStamp), 
sizeof (EFI_TIME));
   }
 }
   }
-- 
2.7.0.windows.1

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

Re: [edk2] PACKAGES_PATH in !include path in Dsc files

2018-10-15 Thread Pankaj Bansal

+edk2-platforms maintainers in To list

Thank you Liming for replying.

Our entire code is in edk2-platforms 
(https://github.com/tianocore/edk2-platforms) which is denoted by PACKAGES_PATH.
The PACKAGES_PATH directory can be anywhere in WORKSPACE depending on the sync 
directory defined by user.
i.e. it can be $(WORKSPACE)/edk2-platforms or $(WORKSPACE)/
As our dsc files are relative to PACKAGES_PATH, I want to specify their path in 
dsc file like this:

!include $(PACKAGES_PATH)/Silicon/NXP/.dsc

Using $(WORKSPACE), I cannot specify above path, as it can be at place other 
than $(WORKSPACE)/edk2-platforms

Regards,
Pankaj Bansal

From: Gao, Liming [mailto:liming@intel.com]
Sent: Tuesday, October 16, 2018 7:06 AM
To: Pankaj Bansal ; Zhu, Yonghong 

Cc: edk2-devel@lists.01.org; Udit Kumar ; Varun Sethi 

Subject: RE: PACKAGES_PATH in !include path in Dsc files

What's your usage model in DSC?

BaseTools will try to replace $(WORKSPACE) with WORKSPACE and PACKAGES_PATH, 
and find the first existing file. So, if you want to refer to one file in 
PACKAGES_PATH directory, you can also use $(WORKSPACE) macro to refer to it.

Thanks
Liming
From: Pankaj Bansal [mailto:pankaj.ban...@nxp.com]
Sent: Saturday, October 13, 2018 5:01 PM
To: Zhu, Yonghong mailto:yonghong@intel.com>>; Gao, 
Liming mailto:liming@intel.com>>
Cc: edk2-devel@lists.01.org; Udit Kumar 
mailto:udit.ku...@nxp.com>>; Varun Sethi 
mailto:v.se...@nxp.com>>
Subject: PACKAGES_PATH in !include path in Dsc files

Hello All,

I am trying to add this functionality that we can specify PACKAGES_PATH in 
!include path in Dsc files just like we can specify WORKSPACE.
I did below changes for it:

--- a/BaseTools/Source/Python/Workspace/MetaFileParser.py
+++ b/BaseTools/Source/Python/Workspace/MetaFileParser.py
@@ -1530,6 +1530,7 @@ class DscParser(MetaFileParser):
 # Allow using system environment variables  in path after !include
 #
 __IncludeMacros['WORKSPACE'] = 
GlobalData.gGlobalDefines['WORKSPACE']
+__IncludeMacros['PACKAGES_PATH'] = 
GlobalData.gGlobalDefines['PACKAGES_PATH']^M
 if "ECP_SOURCE" in GlobalData.gGlobalDefines:
 __IncludeMacros['ECP_SOURCE'] = 
GlobalData.gGlobalDefines['ECP_SOURCE']
 #
diff --git a/BaseTools/Source/Python/build/build.py 
b/BaseTools/Source/Python/build/build.py
index d74082fc26..61dce3a856 100644
--- a/BaseTools/Source/Python/build/build.py
+++ b/BaseTools/Source/Python/build/build.py
@@ -197,6 +197,7 @@ def CheckEnvVariable():
 GlobalData.gEcpSource = EcpSourceDir

 GlobalData.gGlobalDefines["WORKSPACE"]  = WorkspaceDir
+GlobalData.gGlobalDefines["PACKAGES_PATH"]  = PackagesPath^M
 GlobalData.gGlobalDefines["EFI_SOURCE"] = EfiSourceDir
 GlobalData.gGlobalDefines["EDK_SOURCE"] = EdkSourceDir
 GlobalData.gGlobalDefines["ECP_SOURCE"] = EcpSourceDir

With these changes the compilation starts OK, but I get this error later on:

GenFds.py...
: error C0DE: Tools code failure
Please send email to 
edk2-devel@lists.01.org for help, attaching 
following call stack trace!

Traceback (most recent call last):
  File "/home/nxa34148/Desktop/uefi/BaseTools/Source/Python/GenFds/GenFds.py", 
line 246, in main
TargetArchList = 
set(BuildWorkSpace.BuildObject[GenFdsGlobalVariable.ActivePlatform, TAB_COMMON, 
Options.BuildTarget, Options.ToolChain].SupArchList) & set(ArchList)
  File 
"/home/nxa34148/Desktop/uefi/BaseTools/Source/Python/Workspace/WorkspaceDatabase.py",
 line 132, in __getitem__
Toolchain
  File 
"/home/nxa34148/Desktop/uefi/BaseTools/Source/Python/Workspace/DscBuildData.py",
 line 221, in __init__
self._HandleOverridePath()
  File 
"/home/nxa34148/Desktop/uefi/BaseTools/Source/Python/Workspace/DscBuildData.py",
 line 282, in _HandleOverridePath
RecordList = self._RawData[MODEL_META_DATA_COMPONENT, self._Arch]
  File 
"/home/nxa34148/Desktop/uefi/BaseTools/Source/Python/Workspace/MetaFileParser.py",
 line 257, in __getitem__
self._PostProcess()
  File 
"/home/nxa34148/Desktop/uefi/BaseTools/Source/Python/Workspace/MetaFileParser.py",
 line 1358, in _PostProcess
Processer[self._ItemType]()
  File 
"/home/nxa34148/Desktop/uefi/BaseTools/Source/Python/Workspace/MetaFileParser.py",
 line 1533, in __ProcessDirective
__IncludeMacros['PACKAGES_PATH'] = 
GlobalData.gGlobalDefines['PACKAGES_PATH']
KeyError: 'PACKAGES_PATH'



build.py...
: error 7000: Failed to execute command
GenFds -f 
/home/nxa34148/Desktop/uefi/edk2-platforms/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.fdf
 --conf=/home/nxa34148/Desktop/uefi/Conf -o 
/home/nxa34148/Desktop/uefi/Build/LS1043aRdbPkg/RELEASE_GCC49 -t GCC49 -b 
RELEASE -p 
/home/nxa34148/Desktop/uefi/edk2-platforms/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.dsc
 -a AARCH64 -D "EFI_SOURCE=/home/nxa34148/Desktop/uefi/EdkCompatibilityPkg" -D

Re: [edk2] [PATCH] uefi-sct/SctPkg:Add conformance test cases for deprecated EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS attribute.

2018-10-15 Thread Leif Lindholm

Hi Eric,

1) Really happy to see the first SCT patch out for public review!

2) Could you go through Laszlo's excellent guide for contributions at
   
https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers
   ?

Specifically the bits affecting patch generation and sending helps a
lot with reviewing.

Laszlo: a few years ago, you also posted a _really_ useful email about
the process of being a maintainer, and helpful workflows (like "sort
emails to review immediately on reception, even if you don't have time
to review now"). I have since failed to find it in my history (or via
google). Since you're very organised - do you have it lying around,
and if so would you be able to re-post it?

On Sat, Oct 13, 2018 at 11:19:36PM +0800, Eric Jin wrote:
> Cc: Supreeth Venkatesh 
> Cc: Jiaxin Wu 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Jin 
> ---
>  .../AuthVariableServicesBBTestConformance.c   | 143 ++
>  .../VariableServices/BlackBoxTest/Guid.c  |   6 +-
>  .../VariableServices/BlackBoxTest/Guid.h  |  11 +-

For example, the --stat* options make sure we always see full paths to
affected files, and the orderFile ensures we see more fundamental
changes to structs and APIs before we see them used.

Secondly, I realise it is likely that there are many unrelated minor
fixes queued up from the long time during which the relicensing was
being worked on. Nevertheless, it is useful to bundle them together in
patch sets in order to make it easier to keep track of them.

(This is not something that affects patches already sent out, but it
would be appreciated for future postings.)

I am also attending the plufegest in Taipei this week, seated a couple
of rows behind you to the right, if you would like to meet up and chat
:)

Best Regards,

Leif

>  3 files changed, 132 insertions(+), 28 deletions(-)
> 
> diff --git 
> a/uefi-sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/VariableServices/BlackBoxTest/AuthVariableServicesBBTestConformance.c
>  
> b/uefi-sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/VariableServices/BlackBoxTest/AuthVariableServicesBBTestConformance.c
> index 05281054..a1d1c4c3 100644
> --- 
> a/uefi-sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/VariableServices/BlackBoxTest/AuthVariableServicesBBTestConformance.c
> +++ 
> b/uefi-sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/VariableServices/BlackBoxTest/AuthVariableServicesBBTestConformance.c
> @@ -1,7 +1,7 @@
>  /** @file
>  
>Copyright 2006 - 2012 Unified EFI, Inc.
> -  Copyright (c) 2010 - 2012, Intel Corporation. All rights reserved.
> +  Copyright (c) 2010 - 2018, 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
> @@ -151,6 +151,44 @@ AuthVariableDERConfTest (
>EFI_TEST_LOGGING_LIBRARY_PROTOCOL   *LoggingLib;
>UINT32  Attr;
>EFI_TEST_ASSERTION  Result;
> +  UINTN   Index;
> +  UINTN   MaximumVariableStorageSize;
> +  UINTN   RemainingVariableStorageSize;
> +  UINTN   MaximumVariableSize;
> +  UINT32  AttrArray[] = {
> +//
> +//  For 1 attribute.
> +//
> +EFI_VARIABLE_NON_VOLATILE,
> +EFI_VARIABLE_RUNTIME_ACCESS,
> +EFI_VARIABLE_BOOTSERVICE_ACCESS,
> +EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS,
> +
> +//
> +//  For 2 attributes.
> +//
> +EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_RUNTIME_ACCESS,
> +EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_BOOTSERVICE_ACCESS,
> +EFI_VARIABLE_NON_VOLATILE | 
> EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS,
> +
> +EFI_VARIABLE_RUNTIME_ACCESS | EFI_VARIABLE_BOOTSERVICE_ACCESS,
> +EFI_VARIABLE_RUNTIME_ACCESS | 
> EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS,
> +
> +EFI_VARIABLE_BOOTSERVICE_ACCESS | 
> EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS,
> +
> +//
> +//  For 3 attributes.
> +//
> +EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_RUNTIME_ACCESS | 
> EFI_VARIABLE_BOOTSERVICE_ACCESS,
> +EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_RUNTIME_ACCESS | 
> EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS,
> +EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_BOOTSERVICE_ACCESS | 
> EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS,
> +EFI_VARIABLE_RUNTIME_ACCESS | EFI_VARIABLE_BOOTSERVICE_ACCESS | 
> EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS,
> +
> +//
> +//  For 4 attributes.
> +//
> +EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_RUNTIME_ACCESS | 
> EFI_VARIABLE_BOOTSERVICE_ACCESS | 
> EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS,
> +  };
>  
>Status = GetTestSupportLibrary (
>   SupportHandle,
> @@ -192,33 +230,86 @@ AuthVariableDERConfTest (

Re: [edk2] [Patch 1/4] UefiCpuPkg/Include/AcpiCpuData.h: Add Semaphore related Information.

On 10/15/2018 10:49 AM, Eric Dong wrote:

In order to support semaphore related logic, add new definition for it.

Cc: Ruiyu Ni 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong 
---
  UefiCpuPkg/Include/AcpiCpuData.h | 23 ++-
  1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/UefiCpuPkg/Include/AcpiCpuData.h b/UefiCpuPkg/Include/AcpiCpuData.h
index 9e51145c08..b3cf2f664a 100644
--- a/UefiCpuPkg/Include/AcpiCpuData.h
+++ b/UefiCpuPkg/Include/AcpiCpuData.h
@@ -15,6 +15,8 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
  #ifndef _ACPI_CPU_DATA_H_
  #define _ACPI_CPU_DATA_H_

+#include 

+
  //
  // Register types in register table
  //
@@ -22,9 +24,20 @@ typedef enum {
Msr,
ControlRegister,
MemoryMapped,
-  CacheControl
+  CacheControl, > +  Semaphore
I assume the REGISTER_TYPE definition will be move to internal 
(non-public) in phase 2.

  } REGISTER_TYPE;

+//

+// CPU information.
+//
+typedef struct {
+  UINT32PackageCount; // Packages in this CPU.
+  UINT32CoreCount;// Max Core count in the packages.
+  UINT32ThreadCount;  // MAx thread count in the cores.
+  UINT32*ValidCoresInPackages;// Valid cores in each package.

Can you please add more comments to describe each field above?
PackageCount is easy to understand.
But CoreCount is not. Maybe different packages have different number of 
cores. In this case, what value will CoreCount be?

Similar question to ThreadCount.

What does ValidCoresInPackages mean? Does it hold the valid (non-dead) 
core numbers for each package? So it's a UINT32 array with PackageCount 
elements?

How about using name ValidCoreCountPerPackage?
How about using MaxCoreCount/MaxThreadCount for CoreCount and ThreadCount?

+} CPU_STATUS_INFORMATION;
+
  //
  // Element of register table entry
  //
@@ -147,6 +160,14 @@ typedef struct {
// provided.
//
UINT32ApMachineCheckHandlerSize;
+  //
+  // CPU information which is required when set the register table.
+  //
+  CPU_STATUS_INFORMATION CpuStatus;
+  //
+  // Location info for each ap.
+  //
+  EFI_CPU_PHYSICAL_LOCATION  *ApLocation;

Please use EFI_PHYSICAL_ADDRESS for ApLocation. It's ok now. But if 
there are more fields below ApLocation, the offset of those fields 
differs between PEI and DXE. That will cause bugs.

  } ACPI_CPU_DATA;

  #endif

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

Re: [edk2] Does edk2 still support python 2?

2018-10-15 Thread Chen, Farrah

OK, got it, thank you!


Thanks,
Fan



-Original Message-
From: Leif Lindholm [mailto:leif.lindh...@linaro.org] 
Sent: Tuesday, October 16, 2018 10:13 AM
To: Chen, Farrah 
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] Does edk2 still support python 2?

Hi Fan,

This change has been reverted for now.
Please update to latest version of edk2.

Python3 migration will happen at some point, but not this abrupt.

Best Regards,

Leif

On Sat, Oct 13, 2018 at 01:17:05PM +, Chen, Farrah wrote:
> Hello,
> 
> When we make edk2 "OvmfPkg/build.sh -a X64 -n 16", we met below error:
> 
> [vmm@vmm-build edk2]$ OvmfPkg/build.sh -a X64 -n 16 Initializing 
> workspace /home/fan/edk2/BaseTools Loading previous configuration from 
> /home/fan/edk2/Conf/BuildEnv.sh
> WORKSPACE: /home/fan/edk2
> EDK_TOOLS_PATH: /home/fan/edk2/BaseTools
> CONF_PATH: /home/fan/edk2/Conf
> 
> ERROR!!!, python version should greater than or equal to version 3.6.
> 
> Does edk2 still support python 2? How can we make edk2 with python 2? Or we 
> must update the python version to python 3.6?
> 
> 
> Thanks,
> Fan
> 
> ___
> 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] Does edk2 still support python 2?

2018-10-15 Thread Leif Lindholm

Hi Fan,

This change has been reverted for now.
Please update to latest version of edk2.

Python3 migration will happen at some point, but not this abrupt.

Best Regards,

Leif

On Sat, Oct 13, 2018 at 01:17:05PM +, Chen, Farrah wrote:
> Hello,
> 
> When we make edk2 "OvmfPkg/build.sh -a X64 -n 16", we met below error:
> 
> [vmm@vmm-build edk2]$ OvmfPkg/build.sh -a X64 -n 16
> Initializing workspace
> /home/fan/edk2/BaseTools
> Loading previous configuration from /home/fan/edk2/Conf/BuildEnv.sh
> WORKSPACE: /home/fan/edk2
> EDK_TOOLS_PATH: /home/fan/edk2/BaseTools
> CONF_PATH: /home/fan/edk2/Conf
> 
> ERROR!!!, python version should greater than or equal to version 3.6.
> 
> Does edk2 still support python 2? How can we make edk2 with python 2? Or we 
> must update the python version to python 3.6?
> 
> 
> Thanks,
> Fan
> 
> ___
> 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] Where to find the fix for security issue id 686

Rafael:
  https://bugzilla.tianocore.org/show_bug.cgi?id=686 public now. You can view 
it. I also send the patches to fix it. Please check. 

Thanks
Liming
>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Rafael Machado
>Sent: Tuesday, October 16, 2018 8:41 AM
>To: Zimmer, Vincent 
>Cc: edk2-devel@lists.01.org
>Subject: Re: [edk2] Where to find the fix for security issue id 686
>
>I understood this issue's fix was already released at some branch.
>With your message things make sense again.
>
>In this case I can wait for this fix to be publicly available.
>Thanks for the clarification!
>
>Best Regards
>Rafael
>
>Em seg, 15 de out de 2018 às 16:42, Zimmer, Vincent <
>vincent.zim...@intel.com> escreveu:
>
>> Ah ok
>>
>>
>>
>> From
>> https://github.com/tianocore/tianocore.github.io/wiki/Reporting-Security-
>Issues
>> you will see that issues are only visible to the report and infosec group
>> of Bugzilla, namely “Issues in the *Tianocore Security Issue* product are
>> only visible to the *Reporter* of the issue and the members of the
>> *infosec* group. ”
>>
>>
>>
>> Since you were not the reporter of 686 and are not part of infosec, you
>> cannot see it.
>>
>>
>>
>> If you or anyone in the community would like to help work these issues
>> while in triage and embargo, let me know and we can add you to the infosec
>> group.
>>
>>
>>
>> Vincent
>>
>>
>>
>> *From:* Rafael Machado [mailto:rafaelrodrigues.mach...@gmail.com]
>> *Sent:* Monday, October 15, 2018 12:17 PM
>> *To:* Zimmer, Vincent 
>> *Cc:* edk2-devel@lists.01.org
>> *Subject:* Re: [edk2] Where to find the fix for security issue id 686
>>
>>
>>
>> Hi Vincent
>>
>>
>>
>> Thanks for the answer.
>>
>> The problem is that when I try to access this link I have this message: "You
>> are not authorized to access bug #686."
>>
>>
>>
>> Any idea?
>>
>>
>>
>> Em seg, 15 de out de 2018 às 14:28, Zimmer, Vincent <
>> vincent.zim...@intel.com> escreveu:
>>
>> You can find reference to patches via the advisory entry
>>
>> "31. EDK II TIANOCOMPRESS BOUNDS CHECKING ISSUES" advisory entry
>> https://edk2-docs.gitbooks.io/security-advisory/content/edk-ii-
>tianocompress-bounds-checking-issues.html
>> has an embedded link to
>> https://bugzilla.tianocore.org/attachment.cgi?id=150
>>
>> Vincent
>>
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Rafael Machado
>> Sent: Monday, October 15, 2018 5:39 AM
>> To: edk2-devel@lists.01.org
>> Subject: [edk2] Where to find the fix for security issue id 686
>>
>> Hi everyone
>>
>> I was tying to find the patch to fix the reported security issue id 686 (
>> https://bugzilla.tianocore.org/show_bug.cgi?id=686),
>> but was not able to access it.
>>
>> Could someone please tell if this patch, or series of patches, was already
>> merged to some branch that is public available?
>>
>> Thanks and Regards
>> Rafael R. Machado
>> ___
>> 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

[edk2] [Patch 3/3] BaseTools: Add more checker in Decompress algorithm to access the valid buffer

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

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Holtsclaw Brent 
Signed-off-by: Liming Gao 
---
 BaseTools/Source/C/Common/Decompress.c   | 23 +++--
 BaseTools/Source/C/TianoCompress/TianoCompress.c | 26 +++-
 2 files changed, 46 insertions(+), 3 deletions(-)

diff --git a/BaseTools/Source/C/Common/Decompress.c 
b/BaseTools/Source/C/Common/Decompress.c
index 9906888..71313b1 100644
--- a/BaseTools/Source/C/Common/Decompress.c
+++ b/BaseTools/Source/C/Common/Decompress.c
@@ -194,12 +194,16 @@ Returns:
   UINT16  Avail;
   UINT16  NextCode;
   UINT16  Mask;
+  UINT16  MaxTableLength;
 
   for (Index = 1; Index <= 16; Index++) {
 Count[Index] = 0;
   }
 
   for (Index = 0; Index < NumOfChar; Index++) {
+if (BitLen[Index] > 16) {
+  return (UINT16) BAD_TABLE;
+}
 Count[BitLen[Index]]++;
   }
 
@@ -237,6 +241,7 @@ Returns:
 
   Avail = NumOfChar;
   Mask  = (UINT16) (1U << (15 - TableBits));
+  MaxTableLength = (UINT16) (1U << TableBits);
 
   for (Char = 0; Char < NumOfChar; Char++) {
 
@@ -250,6 +255,9 @@ Returns:
 if (Len <= TableBits) {
 
   for (Index = Start[Len]; Index < NextCode; Index++) {
+if (Index >= MaxTableLength) {
+  return (UINT16) BAD_TABLE;
+}
 Table[Index] = Char;
   }
 
@@ -643,10 +651,14 @@ Returns: (VOID)
 
   BytesRemain--;
   while ((INT16) (BytesRemain) >= 0) {
-Sd->mDstBase[Sd->mOutBuf++] = Sd->mDstBase[DataIdx++];
 if (Sd->mOutBuf >= Sd->mOrigSize) {
   return ;
 }
+if (DataIdx >= Sd->mOrigSize) {
+  Sd->mBadTableFlag = (UINT16) BAD_TABLE;
+  return ;
+}
+Sd->mDstBase[Sd->mOutBuf++] = Sd->mDstBase[DataIdx++];
 
 BytesRemain--;
   }
@@ -684,6 +696,7 @@ Returns:
 --*/
 {
   UINT8 *Src;
+  UINT32 CompSize;
 
   *ScratchSize  = sizeof (SCRATCH_DATA);
 
@@ -692,7 +705,13 @@ Returns:
 return EFI_INVALID_PARAMETER;
   }
 
+  CompSize = Src[0] + (Src[1] << 8) + (Src[2] << 16) + (Src[3] << 24);
   *DstSize = Src[4] + (Src[5] << 8) + (Src[6] << 16) + (Src[7] << 24);
+
+  if (SrcSize < CompSize + 8 || (CompSize + 8) < 8) {
+return EFI_INVALID_PARAMETER;
+  }
+
   return EFI_SUCCESS;
 }
 
@@ -752,7 +771,7 @@ Returns:
   CompSize  = Src[0] + (Src[1] << 8) + (Src[2] << 16) + (Src[3] << 24);
   OrigSize  = Src[4] + (Src[5] << 8) + (Src[6] << 16) + (Src[7] << 24);
 
-  if (SrcSize < CompSize + 8) {
+  if (SrcSize < CompSize + 8 || (CompSize + 8) < 8) {
 return EFI_INVALID_PARAMETER;
   }
 
diff --git a/BaseTools/Source/C/TianoCompress/TianoCompress.c 
b/BaseTools/Source/C/TianoCompress/TianoCompress.c
index b88d7da..2d6fc4c 100644
--- a/BaseTools/Source/C/TianoCompress/TianoCompress.c
+++ b/BaseTools/Source/C/TianoCompress/TianoCompress.c
@@ -1757,6 +1757,7 @@ Returns:
   SCRATCH_DATA  *Scratch;
   UINT8  *Src;
   UINT32 OrigSize;
+  UINT32 CompSize;
 
   SetUtilityName(UTILITY_NAME);
 
@@ -1765,6 +1766,7 @@ Returns:
   OutBuffer = NULL;
   Scratch   = NULL;
   OrigSize = 0;
+  CompSize = 0;
   InputLength = 0;
   InputFileName = NULL;
   OutputFileName = NULL;
@@ -2006,15 +2008,24 @@ Returns:
 }
 fwrite(OutBuffer, (size_t)(DstSize), 1, OutputFile);
   } else {
+if (InputLength < 8){
+  Error (NULL, 0, 3000, "Invalid", "The input file %s is too small.", 
InputFileName);
+  goto ERROR;
+}
 //
 // Get Compressed file original size
 //
 Src = (UINT8 *)FileBuffer;
 OrigSize  = Src[4] + (Src[5] << 8) + (Src[6] << 16) + (Src[7] << 24);
+CompSize  = Src[0] + (Src[1] << 8) + (Src[2] <<16) + (Src[3] <<24);
 
 //
 // Allocate OutputBuffer
 //
+if (InputLength < CompSize + 8 || (CompSize + 8) < 8) {
+  Error (NULL, 0, 3000, "Invalid", "The input file %s data is invalid.", 
InputFileName);
+  goto ERROR;
+}
 OutBuffer = (UINT8 *)malloc(OrigSize);
 if (OutBuffer == NULL) {
   Error (NULL, 0, 4001, "Resource:", "Memory cannot be allocated!");
@@ -2204,12 +2215,16 @@ Returns:
   UINT16  Mask;
   UINT16  WordOfStart;
   UINT16  WordOfCount;
+  UINT16  MaxTableLength;
 
   for (Index = 0; Index <= 16; Index++) {
 Count[Index] = 0;
   }
 
   for (Index = 0; Index < NumOfChar; Index++) {
+if (BitLen[Index] > 16) {
+  return (UINT16) BAD_TABLE;
+}
 Count[BitLen[Index]]++;
   }
 
@@ -2253,6 +2268,7 @@ Returns:
 
   Avail = NumOfChar;
   Mask  = (UINT16) (1U << (15 - TableBits));
+  MaxTableLength = (UINT16) (1U << TableBits);
 
   for (Char = 0; Char < NumOfChar; Char++) {
 
@@ -2266,6 +2282,9 @@ Returns:
 if (Len <= TableBits) {
 
   for (Index = Start[Len]; Index < NextCode; Index++) {
+if (Index >= MaxTableLength) {
+  return (UINT16) BAD_TABLE;
+}
 Table[Index] = Char;
   }
 
@@ -2650,11 +2669,16 @@ Returns: (VOID)
   DataIdx = Sd->mOutBuf - DecodeP (Sd) -

[edk2] [Patch 2/3] IntelFrameworkModulePkg: Add more checker in UefiTianoDecompressLib

https://bugzilla.tianocore.org/show_bug.cgi?id=686
To make sure the valid buffer be accessed only.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Holtsclaw Brent 
Signed-off-by: Liming Gao 
---
 .../BaseUefiTianoCustomDecompressLib.c   | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git 
a/IntelFrameworkModulePkg/Library/BaseUefiTianoCustomDecompressLib/BaseUefiTianoCustomDecompressLib.c
 
b/IntelFrameworkModulePkg/Library/BaseUefiTianoCustomDecompressLib/BaseUefiTianoCustomDecompressLib.c
index ab7987a..3a0 100644
--- 
a/IntelFrameworkModulePkg/Library/BaseUefiTianoCustomDecompressLib/BaseUefiTianoCustomDecompressLib.c
+++ 
b/IntelFrameworkModulePkg/Library/BaseUefiTianoCustomDecompressLib/BaseUefiTianoCustomDecompressLib.c
@@ -143,6 +143,7 @@ MakeTable (
   UINT16  Mask;
   UINT16  WordOfStart;
   UINT16  WordOfCount;
+  UINT16  MaxTableLength;
 
   //
   // The maximum mapping table width supported by this internal
@@ -155,6 +156,9 @@ MakeTable (
   }
 
   for (Index = 0; Index < NumOfChar; Index++) {
+if (BitLen[Index] > 16) {
+  return (UINT16) BAD_TABLE;
+}
 Count[BitLen[Index]]++;
   }
 
@@ -196,6 +200,7 @@ MakeTable (
 
   Avail = NumOfChar;
   Mask  = (UINT16) (1U << (15 - TableBits));
+  MaxTableLength = (UINT16) (1U << TableBits);
 
   for (Char = 0; Char < NumOfChar; Char++) {
 
@@ -209,6 +214,9 @@ MakeTable (
 if (Len <= TableBits) {
 
   for (Index = Start[Len]; Index < NextCode; Index++) {
+if (Index >= MaxTableLength) {
+  return (UINT16) BAD_TABLE;
+}
 Table[Index] = Char;
   }
 
@@ -615,10 +623,14 @@ Decode (
   //
   BytesRemain--;
   while ((INT16) (BytesRemain) >= 0) {
-Sd->mDstBase[Sd->mOutBuf++] = Sd->mDstBase[DataIdx++];
 if (Sd->mOutBuf >= Sd->mOrigSize) {
   goto Done ;
 }
+if (DataIdx >= Sd->mOrigSize) {
+  Sd->mBadTableFlag = (UINT16) BAD_TABLE;
+  goto Done ;
+}
+Sd->mDstBase[Sd->mOutBuf++] = Sd->mDstBase[DataIdx++];
 
 BytesRemain--;
   }
@@ -688,7 +700,7 @@ UefiDecompressGetInfo (
   }
 
   CompressedSize   = ReadUnaligned32 ((UINT32 *)Source);
-  if (SourceSize < (CompressedSize + 8)) {
+  if (SourceSize < (CompressedSize + 8) || (CompressedSize + 8) < 8) {
 return RETURN_INVALID_PARAMETER;
   }
 
-- 
2.10.0.windows.1

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

[edk2] [Patch 1/3] MdePkg: Add more checker in UefiDecompressLib to access the valid buffer only

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

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Holtsclaw Brent 
Signed-off-by: Liming Gao 
---
 .../BaseUefiDecompressLib/BaseUefiDecompressLib.c   | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/MdePkg/Library/BaseUefiDecompressLib/BaseUefiDecompressLib.c 
b/MdePkg/Library/BaseUefiDecompressLib/BaseUefiDecompressLib.c
index dc89157..9fc637e 100644
--- a/MdePkg/Library/BaseUefiDecompressLib/BaseUefiDecompressLib.c
+++ b/MdePkg/Library/BaseUefiDecompressLib/BaseUefiDecompressLib.c
@@ -152,6 +152,7 @@ MakeTable (
   UINT16  Mask;
   UINT16  WordOfStart;
   UINT16  WordOfCount;
+  UINT16  MaxTableLength;
 
   //
   // The maximum mapping table width supported by this internal
@@ -164,6 +165,9 @@ MakeTable (
   }
 
   for (Index = 0; Index < NumOfChar; Index++) {
+if (BitLen[Index] > 16) {
+  return (UINT16) BAD_TABLE;
+}
 Count[BitLen[Index]]++;
   }
 
@@ -205,6 +209,7 @@ MakeTable (
 
   Avail = NumOfChar;
   Mask  = (UINT16) (1U << (15 - TableBits));
+  MaxTableLength = (UINT16) (1U << TableBits);
 
   for (Char = 0; Char < NumOfChar; Char++) {
 
@@ -218,6 +223,9 @@ MakeTable (
 if (Len <= TableBits) {
 
   for (Index = Start[Len]; Index < NextCode; Index++) {
+if (Index >= MaxTableLength) {
+  return (UINT16) BAD_TABLE;
+}
 Table[Index] = Char;
   }
 
@@ -620,11 +628,16 @@ Decode (
   // Write BytesRemain of bytes into mDstBase
   //
   BytesRemain--;
+
   while ((INT16) (BytesRemain) >= 0) {
-Sd->mDstBase[Sd->mOutBuf++] = Sd->mDstBase[DataIdx++];
 if (Sd->mOutBuf >= Sd->mOrigSize) {
   goto Done;
 }
+if (DataIdx >= Sd->mOrigSize) {
+  Sd->mBadTableFlag = (UINT16) BAD_TABLE;
+  goto Done;
+}
+Sd->mDstBase[Sd->mOutBuf++] = Sd->mDstBase[DataIdx++];
 
 BytesRemain--;
   }
@@ -694,7 +707,7 @@ UefiDecompressGetInfo (
   }
 
   CompressedSize   = ReadUnaligned32 ((UINT32 *)Source);
-  if (SourceSize < (CompressedSize + 8)) {
+  if (SourceSize < (CompressedSize + 8) || (CompressedSize + 8) < 8) {
 return RETURN_INVALID_PARAMETER;
   }
 
-- 
2.10.0.windows.1

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

[edk2] [Patch 0/3] Add more checker for Tianocompress and Ueficompress

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

Liming Gao (3):
  MdePkg: Add more checker in UefiDecompressLib to access the valid
buffer only
  IntelFrameworkModulePkg: Add more checker in UefiTianoDecompressLib
  BaseTools: Add more checker in Decompress algorithm to access the
valid buffer

 BaseTools/Source/C/Common/Decompress.c | 23 +--
 BaseTools/Source/C/TianoCompress/TianoCompress.c   | 26 +-
 .../BaseUefiTianoCustomDecompressLib.c | 16 +++--
 .../BaseUefiDecompressLib/BaseUefiDecompressLib.c  | 17 --
 4 files changed, 75 insertions(+), 7 deletions(-)

-- 
2.10.0.windows.1

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

Re: [edk2] [Patch] NetworkPkg/TlsDxe: Remove the redundant library class.

2018-10-15 Thread Fu, Siyuan

Reviewed-by: Fu Siyuan 

> -Original Message-
> From: Wu, Jiaxin
> Sent: Tuesday, October 16, 2018 9:55 AM
> To: edk2-devel@lists.01.org
> Cc: Fu, Siyuan ; Ye, Ting ; Wu,
> Jiaxin 
> Subject: [Patch] NetworkPkg/TlsDxe: Remove the redundant library class.
> 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1018.
> 
> Cc: Fu Siyuan 
> Cc: Ye Ting 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Wu Jiaxin 
> ---
>  NetworkPkg/TlsDxe/TlsDxe.inf | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/NetworkPkg/TlsDxe/TlsDxe.inf b/NetworkPkg/TlsDxe/TlsDxe.inf
> index 907feb735b..aaea0fc2ff 100644
> --- a/NetworkPkg/TlsDxe/TlsDxe.inf
> +++ b/NetworkPkg/TlsDxe/TlsDxe.inf
> @@ -3,11 +3,11 @@
>  #  EFI TLS Configuration Protocol.
>  #
>  #  This module produces EFI TLS (Transport Layer Security) Protocol and
> EFI TLS
>  #  Service Binding Protocol, to provide TLS services.
>  #
> -#  Copyright (c) 2016, Intel Corporation. All rights reserved.
> +#  Copyright (c) 2016 - 2018, 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
>  #  http://opensource.org/licenses/bsd-license.php.
> @@ -50,11 +50,10 @@
>MemoryAllocationLib
>BaseMemoryLib
>BaseLib
>UefiLib
>DebugLib
> -  NetLib
>BaseCryptLib
>TlsLib
> 
>  [Protocols]
>gEfiTlsServiceBindingProtocolGuid  ## PRODUCES
> --
> 2.17.1.windows.2

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

Re: [edk2] Regression with PXE boot on OvmfPkg/VirtioNetDxe driver on aarch64 system

2018-10-15 Thread Ard Biesheuvel

On 15 October 2018 at 22:52,   wrote:
>
>
> On 10/04/18 06:06, Laszlo Ersek wrote:
>>
>> On 10/04/18 11:24, Leif Lindholm wrote:
>>>
>>> +Peter
>>>
>>> On Wed, Oct 03, 2018 at 04:59:54PM -0700, aaron.yo...@oracle.com wrote:

   I am suspecting that this patch to GRUB is the cause of a Buffer being
 re-transmitted before reaping the Buffer via SNP->GetStatus():


 https://git.centos.org/blob/rpms!grub2.git/1065bd29e776aef83f927747882140dcb6fd5cde/SOURCES!0183-efinet-retransmit-if-our-device-is-busy.patch

   So, to reproduce the issue, the GRUB used via PXE boot needs to
 include
 this patch.
>>>
>>> So the issue cannot be reproduced with upstream GRUB?
>>>
>>> Does Fedora/Red Hat include the same patch?
>>
>> Here's what I can see.
>>
>> (1) In upstream grub , at
>> commit 8ada906031d9 ("msdos: Fix overflow in converting partition start
>> and length into 512B blocks", 2018-09-27), on the master branch, the
>> patch is not present.
>>
>> (2) In "rhboot" grub2 , where the
>> master branch seems to track upstream grub, the patch is present on at
>> least the "fedora-28" and "rhel-7.5" branches. Commit hashes,
>> respectively: c2b126f52143, 1b9767c136082.
>>
>> (3) In the commit message, Josef wrote, "When I fixed the txbuf handling
>> I ripped out the retransmission code". I think he referred to his
>> earlier commit 4fe8e6d4a127 ("efinet: handle get_status() on buggy
>> firmware properly", 2015-08-09). That commit is upstream.
>>
>> In my opinion, commit 4fe8e6d4a127, the chronologically first, and
>> upstream, tweak, was right (assuming the comment it added was true,
>> about grub).
>>
>> On the other hand, the downstream-only (chronologically 2nd) commit was
>> wrong. Not only did it break the spec, it broke even grub's own internal
>> invariant, described in the comment that was added in upstream commit
>> 4fe8e6d4a127. The comment states, "we only transmit one packet at a
>> time". With the downstream-only tweak applied, that's no longer true.
>> Namely, SNP.Transmit() is called while we know another transmission is
>> pending on the egress queue. That's the definition of sending more than
>> one packet at a time.
>>
>> I'm curious why the patch in question is not upstream. Was it submitted
>> and rejected? Submitted and ignored? Not submitted at all?
>>
>> I'm not a fan of the hard-liner "spec above everything" approach. In
>> this case though, after the downstream-only tweak, grub is inconsistent
>> not only with the spec, but with itself too.
>>
>> IMO, downstream(s) should revert the downstream-only patch.
>>
>> Thanks,
>> Laszlo
>
>
> I have confirmed that reverting this GRUB patch indeed fixes the issue (i.e.
> with the VirtioNetDxe/SnpSharedHelpers.c(184) ASSERT).
>
>   Thanks for the help/info in resolving this issue.
>
>   As a follow up question - it seems that the VirtioNetDxe driver is fragile
> in that it can get into broken state if (for whatever reason) a tx buffer is
> not successfully transmitted and thus never shows back up on the Used Ring.
> i.e. If a SNP client has repeatedly called SNP-GetStatus() and, after a
> certain amount of time, fails gets back the buffer, what should it do? If it
> attempts to re-transmit the buffer, it'll hit the ASSERT. Perhaps it should
> shutdown/re-init the interface in this case (to free up the buffer mapping
> in Dev->TxBufCollection)? Or, are we confident this condition can _never_
> happen?
>

It is an implementation detail of GRUB that it only ever uses a single
TX buffer: the protocol supports an arbitrary number of buffers, and
repeated calls to GetStatus() will return each one once the network
stack is done with them.

So the answer is simply to allocate another buffer, and use that.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch] NetworkPkg/TlsDxe: Remove the redundant library class.

2018-10-15 Thread Jiaxin Wu

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

Cc: Fu Siyuan 
Cc: Ye Ting 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Wu Jiaxin 
---
 NetworkPkg/TlsDxe/TlsDxe.inf | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/NetworkPkg/TlsDxe/TlsDxe.inf b/NetworkPkg/TlsDxe/TlsDxe.inf
index 907feb735b..aaea0fc2ff 100644
--- a/NetworkPkg/TlsDxe/TlsDxe.inf
+++ b/NetworkPkg/TlsDxe/TlsDxe.inf
@@ -3,11 +3,11 @@
 #  EFI TLS Configuration Protocol.
 #
 #  This module produces EFI TLS (Transport Layer Security) Protocol and EFI TLS
 #  Service Binding Protocol, to provide TLS services.
 #
-#  Copyright (c) 2016, Intel Corporation. All rights reserved.
+#  Copyright (c) 2016 - 2018, 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
 #  http://opensource.org/licenses/bsd-license.php.
@@ -50,11 +50,10 @@
   MemoryAllocationLib
   BaseMemoryLib
   BaseLib
   UefiLib
   DebugLib
-  NetLib
   BaseCryptLib
   TlsLib
 
 [Protocols]
   gEfiTlsServiceBindingProtocolGuid  ## PRODUCES
-- 
2.17.1.windows.2

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

Re: [edk2] [Patch 0/4] Fix performance issue caused by Set MSR task.

2018-10-15 Thread Dong, Eric

Hi Laszlo,

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Monday, October 15, 2018 11:52 PM
> To: Dong, Eric ; edk2-devel@lists.01.org
> Cc: Ni, Ruiyu 
> Subject: Re: [Patch 0/4] Fix performance issue caused by Set MSR task.
> 
> Hi Eric,
> 
> On 10/15/18 04:49, Eric Dong wrote:
> > In a system which has multiple cores, current set register value task costs
> huge times.
> > After investigation, current set MSR task costs most of the times.
> > Current logic uses SpinLock to let set MSR task as an single thread
> > task for all cores. Because MSR has scope attribute which may cause GP
> > fault if multiple APs set MSR at the same time, current logic use an
> > easiest solution (use SpinLock) to avoid this issue, but it will cost huge 
> > times.
> >
> > In order to fix this performance issue, new solution will set MSRs
> > base on their scope attribute. After this, the SpinLock will not
> > needed. Without SpinLock, new issue raised which is caused by MSR
> > dependence. For example, MSR A depends on MSR B which means MSR A
> must
> > been set after MSR B has been set. Also MSR B is package scope level
> > and MSR A is thread scope level. If system has multiple threads,
> > Thread 1 needs to set the thread level MSRs and thread 2 needs to set
> thread and package level MSRs. Set MSRs task for thread 1 and thread 2 like
> below:
> >
> > Thread 1 Thread 2
> > MSR B  NY
> > MSR A  YY
> >
> > If driver don't control execute MSR order, for thread 1, it will
> > execute MSR A first, but at this time, MSR B not been executed yet by
> > thread 2. system may trig exception at this time.
> >
> > In order to fix the above issue, driver introduces semaphore logic to
> > control the MSR execute sequence. For the above case, a semaphore will
> > be add between MSR A and B for all threads. Semaphore has scope info for
> it. The possible scope value is core or package.
> > For each thread, when it meets a semaphore during it set registers, it
> > will 1) release semaphore (+1) for each threads in this core or
> > package(based on the scope info for this
> > semaphore) 2) acquire semaphore (-1) for all the threads in this core
> > or package(based on the scope info for this semaphore). With these two
> > steps, driver can control MSR sequence. Sample code logic like below:
> >
> >   //
> >   // First increase semaphore count by 1 for processors in this package.
> >   //
> >   for (ProcessorIndex = 0; ProcessorIndex < PackageThreadsCount ;
> ProcessorIndex ++) {
> > LibReleaseSemaphore ((UINT32 *) [PackageOffset +
> ProcessorIndex]);
> >   }
> >   //
> >   // Second, check whether the count has reach the check number.
> >   //
> >   for (ProcessorIndex = 0; ProcessorIndex < ValidApCount; ProcessorIndex
> ++) {
> > LibWaitForSemaphore ([ApOffset]);
> >   }
> >
> > Platform Requirement:
> > 1. This change requires register MSR setting base on MSR scope info. If 
> > still
> register MSR
> >for all threads, exception may raised.
> 
> Do you mean that platforms are responsible for updating their register tables
> in:
> - ACPI_CPU_DATA.PreSmmInitRegisterTable,
> - ACPI_CPU_DATA.RegisterTable
> 
> so that the tables utilize the new Semaphore REGISTER_TYPE as appropriate?

Yes, platform should set MSR in these two tables base on MSR's scope info. Just 
like if the MSR is core level, this MSR should on been add to the AP which 
control the related core. 
Also if two MSRs have dependence and they have different scope info, a 
semaphore should been added between these two MSRs. 

> 
> >
> > Known limitation:
> > 1. Current CpuFeatures driver supports DXE instance and PEI instance. But
> semaphore logic
> >requires Aps execute in async mode which is not supported by PEI driver.
> So CpuFeature
> >PEI instance not works after this change. We plan to support async mode
> for PEI in phase
> >2 for this task.
> > 2. Current execute MSR task code in duplicated in PiSmmCpuDxeSmm
> driver and
> >RegisterCpuFeaturesLib library because the schedule limitation.
> 
> I don't understand what you mean by "schedule limitation". Are you alluding
> to the upcoming edk2 stable tag (in November), or some other schedule?

Yes, I want to include this change in the upcoming edk2 stable tag. But I can't 
finish all these changes before it, so for this version, I just duplicate the 
code.

> 
> >Will merge the code to
> >RegisterCpuFeaturesLib and export as an API in phase 2 for this task.
> 
> While I agree that common code (especially complex code like this) should
> belong to libraries, there are platforms that consume PiSmmCpuDxeSmm,
> but don't consume RegisterCpuFeaturesLib in any way.
> 
> Do you plan to add the new function(s) to a RegisterCpuFeaturesLib instance,
> and make PiSmmCpuDxeSmm dependent on RegisterCpuFeaturesLib?

Yes, plan to export one new API in RegisterCpuFeaturesLib

Re: [edk2] PACKAGES_PATH in !include path in Dsc files

What's your usage model in DSC?

BaseTools will try to replace $(WORKSPACE) with WORKSPACE and PACKAGES_PATH, 
and find the first existing file. So, if you want to refer to one file in 
PACKAGES_PATH directory, you can also use $(WORKSPACE) macro to refer to it.

Thanks
Liming
From: Pankaj Bansal [mailto:pankaj.ban...@nxp.com]
Sent: Saturday, October 13, 2018 5:01 PM
To: Zhu, Yonghong ; Gao, Liming 
Cc: edk2-devel@lists.01.org; Udit Kumar ; Varun Sethi 

Subject: PACKAGES_PATH in !include path in Dsc files

Hello All,

I am trying to add this functionality that we can specify PACKAGES_PATH in 
!include path in Dsc files just like we can specify WORKSPACE.
I did below changes for it:

--- a/BaseTools/Source/Python/Workspace/MetaFileParser.py
+++ b/BaseTools/Source/Python/Workspace/MetaFileParser.py
@@ -1530,6 +1530,7 @@ class DscParser(MetaFileParser):
 # Allow using system environment variables  in path after !include
 #
 __IncludeMacros['WORKSPACE'] = 
GlobalData.gGlobalDefines['WORKSPACE']
+__IncludeMacros['PACKAGES_PATH'] = 
GlobalData.gGlobalDefines['PACKAGES_PATH']^M
 if "ECP_SOURCE" in GlobalData.gGlobalDefines:
 __IncludeMacros['ECP_SOURCE'] = 
GlobalData.gGlobalDefines['ECP_SOURCE']
 #
diff --git a/BaseTools/Source/Python/build/build.py 
b/BaseTools/Source/Python/build/build.py
index d74082fc26..61dce3a856 100644
--- a/BaseTools/Source/Python/build/build.py
+++ b/BaseTools/Source/Python/build/build.py
@@ -197,6 +197,7 @@ def CheckEnvVariable():
 GlobalData.gEcpSource = EcpSourceDir

 GlobalData.gGlobalDefines["WORKSPACE"]  = WorkspaceDir
+GlobalData.gGlobalDefines["PACKAGES_PATH"]  = PackagesPath^M
 GlobalData.gGlobalDefines["EFI_SOURCE"] = EfiSourceDir
 GlobalData.gGlobalDefines["EDK_SOURCE"] = EdkSourceDir
 GlobalData.gGlobalDefines["ECP_SOURCE"] = EcpSourceDir

With these changes the compilation starts OK, but I get this error later on:

GenFds.py...
: error C0DE: Tools code failure
Please send email to 
edk2-devel@lists.01.org for help, attaching 
following call stack trace!

Traceback (most recent call last):
  File "/home/nxa34148/Desktop/uefi/BaseTools/Source/Python/GenFds/GenFds.py", 
line 246, in main
TargetArchList = 
set(BuildWorkSpace.BuildObject[GenFdsGlobalVariable.ActivePlatform, TAB_COMMON, 
Options.BuildTarget, Options.ToolChain].SupArchList) & set(ArchList)
  File 
"/home/nxa34148/Desktop/uefi/BaseTools/Source/Python/Workspace/WorkspaceDatabase.py",
 line 132, in __getitem__
Toolchain
  File 
"/home/nxa34148/Desktop/uefi/BaseTools/Source/Python/Workspace/DscBuildData.py",
 line 221, in __init__
self._HandleOverridePath()
  File 
"/home/nxa34148/Desktop/uefi/BaseTools/Source/Python/Workspace/DscBuildData.py",
 line 282, in _HandleOverridePath
RecordList = self._RawData[MODEL_META_DATA_COMPONENT, self._Arch]
  File 
"/home/nxa34148/Desktop/uefi/BaseTools/Source/Python/Workspace/MetaFileParser.py",
 line 257, in __getitem__
self._PostProcess()
  File 
"/home/nxa34148/Desktop/uefi/BaseTools/Source/Python/Workspace/MetaFileParser.py",
 line 1358, in _PostProcess
Processer[self._ItemType]()
  File 
"/home/nxa34148/Desktop/uefi/BaseTools/Source/Python/Workspace/MetaFileParser.py",
 line 1533, in __ProcessDirective
__IncludeMacros['PACKAGES_PATH'] = 
GlobalData.gGlobalDefines['PACKAGES_PATH']
KeyError: 'PACKAGES_PATH'



build.py...
: error 7000: Failed to execute command
GenFds -f 
/home/nxa34148/Desktop/uefi/edk2-platforms/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.fdf
 --conf=/home/nxa34148/Desktop/uefi/Conf -o 
/home/nxa34148/Desktop/uefi/Build/LS1043aRdbPkg/RELEASE_GCC49 -t GCC49 -b 
RELEASE -p 
/home/nxa34148/Desktop/uefi/edk2-platforms/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.dsc
 -a AARCH64 -D "EFI_SOURCE=/home/nxa34148/Desktop/uefi/EdkCompatibilityPkg" -D 
"EDK_SOURCE=/home/nxa34148/Desktop/uefi/EdkCompatibilityPkg" -D 
"TOOL_CHAIN_TAG=GCC49" -D "TOOLCHAIN=GCC49" -D "FAMILY=GCC" -D 
"PACKAGES_PATH=/home/nxa34148/Desktop/uefi/edk2-platforms" -D 
"EDK_TOOLS_PATH=/home/nxa34148/Desktop/uefi/BaseTools" -D 
"WORKSPACE=/home/nxa34148/Desktop/uefi" -D "ARCH=AARCH64" -D 
"ECP_SOURCE=/home/nxa34148/Desktop/uefi/EdkCompatibilityPkg" -D 
"TARGET=RELEASE" [/home/nxa34148/Desktop/uefi]

- Failed -

I am not able to understand the cause of this error.

Can you please help?

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

[edk2] [Patch] NetworkPkg/IpSecDxe: Fix issue to parse SA Payload.

2018-10-15 Thread Jiaxin Wu

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

IpSecDxe failed to create the Child SA during parsing SA Payload, the issue
was caused by the below commit:

SHA-1: 1e0db7b11987d0ec93be7dfe26102a327860fdbd
* MdeModulePkg/NetworkPkg: Checking for NULL pointer before use.

In above commit, it changed the value of IsMatch in Ikev2ChildSaParseSaPayload()
to FALSE. That's correct but it exposed the potential bug in to match the 
correct
proposal Data, which will cause the issue happen.

Cc: Fu Siyuan 
Cc: Ye Ting 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Wu Jiaxin 
---
 NetworkPkg/IpSecDxe/Ikev2/Utility.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/NetworkPkg/IpSecDxe/Ikev2/Utility.c 
b/NetworkPkg/IpSecDxe/Ikev2/Utility.c
index 0c9c929705..d61bae8c9d 100644
--- a/NetworkPkg/IpSecDxe/Ikev2/Utility.c
+++ b/NetworkPkg/IpSecDxe/Ikev2/Utility.c
@@ -2502,15 +2502,16 @@ Ikev2ChildSaParseSaPayload (
   IntegrityAlgorithm == PreferIntegrityAlgorithm &&
   IsSupportEsn == PreferIsSupportEsn
   ) {
 IsMatch = TRUE;
   } else {
-PreferEncryptAlgorithm   = 0;
-PreferIntegrityAlgorithm = 0;
-IsSupportEsn = TRUE;
+IntegrityAlgorithm = 0;
+EncryptAlgorithm   = 0;
+EncryptKeylength   = 0;
+IsSupportEsn   = FALSE;
   }
-   ProposalData = (IKEV2_PROPOSAL_DATA*)((UINT8*)(ProposalData + 1) +
+  ProposalData = (IKEV2_PROPOSAL_DATA*)((UINT8*)(ProposalData + 1) +
  ProposalData->NumTransforms * sizeof 
(IKEV2_TRANSFORM_DATA));
 }
 
 ProposalData  = (IKEV2_PROPOSAL_DATA *)((IKEV2_SA_DATA 
*)SaPayload->PayloadBuf + 1);
 if (IsMatch) {
-- 
2.17.1.windows.2

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

Re: [edk2] [PATCH 0/5] MdePkg/BaseSynchronizationLib GCC: fixes, cleanups

Laszlo:
  Sorry for the delay. Your change is good. 

Reviewed-by: Liming Gao 

Thanks
Liming
>-Original Message-
>From: Kinney, Michael D
>Sent: Tuesday, October 16, 2018 3:29 AM
>To: Laszlo Ersek ; Gao, Liming ;
>Kinney, Michael D 
>Cc: edk2-devel-01 
>Subject: RE: [edk2] [PATCH 0/5] MdePkg/BaseSynchronizationLib GCC: fixes,
>cleanups
>
>Laszlo,
>
>Thanks for the reminder.  My knowledge of inline
>GCC assembly syntax is very limited, so I am not
>able to review this patch for correctness.  I can
>ack it.
>
>Acked-by: Michael D Kinney 
>
>Perhaps Liming can do a more complete review.
>
>Mike
>
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-
>> boun...@lists.01.org] On Behalf Of Laszlo Ersek
>> Sent: Monday, October 15, 2018 11:05 AM
>> To: Kinney, Michael D ; Gao,
>> Liming 
>> Cc: edk2-devel-01 
>> Subject: Re: [edk2] [PATCH 0/5]
>> MdePkg/BaseSynchronizationLib GCC: fixes, cleanups
>>
>> On 10/08/18 15:44, Laszlo Ersek wrote:
>> > On 09/30/18 00:23, Laszlo Ersek wrote:
>> >> Repo:   https://github.com/lersek/edk2.git
>> >> Branch: inline_asm_rw_ops_1208
>> >>
>> >> This series mainly fixes the operand constraints
>> (missing input-output
>> >> qualifications) in
>> "BaseSynchronizationLib/*/GccInline.c".
>> >>
>> >> (It would be better to remove these files altogether
>> in favor of the
>> >> already existing NASM implementation, but due to
>> >> ,
>> we can't generally
>> >> do that in libraries yet.)
>> >>
>> >> Cc: Liming Gao 
>> >> Cc: Michael D Kinney 
>> >>
>> >> Thanks,
>> >> Laszlo
>> >>
>> >> Laszlo Ersek (5):
>> >>   MdePkg/BaseSynchronizationLib GCC: fix whitespace
>> and comments
>> >>   MdePkg/BaseSynchronizationLib GCC: fix
>> InternalSyncCompareExchange16()
>> >>   MdePkg/BaseSynchronizationLib GCC: fix
>> InternalSyncCompareExchange32()
>> >>   MdePkg/BaseSynchronizationLib GCC: fix X64
>> >> InternalSyncCompareExchange64()
>> >>   MdePkg/BaseSynchronizationLib GCC: simplify IA32
>> >> InternalSyncCompareExchange64()
>> >>
>> >>
>> MdePkg/Library/BaseSynchronizationLib/Ia32/GccInline.c |
>> 42 +++--
>> >>
>> MdePkg/Library/BaseSynchronizationLib/X64/GccInline.c  |
>> 47 +++-
>> >>  2 files changed, 34 insertions(+), 55 deletions(-)
>> >>
>> >
>> > Ping :)
>>
>> Ping
>> ___
>> 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] Expression spec: Add clarification for String compare

Relational and equality operators require both operands to be of
the same type.
Treat the string 'A' and "A" as same type, but for "A" and L"A"
are not same type since one is general string, another is unicode
string.

Cc: Liming Gao 
Cc: Michael Kinney 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yonghong Zhu 
---
 2_expression_overview.md | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/2_expression_overview.md b/2_expression_overview.md
index c29a632..bf66ffe 100644
--- a/2_expression_overview.md
+++ b/2_expression_overview.md
@@ -1,9 +1,9 @@

Re: [edk2] [PATCH] MdePkg/BaseStackCheckLib: add MSFT toolchain support

2018-10-15 Thread Wang, Jian J

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

Regards,
Jian


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org]
> Sent: Tuesday, October 16, 2018 8:55 AM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Yao, Jiewen
> ; Andrew Fish ; Gao, Liming
> 
> Subject: [edk2] [PATCH] MdePkg/BaseStackCheckLib: add MSFT toolchain
> support
> 
> This patch adds stack check support for MSFT toolchain, with
> compiler option /GS and /RTCs. This functionality is similar
> to the original ones supported by GCC toolchain.
> 
> Usage example:
> This is a NULL library instance. Add it under a [LibraryClasses]
> section in dsc file to let it be built into all modules employed
> in a platform.
> 
> [LibraryClasses]
>   NULL|MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf
> 
> Please note all not modules can be built against this library. Most
> of them are SEC type of modules, such as
> 
> OvmfPkg/ResetVector/ResetVector.inf
> 
> In this case, this library should not be added to a common
> [LibraryClasses] section but to specific ones, like
> [LibraryClasses.common.PEI_CORE/PEIM/...].
> 
> In addition, /GS and/or /RTCs should be added to compiler command line.
> This can be done by adding something like below under [BuildOptions]
> section in dsc file.
> 
> [BuildOptions]
>   MSFT:DEBUG_*_*_CC_FLAGS = /GS /GL-
>   MSFT:DEBUG_*_*_CC_FLAGS = /RTCs /Od
> 
> Note: /GL- is required for /GS, and /Od is required for /RTCs.
> Note: The flash layout might be needed to update to accommodate larger
>   image size due to /Od is enforced.
> 
> Pass tests:
> a. Overwrite a local buffer variable (in a 32-bit and 64-bit driver)and
>check if it's caught by new code (on both real platform and virtual
>platform)
> b. Boot Windows 10 and Ubuntu 18.04 on real platform with this
>lib built-in
> 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Jiewen Yao 
> Cc: Andrew Fish 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang 
> ---
>  .../BaseStackCheckLib/BaseStackCheckLib.inf|  11 +-
>  .../Library/BaseStackCheckLib/BaseStackCheckMsft.c | 221
> +
>  .../Library/BaseStackCheckLib/BaseStackCheckNull.c |  15 --
>  .../BaseStackCheckLib/Ia32/StackCheckStubAsm.nasm  |  76 +++
>  .../BaseStackCheckLib/X64/StackCheckStubAsm.nasm   |  54 +
>  5 files changed, 360 insertions(+), 17 deletions(-)
>  create mode 100644
> MdePkg/Library/BaseStackCheckLib/BaseStackCheckMsft.c
>  delete mode 100644 MdePkg/Library/BaseStackCheckLib/BaseStackCheckNull.c
>  create mode 100644
> MdePkg/Library/BaseStackCheckLib/Ia32/StackCheckStubAsm.nasm
>  create mode 100644
> MdePkg/Library/BaseStackCheckLib/X64/StackCheckStubAsm.nasm
> 
> diff --git a/MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf
> b/MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf
> index e280651b11..1c9e6710c6 100644
> --- a/MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf
> +++ b/MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf
> @@ -4,6 +4,7 @@
>  #  Stack Check Library
>  #
>  #  Copyright (c) 2014, ARM Ltd. All rights reserved.
> +#  Copyright (c) 2018, 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
> @@ -26,13 +27,19 @@
> 
> 
>  #
> -#  VALID_ARCHITECTURES   = ARM AARCH64
> +#  VALID_ARCHITECTURES   = ARM AARCH64 IA32 X64
>  #
> 
>  [Sources]
>BaseStackCheckGcc.c  | GCC
>BaseStackCheckGcc.c  | RVCT
> -  BaseStackCheckNull.c | MSFT
> +  BaseStackCheckMsft.c | MSFT
> +
> +[Sources.IA32]
> +  Ia32/StackCheckStubAsm.nasm | MSFT
> +
> +[Sources.X64]
> +  X64/StackCheckStubAsm.nasm | MSFT
> 
>  [Packages]
>MdePkg/MdePkg.dec
> diff --git a/MdePkg/Library/BaseStackCheckLib/BaseStackCheckMsft.c
> b/MdePkg/Library/BaseStackCheckLib/BaseStackCheckMsft.c
> new file mode 100644
> index 00..951154f0cd
> --- /dev/null
> +++ b/MdePkg/Library/BaseStackCheckLib/BaseStackCheckMsft.c
> @@ -0,0 +1,221 @@
> +/** @file
> + Base Stack Check library for MSFT toolchains compiler options: /GS, RTCs.
> +
> +Copyright (c) 2018, Intel Corporation. All rights reserved.
> +This program and the accompanying materials are licensed and made available
> under
> +the terms and conditions of the BSD License that accompanies this 
> distribution.
> +The full text of the license may be found at
> +http://opensource.org/licenses/bsd-license.php.
> +
> +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 
> +
> +//
> +// cookie value that is inserted by the MSFT compiler into the stack frame.
> +//
> +extern UINTN __security_cookie;
> +
> +//
> +// Data structure used by MSFT compiler to record local variable

[edk2] [PATCH] MdePkg/BaseStackCheckLib: add MSFT toolchain support

2018-10-15 Thread Jian J Wang

This patch adds stack check support for MSFT toolchain, with
compiler option /GS and /RTCs. This functionality is similar
to the original ones supported by GCC toolchain.

Usage example:
This is a NULL library instance. Add it under a [LibraryClasses]
section in dsc file to let it be built into all modules employed
in a platform.

[LibraryClasses]
  NULL|MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf

Please note all not modules can be built against this library. Most
of them are SEC type of modules, such as

OvmfPkg/ResetVector/ResetVector.inf

In this case, this library should not be added to a common
[LibraryClasses] section but to specific ones, like
[LibraryClasses.common.PEI_CORE/PEIM/...].

In addition, /GS and/or /RTCs should be added to compiler command line.
This can be done by adding something like below under [BuildOptions]
section in dsc file.

[BuildOptions]
  MSFT:DEBUG_*_*_CC_FLAGS = /GS /GL-
  MSFT:DEBUG_*_*_CC_FLAGS = /RTCs /Od

Note: /GL- is required for /GS, and /Od is required for /RTCs.
Note: The flash layout might be needed to update to accommodate larger
  image size due to /Od is enforced.

Pass tests:
a. Overwrite a local buffer variable (in a 32-bit and 64-bit driver)and
   check if it's caught by new code (on both real platform and virtual
   platform)
b. Boot Windows 10 and Ubuntu 18.04 on real platform with this
   lib built-in

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Jiewen Yao 
Cc: Andrew Fish 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 .../BaseStackCheckLib/BaseStackCheckLib.inf|  11 +-
 .../Library/BaseStackCheckLib/BaseStackCheckMsft.c | 221 +
 .../Library/BaseStackCheckLib/BaseStackCheckNull.c |  15 --
 .../BaseStackCheckLib/Ia32/StackCheckStubAsm.nasm  |  76 +++
 .../BaseStackCheckLib/X64/StackCheckStubAsm.nasm   |  54 +
 5 files changed, 360 insertions(+), 17 deletions(-)
 create mode 100644 MdePkg/Library/BaseStackCheckLib/BaseStackCheckMsft.c
 delete mode 100644 MdePkg/Library/BaseStackCheckLib/BaseStackCheckNull.c
 create mode 100644 MdePkg/Library/BaseStackCheckLib/Ia32/StackCheckStubAsm.nasm
 create mode 100644 MdePkg/Library/BaseStackCheckLib/X64/StackCheckStubAsm.nasm

diff --git a/MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf 
b/MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf
index e280651b11..1c9e6710c6 100644
--- a/MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf
+++ b/MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf
@@ -4,6 +4,7 @@
 #  Stack Check Library
 #
 #  Copyright (c) 2014, ARM Ltd. All rights reserved.
+#  Copyright (c) 2018, 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
@@ -26,13 +27,19 @@
 
 
 #
-#  VALID_ARCHITECTURES   = ARM AARCH64
+#  VALID_ARCHITECTURES   = ARM AARCH64 IA32 X64
 #
 
 [Sources]
   BaseStackCheckGcc.c  | GCC
   BaseStackCheckGcc.c  | RVCT
-  BaseStackCheckNull.c | MSFT
+  BaseStackCheckMsft.c | MSFT
+
+[Sources.IA32]
+  Ia32/StackCheckStubAsm.nasm | MSFT
+
+[Sources.X64]
+  X64/StackCheckStubAsm.nasm | MSFT
 
 [Packages]
   MdePkg/MdePkg.dec
diff --git a/MdePkg/Library/BaseStackCheckLib/BaseStackCheckMsft.c 
b/MdePkg/Library/BaseStackCheckLib/BaseStackCheckMsft.c
new file mode 100644
index 00..951154f0cd
--- /dev/null
+++ b/MdePkg/Library/BaseStackCheckLib/BaseStackCheckMsft.c
@@ -0,0 +1,221 @@
+/** @file
+ Base Stack Check library for MSFT toolchains compiler options: /GS, RTCs.
+
+Copyright (c) 2018, Intel Corporation. All rights reserved.
+This program and the accompanying materials are licensed and made available 
under
+the terms and conditions of the BSD License that accompanies this distribution.
+The full text of the license may be found at
+http://opensource.org/licenses/bsd-license.php.
+
+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 
+
+//
+// cookie value that is inserted by the MSFT compiler into the stack frame.
+//
+extern UINTN __security_cookie;
+
+//
+// Data structure used by MSFT compiler to record local variable information.
+//
+
+typedef struct _RTC_vardesc {
+  int   Addr;
+  int   Size;
+  char  *Name;
+} _RTC_vardesc;
+
+typedef struct _RTC_framedesc {
+  int   VarCount;
+  _RTC_vardesc  *Variables;
+} _RTC_framedesc;
+
+#define RTC_STACK_CHECK_COOKIE  0x
+
+/**
+  Function called upon unexpected stack pointer change.
+
+  @param Ip   Instruction address where the check happened.
+
+**/
+VOID
+__cdecl
+_RTC_Failure (
+  VOID*Ip
+  )
+{
+  DEBUG ((DEBUG_ERROR, "\nSTACK FAULT: Suspicious stack pointer (IP:%p).\n\n", 
Ip));
+
+  //
+  // Generate a Breakpoint, DeadLoop, or NOP based on PCD settings even if
+  //

Re: [edk2] Where to find the fix for security issue id 686

2018-10-15 Thread Rafael Machado

I understood this issue's fix was already released at some branch.
With your message things make sense again.

In this case I can wait for this fix to be publicly available.
Thanks for the clarification!

Best Regards
Rafael

Em seg, 15 de out de 2018 às 16:42, Zimmer, Vincent <
vincent.zim...@intel.com> escreveu:

> Ah ok
>
>
>
> From
> https://github.com/tianocore/tianocore.github.io/wiki/Reporting-Security-Issues
> you will see that issues are only visible to the report and infosec group
> of Bugzilla, namely “Issues in the *Tianocore Security Issue* product are
> only visible to the *Reporter* of the issue and the members of the
> *infosec* group. ”
>
>
>
> Since you were not the reporter of 686 and are not part of infosec, you
> cannot see it.
>
>
>
> If you or anyone in the community would like to help work these issues
> while in triage and embargo, let me know and we can add you to the infosec
> group.
>
>
>
> Vincent
>
>
>
> *From:* Rafael Machado [mailto:rafaelrodrigues.mach...@gmail.com]
> *Sent:* Monday, October 15, 2018 12:17 PM
> *To:* Zimmer, Vincent 
> *Cc:* edk2-devel@lists.01.org
> *Subject:* Re: [edk2] Where to find the fix for security issue id 686
>
>
>
> Hi Vincent
>
>
>
> Thanks for the answer.
>
> The problem is that when I try to access this link I have this message: "You
> are not authorized to access bug #686."
>
>
>
> Any idea?
>
>
>
> Em seg, 15 de out de 2018 às 14:28, Zimmer, Vincent <
> vincent.zim...@intel.com> escreveu:
>
> You can find reference to patches via the advisory entry
>
> "31. EDK II TIANOCOMPRESS BOUNDS CHECKING ISSUES" advisory entry
> https://edk2-docs.gitbooks.io/security-advisory/content/edk-ii-tianocompress-bounds-checking-issues.html
> has an embedded link to
> https://bugzilla.tianocore.org/attachment.cgi?id=150
>
> Vincent
>
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Rafael Machado
> Sent: Monday, October 15, 2018 5:39 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] Where to find the fix for security issue id 686
>
> Hi everyone
>
> I was tying to find the patch to fix the reported security issue id 686 (
> https://bugzilla.tianocore.org/show_bug.cgi?id=686),
> but was not able to access it.
>
> Could someone please tell if this patch, or series of patches, was already
> merged to some branch that is public available?
>
> Thanks and Regards
> Rafael R. Machado
> ___
> 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] BaseTools: Support to use struct name as datum type before max size

Reviewed-by: Liming Gao 

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Yonghong Zhu
>Sent: Monday, October 15, 2018 9:23 PM
>To: edk2-devel@lists.01.org
>Subject: [edk2] [Patch] BaseTools: Support to use struct name as datum type
>before max size
>
>Original it hard code to use "VOID*", this patch extend it to both
>support VOID* and valid struct name.
>
>Contributed-under: TianoCore Contribution Agreement 1.1
>Signed-off-by: Yonghong Zhu 
>---
> BaseTools/Source/Python/Common/Misc.py  | 4 +++-
> BaseTools/Source/Python/Workspace/MetaFileParser.py | 6 +++---
> 2 files changed, 6 insertions(+), 4 deletions(-)
>
>diff --git a/BaseTools/Source/Python/Common/Misc.py
>b/BaseTools/Source/Python/Common/Misc.py
>index 2cf9574..3c71dfc 100644
>--- a/BaseTools/Source/Python/Common/Misc.py
>+++ b/BaseTools/Source/Python/Common/Misc.py
>@@ -47,10 +47,12 @@ startPatternGeneral = re.compile("^Start[' ']+Length['
>']+Name[' ']+Class")
> addressPatternGeneral = re.compile("^Address[' ']+Publics by Value['
>']+Rva\+Base")
> valuePatternGcc = re.compile('^([\w_\.]+) +([\da-fA-Fx]+) +([\da-fA-Fx]+)$')
> pcdPatternGcc = re.compile('^([\da-fA-Fx]+) +([\da-fA-Fx]+)')
> secReGeneral = re.compile('^([\da-fA-F]+):([\da-fA-F]+) +([\da-fA-F]+)[Hh]?
>+([.\w\$]+) +(\w+)', re.UNICODE)
>
>+StructPattern = re.compile(r'[_a-zA-Z][0-9A-Za-z_]*$')
>+
> ## Dictionary used to store file time stamp for quick re-access
> gFileTimeStampCache = {}# {file path : file time stamp}
>
> ## Dictionary used to store dependencies of files
> gDependencyDatabase = {}# arch : {file path : [dependent files list]}
>@@ -1461,11 +1463,11 @@ def AnalyzeDscPcd(Setting, PcdType, DataType=''):
> if PcdType in (MODEL_PCD_FIXED_AT_BUILD,
>MODEL_PCD_PATCHABLE_IN_MODULE, MODEL_PCD_DYNAMIC_DEFAULT,
>MODEL_PCD_DYNAMIC_EX_DEFAULT):
> Value = FieldList[0]
> Size = ''
> if len(FieldList) > 1 and FieldList[1]:
> DataType = FieldList[1]
>-if FieldList[1] != TAB_VOID:
>+if FieldList[1] != TAB_VOID and StructPattern.match(FieldList[1]) 
>is
>None:
> IsValid = False
> if len(FieldList) > 2:
> Size = FieldList[2]
> if IsValid:
> if DataType == "":
>diff --git a/BaseTools/Source/Python/Workspace/MetaFileParser.py
>b/BaseTools/Source/Python/Workspace/MetaFileParser.py
>index 79e3180..f33b91c 100644
>--- a/BaseTools/Source/Python/Workspace/MetaFileParser.py
>+++ b/BaseTools/Source/Python/Workspace/MetaFileParser.py
>@@ -27,11 +27,11 @@ import Common.EdkLogger as EdkLogger
> import Common.GlobalData as GlobalData
>
> from CommonDataClass.DataClass import *
> from Common.DataType import *
> from Common.StringUtils import *
>-from Common.Misc import GuidStructureStringToGuidString,
>CheckPcdDatum, PathClass, AnalyzePcdData, AnalyzeDscPcd,
>AnalyzePcdExpression, ParseFieldValue
>+from Common.Misc import GuidStructureStringToGuidString,
>CheckPcdDatum, PathClass, AnalyzePcdData, AnalyzeDscPcd,
>AnalyzePcdExpression, ParseFieldValue, StructPattern
> from Common.Expression import *
> from CommonDataClass.Exceptions import *
> from Common.LongFilePathSupport import OpenLongFilePath as open
> from collections import defaultdict
> from .MetaFileTable import MetaFileStorage
>@@ -1610,12 +1610,12 @@ class DscParser(MetaFileParser):
> return
>
> ValList, Valid, Index = AnalyzeDscPcd(self._ValueList[2], 
> self._ItemType)
> if not Valid:
> if self._ItemType in (MODEL_PCD_DYNAMIC_DEFAULT,
>MODEL_PCD_DYNAMIC_EX_DEFAULT, MODEL_PCD_FIXED_AT_BUILD,
>MODEL_PCD_PATCHABLE_IN_MODULE):
>-if ValList[1] != TAB_VOID and ValList[2]:
>-EdkLogger.error('build', FORMAT_INVALID, "Pcd format 
>incorrect.
>Only VOID* type PCD need the maxsize info.", File=self._FileWithError,
>+if ValList[1] != TAB_VOID and StructPattern.match(ValList[1]) 
>is None
>and ValList[2]:
>+EdkLogger.error('build', FORMAT_INVALID, "Pcd format 
>incorrect.
>The datum type info should be VOID* or a valid struct name.",
>File=self._FileWithError,
> Line=self._LineIndex + 1, 
> ExtraData="%s.%s|%s" %
>(self._ValueList[0], self._ValueList[1], self._ValueList[2]))
> EdkLogger.error('build', FORMAT_INVALID, "Pcd format incorrect.",
>File=self._FileWithError, Line=self._LineIndex + 1,
> ExtraData="%s.%s|%s" % (self._ValueList[0], 
> self._ValueList[1],
>self._ValueList[2]))
> PcdValue = ValList[Index]
> if PcdValue and "." not in self._ValueList[0]:
>--
>2.6.1.windows.1
>
>___
>edk2-devel mailing list
>edk2-devel@lists.01.org
>https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org

Re: [edk2] [PATCH] CorebootPayloadPkg: don't use serial output for Release build

2018-10-15 Thread Ma, Maurice

Hi, Kim,

Looks good to me.
Reviewed-by: Maurice Ma 

-Maurice

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Wonkyu 
Kim
Sent: Monday, October 15, 2018 15:45
To: edk2-devel@lists.01.org
Cc: Williams, Hannah ; gauml...@gmail.com; Zhao, 
Lijian ; Kim, Wonkyu ; 
stefan.reina...@coreboot.org; Agyeman, Prince 
Subject: [edk2] [PATCH] CorebootPayloadPkg: don't use serial output for Release 
build

From: Wonkyu Kim 

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Wonkyu Kim 
---
 CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc| 4 
 CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc | 4 
 2 files changed, 8 insertions(+)

diff --git a/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc 
b/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc
index b6cdb697a5b0..7d5052be9301 100644
--- a/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc
+++ b/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc
@@ -263,7 +263,11 @@
 #
 

 [PcdsFeatureFlag]
+!if $(TARGET) == DEBUG
   gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseSerial|TRUE
+!else
+  gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseSerial|FALSE
+!endif
   gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseMemory|FALSE
   gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode|FALSE
   gEfiMdeModulePkgTokenSpaceGuid.PcdConOutGopSupport|TRUE
diff --git a/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc 
b/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc
index c3fe099e5fec..0484e941cce7 100644
--- a/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc
+++ b/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc
@@ -263,7 +263,11 @@
 #
 

 [PcdsFeatureFlag]
+!if $(TARGET) == DEBUG
   gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseSerial|TRUE
+!else
+  gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseSerial|FALSE
+!endif
   gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseMemory|FALSE
   gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode|TRUE
   gEfiMdeModulePkgTokenSpaceGuid.PcdConOutGopSupport|TRUE
-- 
2.17.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] TianoCore Community Meeting Minutes (stephano)

2018-10-15 Thread Jeremiah Cox

Some additional feedback...


General
---
We would like to have a discussion around goals, what are the top issues we are 
trying to solve with these solutions?  We believe a primary challenge is 
getting code integrated downstream.  We would like to see security patches flow 
to more systems, faster, with higher confidence.  The same applies to new UEFI 
features.  Part of making downstream integration efficient is getting 
downstream changes upstreamed, thus we support efforts to improve upstream 
contribution efficiency & quality.


Patch Workflow Improvement
-- 
We would like to propose adding Azure DevOps (previously Visual Studio Online) 
to the list.  Azure DevOps is free for OSS and more feature rich than GitHub: 
https://azure.microsoft.com/en-us/pricing/details/devops/azure-devops-services/ 


Public CI
-
With respect to using Azure DevOps for CI, we have an example of this working 
here:
https://dev.azure.com/projectmu/mu/_build?definitionId=4 


Repos & Submodules
--
In an upcoming meeting, we would like to discuss code layout and repositories.  
We propose to introduce layering and separation for a variety of reasons, best 
articulated by visiting the following:
https://microsoft.github.io/mu/ 



Kind regards,
Jeremiah Cox

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

[edk2] [PATCH] CorebootPayloadPkg: don't use serial output for Release build

2018-10-15 Thread Wonkyu Kim

From: Wonkyu Kim 

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Wonkyu Kim 
---
 CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc| 4 
 CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc | 4 
 2 files changed, 8 insertions(+)

diff --git a/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc 
b/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc
index b6cdb697a5b0..7d5052be9301 100644
--- a/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc
+++ b/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc
@@ -263,7 +263,11 @@
 #
 

 [PcdsFeatureFlag]
+!if $(TARGET) == DEBUG
   gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseSerial|TRUE
+!else
+  gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseSerial|FALSE
+!endif
   gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseMemory|FALSE
   gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode|FALSE
   gEfiMdeModulePkgTokenSpaceGuid.PcdConOutGopSupport|TRUE
diff --git a/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc 
b/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc
index c3fe099e5fec..0484e941cce7 100644
--- a/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc
+++ b/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc
@@ -263,7 +263,11 @@
 #
 

 [PcdsFeatureFlag]
+!if $(TARGET) == DEBUG
   gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseSerial|TRUE
+!else
+  gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseSerial|FALSE
+!endif
   gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseMemory|FALSE
   gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode|TRUE
   gEfiMdeModulePkgTokenSpaceGuid.PcdConOutGopSupport|TRUE
-- 
2.17.1

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

Re: [edk2] Missing Library in StandaloneMmPkg

2018-10-15 Thread Achin Gupta

Hi Eugene,

Apologies for the confusion and inconvenience! I will try and explain.

The original patchset for MM Standalone support on x86 and AArch64 had around 16
patches. These included changes to the StandaloneMmPkg, ArmPkg, BaseTools & the
Arm VExpressPkg mainly. This patchset was split into three main categories (The
BaseTools changes were upstreamed separately)

1. StandaloneMmPkg changes. These were merged into master as described here
   [1]. These include all the generic code, Secure world code on AArch64 and x86
   support.

2. edk2-platform changes. These are still under review here [2]. These include
   the ARM AEM FVP changes to support Standalone MM.

3. ArmPkg changes. These are under review here [3]. These include all the Normal
   world code to support Standalone MM e.g. the communication driver. They also
   include the ArmMmuStandaloneMmCoreLib implementation.

Late in the review cycle, Ard raised some valid concerns about how the
PeCoffExtraActionLib has been used by patchset [3]. You can see this thread here
[4]. He has also suggested an alternative approach to solve the impasse. We are
investigating this within Arm at the moment.

The plan is to get [2] & [3] merged and this would complete upstream support for
Standalone MM on AArch64 AEM FVP. In the meantime, these patches should work in
any case. Please let me or Sughosh know if you run into any issues. We can
provide instructions if that helps. Please let us know.

Once we are past this hurdle, there is a plan to add support for Standalone MM
for AArch64 on QEMU.

One the maintenance front, me and Yao Jiewen are the maintainers. 

Feature wise, on the Arm front, the next major step is to add support for
multiple S-EL0 Standalone MM partitions. This will take 6-9 months at least to
be available upstream as we are still writing the Arm specifications to support
this.

I hope this makes things clearer. Please let me know.

cheers,
Achin

[1] https://lists.01.org/pipermail/edk2-devel/2018-July/027322.html
[2] https://lists.01.org/pipermail/edk2-devel/2018-May/024489.html
[3] https://lists.01.org/pipermail/edk2-devel/2018-July/027383.html
[4] https://lists.01.org/pipermail/edk2-devel/2018-August/029003.html

On Mon, Oct 15, 2018 at 08:00:41PM +, Cohen, Eugene wrote:
>Supreeth, thanks for the fast response.
> 
> 
>I'm struggling with what to do next - it sounds like we have a partial
>StandaloneMmPkg implementation on master.  I'm willing to complete the
>implementation for our needs but would first like to understand what
>the plan is for completing and maintaining the package (and not just on
>the ARM side).
> 
> 
>Thanks,
> 
> 
>Eugene
> 
> 
>From: Supreeth Venkatesh 
>Sent: Monday, October 15, 2018 1:49 PM
>To: Cohen, Eugene ; edk2-devel@lists.01.org; Achin Gupta
>; Jiewen Yao ; Sughosh Ganu
>
>Cc: Dong Wei 
>Subject: RE: Missing Library in StandaloneMmPkg
> 
> 
>Eugene,
>The working StandaloneMm available here:
>[1]https://github.com/supven01/edk2
>[2]https://github.com/supven01/edk2-platforms
>(Caveat: Working Version as of July 2018, May not be latest)
>As you mentioned, the patches were sent in June/July for Review.
>I have not received any comments/feedback on those.
>As you say, it has either not been reviewed by the maintainers or
>merged yet.
>I am no longer working on StandaloneMm at this point.
>However, Achin or Sughosh will be able to point you to the latest code
>base.
>Thanks,
>Supreeth
>-Original Message-
>From: Cohen, Eugene <[3]eug...@hp.com>
>Sent: Monday, October 15, 2018 2:29 PM
>To: [4]edk2-devel@lists.01.org; Achin Gupta <[5]achin.gu...@arm.com>;
>Jiewen Yao <[6]jiewen@intel.com>; Supreeth Venkatesh
><[7]supreeth.venkat...@arm.com>; Sughosh Ganu <[8]sughosh.g...@arm.com>
>Subject: Missing Library in StandaloneMmPkg
>Greetings,
>It appears that StandaloneMmPkg/StandaloneMmPkg.dsc contains a
>reference to this library:
>ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuStandaloneMmCoreLib.inf
>but it does not actually appear in the tree.
>The AArch64StandaloneMm branch on edk2-staging is "stale" (not my words
>but what GitHub calls it) and it does not contain this library so I'm
>led to believe that there is some other branch where this is being
>developed. I also see patch submissions from July that are not yet
>integrated (StandaloneMmServicesTableLib in particular).
>Can I get a summary of the state of the project, in general and on ARM
>platforms? Is there a repo or branch we should be going to where we can
>see a usable system?
>Thanks,
>Eugene
>IMPORTANT NOTICE: The contents of this email and any attachments are
>confidential and may also be privileged. If you are not the intended
>recipient, please notify the sender immediately and do not disclose the
>contents to any other person,

Re: [edk2] [PATCH] BaseTools/EOT: Change to call a program instead of calling Python API.

Hess,

Thanks for the clarification. Makes sense!

I glanced at, but didn't read in detail the code... so.

Acked-by: Jaben Carsey 

> -Original Message-
> From: Chen, Hesheng
> Sent: Monday, October 15, 2018 2:34 PM
> To: Carsey, Jaben ; Zhu, Yonghong
> ; edk2-devel@lists.01.org
> Subject: RE: [edk2] [PATCH] BaseTools/EOT: Change to call a program instead
> of calling Python API.
> Importance: High
> 
> Hello Jaben,
> The API is provided by C code and we want Python tool to use it. The tool
> used to call Python API from DLL files and now we need run Python tools
> from source so we can't build a specific version of DLL binary for it. The DLL
> file may be different for different version of Python. So now we just call the
> C program directly for the API.
> 
> Best Regards,
> Chen, Hess
> Intel China Software Center
> Tel: +86-21-6116-6740
> Email: hesheng.c...@intel.com
> 
> -Original Message-
> From: Carsey, Jaben
> Sent: Tuesday, October 16, 2018 1:45 AM
> To: Zhu, Yonghong ; edk2-devel@lists.01.org
> Cc: Chen, Hesheng 
> Subject: RE: [edk2] [PATCH] BaseTools/EOT: Change to call a program instead
> of calling Python API.
> 
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Yonghong Zhu
> > Sent: Monday, October 15, 2018 3:24 AM
> > To: edk2-devel@lists.01.org
> > Cc: Chen, Hesheng 
> > Subject: [edk2] [PATCH] BaseTools/EOT: Change to call a program
> > instead of calling Python API.
> >
> > From: hchen30 
> >
> > Update the EOT tool to call the program itself instead of calling the
> > Python API when parsing FV images.
> 
> Why do we prefer to launch the separate python program instead of calling
> the APIs?
> 
> 
> >
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Hess Chen 
> > ---
> >  BaseTools/Source/Python/Eot/{Eot.py => EotMain.py} | 465
> > +++--
> > 
> >  BaseTools/Source/Python/Eot/InfParserLite.py   |  26 +-
> >  BaseTools/Source/Python/Eot/Parser.py  |  28 +-
> >  BaseTools/Source/Python/Eot/Report.py  |   6 +-
> >  BaseTools/Source/Python/build/BuildReport.py   |   2 +-
> >  5 files changed, 84 insertions(+), 443 deletions(-)  rename
> > BaseTools/Source/Python/Eot/{Eot.py => EotMain.py} (75%)
> >
> > diff --git a/BaseTools/Source/Python/Eot/Eot.py
> > b/BaseTools/Source/Python/Eot/EotMain.py
> > similarity index 75%
> > rename from BaseTools/Source/Python/Eot/Eot.py
> > rename to BaseTools/Source/Python/Eot/EotMain.py
> > index ce83da1495..49a1494126 100644
> > --- a/BaseTools/Source/Python/Eot/Eot.py
> > +++ b/BaseTools/Source/Python/Eot/EotMain.py
> > @@ -17,18 +17,20 @@
> >  from __future__ import absolute_import  import
> Common.LongFilePathOs
> > as os, time, glob  import Common.EdkLogger as EdkLogger -from . import
> > EotGlobalData
> > +import Eot.EotGlobalData as EotGlobalData
> >  from optparse import OptionParser
> >  from Common.StringUtils import NormPath  from Common import
> > BuildToolError  from Common.Misc import
> > GuidStructureStringToGuidString, sdict -from .InfParserLite import *
> > -from . import c -from . import Database
> > +from Eot.Parser import *
> > +from Eot.InfParserLite import EdkInfParser from Common.StringUtils
> > +import GetSplitValueList from Eot import c from Eot import Database
> >  from array import array
> > -from .Report import Report
> > +from Eot.Report import Report
> >  from Common.BuildVersion import gBUILD_VERSION -from .Parser import
> > ConvertGuid
> > +from Eot.Parser import ConvertGuid
> >  from Common.LongFilePathSupport import OpenLongFilePath as open
> > import struct  import uuid @@ -58,14 +60,14 @@ class Image(array):
> >
> >  self._SubImages = sdict() # {offset: Image()}
> >
> > -array.__init__(self, 'B')
> > +array.__init__(self)
> >
> >  def __repr__(self):
> >  return self._ID_
> >
> >  def __len__(self):
> >  Len = array.__len__(self)
> > -for Offset in self._SubImages:
> > +for Offset in self._SubImages.keys():
> >  Len += len(self._SubImages[Offset])
> >  return Len
> >
> > @@ -154,19 +156,11 @@ class CompressedImage(Image):
> >
> >  def _GetSections(self):
> >  try:
> > -from . import EfiCompressor
> > -TmpData = EfiCompressor.FrameworkDecompress(
> > -self[self._HEADER_SIZE_:],
> > -len(self) - self._HEADER_SIZE_
> > -)
> > +TmpData = DeCompress('Efi', self[self._HEADER_SIZE_:])
> >  DecData = array('B')
> >  DecData.fromstring(TmpData)
> >  except:
> > -from . import EfiCompressor
> > -TmpData = EfiCompressor.UefiDecompress(
> > -self[self._HEADER_SIZE_:],
> > -len(self) -

Re: [edk2] [PATCH] BaseTools/EOT: Change to call a program instead of calling Python API.

2018-10-15 Thread Chen, Hesheng

Hello Jaben,
The API is provided by C code and we want Python tool to use it. The tool used 
to call Python API from DLL files and now we need run Python tools from source 
so we can't build a specific version of DLL binary for it. The DLL file may be 
different for different version of Python. So now we just call the C program 
directly for the API.

Best Regards,
Chen, Hess
Intel China Software Center
Tel: +86-21-6116-6740
Email: hesheng.c...@intel.com

-Original Message-
From: Carsey, Jaben 
Sent: Tuesday, October 16, 2018 1:45 AM
To: Zhu, Yonghong ; edk2-devel@lists.01.org
Cc: Chen, Hesheng 
Subject: RE: [edk2] [PATCH] BaseTools/EOT: Change to call a program instead of 
calling Python API.


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Yonghong Zhu
> Sent: Monday, October 15, 2018 3:24 AM
> To: edk2-devel@lists.01.org
> Cc: Chen, Hesheng 
> Subject: [edk2] [PATCH] BaseTools/EOT: Change to call a program 
> instead of calling Python API.
> 
> From: hchen30 
> 
> Update the EOT tool to call the program itself instead of calling the 
> Python API when parsing FV images.

Why do we prefer to launch the separate python program instead of calling the 
APIs?


> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Hess Chen 
> ---
>  BaseTools/Source/Python/Eot/{Eot.py => EotMain.py} | 465 
> +++--
> 
>  BaseTools/Source/Python/Eot/InfParserLite.py   |  26 +-
>  BaseTools/Source/Python/Eot/Parser.py  |  28 +-
>  BaseTools/Source/Python/Eot/Report.py  |   6 +-
>  BaseTools/Source/Python/build/BuildReport.py   |   2 +-
>  5 files changed, 84 insertions(+), 443 deletions(-)  rename 
> BaseTools/Source/Python/Eot/{Eot.py => EotMain.py} (75%)
> 
> diff --git a/BaseTools/Source/Python/Eot/Eot.py
> b/BaseTools/Source/Python/Eot/EotMain.py
> similarity index 75%
> rename from BaseTools/Source/Python/Eot/Eot.py
> rename to BaseTools/Source/Python/Eot/EotMain.py
> index ce83da1495..49a1494126 100644
> --- a/BaseTools/Source/Python/Eot/Eot.py
> +++ b/BaseTools/Source/Python/Eot/EotMain.py
> @@ -17,18 +17,20 @@
>  from __future__ import absolute_import  import Common.LongFilePathOs 
> as os, time, glob  import Common.EdkLogger as EdkLogger -from . import 
> EotGlobalData
> +import Eot.EotGlobalData as EotGlobalData
>  from optparse import OptionParser
>  from Common.StringUtils import NormPath  from Common import 
> BuildToolError  from Common.Misc import 
> GuidStructureStringToGuidString, sdict -from .InfParserLite import * 
> -from . import c -from . import Database
> +from Eot.Parser import *
> +from Eot.InfParserLite import EdkInfParser from Common.StringUtils 
> +import GetSplitValueList from Eot import c from Eot import Database
>  from array import array
> -from .Report import Report
> +from Eot.Report import Report
>  from Common.BuildVersion import gBUILD_VERSION -from .Parser import 
> ConvertGuid
> +from Eot.Parser import ConvertGuid
>  from Common.LongFilePathSupport import OpenLongFilePath as open  
> import struct  import uuid @@ -58,14 +60,14 @@ class Image(array):
> 
>  self._SubImages = sdict() # {offset: Image()}
> 
> -array.__init__(self, 'B')
> +array.__init__(self)
> 
>  def __repr__(self):
>  return self._ID_
> 
>  def __len__(self):
>  Len = array.__len__(self)
> -for Offset in self._SubImages:
> +for Offset in self._SubImages.keys():
>  Len += len(self._SubImages[Offset])
>  return Len
> 
> @@ -154,19 +156,11 @@ class CompressedImage(Image):
> 
>  def _GetSections(self):
>  try:
> -from . import EfiCompressor
> -TmpData = EfiCompressor.FrameworkDecompress(
> -self[self._HEADER_SIZE_:],
> -len(self) - self._HEADER_SIZE_
> -)
> +TmpData = DeCompress('Efi', self[self._HEADER_SIZE_:])
>  DecData = array('B')
>  DecData.fromstring(TmpData)
>  except:
> -from . import EfiCompressor
> -TmpData = EfiCompressor.UefiDecompress(
> -self[self._HEADER_SIZE_:],
> -len(self) - self._HEADER_SIZE_
> -)
> +TmpData = DeCompress('Framework', 
> + self[self._HEADER_SIZE_:])
>  DecData = array('B')
>  DecData.fromstring(TmpData)
> 
> @@ -297,7 +291,7 @@ class Depex(Image):
> 
>  Expression = property(_GetExpression)
> 
> -## FirmwareVolume() class
> +# # FirmwareVolume() class
>  #
>  #  A class for Firmware Volume
>  #
> @@ -308,12 +302,12 @@ class FirmwareVolume(Image):
> 
>  _FfsGuid = "8C8CE578-8A3D-4F1C-9935-896185C32DD3"
> 
> -_GUID_  = struct.Struct("16x 1I2H8B")
> -_LENGTH_= struct.Struct("16x

Re: [edk2] Regression with PXE boot on OvmfPkg/VirtioNetDxe driver on aarch64 system

2018-10-15 Thread aaron . young

On 10/04/18 06:06, Laszlo Ersek wrote:

On 10/04/18 11:24, Leif Lindholm wrote:

+Peter

On Wed, Oct 03, 2018 at 04:59:54PM -0700, aaron.yo...@oracle.com wrote:

I am suspecting that this patch to GRUB is the cause of a Buffer being
re-transmitted before reaping the Buffer via SNP->GetStatus():

https://git.centos.org/blob/rpms!grub2.git/1065bd29e776aef83f927747882140dcb6fd5cde/SOURCES!0183-efinet-retransmit-if-our-device-is-busy.patch

So, to reproduce the issue, the GRUB used via PXE boot needs to include
this patch.

So the issue cannot be reproduced with upstream GRUB?

Does Fedora/Red Hat include the same patch?

Here's what I can see.

(1) In upstream grub , at
commit 8ada906031d9 ("msdos: Fix overflow in converting partition start
and length into 512B blocks", 2018-09-27), on the master branch, the
patch is not present.

(2) In "rhboot" grub2 , where the
master branch seems to track upstream grub, the patch is present on at
least the "fedora-28" and "rhel-7.5" branches. Commit hashes,
respectively: c2b126f52143, 1b9767c136082.

(3) In the commit message, Josef wrote, "When I fixed the txbuf handling
I ripped out the retransmission code". I think he referred to his
earlier commit 4fe8e6d4a127 ("efinet: handle get_status() on buggy
firmware properly", 2015-08-09). That commit is upstream.

In my opinion, commit 4fe8e6d4a127, the chronologically first, and
upstream, tweak, was right (assuming the comment it added was true,
about grub).

On the other hand, the downstream-only (chronologically 2nd) commit was
wrong. Not only did it break the spec, it broke even grub's own internal
invariant, described in the comment that was added in upstream commit
4fe8e6d4a127. The comment states, "we only transmit one packet at a
time". With the downstream-only tweak applied, that's no longer true.
Namely, SNP.Transmit() is called while we know another transmission is
pending on the egress queue. That's the definition of sending more than
one packet at a time.

I'm curious why the patch in question is not upstream. Was it submitted
and rejected? Submitted and ignored? Not submitted at all?

I'm not a fan of the hard-liner "spec above everything" approach. In
this case though, after the downstream-only tweak, grub is inconsistent
not only with the spec, but with itself too.

IMO, downstream(s) should revert the downstream-only patch.

Thanks,
Laszlo

I have confirmed that reverting this GRUB patch indeed fixes the issue
(i.e. with the VirtioNetDxe/SnpSharedHelpers.c(184) ASSERT).

Thanks for the help/info in resolving this issue.

As a follow up question - it seems that the VirtioNetDxe driver is
fragile in that it can get into broken state if (for whatever reason) a
tx buffer is not successfully transmitted and thus never shows back up
on the Used Ring. i.e. If a SNP client has repeatedly called
SNP-GetStatus() and, after a certain amount of time, fails gets back the
buffer, what should it do? If it attempts to re-transmit the buffer,
it'll hit the ASSERT. Perhaps it should shutdown/re-init the interface
in this case (to free up the buffer mapping in Dev->TxBufCollection)?
Or, are we confident this condition can _never_ happen?

Thanks again,

-Aaron

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

Re: [edk2] Missing Library in StandaloneMmPkg

2018-10-15 Thread Cohen, Eugene

Supreeth, thanks for the fast response.

I'm struggling with what to do next - it sounds like we have a partial 
StandaloneMmPkg implementation on master.  I'm willing to complete the 
implementation for our needs but would first like to understand what the plan 
is for completing and maintaining the package (and not just on the ARM side).

Thanks,

Eugene

From: Supreeth Venkatesh 
Sent: Monday, October 15, 2018 1:49 PM
To: Cohen, Eugene ; edk2-devel@lists.01.org; Achin Gupta 
; Jiewen Yao ; Sughosh Ganu 

Cc: Dong Wei 
Subject: RE: Missing Library in StandaloneMmPkg

Eugene,

The working StandaloneMm available here:
https://github.com/supven01/edk2
https://github.com/supven01/edk2-platforms
(Caveat: Working Version as of July 2018, May not be latest)

As you mentioned, the patches were sent in June/July for Review.
I have not received any comments/feedback on those.
As you say, it has either not been reviewed by the maintainers or merged yet.

I am no longer working on StandaloneMm at this point.
However, Achin or Sughosh will be able to point you to the latest code base.

Thanks,
Supreeth

-Original Message-
From: Cohen, Eugene mailto:eug...@hp.com>>
Sent: Monday, October 15, 2018 2:29 PM
To: edk2-devel@lists.01.org; Achin Gupta 
mailto:achin.gu...@arm.com>>; Jiewen Yao 
mailto:jiewen@intel.com>>; Supreeth Venkatesh 
mailto:supreeth.venkat...@arm.com>>; Sughosh Ganu 
mailto:sughosh.g...@arm.com>>
Subject: Missing Library in StandaloneMmPkg

Greetings,

It appears that StandaloneMmPkg/StandaloneMmPkg.dsc contains a reference to 
this library:

ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuStandaloneMmCoreLib.inf

but it does not actually appear in the tree.

The AArch64StandaloneMm branch on edk2-staging is "stale" (not my words but 
what GitHub calls it) and it does not contain this library so I'm led to 
believe that there is some other branch where this is being developed. I also 
see patch submissions from July that are not yet integrated 
(StandaloneMmServicesTableLib in particular).


Can I get a summary of the state of the project, in general and on ARM 
platforms? Is there a repo or branch we should be going to where we can see a 
usable system?

Thanks,

Eugene



IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Missing Library in StandaloneMmPkg

Eugene,

The working StandaloneMm available here:
https://github.com/supven01/edk2
https://github.com/supven01/edk2-platforms
(Caveat: Working Version as of July 2018, May not be latest)

As you mentioned, the patches were sent in June/July for Review.
I have not received any comments/feedback on those.
As you say, it has either not been reviewed by the maintainers or merged yet.

I am no longer working on StandaloneMm at this point.
However, Achin or Sughosh will be able to point you to the latest code base.

Thanks,
Supreeth

-Original Message-
From: Cohen, Eugene 
Sent: Monday, October 15, 2018 2:29 PM
To: edk2-devel@lists.01.org; Achin Gupta ; Jiewen Yao 
; Supreeth Venkatesh ; 
Sughosh Ganu 
Subject: Missing Library in StandaloneMmPkg

Greetings,

It appears that StandaloneMmPkg/StandaloneMmPkg.dsc contains a reference to 
this library:

ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuStandaloneMmCoreLib.inf

but it does not actually appear in the tree.

The AArch64StandaloneMm branch on edk2-staging is "stale" (not my words but 
what GitHub calls it) and it does not contain this library so I'm led to 
believe that there is some other branch where this is being developed.  I also 
see patch submissions from July that are not yet integrated 
(StandaloneMmServicesTableLib in particular).


Can I get a summary of the state of the project, in general and on ARM 
platforms?  Is there a repo or branch we should be going to where we can see a 
usable system?

Thanks,

Eugene



IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Where to find the fix for security issue id 686

2018-10-15 Thread Zimmer, Vincent

Ah ok

From 
https://github.com/tianocore/tianocore.github.io/wiki/Reporting-Security-Issues 
you will see that issues are only visible to the report and infosec group of 
Bugzilla, namely “Issues in the Tianocore Security Issue product are only 
visible to the Reporter of the issue and the members of the infosec group. ”

Since you were not the reporter of 686 and are not part of infosec, you cannot 
see it.

If you or anyone in the community would like to help work these issues while in 
triage and embargo, let me know and we can add you to the infosec group.

Vincent

From: Rafael Machado [mailto:rafaelrodrigues.mach...@gmail.com]
Sent: Monday, October 15, 2018 12:17 PM
To: Zimmer, Vincent 
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] Where to find the fix for security issue id 686

Hi Vincent

Thanks for the answer.
The problem is that when I try to access this link I have this message: "You 
are not authorized to access bug #686."

Any idea?

Em seg, 15 de out de 2018 às 14:28, Zimmer, Vincent 
mailto:vincent.zim...@intel.com>> escreveu:
You can find reference to patches via the advisory entry

"31. EDK II TIANOCOMPRESS BOUNDS CHECKING ISSUES" advisory entry 
https://edk2-docs.gitbooks.io/security-advisory/content/edk-ii-tianocompress-bounds-checking-issues.html
 has an embedded link to https://bugzilla.tianocore.org/attachment.cgi?id=150

Vincent

-Original Message-
From: edk2-devel 
[mailto:edk2-devel-boun...@lists.01.org]
 On Behalf Of Rafael Machado
Sent: Monday, October 15, 2018 5:39 AM
To: edk2-devel@lists.01.org
Subject: [edk2] Where to find the fix for security issue id 686

Hi everyone

I was tying to find the patch to fix the reported security issue id 686 ( 
https://bugzilla.tianocore.org/show_bug.cgi?id=686),
but was not able to access it.

Could someone please tell if this patch, or series of patches, was already 
merged to some branch that is public available?

Thanks and Regards
Rafael R. Machado
___
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] Missing Library in StandaloneMmPkg

2018-10-15 Thread Cohen, Eugene

Greetings,

It appears that StandaloneMmPkg/StandaloneMmPkg.dsc contains a reference to 
this library:

ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuStandaloneMmCoreLib.inf

but it does not actually appear in the tree.

The AArch64StandaloneMm branch on edk2-staging is "stale" (not my words but 
what GitHub calls it) and it does not contain this library so I'm led to 
believe that there is some other branch where this is being developed.  I also 
see patch submissions from July that are not yet integrated 
(StandaloneMmServicesTableLib in particular).


Can I get a summary of the state of the project, in general and on ARM 
platforms?  Is there a repo or branch we should be going to where we can see a 
usable system?

Thanks,

Eugene



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

Re: [edk2] [PATCH 0/5] MdePkg/BaseSynchronizationLib GCC: fixes, cleanups

2018-10-15 Thread Kinney, Michael D

Laszlo,

Thanks for the reminder.  My knowledge of inline
GCC assembly syntax is very limited, so I am not
able to review this patch for correctness.  I can
ack it.

Acked-by: Michael D Kinney 

Perhaps Liming can do a more complete review.

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Laszlo Ersek
> Sent: Monday, October 15, 2018 11:05 AM
> To: Kinney, Michael D ; Gao,
> Liming 
> Cc: edk2-devel-01 
> Subject: Re: [edk2] [PATCH 0/5]
> MdePkg/BaseSynchronizationLib GCC: fixes, cleanups
> 
> On 10/08/18 15:44, Laszlo Ersek wrote:
> > On 09/30/18 00:23, Laszlo Ersek wrote:
> >> Repo:   https://github.com/lersek/edk2.git
> >> Branch: inline_asm_rw_ops_1208
> >>
> >> This series mainly fixes the operand constraints
> (missing input-output
> >> qualifications) in
> "BaseSynchronizationLib/*/GccInline.c".
> >>
> >> (It would be better to remove these files altogether
> in favor of the
> >> already existing NASM implementation, but due to
> >> ,
> we can't generally
> >> do that in libraries yet.)
> >>
> >> Cc: Liming Gao 
> >> Cc: Michael D Kinney 
> >>
> >> Thanks,
> >> Laszlo
> >>
> >> Laszlo Ersek (5):
> >>   MdePkg/BaseSynchronizationLib GCC: fix whitespace
> and comments
> >>   MdePkg/BaseSynchronizationLib GCC: fix
> InternalSyncCompareExchange16()
> >>   MdePkg/BaseSynchronizationLib GCC: fix
> InternalSyncCompareExchange32()
> >>   MdePkg/BaseSynchronizationLib GCC: fix X64
> >> InternalSyncCompareExchange64()
> >>   MdePkg/BaseSynchronizationLib GCC: simplify IA32
> >> InternalSyncCompareExchange64()
> >>
> >>
> MdePkg/Library/BaseSynchronizationLib/Ia32/GccInline.c |
> 42 +++--
> >>
> MdePkg/Library/BaseSynchronizationLib/X64/GccInline.c  |
> 47 +++-
> >>  2 files changed, 34 insertions(+), 55 deletions(-)
> >>
> >
> > Ping :)
> 
> Ping
> ___
> 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] Where to find the fix for security issue id 686

2018-10-15 Thread Rafael Machado

Hi Vincent

Thanks for the answer.
The problem is that when I try to access this link I have this message: "You
are not authorized to access bug #686."

Any idea?

Em seg, 15 de out de 2018 às 14:28, Zimmer, Vincent <
vincent.zim...@intel.com> escreveu:

> You can find reference to patches via the advisory entry
>
> "31. EDK II TIANOCOMPRESS BOUNDS CHECKING ISSUES" advisory entry
> https://edk2-docs.gitbooks.io/security-advisory/content/edk-ii-tianocompress-bounds-checking-issues.html
> has an embedded link to
> https://bugzilla.tianocore.org/attachment.cgi?id=150
>
> Vincent
>
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Rafael Machado
> Sent: Monday, October 15, 2018 5:39 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] Where to find the fix for security issue id 686
>
> Hi everyone
>
> I was tying to find the patch to fix the reported security issue id 686 (
> https://bugzilla.tianocore.org/show_bug.cgi?id=686),
> but was not able to access it.
>
> Could someone please tell if this patch, or series of patches, was already
> merged to some branch that is public available?
>
> Thanks and Regards
> Rafael R. Machado
> ___
> 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/5] MdePkg/BaseSynchronizationLib GCC: fixes, cleanups

On 10/08/18 15:44, Laszlo Ersek wrote:
> On 09/30/18 00:23, Laszlo Ersek wrote:
>> Repo:   https://github.com/lersek/edk2.git
>> Branch: inline_asm_rw_ops_1208
>>
>> This series mainly fixes the operand constraints (missing input-output
>> qualifications) in "BaseSynchronizationLib/*/GccInline.c".
>>
>> (It would be better to remove these files altogether in favor of the
>> already existing NASM implementation, but due to
>> , we can't generally
>> do that in libraries yet.)
>>
>> Cc: Liming Gao 
>> Cc: Michael D Kinney 
>>
>> Thanks,
>> Laszlo
>>
>> Laszlo Ersek (5):
>>   MdePkg/BaseSynchronizationLib GCC: fix whitespace and comments
>>   MdePkg/BaseSynchronizationLib GCC: fix InternalSyncCompareExchange16()
>>   MdePkg/BaseSynchronizationLib GCC: fix InternalSyncCompareExchange32()
>>   MdePkg/BaseSynchronizationLib GCC: fix X64
>> InternalSyncCompareExchange64()
>>   MdePkg/BaseSynchronizationLib GCC: simplify IA32
>> InternalSyncCompareExchange64()
>>
>>  MdePkg/Library/BaseSynchronizationLib/Ia32/GccInline.c | 42 
>> +++--
>>  MdePkg/Library/BaseSynchronizationLib/X64/GccInline.c  | 47 
>> +++-
>>  2 files changed, 34 insertions(+), 55 deletions(-)
>>
> 
> Ping :)

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

Re: [edk2] [PATCH] BaseTools/EOT: Change to call a program instead of calling Python API.



> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Yonghong Zhu
> Sent: Monday, October 15, 2018 3:24 AM
> To: edk2-devel@lists.01.org
> Cc: Chen, Hesheng 
> Subject: [edk2] [PATCH] BaseTools/EOT: Change to call a program instead of
> calling Python API.
> 
> From: hchen30 
> 
> Update the EOT tool to call the program itself instead of calling the Python
> API when parsing FV images.

Why do we prefer to launch the separate python program instead of calling the 
APIs?


> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Hess Chen 
> ---
>  BaseTools/Source/Python/Eot/{Eot.py => EotMain.py} | 465 +++--
> 
>  BaseTools/Source/Python/Eot/InfParserLite.py   |  26 +-
>  BaseTools/Source/Python/Eot/Parser.py  |  28 +-
>  BaseTools/Source/Python/Eot/Report.py  |   6 +-
>  BaseTools/Source/Python/build/BuildReport.py   |   2 +-
>  5 files changed, 84 insertions(+), 443 deletions(-)
>  rename BaseTools/Source/Python/Eot/{Eot.py => EotMain.py} (75%)
> 
> diff --git a/BaseTools/Source/Python/Eot/Eot.py
> b/BaseTools/Source/Python/Eot/EotMain.py
> similarity index 75%
> rename from BaseTools/Source/Python/Eot/Eot.py
> rename to BaseTools/Source/Python/Eot/EotMain.py
> index ce83da1495..49a1494126 100644
> --- a/BaseTools/Source/Python/Eot/Eot.py
> +++ b/BaseTools/Source/Python/Eot/EotMain.py
> @@ -17,18 +17,20 @@
>  from __future__ import absolute_import
>  import Common.LongFilePathOs as os, time, glob
>  import Common.EdkLogger as EdkLogger
> -from . import EotGlobalData
> +import Eot.EotGlobalData as EotGlobalData
>  from optparse import OptionParser
>  from Common.StringUtils import NormPath
>  from Common import BuildToolError
>  from Common.Misc import GuidStructureStringToGuidString, sdict
> -from .InfParserLite import *
> -from . import c
> -from . import Database
> +from Eot.Parser import *
> +from Eot.InfParserLite import EdkInfParser
> +from Common.StringUtils import GetSplitValueList
> +from Eot import c
> +from Eot import Database
>  from array import array
> -from .Report import Report
> +from Eot.Report import Report
>  from Common.BuildVersion import gBUILD_VERSION
> -from .Parser import ConvertGuid
> +from Eot.Parser import ConvertGuid
>  from Common.LongFilePathSupport import OpenLongFilePath as open
>  import struct
>  import uuid
> @@ -58,14 +60,14 @@ class Image(array):
> 
>  self._SubImages = sdict() # {offset: Image()}
> 
> -array.__init__(self, 'B')
> +array.__init__(self)
> 
>  def __repr__(self):
>  return self._ID_
> 
>  def __len__(self):
>  Len = array.__len__(self)
> -for Offset in self._SubImages:
> +for Offset in self._SubImages.keys():
>  Len += len(self._SubImages[Offset])
>  return Len
> 
> @@ -154,19 +156,11 @@ class CompressedImage(Image):
> 
>  def _GetSections(self):
>  try:
> -from . import EfiCompressor
> -TmpData = EfiCompressor.FrameworkDecompress(
> -self[self._HEADER_SIZE_:],
> -len(self) - self._HEADER_SIZE_
> -)
> +TmpData = DeCompress('Efi', self[self._HEADER_SIZE_:])
>  DecData = array('B')
>  DecData.fromstring(TmpData)
>  except:
> -from . import EfiCompressor
> -TmpData = EfiCompressor.UefiDecompress(
> -self[self._HEADER_SIZE_:],
> -len(self) - self._HEADER_SIZE_
> -)
> +TmpData = DeCompress('Framework', self[self._HEADER_SIZE_:])
>  DecData = array('B')
>  DecData.fromstring(TmpData)
> 
> @@ -297,7 +291,7 @@ class Depex(Image):
> 
>  Expression = property(_GetExpression)
> 
> -## FirmwareVolume() class
> +# # FirmwareVolume() class
>  #
>  #  A class for Firmware Volume
>  #
> @@ -308,12 +302,12 @@ class FirmwareVolume(Image):
> 
>  _FfsGuid = "8C8CE578-8A3D-4F1C-9935-896185C32DD3"
> 
> -_GUID_  = struct.Struct("16x 1I2H8B")
> -_LENGTH_= struct.Struct("16x 16x 1Q")
> -_SIG_   = struct.Struct("16x 16x 8x 1I")
> -_ATTR_  = struct.Struct("16x 16x 8x 4x 1I")
> -_HLEN_  = struct.Struct("16x 16x 8x 4x 4x 1H")
> -_CHECKSUM_  = struct.Struct("16x 16x 8x 4x 4x 2x 1H")
> +_GUID_ = struct.Struct("16x 1I2H8B")
> +_LENGTH_ = struct.Struct("16x 16x 1Q")
> +_SIG_ = struct.Struct("16x 16x 8x 1I")
> +_ATTR_ = struct.Struct("16x 16x 8x 4x 1I")
> +_HLEN_ = struct.Struct("16x 16x 8x 4x 4x 1H")
> +_CHECKSUM_ = struct.Struct("16x 16x 8x 4x 4x 2x 1H")
> 
>  def __init__(self, Name=''):
>  Image.__init__(self)
> @@ -387,7 +381,7 @@ class FirmwareVolume(Image):
>  DepexString = DepexList[0].strip()
>

Re: [edk2] [Patch] BaseTools: Add check for the string type whether is same

Reviewed-by: Jaben Carsey 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Yonghong Zhu
> Sent: Monday, October 15, 2018 5:45 AM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming 
> Subject: [edk2] [Patch] BaseTools: Add check for the string type whether is
> same
> 
> From: zhijufan 
> 
> Relational and equality operators require both operands to be of
> the same type.
> Treat the string 'A' and "A" as same type, but for "A" and L"A"
> are not same type since one is general string, another is unicode
> string.
> 
> True:'A'<'B', "A"<"B" 'A'<"B", L'A' Error:'A' 
> Cc: Liming Gao 
> Cc: Yonghong Zhu 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Zhiju.Fan 
> ---
>  BaseTools/Source/Python/Common/Expression.py | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/BaseTools/Source/Python/Common/Expression.py
> b/BaseTools/Source/Python/Common/Expression.py
> index 78c69fa..84898f7 100644
> --- a/BaseTools/Source/Python/Common/Expression.py
> +++ b/BaseTools/Source/Python/Common/Expression.py
> @@ -295,12 +295,12 @@ class ValueExpression(BaseExpression):
>  # bitwise and logical operation between number and 
> boolean is
> allowed
>  pass
>  else:
>  raise BadExpression(ERR_EXPR_TYPE)
>  if isinstance(Oprand1, type('')) and isinstance(Oprand2, 
> type('')):
> -if (Oprand1.startswith('L"') and not 
> Oprand2.startswith('L"')) or \
> -(not Oprand1.startswith('L"') and 
> Oprand2.startswith('L"')):
> +if ((Oprand1.startswith('L"') or Oprand1.startswith('L')) 
> and (not
> Oprand2.startswith('L"')) and (not Oprand2.startswith("L'"))) or \
> +(((not Oprand1.startswith('L"')) and (not
> Oprand1.startswith("L'"))) and (Oprand2.startswith('L"') or
> Oprand2.startswith('L'))):
>  raise BadExpression(ERR_STRING_CMP % (Oprand1, Operator,
> Oprand2))
>  if 'in' in Operator and isinstance(Oprand2, type('')):
>  Oprand2 = Oprand2.split()
>  EvalStr = 'Oprand1 ' + Operator + ' Oprand2'
> 
> @@ -825,10 +825,12 @@ class ValueExpressionEx(ValueExpression):
>  except BadExpression as Value:
>  if self.PcdType in TAB_PCD_NUMERIC_TYPES:
>  PcdValue = PcdValue.strip()
>  if PcdValue.startswith('{') and PcdValue.endswith('}'):
>  PcdValue = SplitPcdValueString(PcdValue[1:-1])
> +if ERR_STRING_CMP.split(':')[0] in Value.message:
> +raise BadExpression("Type: %s, Value: %s, %s" % 
> (self.PcdType,
> PcdValue, Value))
>  if isinstance(PcdValue, type([])):
>  TmpValue = 0
>  Size = 0
>  ValueType = ''
>  for Item in PcdValue:
> --
> 2.6.1.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] BaseTools: Fix bugs use special character in the --pcd option

Reviewed-by: Jaben Carsey 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Yonghong Zhu
> Sent: Monday, October 15, 2018 5:46 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [Patch] BaseTools: Fix bugs use special character in the --pcd
> option
> 
> Cases:
> --pcd Token.Name="!"
> --pcd Token.Name="\'W&\'"
> --pcd Token.Name="2*h"
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Yonghong Zhu 
> ---
>  BaseTools/Source/Python/Workspace/DscBuildData.py | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/BaseTools/Source/Python/Workspace/DscBuildData.py
> b/BaseTools/Source/Python/Workspace/DscBuildData.py
> index aaef404..1a0a293 100644
> --- a/BaseTools/Source/Python/Workspace/DscBuildData.py
> +++ b/BaseTools/Source/Python/Workspace/DscBuildData.py
> @@ -1078,10 +1078,12 @@ class DscBuildData(PlatformBuildClassObject):
>  if PcdValue.upper() == 'TRUE':
>  PcdValue = str(1)
>  if not FieldName:
>  if PcdDatumType not in TAB_PCD_NUMERIC_TYPES:
>  PcdValue = '"' + PcdValue + '"'
> +elif not PcdValue.isdigit() and not 
> PcdValue.upper().startswith('0X'):
> +PcdValue = '"' + PcdValue + '"'
>  else:
>  IsArray = False
>  Base = 10
>  if PcdValue.upper().startswith('0X'):
>  Base = 16
> --
> 2.6.1.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Where to find the fix for security issue id 686

2018-10-15 Thread Zimmer, Vincent

You can find reference to patches via the advisory entry

"31. EDK II TIANOCOMPRESS BOUNDS CHECKING ISSUES" advisory entry 
https://edk2-docs.gitbooks.io/security-advisory/content/edk-ii-tianocompress-bounds-checking-issues.html
 has an embedded link to https://bugzilla.tianocore.org/attachment.cgi?id=150 

Vincent

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Rafael 
Machado
Sent: Monday, October 15, 2018 5:39 AM
To: edk2-devel@lists.01.org
Subject: [edk2] Where to find the fix for security issue id 686

Hi everyone

I was tying to find the patch to fix the reported security issue id 686 ( 
https://bugzilla.tianocore.org/show_bug.cgi?id=686),
but was not able to access it.

Could someone please tell if this patch, or series of patches, was already 
merged to some branch that is public available?

Thanks and Regards
Rafael R. Machado
___
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/4] UefiCpuPkg/PiSmmCpuDxeSmm: Add logic to support semaphore type.

On 10/15/18 04:49, Eric Dong wrote:
> Because this driver needs to set MSRs saved in normal boot phase, sync 
> semaphore
> logic from RegisterCpuFeaturesLib code which used for normal boot phase.

(My review of this patch is going to be superficial. I'm not trying to
validate the actual algorithm. I'm mostly sanity-checking the code, and
gauging whether it will break platforms that use CpuS3DataDxe.)


> Detail see change SHA-1: dcdf1774212d87e2d7feb36286a408ea7475fd7b for
> RegisterCpuFeaturesLib.

(1) I think it is valid to reference other patches in the same series.
However, the commit hashes are not stable yet -- when you rebase the
series, the commit hashes will change. Therefore, when we refer to a
patch that is not upstream yet (i.e. it is part of the same series), it
is best to spell out the full subject, such as:

UefiCpuPkg/RegisterCpuFeaturesLib: Add logic to support semaphore type.


> 
> Cc: Ruiyu Ni 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Dong 
> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c  | 316 
> -
>  UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c  |   3 -
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h |   3 +-
>  3 files changed, 180 insertions(+), 142 deletions(-)
> 
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c
> index 52ff9679d5..5a35f7a634 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c
> @@ -38,9 +38,12 @@ typedef struct {
>  } MP_ASSEMBLY_ADDRESS_MAP;
>  
>  //
> -// Spin lock used to serialize MemoryMapped operation
> +// Flags used when program the register.
>  //
> -SPIN_LOCK*mMemoryMappedLock = NULL;
> +typedef struct {
> +  volatile UINTN   MemoryMappedLock; // Spinlock used to program 
> mmio
> +  volatile UINT32  *SemaphoreCount;  // Semaphore used to 
> program semaphore.
> +} PROGRAM_CPU_REGISTER_FLAGS;
>  
>  //
>  // Signal that SMM BASE relocation is complete.
> @@ -62,13 +65,11 @@ AsmGetAddressMap (
>  #define LEGACY_REGION_SIZE(2 * 0x1000)
>  #define LEGACY_REGION_BASE(0xA - LEGACY_REGION_SIZE)
>  
> +PROGRAM_CPU_REGISTER_FLAGS   mCpuFlags;
>  ACPI_CPU_DATAmAcpiCpuData;
>  volatile UINT32  mNumberToFinish;
>  MP_CPU_EXCHANGE_INFO *mExchangeInfo;
>  BOOLEAN  mRestoreSmmConfigurationInS3 = FALSE;
> -MP_MSR_LOCK  *mMsrSpinLocks = NULL;
> -UINTNmMsrSpinLockCount;
> -UINTNmMsrCount = 0;
>  
>  //
>  // S3 boot flag
> @@ -91,89 +92,6 @@ UINT8mApHltLoopCodeTemplate[] = {
> 0xEB, 0xFC   // jmp $-2
> };
>  
> -/**
> -  Get MSR spin lock by MSR index.
> -
> -  @param  MsrIndex   MSR index value.
> -
> -  @return Pointer to MSR spin lock.
> -
> -**/
> -SPIN_LOCK *
> -GetMsrSpinLockByIndex (
> -  IN UINT32  MsrIndex
> -  )
> -{
> -  UINTN Index;
> -  for (Index = 0; Index < mMsrCount; Index++) {
> -if (MsrIndex == mMsrSpinLocks[Index].MsrIndex) {
> -  return mMsrSpinLocks[Index].SpinLock;
> -}
> -  }
> -  return NULL;
> -}
> -
> -/**
> -  Initialize MSR spin lock by MSR index.
> -
> -  @param  MsrIndex   MSR index value.
> -
> -**/
> -VOID
> -InitMsrSpinLockByIndex (
> -  IN UINT32  MsrIndex
> -  )
> -{
> -  UINTNMsrSpinLockCount;
> -  UINTNNewMsrSpinLockCount;
> -  UINTNIndex;
> -  UINTNAddedSize;
> -
> -  if (mMsrSpinLocks == NULL) {
> -MsrSpinLockCount = mSmmCpuSemaphores.SemaphoreMsr.AvailableCounter;
> -mMsrSpinLocks = (MP_MSR_LOCK *) AllocatePool (sizeof (MP_MSR_LOCK) * 
> MsrSpinLockCount);
> -ASSERT (mMsrSpinLocks != NULL);
> -for (Index = 0; Index < MsrSpinLockCount; Index++) {
> -  mMsrSpinLocks[Index].SpinLock =
> -   (SPIN_LOCK *)((UINTN)mSmmCpuSemaphores.SemaphoreMsr.Msr + Index * 
> mSemaphoreSize);
> -  mMsrSpinLocks[Index].MsrIndex = (UINT32)-1;
> -}
> -mMsrSpinLockCount = MsrSpinLockCount;
> -mSmmCpuSemaphores.SemaphoreMsr.AvailableCounter = 0;
> -  }
> -  if (GetMsrSpinLockByIndex (MsrIndex) == NULL) {
> -//
> -// Initialize spin lock for MSR programming
> -//
> -mMsrSpinLocks[mMsrCount].MsrIndex = MsrIndex;
> -InitializeSpinLock (mMsrSpinLocks[mMsrCount].SpinLock);
> -mMsrCount ++;
> -if (mMsrCount == mMsrSpinLockCount) {
> -  //
> -  // If MSR spin lock buffer is full, enlarge it
> -  //
> -  AddedSize = SIZE_4KB;
> -  mSmmCpuSemaphores.SemaphoreMsr.Msr =
> -AllocatePages (EFI_SIZE_TO_PAGES(AddedSize));
> -  ASSERT (mSmmCpuSemaphores.SemaphoreMsr.Msr != NULL);
> -  NewMsrSpinLockCount = mMsrSpinLockCount + AddedSize / mSemaphoreSize;
> -  mMsrSpinLocks = ReallocatePool (
> -sizeof (MP_MSR_LOCK) * mMsrSpinLockCount,
> -

Re: [edk2] [Patch 1/4] UefiCpuPkg/Include/AcpiCpuData.h: Add Semaphore related Information.

On 10/15/18 04:49, Eric Dong wrote:
> In order to support semaphore related logic, add new definition for it.
> 
> Cc: Ruiyu Ni 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Dong 
> ---
>  UefiCpuPkg/Include/AcpiCpuData.h | 23 ++-
>  1 file changed, 22 insertions(+), 1 deletion(-)

(1) If it's possible, I suggest moving the (very nice) description from
the 0/4 cover letter to this patch. The cover letter is not captured in
the git commit history.

I don't insist, but it would be a nice touch, IMO.

> 
> diff --git a/UefiCpuPkg/Include/AcpiCpuData.h 
> b/UefiCpuPkg/Include/AcpiCpuData.h
> index 9e51145c08..b3cf2f664a 100644
> --- a/UefiCpuPkg/Include/AcpiCpuData.h
> +++ b/UefiCpuPkg/Include/AcpiCpuData.h
> @@ -15,6 +15,8 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
> EXPRESS OR IMPLIED.
>  #ifndef _ACPI_CPU_DATA_H_
>  #define _ACPI_CPU_DATA_H_
>  
> +#include 
> +
>  //
>  // Register types in register table
>  //
> @@ -22,9 +24,20 @@ typedef enum {
>Msr,
>ControlRegister,
>MemoryMapped,
> -  CacheControl
> +  CacheControl,
> +  Semaphore
>  } REGISTER_TYPE;
>  
> +//
> +// CPU information.
> +//
> +typedef struct {
> +  UINT32PackageCount; // Packages in this CPU.

(2) Is it possible to have multiple packages in a single CPU? If not,
then please clean up the comment.

Did you perhaps mean "number of sockets in the system"?

> +  UINT32CoreCount;// Max Core count in the packages.
> +  UINT32ThreadCount;  // MAx thread count in the cores.

(3) The word "MAx" should be "Max", I think.

> +  UINT32*ValidCoresInPackages;// Valid cores in each package.

(4) Is it possible to document the structure of this array (?) in some
detail? Other parts of "UefiCpuPkg/Include/AcpiCpuData.h" are very well
documented.

> +} CPU_STATUS_INFORMATION;
> +
>  //
>  // Element of register table entry
>  //
> @@ -147,6 +160,14 @@ typedef struct {
>// provided.
>//
>UINT32ApMachineCheckHandlerSize;
> +  //
> +  // CPU information which is required when set the register table.
> +  //
> +  CPU_STATUS_INFORMATION CpuStatus;
> +  //
> +  // Location info for each ap.

(5) This header file spells "AP" in upper case elsewhere.

> +  //
> +  EFI_CPU_PHYSICAL_LOCATION  *ApLocation;

(6) Is this supposed to be an array? If so, what is the structure of the
array? What is the size?

(7) This is the first field in ACPI_CPU_DATA that has pointer type.
Other pointers are represented as EFI_PHYSICAL_ADDRESS.

What justifies this difference?

>  } ACPI_CPU_DATA;
>  
>  #endif
> 

(8) "UefiCpuPkg/CpuS3DataDxe/CpuS3Data.c" will zero-fill the new fields.
Is that safe?

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

Re: [edk2] [Patch 0/4] Fix performance issue caused by Set MSR task.

Hi Eric,

On 10/15/18 04:49, Eric Dong wrote:
> In a system which has multiple cores, current set register value task costs 
> huge times.
> After investigation, current set MSR task costs most of the times. Current 
> logic uses
> SpinLock to let set MSR task as an single thread task for all cores. Because 
> MSR has
> scope attribute which may cause GP fault if multiple APs set MSR at the same 
> time,
> current logic use an easiest solution (use SpinLock) to avoid this issue, but 
> it will
> cost huge times.
> 
> In order to fix this performance issue, new solution will set MSRs base on 
> their scope
> attribute. After this, the SpinLock will not needed. Without SpinLock, new 
> issue raised
> which is caused by MSR dependence. For example, MSR A depends on MSR B which 
> means MSR A
> must been set after MSR B has been set. Also MSR B is package scope level and 
> MSR A is
> thread scope level. If system has multiple threads, Thread 1 needs to set the 
> thread level
> MSRs and thread 2 needs to set thread and package level MSRs. Set MSRs task 
> for thread 1
> and thread 2 like below:
> 
> Thread 1 Thread 2
> MSR B  NY
> MSR A  YY
> 
> If driver don't control execute MSR order, for thread 1, it will execute MSR 
> A first, but
> at this time, MSR B not been executed yet by thread 2. system may trig 
> exception at this
> time.
> 
> In order to fix the above issue, driver introduces semaphore logic to control 
> the MSR
> execute sequence. For the above case, a semaphore will be add between MSR A 
> and B for
> all threads. Semaphore has scope info for it. The possible scope value is 
> core or package.
> For each thread, when it meets a semaphore during it set registers, it will 
> 1) release
> semaphore (+1) for each threads in this core or package(based on the scope 
> info for this
> semaphore) 2) acquire semaphore (-1) for all the threads in this core or 
> package(based
> on the scope info for this semaphore). With these two steps, driver can 
> control MSR
> sequence. Sample code logic like below:
> 
>   //
>   // First increase semaphore count by 1 for processors in this package.
>   //
>   for (ProcessorIndex = 0; ProcessorIndex < PackageThreadsCount ; 
> ProcessorIndex ++) {
> LibReleaseSemaphore ((UINT32 *) [PackageOffset + 
> ProcessorIndex]);
>   }
>   //
>   // Second, check whether the count has reach the check number.
>   //
>   for (ProcessorIndex = 0; ProcessorIndex < ValidApCount; ProcessorIndex ++) {
> LibWaitForSemaphore ([ApOffset]);
>   }
> 
> Platform Requirement:
> 1. This change requires register MSR setting base on MSR scope info. If still 
> register MSR
>for all threads, exception may raised.

Do you mean that platforms are responsible for updating their register
tables in:
- ACPI_CPU_DATA.PreSmmInitRegisterTable,
- ACPI_CPU_DATA.RegisterTable

so that the tables utilize the new Semaphore REGISTER_TYPE as appropriate?

> 
> Known limitation:
> 1. Current CpuFeatures driver supports DXE instance and PEI instance. But 
> semaphore logic
>requires Aps execute in async mode which is not supported by PEI driver. 
> So CpuFeature
>PEI instance not works after this change. We plan to support async mode 
> for PEI in phase
>2 for this task.
> 2. Current execute MSR task code in duplicated in PiSmmCpuDxeSmm driver and 
>RegisterCpuFeaturesLib library because the schedule limitation.

I don't understand what you mean by "schedule limitation". Are you
alluding to the upcoming edk2 stable tag (in November), or some other
schedule?

>Will merge the code to 
>RegisterCpuFeaturesLib and export as an API in phase 2 for this task.

While I agree that common code (especially complex code like this)
should belong to libraries, there are platforms that consume
PiSmmCpuDxeSmm, but don't consume RegisterCpuFeaturesLib in any way.

Do you plan to add the new function(s) to a RegisterCpuFeaturesLib
instance, and make PiSmmCpuDxeSmm dependent on RegisterCpuFeaturesLib?

If so, I think it can work, but then the RegisterCpuFeaturesLib instance
in question should do nothing at all in the constructor. On platforms
that don't use this feature at all -- i.e., the Semaphore REGISTER_TYPE
--, there should be no impact.

(BTW, DxeRegisterCpuFeaturesLib is currently restricted to DXE_DRIVER
modules.)

> Extra Notes:
>   I will send the other patch to set MSR base on scope info and check in it 
> before check in
>   this serial.

I don't understand. I assume that you are referring to some concrete
platform (?) where the Semaphore REGISTER_TYPE *must* be used, in order
to successfully boot (and/or perform S3), if this series is applied.

What platform is that?

And, if that other patch is indeed a pre-requisite for *this* set (on
some specific platform anyway), then people on that platform will not be
able to test this series until you post those patches.

My point here is that, on

[edk2] [Patch] BaseTools: Support to use struct name as datum type before max size

Original it hard code to use "VOID*", this patch extend it to both
support VOID* and valid struct name.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yonghong Zhu 
---
 BaseTools/Source/Python/Common/Misc.py  | 4 +++-
 BaseTools/Source/Python/Workspace/MetaFileParser.py | 6 +++---
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/BaseTools/Source/Python/Common/Misc.py 
b/BaseTools/Source/Python/Common/Misc.py
index 2cf9574..3c71dfc 100644
--- a/BaseTools/Source/Python/Common/Misc.py
+++ b/BaseTools/Source/Python/Common/Misc.py
@@ -47,10 +47,12 @@ startPatternGeneral = re.compile("^Start[' ']+Length[' 
']+Name[' ']+Class")
 addressPatternGeneral = re.compile("^Address[' ']+Publics by Value[' 
']+Rva\+Base")
 valuePatternGcc = re.compile('^([\w_\.]+) +([\da-fA-Fx]+) +([\da-fA-Fx]+)$')
 pcdPatternGcc = re.compile('^([\da-fA-Fx]+) +([\da-fA-Fx]+)')
 secReGeneral = re.compile('^([\da-fA-F]+):([\da-fA-F]+) +([\da-fA-F]+)[Hh]? 
+([.\w\$]+) +(\w+)', re.UNICODE)
 
+StructPattern = re.compile(r'[_a-zA-Z][0-9A-Za-z_]*$')
+
 ## Dictionary used to store file time stamp for quick re-access
 gFileTimeStampCache = {}# {file path : file time stamp}
 
 ## Dictionary used to store dependencies of files
 gDependencyDatabase = {}# arch : {file path : [dependent files list]}
@@ -1461,11 +1463,11 @@ def AnalyzeDscPcd(Setting, PcdType, DataType=''):
 if PcdType in (MODEL_PCD_FIXED_AT_BUILD, MODEL_PCD_PATCHABLE_IN_MODULE, 
MODEL_PCD_DYNAMIC_DEFAULT, MODEL_PCD_DYNAMIC_EX_DEFAULT):
 Value = FieldList[0]
 Size = ''
 if len(FieldList) > 1 and FieldList[1]:
 DataType = FieldList[1]
-if FieldList[1] != TAB_VOID:
+if FieldList[1] != TAB_VOID and StructPattern.match(FieldList[1]) 
is None:
 IsValid = False
 if len(FieldList) > 2:
 Size = FieldList[2]
 if IsValid:
 if DataType == "":
diff --git a/BaseTools/Source/Python/Workspace/MetaFileParser.py 
b/BaseTools/Source/Python/Workspace/MetaFileParser.py
index 79e3180..f33b91c 100644
--- a/BaseTools/Source/Python/Workspace/MetaFileParser.py
+++ b/BaseTools/Source/Python/Workspace/MetaFileParser.py
@@ -27,11 +27,11 @@ import Common.EdkLogger as EdkLogger
 import Common.GlobalData as GlobalData
 
 from CommonDataClass.DataClass import *
 from Common.DataType import *
 from Common.StringUtils import *
-from Common.Misc import GuidStructureStringToGuidString, CheckPcdDatum, 
PathClass, AnalyzePcdData, AnalyzeDscPcd, AnalyzePcdExpression, ParseFieldValue
+from Common.Misc import GuidStructureStringToGuidString, CheckPcdDatum, 
PathClass, AnalyzePcdData, AnalyzeDscPcd, AnalyzePcdExpression, 
ParseFieldValue, StructPattern
 from Common.Expression import *
 from CommonDataClass.Exceptions import *
 from Common.LongFilePathSupport import OpenLongFilePath as open
 from collections import defaultdict
 from .MetaFileTable import MetaFileStorage
@@ -1610,12 +1610,12 @@ class DscParser(MetaFileParser):
 return
 
 ValList, Valid, Index = AnalyzeDscPcd(self._ValueList[2], 
self._ItemType)
 if not Valid:
 if self._ItemType in (MODEL_PCD_DYNAMIC_DEFAULT, 
MODEL_PCD_DYNAMIC_EX_DEFAULT, MODEL_PCD_FIXED_AT_BUILD, 
MODEL_PCD_PATCHABLE_IN_MODULE):
-if ValList[1] != TAB_VOID and ValList[2]:
-EdkLogger.error('build', FORMAT_INVALID, "Pcd format 
incorrect. Only VOID* type PCD need the maxsize info.", 
File=self._FileWithError,
+if ValList[1] != TAB_VOID and StructPattern.match(ValList[1]) 
is None and ValList[2]:
+EdkLogger.error('build', FORMAT_INVALID, "Pcd format 
incorrect. The datum type info should be VOID* or a valid struct name.", 
File=self._FileWithError,
 Line=self._LineIndex + 1, 
ExtraData="%s.%s|%s" % (self._ValueList[0], self._ValueList[1], 
self._ValueList[2]))
 EdkLogger.error('build', FORMAT_INVALID, "Pcd format incorrect.", 
File=self._FileWithError, Line=self._LineIndex + 1,
 ExtraData="%s.%s|%s" % (self._ValueList[0], 
self._ValueList[1], self._ValueList[2]))
 PcdValue = ValList[Index]
 if PcdValue and "." not in self._ValueList[0]:
-- 
2.6.1.windows.1

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

Re: [edk2] [PATCH] uefi-sct/SctPkg:Fix the flaw in BBTestCreateEventEx_Func_Sub3 on certain situation. Besides AllocatePages(), CreateEventEx may cause the memorymap change itself. Enhance the test to




On 10/15/2018 02:33 AM, Supreeth Venkatesh wrote:
Please use a commit message less than 80 Cols.


On 10/13/2018 04:42 PM, Eric Jin wrote:

Cc: Supreeth Venkatesh 

Cc: Jiaxin Wu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Jin 
---
  ...rTaskPriorityServicesBBTestCreateEventEx.c | 26 +++
  .../BlackBoxTest/Support.c| 19 +-
  2 files changed, 33 insertions(+), 12 deletions(-)

diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/EventTimerTaskPriorityServices/BlackBoxTest/EventTimerTaskPriorityServicesBBTestCreateEventEx.c
 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/EventTimerTaskPriorityServices/BlackBoxTest/EventTimerTaskPriorityServicesBBTestCreateEventEx.c
index e2e173ab..25d1ed97 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/EventTimerTaskPriorityServices/BlackBoxTest/EventTimerTaskPriorityServicesBBTestCreateEventEx.c
+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/EventTimerTaskPriorityServices/BlackBoxTest/EventTimerTaskPriorityServicesBBTestCreateEventEx.c
@@ -1,7 +1,7 @@
  /** @file
  Copyright 2006 - 2016 Unified EFI, Inc.
-  Copyright (c) 2010 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2010 - 2018, 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
@@ -192,6 +192,10 @@ BBTestCreateEventEx_Func (
BBTestCreateEventEx_Func_Sub2 (StandardLib);
  #endif
  +  //
+  // The test for the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE
+  // This event group is notified by the system when the memory map has 
changed.
+  //
BBTestCreateEventEx_Func_Sub3 (StandardLib);
  //
@@ -599,12 +603,12 @@ BBTestCreateEventEx_Func_Sub1 (
UINTN   Buffer[MAX_TEST_EVENT_NUM + MAX_TEST_EVENT_NUM*2];
  //
-  // Initialize Buffer
+  // Initialize Buffer and the 0xAA is only for the Sub3 test
//
for (Index = 0; Index < MAX_TEST_EVENT_NUM; Index ++) {
Strange Logic here. Needs re-look.

  Buffer[Index] = Index;
-Buffer[Index + MAX_TEST_EVENT_NUM + Index] = (UINTN)(-1);
-Buffer[Index + MAX_TEST_EVENT_NUM + 1 + Index] = (UINTN)(-1);
+Buffer[Index + MAX_TEST_EVENT_NUM + Index] = (UINTN)(0xAA);
Magic Number 0xAA

+Buffer[Index + MAX_TEST_EVENT_NUM + 1 + Index] = (UINTN)(0xAA);
Magic Number 0xAA. Please define Macro or const.

}
  //
@@ -755,12 +759,12 @@ BBTestCreateEventEx_Func_Sub2 (
UINTN   Buffer[MAX_TEST_EVENT_NUM + MAX_TEST_EVENT_NUM*2];
  //
-  // Initialize Buffer
+  // Initialize Buffer and the 0xAA is only for the Sub3 test
//
for (Index = 0; Index < MAX_TEST_EVENT_NUM; Index ++) {
  Buffer[Index] = Index;
-Buffer[Index + MAX_TEST_EVENT_NUM + Index] = (UINTN)(-1);
-Buffer[Index + MAX_TEST_EVENT_NUM + 1 + Index] = (UINTN)(-1);
+Buffer[Index + MAX_TEST_EVENT_NUM + Index] = (UINTN)(0xAA);
Magic Number 0xAA. Please define Macro or const.

+Buffer[Index + MAX_TEST_EVENT_NUM + 1 + Index] = (UINTN)(0xAA);
Magic Number 0xAA. Please define Macro or const.

}
  //
@@ -914,12 +918,12 @@ BBTestCreateEventEx_Func_Sub3 (
UINTN   Buffer[MAX_TEST_EVENT_NUM + MAX_TEST_EVENT_NUM*2];
  //
-  // Initialize Buffer
+  // Initialize Buffer and the trick to initial it as 0xAA
//
for (Index = 0; Index < MAX_TEST_EVENT_NUM; Index ++) {
  Buffer[Index] = Index;
-Buffer[Index + MAX_TEST_EVENT_NUM + Index] = (UINTN)(-1);
-Buffer[Index + MAX_TEST_EVENT_NUM + 1 + Index] = (UINTN)(-1);
+Buffer[Index + MAX_TEST_EVENT_NUM + Index] = (UINTN)(0xAA);
Strange Logic here. Needs re-look. Also, Magic Number AA.

+Buffer[Index + MAX_TEST_EVENT_NUM + 1 + Index] = (UINTN)(0xAA);
Strange Logic here. Needs re-look. Also, Magic Number AA.

}
  //
@@ -974,7 +978,7 @@ BBTestCreateEventEx_Func_Sub3 (
}
//
-  // Install a configuration table at TPL_NOTIFY
+  // Call AllocatePage to change the memorymap
//
OldTpl = gtBS->RaiseTPL (TPL_NOTIFY);
diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/EventTimerTaskPriorityServices/BlackBoxTest/Support.c
 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/EventTimerTaskPriorityServices/BlackBoxTest/Support.c
index aa02383e..823e16ab 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/EventTimerTaskPriorityServices/BlackBoxTest/Support.c
+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/EventTimerTaskPriorityServices/BlackBoxTest/Support.c
@@ -1,7 +1,7 @@
  /** @file
  Copyright 2006 - 2010 Unified EFI, Inc.
-  Copyright (c) 2010, Intel Corporation. All rights reserved.
+  Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
  This program and the accompanying materials
are licensed and made available under the terms and conditions of the

Re: [edk2] [PATCH] uefi-sct/SctPkg:The original design for the 'EraseLengthGranularity' test need consider this case

FYI

On 10/15/2018 03:08 AM, Supreeth Venkatesh wrote:



Commit Message less than 80 cols please.

On 10/13/2018 04:51 PM, Eric Jin wrote:

For the SD device, no same as the eMMC, the 'EraseLengthGranularity' is 1.



Cc: Supreeth Venkatesh 


Cc: Jiaxin Wu 

Contributed-under: TianoCore Contribution Agreement 1.1

Signed-off-by: Eric Jin 

---

 .../BlackBoxTest/EraseBlockBBTestFunction.c   | 154 +-

 1 file changed, 78 insertions(+), 76 deletions(-)



diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/EraseBlock/BlackBoxTest/EraseBlockBBTestFunction.c
 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/EraseBlock/BlackBoxTest/EraseBlockBBTestFunction.c

index bc16a473..ea081625 100644

--- 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/EraseBlock/BlackBoxTest/EraseBlockBBTestFunction.c

+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/EraseBlock/BlackBoxTest/EraseBlockBBTestFunction.c

@@ -214,54 +214,56 @@ BBTestEraseBlocksFunctionTest (

   }



   // Erase Blocks with non-EraseLengthGranularity blocks

-  Token.Event = NULL;

-  Token.TransactionStatus = EFI_NOT_READY;

-  EraseStatus = EraseBlock->EraseBlocks (EraseBlock, MediaId, Lba+1, 
, BufferSize - 2 * BlockSize);

-

-  // Read the data with 0, the first/last block should not be erased

-  ReadStatus = BlockIo->ReadBlocks (BlockIo, MediaId, Lba, BufferSize, 
(VOID*)Buffer2);

-  if (ReadStatus == EFI_SUCCESS) {

-for (Index1 = 0; Index1 < BlockSize; Index1++) {

-  if (Buffer2[Index1] != 0) {

-IsZero1 = FALSE;

-break;

+  if (BufferSize > 2 * BlockSize) {
Magic Number 2.


+Token.Event = NULL;

+Token.TransactionStatus = EFI_NOT_READY;

+

+EraseStatus = EraseBlock->EraseBlocks (EraseBlock, MediaId, Lba+1, 
, BufferSize - 2 * BlockSize);
Magic number 2.


+

+// Read the data with 0, the first/last block should not be erased

+ReadStatus = BlockIo->ReadBlocks (BlockIo, MediaId, Lba, BufferSize, 
(VOID*)Buffer2);

+if (ReadStatus == EFI_SUCCESS) {

+  for (Index1 = 0; Index1 < BlockSize; Index1++) {

+if (Buffer2[Index1] != 0) {

+  IsZero1 = FALSE;

+  break;

+}

   }

-}



-for (Index1 = BlockSize; Index1 < BufferSize - BlockSize; Index1++) {

-  if (Buffer2[Index1] != 0) {

-IsZero2 = FALSE;

-break;

+  for (Index1 = BlockSize; Index1 < BufferSize - BlockSize; Index1++) {

+if (Buffer2[Index1] != 0) {

+  IsZero2 = FALSE;

+  break;

+}

   }

-}



-for (Index1 = BufferSize - BlockSize; Index1 < BufferSize; Index1++) {

-  if (Buffer2[Index1] != 0) {

-IsZero3 = FALSE;

-break;

+  for (Index1 = BufferSize - BlockSize; Index1 < BufferSize; Index1++) 
{

+if (Buffer2[Index1] != 0) {

+  IsZero3 = FALSE;

+  break;

+}

   }

-}



-if ((EraseStatus == EFI_SUCCESS) && (IsZero1 == FALSE) && (IsZero2 == 
TRUE) && ((IsZero3 == FALSE)))

-AssertionType = EFI_TEST_ASSERTION_PASSED;

-else

-  AssertionType = EFI_TEST_ASSERTION_FAILED;

+  if ((EraseStatus == EFI_SUCCESS) && (IsZero1 == FALSE) && (IsZero2 
== TRUE) && ((IsZero3 == FALSE)))
Less than 80 cols.


+  AssertionType = EFI_TEST_ASSERTION_PASSED;

+  else

+AssertionType = EFI_TEST_ASSERTION_FAILED;





-StandardLib->RecordAssertion (

-   StandardLib,

-   AssertionType,

-   gEraseBlockBBTestFunctionAssertionGuid003,

-   L"EraseBlocks - EraseBlocks for testing, the first/last 
block should not be erased",

-   L"%a:%d:EraseBlocks Status - %r, IsZero1 - %d, IsZero2 
- %d, IsZero3 - %d",

-   __FILE__,

-   (UINTN)__LINE__,

-   Status,

-   IsZero1, IsZero2, IsZero3

-   );

+  StandardLib->RecordAssertion (

+ StandardLib,

+ AssertionType,

+ gEraseBlockBBTestFunctionAssertionGuid003,

+ L"EraseBlocks - EraseBlocks for testing, the 
first/last block should not be erased",

+ L"%a:%d:EraseBlocks Status - %r, IsZero1 - %d, 
IsZero2 - %d, IsZero3 - %d",

+ __FILE__,

+ (UINTN)__LINE__,

+ EraseStatus,

+ IsZero1, IsZero2, IsZero3

+ );



+}

   }

-

   //

   // Erase Blocks with the EraseLengthGranularity blocks

Re: [edk2] [PATCH] uefi-sct/SctPkg:Implement the iSCSI devicepath to text

FYI

On 10/15/2018 03:33 AM, Supreeth Venkatesh wrote:


On 10/14/2018 03:25 AM, Eric Jin wrote:

Cc: Supreeth Venkatesh 

Cc: Jiaxin Wu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Jin 
---
  .../DevicePathToTextBBTestCoverage.c  | 43 ++-
  .../BlackBoxTest/DevicePathToTextBBTestMain.c | 26 +--
  .../DevicePathToText/BlackBoxTest/Guid.c  |  1 +
  .../DevicePathToText/BlackBoxTest/Guid.h  |  7 +++
  4 files changed, 73 insertions(+), 4 deletions(-)

diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/DevicePathToText/BlackBoxTest/DevicePathToTextBBTestCoverage.c
 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/DevicePathToText/BlackBoxTest/DevicePathToTextBBTestCoverage.c
index c30af434..14c4c460 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/DevicePathToText/BlackBoxTest/DevicePathToTextBBTestCoverage.c
+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/DevicePathToText/BlackBoxTest/DevicePathToTextBBTestCoverage.c
@@ -2202,7 +2202,48 @@ DevicePathToTextConvertDeviceNodeToTextCoverageTest (
  SctFreePool (Text);
}
  -
+  //
+  // iSCSI(Name,0x12AB,0x00567800,CRC32C,None,CHAP_BI,TCP)
+  //
+  pDeviceNode1 = DevicePathUtilities->CreateDeviceNode (0x3, 0x13, sizeof 
(ISCSI_DEVICE_PATH_WITH_NAME) + 4);
Why 0x03, 0x13 and + 4? - Magic Numbers.

  +  ((ISCSI_DEVICE_PATH_WITH_NAME *)pDeviceNode1)->NetworkProtocol = 0x0;  
//TCP
+  ((ISCSI_DEVICE_PATH_WITH_NAME *)pDeviceNode1)->LoginOption = 0x0002;
Magic Number 2.

+  ((ISCSI_DEVICE_PATH_WITH_NAME *)pDeviceNode1)->Lun = 0x00785600;
Magic Number

+  ((ISCSI_DEVICE_PATH_WITH_NAME *)pDeviceNode1)->TargetPortalGroupTag = 0x12AB;
Magic Number.

+  ((ISCSI_DEVICE_PATH_WITH_NAME *)pDeviceNode1)->iSCSITargetName[0] = 'N';
+  ((ISCSI_DEVICE_PATH_WITH_NAME *)pDeviceNode1)->iSCSITargetName[1] = 'a';
+  ((ISCSI_DEVICE_PATH_WITH_NAME *)pDeviceNode1)->iSCSITargetName[2] = 'm';
+  ((ISCSI_DEVICE_PATH_WITH_NAME *)pDeviceNode1)->iSCSITargetName[3] = 'e';
+
+  Text = DevicePathToText->ConvertDeviceNodeToText (pDeviceNode1, FALSE, 
FALSE);
+  pDeviceNode2 = SctConvertTextToDeviceNode(Text);
+
+  if ((pDeviceNode2 != NULL) && (SctCompareMem (pDeviceNode2, pDeviceNode1, 
SctDevicePathNodeLength(pDeviceNode1)) == 0)) {
+AssertionType = EFI_TEST_ASSERTION_PASSED;
+  } else {
+AssertionType = EFI_TEST_ASSERTION_FAILED;
+  }
+
+  StandardLib->RecordAssertion (
+StandardLib,
+AssertionType,
+gDevicePathToTextBBTestFunctionAssertionGuid135,
+L"EFI_DEVICE_PATH_FROM_TEXT_PROTOCOL - ConvertDeviceNodeToText 
must correctly recover the converting ConvertTextToDeviceNode has acted on the 
device node string",
+L"%a:%d: Convert result: %s - 
Expected:iSCSI(MyTargetName,0x12AB,0x00567800,CRC32C,None,CHAP_BI,TCP)",
Magic Numbers.

+__FILE__,
+(UINTN)__LINE__,
+Text
+);
+  if (pDeviceNode1 != NULL) {
+SctFreePool (pDeviceNode1);
+  }
+  if (pDeviceNode2 != NULL) {
+SctFreePool (pDeviceNode2);
+  }
+  if (Text != NULL) {
+SctFreePool (Text);
+  }
+
return EFI_SUCCESS;
  }
  diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/DevicePathToText/BlackBoxTest/DevicePathToTextBBTestMain.c
 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/DevicePathToText/BlackBoxTest/DevicePathToTextBBTestMain.c
index 41cf217b..d755227c 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/DevicePathToText/BlackBoxTest/DevicePathToTextBBTestMain.c
+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/DevicePathToText/BlackBoxTest/DevicePathToTextBBTestMain.c
@@ -2437,6 +2437,7 @@ BuildiSCSIDeviceNode (
CHAR16 *LunStr;
UINT16 Options;
UINT64 LunNum;
+  UINT64 TempLunNum;
  Status = GetNextRequiredParam(, L"TargetName", 
, );
if ((!EFI_ERROR(Status)) && (ParamIdentifierVal != NULL)) {
@@ -2459,7 +2460,7 @@ BuildiSCSIDeviceNode (
return NULL;
}
  -  Length = sizeof (ISCSI_DEVICE_PATH_WITH_NAME) + (UINT16) (SctStrLen 
(NameStr) * 2 + 2);
+  Length = sizeof (ISCSI_DEVICE_PATH_WITH_NAME) + (UINT16) (SctStrLen 
(NameStr));
iSCSI = (ISCSI_DEVICE_PATH_WITH_NAME *) CreateDeviceNode (0x3, 0x13, 
Length);
if (iSCSI == NULL) {
return NULL;
@@ -2499,7 +2500,7 @@ BuildiSCSIDeviceNode (
  if (SctStrCmp (ParamIdentifierVal, L"CRC32C") == 0) {
Options |= 0x0002;
  }
-break;
+break;
  case 1:  // DataDigest
  if (SctStrCmp (ParamIdentifierVal, L"CRC32C") == 0) {
@@ -2514,6 +2515,9 @@ BuildiSCSIDeviceNode (
  if (SctStrCmp (ParamIdentifierVal, L"CHAP_UNI") == 0) {
Options |= 0x1000;
  }
+if (SctStrCmp (ParamIdentifierVal, L"CHAP_BI") ==

Re: [edk2] [PATCH] uefi-sct/SctPkg: Fix the Possible numeric underflow

FYI

On 10/15/2018 03:20 AM, Supreeth Venkatesh wrote:
Reviewed-by: Supreeth Venkatesh 



On 10/13/2018 05:27 PM, Eric Jin wrote:

Possible numeric underflow when calculating the starting LBA for 
ReadBlocks_Func test

Cc: Supreeth Venkatesh 

Cc: Jiaxin Wu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Jin 
---
  .../Protocol/BlockIo/BlackBoxTest/BlockIoBBTestFunction.c   | 6 +-
  .../Protocol/BlockIo/BlackBoxTest/BlockIoBBTestFunction.c   | 6 +-
  2 files changed, 10 insertions(+), 2 deletions(-)

diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/BlockIo/BlackBoxTest/BlockIoBBTestFunction.c
 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/BlockIo/BlackBoxTest/BlockIoBBTestFunction.c
index 847ff9cb..e25743b7 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/BlockIo/BlackBoxTest/BlockIoBBTestFunction.c
+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/BlockIo/BlackBoxTest/BlockIoBBTestFunction.c
@@ -1,7 +1,7 @@
  /** @file
  Copyright 2006 - 2016 Unified EFI, Inc.
-  Copyright (c) 2010 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2010 - 2018, 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
@@ -316,9 +316,13 @@ BBTestReadBlocksFunctionAutoTest (
NewLba = IndexJ;
  } else if (IndexJ < 2 * MAX_DIFFERENT_LBA_FOR_TEST) {
// from (LastBlock - MAX_DIFFERENT_LBA_FOR_TEST - 
MAX_DIFFERENT_BUFFERSIZE_FOR_TEST)  to (LastBlock - 
MAX_DIFFERENT_BUFFERSIZE_FOR_TEST)
+  if (LastBlock < MAX_DIFFERENT_LBA_FOR_TEST + 
MAX_DIFFERENT_BUFFERSIZE_FOR_TEST)
+continue;
NewLba = IndexJ + LastBlock - 2 * MAX_DIFFERENT_LBA_FOR_TEST - 
MAX_DIFFERENT_BUFFERSIZE_FOR_TEST;
  } else {
// from (LastBlock/2 - MAX_DIFFERENT_LBA_FOR_TEST/2) to 
(LastBlock/2 + MAX_DIFFERENT_LBA_FOR_TEST/2)
+  if (LastBlock < MAX_DIFFERENT_LBA_FOR_TEST)
+continue;
NewLba = IndexJ - 2 * MAX_DIFFERENT_LBA_FOR_TEST + (SctDivU64x32 
(LastBlock, 2, ) - MAX_DIFFERENT_LBA_FOR_TEST / 2);
  }
  diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/BlockIo/BlackBoxTest/BlockIoBBTestFunction.c
 
b/uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/BlockIo/BlackBoxTest/BlockIoBBTestFunction.c
index 2590c035..e8d4295e 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/BlockIo/BlackBoxTest/BlockIoBBTestFunction.c
+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/BlockIo/BlackBoxTest/BlockIoBBTestFunction.c
@@ -1,7 +1,7 @@
  /** @file
  Copyright 2006 - 2016 Unified EFI, Inc.
-  Copyright (c) 2010 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2010 - 2018, 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
@@ -316,9 +316,13 @@ BBTestReadBlocksFunctionAutoTest (
NewLba = IndexJ;
  } else if (IndexJ < 2 * MAX_DIFFERENT_LBA_FOR_TEST) {
// from (LastBlock - MAX_DIFFERENT_LBA_FOR_TEST - 
MAX_DIFFERENT_BUFFERSIZE_FOR_TEST)  to (LastBlock - 
MAX_DIFFERENT_BUFFERSIZE_FOR_TEST)
+  if (LastBlock < MAX_DIFFERENT_LBA_FOR_TEST + 
MAX_DIFFERENT_BUFFERSIZE_FOR_TEST)
+continue;
NewLba = IndexJ + LastBlock - 2 * MAX_DIFFERENT_LBA_FOR_TEST - 
MAX_DIFFERENT_BUFFERSIZE_FOR_TEST;
  } else {
// from (LastBlock/2 - MAX_DIFFERENT_LBA_FOR_TEST/2) to 
(LastBlock/2 + MAX_DIFFERENT_LBA_FOR_TEST/2)
+  if (LastBlock < MAX_DIFFERENT_LBA_FOR_TEST)
+continue;
NewLba = IndexJ - 2 * MAX_DIFFERENT_LBA_FOR_TEST + (SctDivU64x32 
(LastBlock, 2, ) - MAX_DIFFERENT_LBA_FOR_TEST / 2);
  }



IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] uefi-sct/SctPkg:Enhance the EraseBlock Test

FYI

On 10/15/2018 03:43 AM, Supreeth Venkatesh wrote:


On 10/14/2018 05:26 PM, Eric Jin wrote:

The EraseSize in the EraseBlocks conf test should be bytes.
Cover the case that the size of the data to erase is a
multiple of the 'EraseLengthGranularity' value of an Erase Block
Protocol instance. And check whether the data on adjacent blocks
are mistakenly erased.

Cc: Supreeth Venkatesh 

Cc: Jiaxin Wu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Jin 
---
  .../EraseBlockBBTestConformance.c |  25 +-
  .../BlackBoxTest/EraseBlockBBTestFunction.c   | 600 --
  .../BlackBoxTest/EraseBlockBBTestMain.h   |  16 +-
  .../Protocol/EraseBlock/BlackBoxTest/Guid.c   |   4 +-
  .../Protocol/EraseBlock/BlackBoxTest/Guid.h   |   7 +
  5 files changed, 589 insertions(+), 63 deletions(-)

diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/EraseBlock/BlackBoxTest/EraseBlockBBTestConformance.c
 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/EraseBlock/BlackBoxTest/EraseBlockBBTestConformance.c
index df057b26..7e848239 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/EraseBlock/BlackBoxTest/EraseBlockBBTestConformance.c
+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/EraseBlock/BlackBoxTest/EraseBlockBBTestConformance.c
@@ -1,7 +1,7 @@
  /** @file
  Copyright 2017 Unified EFI, Inc.
-  Copyright (c) 2017, Intel Corporation. All rights reserved.
+  Copyright (c) 2017 - 2018, 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
@@ -51,8 +51,8 @@ BBTestEraseBlocksConformanceTest (
UINT32BlockSize;
UINT32IoAlign;
EFI_LBA   LastBlock;
-
-  UINT32BlockNumber;
+  UINT32EraseLengthGranularity;
+  UINTN EraseSize;
  EFI_ERASE_BLOCK_TOKEN Token;
  @@ -121,10 +121,11 @@ BBTestEraseBlocksConformanceTest (
IoAlign   = Media->IoAlign;
LastBlock = Media->LastBlock;
  -  BlockNumber   = (UINT32) MINIMUM(LastBlock, 
MAX_NUMBER_OF_READ_BLOCK_BUFFER);
+  EraseLengthGranularity = EraseBlock->EraseLengthGranularity;
+  EraseSize  = (UINTN)SctMultU64x32 (EraseLengthGranularity, 
BlockSize);
  if (MediaPresent == FALSE) {
-Status = EraseBlock->EraseBlocks(EraseBlock, MediaId, 0, , 
BlockNumber);
+Status = EraseBlock->EraseBlocks(EraseBlock, MediaId, 0, , 
EraseSize);
  if (Status == EFI_NO_MEDIA)
AssertionType = EFI_TEST_ASSERTION_PASSED;
  else
@@ -141,7 +142,7 @@ BBTestEraseBlocksConformanceTest (
   Status
   );
  -Status = EraseBlock->EraseBlocks(EraseBlock, MediaId, LastBlock + 1, 
, BlockNumber);
+Status = EraseBlock->EraseBlocks(EraseBlock, MediaId, LastBlock + 1, 
, EraseSize);
  if (Status == EFI_NO_MEDIA)
AssertionType = EFI_TEST_ASSERTION_PASSED;
  else
@@ -158,7 +159,7 @@ BBTestEraseBlocksConformanceTest (
   Status
   );
  -Status = EraseBlock->EraseBlocks(EraseBlock, MediaId, LastBlock - 10, 
, BlockNumber + 1);
+Status = EraseBlock->EraseBlocks(EraseBlock, MediaId, LastBlock - 10, 
, EraseSize + 1);
Why -10? Magic Number.

  if (Status == EFI_NO_MEDIA)
AssertionType = EFI_TEST_ASSERTION_PASSED;
  else
@@ -177,7 +178,7 @@ BBTestEraseBlocksConformanceTest (
   } else {
  if (ReadOnly == TRUE) {
-  Status = EraseBlock->EraseBlocks(EraseBlock, MediaId, 0, , 
BlockNumber);
+  Status = EraseBlock->EraseBlocks(EraseBlock, MediaId, 0, , 
EraseSize);
if (Status == EFI_WRITE_PROTECTED)
  AssertionType = EFI_TEST_ASSERTION_PASSED;
else
@@ -195,7 +196,7 @@ BBTestEraseBlocksConformanceTest (
   );
} else {
-  Status = EraseBlock->EraseBlocks(EraseBlock, MediaId + 1, 0, , 
BlockNumber);
+  Status = EraseBlock->EraseBlocks(EraseBlock, MediaId + 1, 0, , 
EraseSize);
if (Status == EFI_MEDIA_CHANGED)
  AssertionType = EFI_TEST_ASSERTION_PASSED;
else
@@ -212,7 +213,7 @@ BBTestEraseBlocksConformanceTest (
   Status
   );
  -  Status = EraseBlock->EraseBlocks(EraseBlock, MediaId + 1, LastBlock + 
1, , BlockNumber);
+  Status = EraseBlock->EraseBlocks(EraseBlock, MediaId + 1, LastBlock + 1, 
, EraseSize);
if (Status == EFI_MEDIA_CHANGED)
  AssertionType = EFI_TEST_ASSERTION_PASSED;
else
@@ -229,7 +230,7 @@ BBTestEraseBlocksConformanceTest (
   Status
   );
  -  Status = EraseBlock->EraseBlocks(EraseBlock, MediaId + 1, LastBlock - 
10, ,

Re: [edk2] [PATCH] uefi-sct/SctPkg:The original design for the 'EraseLengthGranularity' test need consider this case

FYI

On 10/15/2018 02:44 AM, Supreeth Venkatesh wrote:

Commit Message less than 80 cols please.


On 10/13/2018 04:51 PM, Eric Jin wrote:

For the SD device, no same as the eMMC, the 'EraseLengthGranularity' is 1.

Cc: Supreeth Venkatesh 

Cc: Jiaxin Wu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Jin 
---
  .../BlackBoxTest/EraseBlockBBTestFunction.c   | 154 +-
  1 file changed, 78 insertions(+), 76 deletions(-)

diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/EraseBlock/BlackBoxTest/EraseBlockBBTestFunction.c
 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/EraseBlock/BlackBoxTest/EraseBlockBBTestFunction.c
index bc16a473..ea081625 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/EraseBlock/BlackBoxTest/EraseBlockBBTestFunction.c
+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/EraseBlock/BlackBoxTest/EraseBlockBBTestFunction.c
@@ -214,54 +214,56 @@ BBTestEraseBlocksFunctionTest (
}
  // Erase Blocks with non-EraseLengthGranularity blocks
-  Token.Event = NULL;
-  Token.TransactionStatus = EFI_NOT_READY;
-  EraseStatus = EraseBlock->EraseBlocks (EraseBlock, MediaId, Lba+1, 
, BufferSize - 2 * BlockSize);
-
-  // Read the data with 0, the first/last block should not be erased
-  ReadStatus = BlockIo->ReadBlocks (BlockIo, MediaId, Lba, BufferSize, 
(VOID*)Buffer2);
-  if (ReadStatus == EFI_SUCCESS) {
-for (Index1 = 0; Index1 < BlockSize; Index1++) {
-  if (Buffer2[Index1] != 0) {
-IsZero1 = FALSE;
-break;
+  if (BufferSize > 2 * BlockSize) {
Magic Number 2.

+Token.Event = NULL;
+Token.TransactionStatus = EFI_NOT_READY;
+
+EraseStatus = EraseBlock->EraseBlocks (EraseBlock, MediaId, Lba+1, 
, BufferSize - 2 * BlockSize);
Magic number 2.

+
+// Read the data with 0, the first/last block should not be erased
+ReadStatus = BlockIo->ReadBlocks (BlockIo, MediaId, Lba, BufferSize, 
(VOID*)Buffer2);
+if (ReadStatus == EFI_SUCCESS) {
+  for (Index1 = 0; Index1 < BlockSize; Index1++) {
+if (Buffer2[Index1] != 0) {
+  IsZero1 = FALSE;
+  break;
+}
}
-}
  -for (Index1 = BlockSize; Index1 < BufferSize - BlockSize; Index1++) {
-  if (Buffer2[Index1] != 0) {
-IsZero2 = FALSE;
-break;
+  for (Index1 = BlockSize; Index1 < BufferSize - BlockSize; Index1++) {
+if (Buffer2[Index1] != 0) {
+  IsZero2 = FALSE;
+  break;
+}
}
-}
  -for (Index1 = BufferSize - BlockSize; Index1 < BufferSize; Index1++) 
{
-  if (Buffer2[Index1] != 0) {
-IsZero3 = FALSE;
-break;
+  for (Index1 = BufferSize - BlockSize; Index1 < BufferSize; Index1++) 
{
+if (Buffer2[Index1] != 0) {
+  IsZero3 = FALSE;
+  break;
+}
}
-}
  -if ((EraseStatus == EFI_SUCCESS) && (IsZero1 == FALSE) && (IsZero2 
== TRUE) && ((IsZero3 == FALSE)))
- AssertionType = EFI_TEST_ASSERTION_PASSED;
-else
-  AssertionType = EFI_TEST_ASSERTION_FAILED;
+  if ((EraseStatus == EFI_SUCCESS) && (IsZero1 == FALSE) && (IsZero2 
== TRUE) && ((IsZero3 == FALSE)))
Less than 80 cols.

+   AssertionType = EFI_TEST_ASSERTION_PASSED;
+  else
+AssertionType = EFI_TEST_ASSERTION_FAILED;
-StandardLib->RecordAssertion (
-   StandardLib,
-   AssertionType,
-   gEraseBlockBBTestFunctionAssertionGuid003,
-   L"EraseBlocks - EraseBlocks for testing, the first/last 
block should not be erased",
-   L"%a:%d:EraseBlocks Status - %r, IsZero1 - %d, IsZero2 
- %d, IsZero3 - %d",
-   __FILE__,
-   (UINTN)__LINE__,
-   Status,
-   IsZero1, IsZero2, IsZero3
-   );
+  StandardLib->RecordAssertion (
+ StandardLib,
+ AssertionType,
+ gEraseBlockBBTestFunctionAssertionGuid003,
+ L"EraseBlocks - EraseBlocks for testing, the 
first/last block should not be erased",
+ L"%a:%d:EraseBlocks Status - %r, IsZero1 - %d, 
IsZero2 - %d, IsZero3 - %d",
+ __FILE__,
+ (UINTN)__LINE__,
+ EraseStatus,
+ IsZero1, IsZero2, IsZero3
+ );
  +}
}
-
//
// Erase Blocks with the EraseLengthGranularity blocks
//
@@ -453,13 +455,13 @@ BlockIo2:
//
// Erase Blocks with non

Re: [edk2] [PATCH] uefi-sct/SctPkg:Assign 0 to the tail of HwErrRecVariableName

FYI

On 10/15/2018 03:23 AM, Supreeth Venkatesh wrote:


On 10/14/2018 02:31 AM, Eric Jin wrote:

Ensure the HwErrRecVariable could be deleted before the test exit.

Cc: Supreeth Venkatesh 

Cc: Jiaxin Wu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Jin 
---
  .../BlackBoxTest/VariableServicesBBTestFunction.c  | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/VariableServices/BlackBoxTest/VariableServicesBBTestFunction.c
 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/VariableServices/BlackBoxTest/VariableServicesBBTestFunction.c
index d1064cec..1be1720a 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/VariableServices/BlackBoxTest/VariableServicesBBTestFunction.c
+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/VariableServices/BlackBoxTest/VariableServicesBBTestFunction.c
@@ -1,7 +1,7 @@
  /** @file
  Copyright 2006 - 2012 Unified EFI, Inc.
-  Copyright (c) 2010 - 2012, Intel Corporation. All rights reserved.
+  Copyright (c) 2010 - 2018, 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
@@ -3052,6 +3052,7 @@ HardwareErrorRecordFuncTest (
//
  step2:
DataSize = 255;
+  HwErrRecVariableName[12] = L'\0';
Magic Number 12.

SctStrnCpy ( HwErrRecVariableName, (CHAR16*)(RecoveryData+2), 12 );
Status = RT->GetVariable (
  HwErrRecVariableName,


IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] uefi-sct/SctPkg:The Lun display order issue in iSCSI device path text

FYI

On 10/15/2018 03:22 AM, Supreeth Venkatesh wrote:


On 10/13/2018 05:33 PM, Eric Jin wrote:

Cc: Supreeth Venkatesh 

Cc: Jiaxin Wu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Jin 
---
  .../BlackBoxTest/DevicePathFromTextBBTestCoverage.c  | 12 ++--
  1 file changed, 6 insertions(+), 6 deletions(-)

diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/DevicePathFromText/BlackBoxTest/DevicePathFromTextBBTestCoverage.c
 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/DevicePathFromText/BlackBoxTest/DevicePathFromTextBBTestCoverage.c
index fc099d8e..6f97924a 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/DevicePathFromText/BlackBoxTest/DevicePathFromTextBBTestCoverage.c
+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/DevicePathFromText/BlackBoxTest/DevicePathFromTextBBTestCoverage.c
@@ -1,7 +1,7 @@
  /** @file
  Copyright 2006 - 2017 Unified EFI, Inc.
-  Copyright (c) 2010 - 2017, Intel Corporation. All rights reserved.
+  Copyright (c) 2010 - 2018, 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
@@ -1442,7 +1442,7 @@ CreateiScsiDeviceNode (
CHAR16  *DataDigestStr;
CHAR16  *AuthenticationStr;
CHAR16  *ProtocolStr;
-  UINT64  LunNum;
+  UINT64  LunNum = 0;
EFI coding convention does not allow initialization during definition.

ISCSI_DEVICE_PATH_WITH_NAME *iSCSI;
  NameStr   = SctSplitStr (, L',');
@@ -1459,7 +1459,7 @@ CreateiScsiDeviceNode (
  );
SctUnicodeToAscii (iSCSI->iSCSITargetName, NameStr, SctStrLen (NameStr));
iSCSI->TargetPortalGroupTag = (UINT16) SctStrToUInt (PortalGroupStr);
-  SctStrToUInt64 (LunStr, );
+  StrToUInt8Array(LunStr, );
iSCSI->Lun = LunNum;
  Options = 0x;
@@ -2846,12 +2846,12 @@ DevicePathFromTextConvertTextToDeviceNodeCoverageTest (
  (UINTN)__LINE__
  );
//
-  // TDS 3.10.1.2.26
+  // TDS 3.10.1.2.26   0x5678 - byte 3 is 0x56 and byte4 is 0x78
//
-  SctStrCpy (text, L"MyTargetName,0x12AB,5678,CRC32C,None,CHAP_BI,TCP");
+  SctStrCpy (text, 
L"MyTargetName,0x12AB,0x00567800,CRC32C,None,CHAP_BI,TCP");
Magic String.

pDevicePath = CreateiScsiDeviceNode(text);
  -  SctStrCpy (text, 
L"iSCSI(MyTargetName,0x12AB,5678,CRC32C,None,CHAP_BI,TCP)");
+  SctStrCpy (text, 
L"iSCSI(MyTargetName,0x12AB,0x00567800,CRC32C,None,CHAP_BI,TCP)");
Magic String.

pReDevicePath = DevicePathFromText->ConvertTextToDeviceNode (text);
if (SctCompareMem (pDevicePath, pReDevicePath, SctDevicePathNodeLength 
((EFI_DEVICE_PATH_PROTOCOL *) pReDevicePath)) == 0) {
  AssertionType = EFI_TEST_ASSERTION_PASSED;


IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] uefi-sct/SctPkg: Fix the BlueTooth Guid and Enable BLE test

FYI

On 10/15/2018 03:36 AM, Supreeth Venkatesh wrote:


On 10/14/2018 04:54 AM, Eric Jin wrote:

Correct the guid of EFI_GUID gEfiBlueToothIoProtocolGuid and 
gEfiBlueToothConfigProtocolGuid
Add BlueToothLE support test in the EfiCompliant part

Cc: Supreeth Venkatesh 

Cc: Jiaxin Wu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Jin 
---
  .../Dependency/Config/EfiCompliant.ini|   9 +-
  .../EfiCompliantBBTestPlatform_uefi.c | 127 --
  .../EfiCompliant/BlackBoxTest/Guid_uefi.c |   4 +-
  .../EfiCompliant/BlackBoxTest/Guid_uefi.h |   7 +-
  4 files changed, 132 insertions(+), 15 deletions(-)

diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Generic/EfiCompliant/BlackBoxTest/Dependency/Config/EfiCompliant.ini
 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Generic/EfiCompliant/BlackBoxTest/Dependency/Config/EfiCompliant.ini
index 78b5f7b5..7c0bdcd6 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Generic/EfiCompliant/BlackBoxTest/Dependency/Config/EfiCompliant.ini
+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Generic/EfiCompliant/BlackBoxTest/Dependency/Config/EfiCompliant.ini
@@ -1,7 +1,7 @@
  ## @file
  #
  #  Copyright 2006 - 2016 Unified EFI, Inc.
-#  Copyright (c) 2010 - 2016, Intel Corporation. All rights reserved.
+#  Copyright (c) 2010 - 2018, 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
@@ -84,7 +84,9 @@
  #
  #   EAPSupport= 
  #
-#   BlueToothSupport  = 
+#   BlueToothClassicSupport   = 
+#
+#   BlueToothLESupport= 
  #
  #   IPSecSupport  = 
  #
@@ -120,6 +122,7 @@ DNS6Support   = yes
  TLSSupport= yes
  HTTPSupport   = yes
  EAPSupport= yes
-BlueToothSupport  = yes
+BlueToothClassicSupport   = yes
+BlueToothLESupport= yes
  IPSecSupport  = yes
  diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Generic/EfiCompliant/BlackBoxTest/EfiCompliantBBTestPlatform_uefi.c
 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Generic/EfiCompliant/BlackBoxTest/EfiCompliantBBTestPlatform_uefi.c
index 17df564b..2d45a7c0 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Generic/EfiCompliant/BlackBoxTest/EfiCompliantBBTestPlatform_uefi.c
+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Generic/EfiCompliant/BlackBoxTest/EfiCompliantBBTestPlatform_uefi.c
@@ -1,7 +1,7 @@
  /** @file
  Copyright 2006 - 2016 Unified EFI, Inc.
-  Copyright (c) 2010 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2010 - 2018, 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
@@ -152,9 +152,9 @@ EFI_GUID gEfiBlueToothHcProtocolGuid = { 0xb3930571, 
0xbeba, 0x4fc5, {0x92, 0x3,
EFI_GUID gEfiBlueToothServiceBindingProtocolGuid = { 0x388278d3, 0x7b85, 
0x42f0, {0xab, 0xa9, 0xfb, 0x4b, 0xfd, 0x69, 0xf5, 0xab }};
  -EFI_GUID gEfiBlueToothIoProtocolGuid = { 0x388278d3, 0x7b85, 0x42f0, {0xab, 
0xa9, 0xfb, 0x4b, 0xfd, 0x69, 0xf5, 0xab }};
+EFI_GUID gEfiBlueToothIoProtocolGuid = { 0x467313de, 0x4e30, 0x43f1,{ 0x94, 
0x3e, 0x32, 0x3f, 0x89, 0x84, 0x5d, 0xb5 }};
  -EFI_GUID gEfiBlueToothConfigProtocolGuid = { 0xb3930571, 0xbeba, 0x4fc5, 
{0x92, 0x3, 0x94, 0x27, 0x24, 0x2e, 0x6a, 0x43 }};
+EFI_GUID gEfiBlueToothConfigProtocolGuid = { 0x62960cf3, 0x40ff, 0x4263,{0xa7, 
0x7c, 0xdf, 0xde, 0xbd, 0x19, 0x1b, 0x4b }};
EFI_GUID gEfiEapProtocolGuid = { 0x5d9f96db, 0xe731, 0x4caa, {0xa0, 0x0d, 
0x72, 0xe1, 0x87, 0xcd, 0x77, 0x62 }};
  @@ -166,6 +166,10 @@ EFI_GUID gEfiIPSecConfigProtocolGuid = { 0xce5e5929, 
0xc7a3, 0x4602, {0xad, 0x9e
EFI_GUID gEfiIPSec2ProtocolGuid = { 0xa3979e64, 0xace8, 0x4ddc, {0xbc, 
0x07, 0x4d, 0x66, 0xb8, 0xfd, 0x09, 0x77 }};
  +EFI_GUID gEfiBlueToothAttributeProtocolGuid = { 0x898890e9, 0x84b2, 0x4f3a, 
{ 0x8c, 0x58, 0xd8, 0x57, 0x78, 0x13, 0xe0, 0xac }};
+
+EFI_GUID gEfiBlueToothLEConfigProtocolGuid = { 0x8f76da58, 0x1f99, 0x4275, { 
0xa4, 0xec, 0x47, 0x56, 0x51, 0x5b, 0x1c, 0xe8 }};
+
  //
  // Internal functions declarations
  //
@@ -353,7 +357,13 @@ CheckEAPProtocols (
);
EFI_STATUS
-CheckBlueToothProtocols (
+CheckBlueToothClassicProtocols (
+  IN EFI_STANDARD_TEST_LIBRARY_PROTOCOL   *StandardLib,
+  IN EFI_INI_FILE_HANDLE  IniFile
+  );
+
+EFI_STATUS
+CheckBlueToothLEProtocols (
IN EFI_STANDARD_TEST_LIBRARY_PROTOCOL   *StandardLib,
IN EFI_INI_FILE_HANDLE  IniFile
);
@@ -564,7 +574,8 @@ Routine Description:
//
// Check the BlueTooth protocols
//
-  CheckBlueToothProtocols (StandardLib, IniFile);
+  CheckBlueToothClassicProtocols (StandardLib, IniFile);
+  CheckBlueToothLEProtocols (StandardLib, IniFile);
  //
// Check the

Re: [edk2] [PATCH] uefi-sct/SctPkg:Add the checkpoint of Toggle state of ReadKeyStrokeEx

FYI

On 10/15/2018 03:17 AM, Supreeth Venkatesh wrote:


On 10/13/2018 05:21 PM, Eric Jin wrote:

UEFI Spec clarify the Toggle state

Cc: Supreeth Venkatesh 

Cc: Jiaxin Wu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Jin 
---
  .../SimpleTextInputEx/BlackBoxTest/Guid.c |   7 +-
  .../SimpleTextInputEx/BlackBoxTest/Guid.h |  12 +-
  .../SimpleTextInputExBBTestFunction.c | 210 +
  .../SimpleTextInputExBBTestMain.c |  13 +-
  .../SimpleTextInputExBBTestMain.h |  22 +-
  .../SimpleTextInputEx/BlackBoxTest/Guid.c |   7 +-
  .../SimpleTextInputEx/BlackBoxTest/Guid.h |  12 +-
  .../SimpleTextInputExBBTestFunction.c | 212 +-
  .../SimpleTextInputExBBTestMain.c |  11 +-
  .../SimpleTextInputExBBTestMain.h |  20 +-
  10 files changed, 513 insertions(+), 13 deletions(-)

diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextInputEx/BlackBoxTest/Guid.c
 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextInputEx/BlackBoxTest/Guid.c
index 9cb19f48..ff2d50fa 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextInputEx/BlackBoxTest/Guid.c
+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextInputEx/BlackBoxTest/Guid.c
@@ -1,7 +1,7 @@
  /** @file
  Copyright 2006 - 2012 Unified EFI, Inc.
-  Copyright (c) 2010 - 2012, Intel Corporation. All rights reserved.
+  Copyright (c) 2010 - 2018, 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
@@ -63,3 +63,8 @@ EFI_GUID gSimpleTextInputExBBTestFunctionAssertionGuid007 = 
EFI_TEST_SIMPLETEXTI
  EFI_GUID gSimpleTextInputExBBTestFunctionAssertionGuid008 = 
EFI_TEST_SIMPLETEXTINPUTEXBBTESTFUNCTION_ASSERTION_008_GUID;
EFI_GUID gSimpleTextInputExBBTestFunctionAssertionGuid009 = 
EFI_TEST_SIMPLETEXTINPUTEXBBTESTFUNCTION_ASSERTION_009_GUID;
+
+EFI_GUID gSimpleTextInputExBBTestFunctionAssertionGuid010 = 
EFI_TEST_SIMPLETEXTINPUTEXBBTESTFUNCTION_ASSERTION_010_GUID;
+
+EFI_GUID gSimpleTextInputExBBTestFunctionAssertionGuid011 = 
EFI_TEST_SIMPLETEXTINPUTEXBBTESTFUNCTION_ASSERTION_011_GUID;
+
diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextInputEx/BlackBoxTest/Guid.h
 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextInputEx/BlackBoxTest/Guid.h
index 6c90fca3..2a6be48b 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextInputEx/BlackBoxTest/Guid.h
+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextInputEx/BlackBoxTest/Guid.h
@@ -1,7 +1,7 @@
  /** @file
  Copyright 2006 - 2010 Unified EFI, Inc.
-  Copyright (c) 2010, Intel Corporation. All rights reserved.
+  Copyright (c) 2010 - 2018, 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
@@ -119,3 +119,13 @@ extern EFI_GUID 
gSimpleTextInputExBBTestFunctionAssertionGuid008;
  { 0x534369f7, 0x8399, 0x4353, { 0x94, 0xad, 0xc4, 0x48, 0xfa, 0xda, 0xeb, 
0x84 } }
extern EFI_GUID gSimpleTextInputExBBTestFunctionAssertionGuid009;
+
+#define EFI_TEST_SIMPLETEXTINPUTEXBBTESTFUNCTION_ASSERTION_010_GUID \
+{ 0xcf4d54eb, 0x6696, 0x4794, { 0x91, 0x74, 0x59, 0xd, 0x1c, 0x22, 0xa8, 0x67 
} }
+
+extern EFI_GUID gSimpleTextInputExBBTestFunctionAssertionGuid010;
+
+#define EFI_TEST_SIMPLETEXTINPUTEXBBTESTFUNCTION_ASSERTION_011_GUID \
+{ 0xf8e8f879, 0xa6d4, 0x4fd3, { 0x8b, 0x8e, 0xba, 0x1d, 0x18, 0xf1, 0x40, 0x71 
} }
+
+extern EFI_GUID gSimpleTextInputExBBTestFunctionAssertionGuid011;
diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextInputEx/BlackBoxTest/SimpleTextInputExBBTestFunction.c
 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextInputEx/BlackBoxTest/SimpleTextInputExBBTestFunction.c
index 153ade03..48f91002 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextInputEx/BlackBoxTest/SimpleTextInputExBBTestFunction.c
+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextInputEx/BlackBoxTest/SimpleTextInputExBBTestFunction.c
@@ -456,6 +456,78 @@ BBTestUnregisterKeyNotifyFunctionManualTest (
  }
+EFI_STATUS
+BBTestReadKeyStrokeExFunctionAutoTest (
+  IN EFI_BB_TEST_PROTOCOL   *This,
+  IN VOID   *ClientInterface,
+  IN EFI_TEST_LEVEL TestLevel,
+  IN EFI_HANDLE SupportHandle
+  )
+{
+  EFI_STANDARD_TEST_LIBRARY_PROTOCOL*StandardLib;
+  EFI_STATUSStatus;
+  EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL *SimpleTextInputEx;
+
+  EFI_DEVICE_PATH_PROTOCOL *DevicePath;
+  CHAR16   *DevicePathStr;
+
+  //
+  // init
+  //
+  SimpleTextInputEx = (EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL*)ClientInterface;
+
+  //
+  // Get the Standard

Re: [edk2] [PATCH] uefi-sct/SctPkg:Fix the incorrect buffer free in SctAPrint()




On 10/15/2018 03:24 AM, Supreeth Venkatesh wrote:
Reviewed-by: Supreeth Venkatesh 



On 10/14/2018 02:58 AM, Eric Jin wrote:

Cc: Supreeth Venkatesh 

Cc: Jiaxin Wu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Jin 
---
  uefi-sct/SctPkg/Library/SctLib/Print.c | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/uefi-sct/SctPkg/Library/SctLib/Print.c 
b/uefi-sct/SctPkg/Library/SctLib/Print.c
index c25aff11..e523073a 100644
--- a/uefi-sct/SctPkg/Library/SctLib/Print.c
+++ b/uefi-sct/SctPkg/Library/SctLib/Print.c
@@ -2,7 +2,7 @@
  Copyright 2006 - 2015 Unified EFI, Inc.
Copyright (c) 2013 - 2014, ARM Ltd. All rights reserved.
-  Copyright (c) 2014 - 2015, Intel Corporation. All rights reserved.
+  Copyright (c) 2014 - 2018, 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
@@ -676,7 +676,9 @@ _IPrint (
}
  ret = _Print ();
-  SctFreePool(ps.fmt.u.pw);
+  if (fmt) {
+SctFreePool(ps.fmt.u.pw);
+  }
return ret;
  }



IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] uefi-sct/SctPkg:Enhance the SimpleNetwork Test

FYI

On 10/15/2018 03:30 AM, Supreeth Venkatesh wrote:


On 10/14/2018 03:06 AM, Eric Jin wrote:

Add the EFI_SIMPLE_NETWORK_RECEIVE_MULTICAST bit in the Enable parameter
Add one checkpoint to MCastFilterCount is zero

Cc: Supreeth Venkatesh 

Cc: Jiaxin Wu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Jin 
---
  .../SimpleNetwork/BlackBoxTest/Guid.c |  4 +-
  .../SimpleNetwork/BlackBoxTest/Guid.h |  7 +-
  .../SimpleNetworkBBTestConformance.c  | 66 +--
  .../SimpleNetwork/BlackBoxTest/Guid.c |  4 +-
  .../SimpleNetwork/BlackBoxTest/Guid.h |  7 +-
  .../SimpleNetworkBBTestConformance.c  | 66 +--
  6 files changed, 110 insertions(+), 44 deletions(-)

diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleNetwork/BlackBoxTest/Guid.c 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleNetwork/BlackBoxTest/Guid.c
index 6ea6c4cb..72343236 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleNetwork/BlackBoxTest/Guid.c
+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleNetwork/BlackBoxTest/Guid.c
@@ -1,7 +1,7 @@
  /** @file
  Copyright 2006 - 2016 Unified EFI, Inc.
-  Copyright (c) 2010 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2010 - 2018, 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
@@ -112,6 +112,8 @@ EFI_GUID gSimpleNetworkBBTestConformanceAssertionGuid041 = 
EFI_TEST_SIMPLENETWOR
EFI_GUID gSimpleNetworkBBTestConformanceAssertionGuid042 = 
EFI_TEST_SIMPLENETWORKBBTESTCONFORMANCE_ASSERTION_042_GUID;
  +EFI_GUID gSimpleNetworkBBTestConformanceAssertionGuid043 = 
EFI_TEST_SIMPLENETWORKBBTESTCONFORMANCE_ASSERTION_043_GUID;
+
  EFI_GUID gSimpleNetworkBBTestFunctionAssertionGuid001 = 
EFI_TEST_SIMPLENETWORKBBTESTFUNCTION_ASSERTION_001_GUID;
EFI_GUID gSimpleNetworkBBTestFunctionAssertionGuid002 = 
EFI_TEST_SIMPLENETWORKBBTESTFUNCTION_ASSERTION_002_GUID;
diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleNetwork/BlackBoxTest/Guid.h 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleNetwork/BlackBoxTest/Guid.h
index 281d893a..bf909d1c 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleNetwork/BlackBoxTest/Guid.h
+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleNetwork/BlackBoxTest/Guid.h
@@ -1,7 +1,7 @@
  /** @file
  Copyright 2006 - 2016 Unified EFI, Inc.
-  Copyright (c) 2010 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2010 - 2018, 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
@@ -235,6 +235,11 @@ extern EFI_GUID 
gSimpleNetworkBBTestConformanceAssertionGuid041;
extern EFI_GUID gSimpleNetworkBBTestConformanceAssertionGuid042;
  +#define EFI_TEST_SIMPLENETWORKBBTESTCONFORMANCE_ASSERTION_043_GUID \
+{ 0x8cec0b86, 0x7773, 0x4d3c, {0x84, 0x13, 0x26, 0x37, 0xfb, 0xd0, 0x8e, 0x1b 
}}
+
+extern EFI_GUID gSimpleNetworkBBTestConformanceAssertionGuid043;
+
  #define EFI_TEST_SIMPLENETWORKBBTESTFUNCTION_ASSERTION_001_GUID \
  { 0xf58651fe, 0x0538, 0x4407, {0x88, 0xe0, 0x88, 0xb8, 0xda, 0x18, 0x38, 0x3a 
}}
  diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleNetwork/BlackBoxTest/SimpleNetworkBBTestConformance.c
 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleNetwork/BlackBoxTest/SimpleNetworkBBTestConformance.c
index ccbbad08..b65d7d3b 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleNetwork/BlackBoxTest/SimpleNetworkBBTestConformance.c
+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleNetwork/BlackBoxTest/SimpleNetworkBBTestConformance.c
@@ -1,7 +1,7 @@
  /** @file
  Copyright 2006 - 2016 Unified EFI, Inc.
-  Copyright (c) 2010 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2010 - 2018, 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
@@ -581,11 +581,12 @@ BBTestReceiveFilterConformanceTest (
  {
EFI_STANDARD_TEST_LIBRARY_PROTOCOL*StandardLib;
EFI_STATUSStatus;
-  EFI_STATUSStatusBuf[5];
-  EFI_TEST_ASSERTIONAssertionType[5];
+  EFI_STATUSStatusBuf[6];
Magic Number 6.

+  EFI_TEST_ASSERTIONAssertionType[6];
Magic number 6.

EFI_SIMPLE_NETWORK_PROTOCOL   *SnpInterface;
EFI_SIMPLE_NETWORK_STATE  State1, State2;
-
+  EFI_MAC_ADDRESS   MAC;
+
//
// Get the Standard Library Interface
//
@@ -673,23 +674,37 @@ BBTestReceiveFilterConformanceTest (
//
//  Call ReceiveFilters

Re: [edk2] [PATCH] uefi-sct/SctPkg:One checkpoint in the ExtractConfigFunction need be removed

FYI

On 10/15/2018 03:48 AM, Supreeth Venkatesh wrote:
Reviewed-by: Supreeth Venkatesh 



On 10/13/2018 04:30 PM, Eric Jin wrote:

The Results output from ExtractConfigFunction() may be different during two 
calls in some case.

Cc: Supreeth Venkatesh 

Cc: Jiaxin Wu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Jin 
---
  .../HIIConfigRouting/BlackBoxTest/Guid.c  |  4 +---
  .../HIIConfigRouting/BlackBoxTest/Guid.h  |  6 +
  .../HIIConfigRoutingBBTestFunction.c  | 23 +--
  3 files changed, 3 insertions(+), 30 deletions(-)

diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/HIIConfigRouting/BlackBoxTest/Guid.c
 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/HIIConfigRouting/BlackBoxTest/Guid.c
index 18282f30..93265947 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/HIIConfigRouting/BlackBoxTest/Guid.c
+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/HIIConfigRouting/BlackBoxTest/Guid.c
@@ -1,7 +1,7 @@
  /** @file
  Copyright 2006 - 2011 Unified EFI, Inc.
-  Copyright (c) 2010 - 2011, Intel Corporation. All rights reserved.
+  Copyright (c) 2010 - 2018, 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
@@ -88,7 +88,5 @@ EFI_GUID gHIIConfigRoutingBBTestFunctionAssertionGuid009 = 
EFI_TEST_HIICONFIGROU
EFI_GUID gHIIConfigRoutingBBTestFunctionAssertionGuid010 = 
EFI_TEST_HIICONFIGROUTINGBBTESTFUNCTION_ASSERTION_010_GUID;
  -EFI_GUID gHIIConfigRoutingBBTestFunctionAssertionGuid011 = 
EFI_TEST_HIICONFIGROUTINGBBTESTFUNCTION_ASSERTION_011_GUID;
-
  EFI_GUID gHIIConfigRoutingBBTestFunctionAssertionGuid012 = 
EFI_TEST_HIICONFIGROUTINGBBTESTFUNCTION_ASSERTION_012_GUID;
  diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/HIIConfigRouting/BlackBoxTest/Guid.h
 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/HIIConfigRouting/BlackBoxTest/Guid.h
index 97e257e7..7ade1a0f 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/HIIConfigRouting/BlackBoxTest/Guid.h
+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/HIIConfigRouting/BlackBoxTest/Guid.h
@@ -1,7 +1,7 @@
  /** @file
  Copyright 2006 - 2011 Unified EFI, Inc.
-  Copyright (c) 2010 - 2011, Intel Corporation. All rights reserved.
+  Copyright (c) 2010 - 2018, 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
@@ -180,10 +180,6 @@ extern EFI_GUID 
gHIIConfigRoutingBBTestFunctionAssertionGuid009;
extern EFI_GUID gHIIConfigRoutingBBTestFunctionAssertionGuid010;
  -#define EFI_TEST_HIICONFIGROUTINGBBTESTFUNCTION_ASSERTION_011_GUID \
-{ 0xf91ef5f3, 0xe0c6, 0x4aca, { 0xa0, 0xd0, 0x5, 0xf9, 0xb1, 0x6a, 0x13, 0xbd 
} }
-
-extern EFI_GUID gHIIConfigRoutingBBTestFunctionAssertionGuid011;
#define EFI_TEST_HIICONFIGROUTINGBBTESTFUNCTION_ASSERTION_012_GUID \
  { 0xf732d246, 0x9fa5, 0x4ed3, { 0x88, 0x95, 0x28, 0x63, 0xba, 0xf4, 0x68, 
0x5d } }
diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/HIIConfigRouting/BlackBoxTest/HIIConfigRoutingBBTestFunction.c
 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/HIIConfigRouting/BlackBoxTest/HIIConfigRoutingBBTestFunction.c
index 5eed6c6c..d4bd23d1 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/HIIConfigRouting/BlackBoxTest/HIIConfigRoutingBBTestFunction.c
+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/HIIConfigRouting/BlackBoxTest/HIIConfigRoutingBBTestFunction.c
@@ -1,7 +1,7 @@
  /** @file
  Copyright 2006 - 2016 Unified EFI, Inc.
-  Copyright (c) 2010 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2010 - 2018, 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
@@ -418,27 +418,6 @@ BBTestExtractConfigFunctionTestCheckpoint1 (
   Status
   );
  -  //
-  // Since ExtractConfig may not append  at string tail.
-  // We check whether Results is a substring of MultiConfigAltResp from 
ExportConfig
-  //
-  if (Status == EFI_SUCCESS && (SctStrStr (MultiConfigAltResp, Results) != 
NULL)) {
-AssertionType = EFI_TEST_ASSERTION_PASSED;
-  } else if (EFI_OUT_OF_RESOURCES == Status){
-AssertionType = EFI_TEST_ASSERTION_WARNING;
-  } else {
-AssertionType = EFI_TEST_ASSERTION_FAILED;
-  }
-  StandardLib->RecordAssertion (
- StandardLib,
- AssertionType,
- gHIIConfigRoutingBBTestFunctionAssertionGuid011,
- L"HII_CONFIG_ROUTING_PROTOCOL.ExtractConfig - ExtractConfig() 
Check if Results is in  format.",
- L"%a:%d:",
- __FILE__,
- (UINTN)__LINE__
-

Re: [edk2] [PATCH] uefi-sct/SctPkg:Add conformance test cases for deprecated EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS attribute.

FYI

On 10/15/2018 03:46 AM, Supreeth Venkatesh wrote:
Reviewed-by: Supreeth Venkatesh 


If the commit message is broken down into multiple lines less than 80 cols.


On 10/13/2018 04:19 PM, Eric Jin wrote:

Cc: Supreeth Venkatesh 

Cc: Jiaxin Wu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Jin 
---
  .../AuthVariableServicesBBTestConformance.c   | 143 ++
  .../VariableServices/BlackBoxTest/Guid.c  |   6 +-
  .../VariableServices/BlackBoxTest/Guid.h  |  11 +-
  3 files changed, 132 insertions(+), 28 deletions(-)

diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/VariableServices/BlackBoxTest/AuthVariableServicesBBTestConformance.c
 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/VariableServices/BlackBoxTest/AuthVariableServicesBBTestConformance.c
index 05281054..a1d1c4c3 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/VariableServices/BlackBoxTest/AuthVariableServicesBBTestConformance.c
+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/VariableServices/BlackBoxTest/AuthVariableServicesBBTestConformance.c
@@ -1,7 +1,7 @@
  /** @file
  Copyright 2006 - 2012 Unified EFI, Inc.
-  Copyright (c) 2010 - 2012, Intel Corporation. All rights reserved.
+  Copyright (c) 2010 - 2018, 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
@@ -151,6 +151,44 @@ AuthVariableDERConfTest (
EFI_TEST_LOGGING_LIBRARY_PROTOCOL   *LoggingLib;
UINT32  Attr;
EFI_TEST_ASSERTION  Result;
+  UINTN   Index;
+  UINTN   MaximumVariableStorageSize;
+  UINTN   RemainingVariableStorageSize;
+  UINTN   MaximumVariableSize;
+  UINT32  AttrArray[] = {
+//
+//  For 1 attribute.
+//
+EFI_VARIABLE_NON_VOLATILE,
+EFI_VARIABLE_RUNTIME_ACCESS,
+EFI_VARIABLE_BOOTSERVICE_ACCESS,
+EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS,
+
+//
+//  For 2 attributes.
+//
+EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_RUNTIME_ACCESS,
+EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_BOOTSERVICE_ACCESS,
+EFI_VARIABLE_NON_VOLATILE | 
EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS,
+
+EFI_VARIABLE_RUNTIME_ACCESS | EFI_VARIABLE_BOOTSERVICE_ACCESS,
+EFI_VARIABLE_RUNTIME_ACCESS | 
EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS,
+
+EFI_VARIABLE_BOOTSERVICE_ACCESS | 
EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS,
+
+//
+//  For 3 attributes.
+//
+EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_RUNTIME_ACCESS | 
EFI_VARIABLE_BOOTSERVICE_ACCESS,
+EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_RUNTIME_ACCESS | 
EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS,
+EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_BOOTSERVICE_ACCESS | 
EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS,
+EFI_VARIABLE_RUNTIME_ACCESS | EFI_VARIABLE_BOOTSERVICE_ACCESS | 
EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS,
+
+//
+//  For 4 attributes.
+//
+EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_RUNTIME_ACCESS | 
EFI_VARIABLE_BOOTSERVICE_ACCESS | 
EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS,
+  };
  Status = GetTestSupportLibrary (
   SupportHandle,
@@ -192,33 +230,86 @@ AuthVariableDERConfTest (
   Status
   );
  -  Attr = EFI_VARIABLE_NON_VOLATILE |
- EFI_VARIABLE_RUNTIME_ACCESS |
- EFI_VARIABLE_BOOTSERVICE_ACCESS |
- EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS;
+  for (Index = 0; Index < sizeof (AttrArray) / sizeof (AttrArray[0]); Index = 
Index + 1) {
+Attr = AttrArray[Index];
+Attr |= EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS;
+
+Status = RT->SetVariable (
+   L"AuthVarDER",
+   ,
+   Attr,
+   sizeof (mValidAuthVarDERCreate),
+   (VOID *) mValidAuthVarDERCreate
+   );
+if (Status == EFI_UNSUPPORTED) {
+  Result = EFI_TEST_ASSERTION_PASSED;
+} else {
+  Result = EFI_TEST_ASSERTION_FAILED;
+}
+
+StandardLib->RecordAssertion (
+   StandardLib,
+   Result,
+   gVariableServicesBbTestConformanceAssertionGuid020,
+   L"RT.SetVariable - Set Auth Variable with valid cert.",
+   L"Attributes = Array[%d]. %a:%d:Status - %r",
+   Index,
+   __FILE__,
+   (UINTN)__LINE__,
+   Status
+   );
+
+Status = RT->SetVariable (
+   L"AuthVarDER",
+   ,
+   Attr,
+

[edk2] [Patch] BaseTools: Fix bugs use special character in the --pcd option

Cases:
--pcd Token.Name="!"
--pcd Token.Name="\'W&\'"
--pcd Token.Name="2*h"

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yonghong Zhu 
---
 BaseTools/Source/Python/Workspace/DscBuildData.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/BaseTools/Source/Python/Workspace/DscBuildData.py 
b/BaseTools/Source/Python/Workspace/DscBuildData.py
index aaef404..1a0a293 100644
--- a/BaseTools/Source/Python/Workspace/DscBuildData.py
+++ b/BaseTools/Source/Python/Workspace/DscBuildData.py
@@ -1078,10 +1078,12 @@ class DscBuildData(PlatformBuildClassObject):
 if PcdValue.upper() == 'TRUE':
 PcdValue = str(1)
 if not FieldName:
 if PcdDatumType not in TAB_PCD_NUMERIC_TYPES:
 PcdValue = '"' + PcdValue + '"'
+elif not PcdValue.isdigit() and not 
PcdValue.upper().startswith('0X'):
+PcdValue = '"' + PcdValue + '"'
 else:
 IsArray = False
 Base = 10
 if PcdValue.upper().startswith('0X'):
 Base = 16
-- 
2.6.1.windows.1

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

[edk2] [Patch] BaseTools: Add check for the string type whether is same

From: zhijufan 

Relational and equality operators require both operands to be of
the same type.
Treat the string 'A' and "A" as same type, but for "A" and L"A"
are not same type since one is general string, another is unicode
string.

True:'A'<'B', "A"<"B" 'A'<"B", L'A'
Cc: Yonghong Zhu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Zhiju.Fan 
---
 BaseTools/Source/Python/Common/Expression.py | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/BaseTools/Source/Python/Common/Expression.py 
b/BaseTools/Source/Python/Common/Expression.py
index 78c69fa..84898f7 100644
--- a/BaseTools/Source/Python/Common/Expression.py
+++ b/BaseTools/Source/Python/Common/Expression.py
@@ -295,12 +295,12 @@ class ValueExpression(BaseExpression):
 # bitwise and logical operation between number and boolean 
is allowed
 pass
 else:
 raise BadExpression(ERR_EXPR_TYPE)
 if isinstance(Oprand1, type('')) and isinstance(Oprand2, type('')):
-if (Oprand1.startswith('L"') and not Oprand2.startswith('L"')) 
or \
-(not Oprand1.startswith('L"') and 
Oprand2.startswith('L"')):
+if ((Oprand1.startswith('L"') or Oprand1.startswith('L')) and 
(not Oprand2.startswith('L"')) and (not Oprand2.startswith("L'"))) or \
+(((not Oprand1.startswith('L"')) and (not 
Oprand1.startswith("L'"))) and (Oprand2.startswith('L"') or 
Oprand2.startswith('L'))):
 raise BadExpression(ERR_STRING_CMP % (Oprand1, Operator, 
Oprand2))
 if 'in' in Operator and isinstance(Oprand2, type('')):
 Oprand2 = Oprand2.split()
 EvalStr = 'Oprand1 ' + Operator + ' Oprand2'
 
@@ -825,10 +825,12 @@ class ValueExpressionEx(ValueExpression):
 except BadExpression as Value:
 if self.PcdType in TAB_PCD_NUMERIC_TYPES:
 PcdValue = PcdValue.strip()
 if PcdValue.startswith('{') and PcdValue.endswith('}'):
 PcdValue = SplitPcdValueString(PcdValue[1:-1])
+if ERR_STRING_CMP.split(':')[0] in Value.message:
+raise BadExpression("Type: %s, Value: %s, %s" % 
(self.PcdType, PcdValue, Value))
 if isinstance(PcdValue, type([])):
 TmpValue = 0
 Size = 0
 ValueType = ''
 for Item in PcdValue:
-- 
2.6.1.windows.1

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

[edk2] Where to find the fix for security issue id 686

2018-10-15 Thread Rafael Machado

Hi everyone

I was tying to find the patch to fix the reported security issue id 686 (
https://bugzilla.tianocore.org/show_bug.cgi?id=686),
but was not able to access it.

Could someone please tell if this patch, or series of patches, was already
merged to some branch that is public available?

Thanks and Regards
Rafael R. Machado
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v1 0/7] Code refinements in UdfDxe

2018-10-15 Thread Paulo Alcantara

Hi,

Hao Wu  writes:

> This series will refine the codes in MdeModulePkg/Universal/Disk/UdfDxe
> for:
>
> A. Refine asserts used for memory allocation failure and error cases that
>are possible to happen. Will use error handling logic for them;
>
> B. Address some dead codes within this module.
>
> Cc: Paulo Alcantara 
> Cc: Ruiyu Ni 
> Cc: Star Zeng 
>
> Hao Wu (7):
>   MdeModulePkg/UdfDxe: Use error handling for memory allocation failure
>   MdeModulePkg/UdfDxe: ASSERT for false positives of NULL ptr deref
>   MdeModulePkg/UdfDxe: Use error handling when fail to return LSN
>   MdeModulePkg/UdfDxe: Use debug msg instead of ASSERT in UdfOpen()
>   MdeModulePkg/UdfDxe: Handle dead codes in File.c
>   MdeModulePkg/UdfDxe: Remove dead codes in FileName.c
>   MdeModulePkg/UdfDxe: Handle dead codes in FileSystemOperations.c
>
>  MdeModulePkg/Universal/Disk/UdfDxe/File.c |  19 ++-
>  MdeModulePkg/Universal/Disk/UdfDxe/FileName.c |  15 --
>  MdeModulePkg/Universal/Disk/UdfDxe/FileSystemOperations.c | 162 
> +++-
>  3 files changed, 142 insertions(+), 54 deletions(-)

Looks good to me. Thanks!

For the series:

Reviewed-by: Paulo Alcantara 

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

Re: [edk2] [PATCH 06/11] SourceLevelDebugPkg/Usb3: Make sure data from HW can fit in buffer

2018-10-15 Thread Wu, Hao A

Reviewed-by: Hao Wu 

Best Regards,
Hao Wu


> -Original Message-
> From: Ni, Ruiyu
> Sent: Monday, October 15, 2018 2:38 PM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A
> Subject: [PATCH 06/11] SourceLevelDebugPkg/Usb3: Make sure data from
> HW can fit in buffer
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ruiyu Ni 
> Cc: Hao A Wu 
> ---
>  .../DebugCommunicationLibUsb3/DebugCommunicationLibUsb3Transfer.c  |
> 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git
> a/SourceLevelDebugPkg/Library/DebugCommunicationLibUsb3/DebugComm
> unicationLibUsb3Transfer.c
> b/SourceLevelDebugPkg/Library/DebugCommunicationLibUsb3/DebugComm
> unicationLibUsb3Transfer.c
> index fb48010a9a..fda43279a3 100644
> ---
> a/SourceLevelDebugPkg/Library/DebugCommunicationLibUsb3/DebugComm
> unicationLibUsb3Transfer.c
> +++
> b/SourceLevelDebugPkg/Library/DebugCommunicationLibUsb3/DebugComm
> unicationLibUsb3Transfer.c
> @@ -556,6 +556,13 @@ XhcDataTransfer (
> 
>XhcExecTransfer (Handle, Urb, Timeout);
> 
> +  //
> +  // Make sure the data received from HW can fit in the received buffer.
> +  //
> +  if (Urb->Completed > *DataLength) {
> +return EFI_DEVICE_ERROR;
> +  }
> +
>*DataLength = Urb->Completed;
> 
>Status = EFI_TIMEOUT;
> --
> 2.16.1.windows.1

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

Re: [edk2] [PATCH 05/11] MdeModulePkg/Usb: Make sure data from HW is no more than expected

2018-10-15 Thread Wu, Hao A

Reviewed-by: Hao Wu 

Best Regards,
Hao Wu


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Ruiyu Ni
> Sent: Monday, October 15, 2018 2:38 PM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A; Yao, Jiewen; Zeng, Star
> Subject: [edk2] [PATCH 05/11] MdeModulePkg/Usb: Make sure data from
> HW is no more than expected
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ruiyu Ni 
> Cc: Jiewen Yao 
> Cc: Star Zeng 
> Cc: Hao A Wu 
> ---
>  MdeModulePkg/Bus/Pci/EhciDxe/EhciSched.c | 9 ++---
>  MdeModulePkg/Bus/Pci/UhciDxe/UhciSched.c | 7 ---
>  MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c | 9 ++---
>  3 files changed, 16 insertions(+), 9 deletions(-)
> 
> diff --git a/MdeModulePkg/Bus/Pci/EhciDxe/EhciSched.c
> b/MdeModulePkg/Bus/Pci/EhciDxe/EhciSched.c
> index fea6f47f4c..168280be81 100644
> --- a/MdeModulePkg/Bus/Pci/EhciDxe/EhciSched.c
> +++ b/MdeModulePkg/Bus/Pci/EhciDxe/EhciSched.c
> @@ -1009,9 +1009,12 @@ EhcMonitorAsyncRequests (
>  ProcBuf = NULL;
> 
>  if (Urb->Result == EFI_USB_NOERROR) {
> -  ASSERT (Urb->Completed <= Urb->DataLen);
> -
> -  ProcBuf = AllocatePool (Urb->Completed);
> +  //
> +  // Make sure the data received from HW is no more than expected.
> +  //
> +  if (Urb->Completed <= Urb->DataLen) {
> +ProcBuf = AllocatePool (Urb->Completed);
> +  }
> 
>if (ProcBuf == NULL) {
>  EhcUpdateAsyncRequest (Ehc, Urb);
> diff --git a/MdeModulePkg/Bus/Pci/UhciDxe/UhciSched.c
> b/MdeModulePkg/Bus/Pci/UhciDxe/UhciSched.c
> index 90f010c998..f7510f3ec0 100644
> --- a/MdeModulePkg/Bus/Pci/UhciDxe/UhciSched.c
> +++ b/MdeModulePkg/Bus/Pci/UhciDxe/UhciSched.c
> @@ -2,7 +2,7 @@
> 
>The EHCI register operation routines.
> 
> -Copyright (c) 2007 - 2013, Intel Corporation. All rights reserved.
> +Copyright (c) 2007 - 2018, 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
> @@ -1001,11 +1001,12 @@ UhciMonitorAsyncReqList (
> 
>  //
>  // Copy the data to temporary buffer if there are some
> -// data transferred. We may have zero-length packet
> +// data transferred. We may have zero-length packet.
> +// Make sure the data received from HW is no more than expected.
>  //
>  Data = NULL;
> 
> -if (QhResult.Complete != 0) {
> +if ((QhResult.Complete != 0) && (QhResult.Complete <= AsyncReq-
> >DataLen)) {
>Data = AllocatePool (QhResult.Complete);
> 
>if (Data == NULL) {
> diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c
> b/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c
> index 6a2ef4cd5d..166c44bf5e 100644
> --- a/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c
> +++ b/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c
> @@ -1556,9 +1556,12 @@ XhcMonitorAsyncRequests (
>  //
>  ProcBuf = NULL;
>  if (Urb->Result == EFI_USB_NOERROR) {
> -  ASSERT (Urb->Completed <= Urb->DataLen);
> -
> -  ProcBuf = AllocateZeroPool (Urb->Completed);
> +  //
> +  // Make sure the data received from HW is no more than expected.
> +  //
> +  if (Urb->Completed <= Urb->DataLen) {
> +ProcBuf = AllocateZeroPool (Urb->Completed);
> +  }
> 
>if (ProcBuf == NULL) {
>  XhcUpdateAsyncRequest (Xhc, Urb);
> --
> 2.16.1.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Revert BaseTools Python3 Migration has been done at 1ccc4d895dd8d659d016efcd6ef8a48749aba1d0