date:20240419

[edk2-devel] [PATCH 7/7] OvmfPkg: Use newly defined Unaccepted Memory Type

2024-04-19 Thread Sachin Ganesh via groups.io

EFI_RESOURCE_MEMORY_UNACCEPTED has been officially defined in the PI
1.8 specification. So all temporary solutions have been replaced with
the actual definition.

Cc: Felix Polyudov 
Cc: Dhanaraj V 
Cc: Jiewen Yao 
Cc: Liming Gao 
Signed-off-by: Sachin Ganesh 
---
 OvmfPkg/AmdSevDxe/AmdSevDxe.c| 4 ++--
 OvmfPkg/IntelTdx/TdxHelperLib/SecTdxHelper.c | 8 
 OvmfPkg/Library/PeilessStartupLib/Hob.c  | 4 ++--
 OvmfPkg/Library/PlatformInitLib/IntelTdx.c   | 8 
 OvmfPkg/PlatformPei/AmdSev.c | 4 ++--
 5 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/OvmfPkg/AmdSevDxe/AmdSevDxe.c b/OvmfPkg/AmdSevDxe/AmdSevDxe.c
index db3675ae86..d497a343d3 100644
--- a/OvmfPkg/AmdSevDxe/AmdSevDxe.c
+++ b/OvmfPkg/AmdSevDxe/AmdSevDxe.c
@@ -20,7 +20,7 @@
 #include 

 #include 

 #include 

-#include 

+#include 

 #include 

 #include 

 #include 

@@ -119,7 +119,7 @@ AcceptAllMemory (
 CONST EFI_GCD_MEMORY_SPACE_DESCRIPTOR  *Desc;



 Desc = [Index];

-if (Desc->GcdMemoryType != EFI_GCD_MEMORY_TYPE_UNACCEPTED) {

+if (Desc->GcdMemoryType != EfiGcdMemoryTypeUnaccepted) {

   continue;

 }



diff --git a/OvmfPkg/IntelTdx/TdxHelperLib/SecTdxHelper.c 
b/OvmfPkg/IntelTdx/TdxHelperLib/SecTdxHelper.c
index 3372cee2f7..b6085eab44 100644
--- a/OvmfPkg/IntelTdx/TdxHelperLib/SecTdxHelper.c
+++ b/OvmfPkg/IntelTdx/TdxHelperLib/SecTdxHelper.c
@@ -19,7 +19,7 @@
 #include 

 #include 

 #include 

-#include 

+#include 

 #include 

 #include 

 #include 

@@ -351,7 +351,7 @@ AcceptMemoryForAPsStack (
 if (Hob.Header->HobType == EFI_HOB_TYPE_RESOURCE_DESCRIPTOR) {

   DEBUG ((DEBUG_INFO, "\nResourceType: 0x%x\n", 
Hob.ResourceDescriptor->ResourceType));



-  if (Hob.ResourceDescriptor->ResourceType == 
BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED) {

+  if (Hob.ResourceDescriptor->ResourceType == 
EFI_RESOURCE_MEMORY_UNACCEPTED) {

 ResourceLength = Hob.ResourceDescriptor->ResourceLength;

 PhysicalStart  = Hob.ResourceDescriptor->PhysicalStart;

 PhysicalEnd= PhysicalStart + ResourceLength;

@@ -427,7 +427,7 @@ AcceptMemory (
   //

   while (!END_OF_HOB_LIST (Hob)) {

 if (Hob.Header->HobType == EFI_HOB_TYPE_RESOURCE_DESCRIPTOR) {

-  if (Hob.ResourceDescriptor->ResourceType == 
BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED) {

+  if (Hob.ResourceDescriptor->ResourceType == 
EFI_RESOURCE_MEMORY_UNACCEPTED) {

 PhysicalStart = Hob.ResourceDescriptor->PhysicalStart;

 PhysicalEnd   = PhysicalStart + Hob.ResourceDescriptor->ResourceLength;



@@ -563,7 +563,7 @@ ValidateHobList (
 EFI_RESOURCE_MEMORY_MAPPED_IO_PORT,

 EFI_RESOURCE_MEMORY_RESERVED,

 EFI_RESOURCE_IO_RESERVED,

-BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED

+EFI_RESOURCE_MEMORY_UNACCEPTED

   };



   if (VmmHobList == NULL) {

diff --git a/OvmfPkg/Library/PeilessStartupLib/Hob.c 
b/OvmfPkg/Library/PeilessStartupLib/Hob.c
index 318b74c95d..725927da73 100644
--- a/OvmfPkg/Library/PeilessStartupLib/Hob.c
+++ b/OvmfPkg/Library/PeilessStartupLib/Hob.c
@@ -20,7 +20,7 @@
 #include 

 #include 

 #include 

-#include 

+#include 

 #include "PeilessStartupInternal.h"



 /**

@@ -92,7 +92,7 @@ ConstructFwHobList (
   //

   while (!END_OF_HOB_LIST (Hob)) {

 if (Hob.Header->HobType == EFI_HOB_TYPE_RESOURCE_DESCRIPTOR) {

-  if (Hob.ResourceDescriptor->ResourceType == 
BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED) {

+  if (Hob.ResourceDescriptor->ResourceType == 
EFI_RESOURCE_MEMORY_UNACCEPTED) {

 PhysicalEnd= Hob.ResourceDescriptor->PhysicalStart + 
Hob.ResourceDescriptor->ResourceLength;

 ResourceLength = Hob.ResourceDescriptor->ResourceLength;



diff --git a/OvmfPkg/Library/PlatformInitLib/IntelTdx.c 
b/OvmfPkg/Library/PlatformInitLib/IntelTdx.c
index ada8592ddd..e561cee30b 100644
--- a/OvmfPkg/Library/PlatformInitLib/IntelTdx.c
+++ b/OvmfPkg/Library/PlatformInitLib/IntelTdx.c
@@ -17,7 +17,7 @@
 #include 

 #include 

 #include 

-#include 

+#include 

 #include 

 #include 



@@ -40,9 +40,9 @@ BuildResourceDescriptorHobForUnacceptedMemory (
   EFI_RESOURCE_ATTRIBUTE_TYPE  ResourceAttribute;

   UINT64   MaxAcceptedMemoryAddress;



-  ASSERT (Hob->ResourceType == BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED);

+  ASSERT (Hob->ResourceType == EFI_RESOURCE_MEMORY_UNACCEPTED);



-  ResourceType  = BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED;

+  ResourceType  = EFI_RESOURCE_MEMORY_UNACCEPTED;

   ResourceAttribute = Hob->ResourceAttribute;

   PhysicalStart = Hob->PhysicalStart;

   ResourceLength= Hob->ResourceLength;

@@ -104,7 +104,7 @@ TransferTdxHobList (
 ResourceType  = Hob.ResourceDescriptor->ResourceType;

 ResourceAttribute = Hob.ResourceDescriptor->ResourceAttribute;



-if (ResourceType == BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED) {

+if (ResourceType == EFI_RESOURCE_MEMORY_UNACCEPTED) {

[edk2-devel] [PATCH 5/7] MdePkg: Update Delayed Dispatch PPI as per PI 1.8 Spec

2024-04-19 Thread Sachin Ganesh via groups.io

Added WaitOnEvent() function to EFI_DELAYTED_DISPATCH_PPI.
Modified DispatchRegister() parameter list.

Cc: Felix Polyudov 
Cc: Dhanaraj V 
Cc: Liming Gao 
Signed-off-by: Sachin Ganesh 
---
 MdePkg/Include/Ppi/DelayedDispatch.h | 24 +++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/MdePkg/Include/Ppi/DelayedDispatch.h 
b/MdePkg/Include/Ppi/DelayedDispatch.h
index f9b4fed30f..1c2068404c 100644
--- a/MdePkg/Include/Ppi/DelayedDispatch.h
+++ b/MdePkg/Include/Ppi/DelayedDispatch.h
@@ -49,6 +49,7 @@ This service is the single member function of the 
EFI_DELAYED_DISPATCH_PPI
   @param This   Pointer to the EFI_DELAYED_DISPATCH_PPI instance

   @param Function   Function to call back

   @param ContextContext data

+  @param UniqueId   UniqueId

   @param Delay  Delay interval



   @retval EFI_SUCCESS   Function successfully loaded

@@ -62,9 +63,29 @@ EFI_STATUS
   IN  EFI_DELAYED_DISPATCH_PPI  *This,

   IN  EFI_DELAYED_DISPATCH_FUNCTION  Function,

   IN  UINT64 Context,

+  IN  EFI_GUID   *UniqueId  OPTIONAL,

   OUT UINT32 Delay

   );



+/**

+Function invoked by a PEIM to wait until all specified UniqueId events have 
been dispatched. The other events

+will continue to dispatch while this process is being paused

+

+  @param This   Pointer to the EFI_DELAYED_DISPATCH_PPI instance

+  @param UniqueId   Delayed dispatch request ID the caller will wait on

+

+  @retval EFI_SUCCESS   Function successfully invoked

+  @retval EFI_INVALID_PARAMETER One of the Arguments is not supported

+

+**/

+

+typedef

+EFI_STATUS

+(EFIAPI *EFI_DELAYED_DISPATCH_WAIT_ON_EVENT)(

+  IN EFI_DELAYED_DISPATCH_PPI  *This,

+  IN EFI_GUID  UniqueId

+  );

+

 ///

 /// This PPI is a pointer to the Delayed Dispatch Service.

 /// This service will be published by the Pei Foundation. The PEI Foundation

@@ -72,7 +93,8 @@ EFI_STATUS
 /// execution.

 ///

 struct _EFI_DELAYED_DISPATCH_PPI {

-  EFI_DELAYED_DISPATCH_REGISTERRegister;

+  EFI_DELAYED_DISPATCH_REGISTER Register;

+  EFI_DELAYED_DISPATCH_WAIT_ON_EVENTWaitOnEvent;

 };



 extern EFI_GUID  gEfiPeiDelayedDispatchPpiGuid;

--
2.24.1.windows.2
-The information contained in this message may be confidential and proprietary 
to American Megatrends (AMI). This communication is intended to be read only by 
the individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any distribution of this message, in any form, is strictly prohibited. Please 
promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and 
then delete or destroy all copies of the transmission.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118045): https://edk2.groups.io/g/devel/message/118045
Mute This Topic: https://groups.io/mt/105630624/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 6/7] MdePkg: Update to PI 1.8 Revision

2024-04-19 Thread Sachin Ganesh via groups.io

Revision macros have been updated to indicate PI 1.8 specification
support

Cc: Felix Polyudov 
Cc: Dhanaraj V 
Cc: Liming Gao 
Signed-off-by: Sachin Ganesh 
---
 MdePkg/Include/Pi/PiDxeCis.h | 6 +++---
 MdePkg/Include/Pi/PiMmCis.h  | 6 +++---
 MdePkg/Include/Pi/PiMultiPhase.h | 6 ++
 MdePkg/Include/Pi/PiPeiCis.h | 6 +++---
 MdePkg/Include/Pi/PiSmmCis.h | 2 +-
 5 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/MdePkg/Include/Pi/PiDxeCis.h b/MdePkg/Include/Pi/PiDxeCis.h
index 04410c5a1a..9afeaddeae 100644
--- a/MdePkg/Include/Pi/PiDxeCis.h
+++ b/MdePkg/Include/Pi/PiDxeCis.h
@@ -5,7 +5,7 @@ Copyright (c) 2006 - 2018, Intel Corporation. All rights 
reserved.
 SPDX-License-Identifier: BSD-2-Clause-Patent



   @par Revision Reference:

-  PI Version 1.7

+  PI Version 1.8



 **/



@@ -691,8 +691,8 @@ EFI_STATUS
 // DXE Services Table

 //

 #define DXE_SERVICES_SIGNATURE0x565245535f455844ULL

-#define DXE_SPECIFICATION_MAJOR_REVISION  1

-#define DXE_SPECIFICATION_MINOR_REVISION  70

+#define DXE_SPECIFICATION_MAJOR_REVISION  PI_SPECIFICATION_MAJOR_REVISION

+#define DXE_SPECIFICATION_MINOR_REVISION  PI_SPECIFICATION_MINOR_REVISION

 #define DXE_SERVICES_REVISION 
((DXE_SPECIFICATION_MAJOR_REVISION<<16) | (DXE_SPECIFICATION_MINOR_REVISION))



 typedef struct {

diff --git a/MdePkg/Include/Pi/PiMmCis.h b/MdePkg/Include/Pi/PiMmCis.h
index 01340952d8..7a9f151e59 100644
--- a/MdePkg/Include/Pi/PiMmCis.h
+++ b/MdePkg/Include/Pi/PiMmCis.h
@@ -20,10 +20,10 @@ typedef struct _EFI_MM_SYSTEM_TABLE EFI_MM_SYSTEM_TABLE;
 ///

 #define MM_MMST_SIGNATURE  SIGNATURE_32 ('S', 'M', 'S', 'T')

 ///

-/// The Management Mode System Table (MMST) revision is 1.6

+/// The Management Mode System Table (MMST) revision

 ///

-#define MM_SPECIFICATION_MAJOR_REVISION  1

-#define MM_SPECIFICATION_MINOR_REVISION  60

+#define MM_SPECIFICATION_MAJOR_REVISION  PI_SPECIFICATION_MAJOR_REVISION

+#define MM_SPECIFICATION_MINOR_REVISION  PI_SPECIFICATION_MINOR_REVISION

 #define EFI_MM_SYSTEM_TABLE_REVISION 
((MM_SPECIFICATION_MAJOR_REVISION<<16) | (MM_SPECIFICATION_MINOR_REVISION))



 /**

diff --git a/MdePkg/Include/Pi/PiMultiPhase.h b/MdePkg/Include/Pi/PiMultiPhase.h
index a7e95820ef..863a839601 100644
--- a/MdePkg/Include/Pi/PiMultiPhase.h
+++ b/MdePkg/Include/Pi/PiMultiPhase.h
@@ -20,6 +20,12 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 #include 

 #include 



+//

+// PI Specification Revision information

+//

+#define PI_SPECIFICATION_MAJOR_REVISION  1

+#define PI_SPECIFICATION_MINOR_REVISION  80

+

 /**

   Produces an error code in the range reserved for use by the Platform 
Initialization

   Architecture Specification.

diff --git a/MdePkg/Include/Pi/PiPeiCis.h b/MdePkg/Include/Pi/PiPeiCis.h
index 69eec2c473..0ba013e664 100644
--- a/MdePkg/Include/Pi/PiPeiCis.h
+++ b/MdePkg/Include/Pi/PiPeiCis.h
@@ -5,7 +5,7 @@ Copyright (c) 2006 - 2019, Intel Corporation. All rights 
reserved.
 SPDX-License-Identifier: BSD-2-Clause-Patent



   @par Revision Reference:

-  PI Version 1.7.

+  PI Version 1.8.



 **/



@@ -846,8 +846,8 @@ EFI_STATUS
 //

 // PEI Specification Revision information

 //

-#define PEI_SPECIFICATION_MAJOR_REVISION  1

-#define PEI_SPECIFICATION_MINOR_REVISION  70

+#define PEI_SPECIFICATION_MAJOR_REVISION  PI_SPECIFICATION_MAJOR_REVISION

+#define PEI_SPECIFICATION_MINOR_REVISION  PI_SPECIFICATION_MINOR_REVISION

 ///

 /// Specification inconsistency here:

 /// In the PI1.0 spec, PEI_SERVICES_SIGNATURE is defined as 
0x5652455320494550. But

diff --git a/MdePkg/Include/Pi/PiSmmCis.h b/MdePkg/Include/Pi/PiSmmCis.h
index bf5b580c32..886b5e4a38 100644
--- a/MdePkg/Include/Pi/PiSmmCis.h
+++ b/MdePkg/Include/Pi/PiSmmCis.h
@@ -15,7 +15,7 @@


 typedef struct _EFI_SMM_SYSTEM_TABLE2 EFI_SMM_SYSTEM_TABLE2;

 //

-// Define new MM related definition introduced by PI 1.5.

+// MM related definitions

 //

 #define  SMM_SMST_SIGNATUREMM_MMST_SIGNATURE

 #define  SMM_SPECIFICATION_MAJOR_REVISION  MM_SPECIFICATION_MAJOR_REVISION

--
2.24.1.windows.2
-The information contained in this message may be confidential and proprietary 
to American Megatrends (AMI). This communication is intended to be read only by 
the individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any distribution of this message, in any form, is strictly prohibited. Please 
promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and 
then delete or destroy all copies of the transmission.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118046): https://edk2.groups.io/g/devel/message/118046
Mute This Topic: https://groups.io/mt/105630625/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 2/7] MdePkg: Add new Resource Attributes defined in PI 1.8 Spec

2024-04-19 Thread Sachin Ganesh via groups.io

Defined Encrypted and Special Purpose resource attributes as
defined in PI 1.8 Specification

Cc: Felix Polyudov 
Cc: Dhanaraj V 
Cc: Liming Gao 
Signed-off-by: Sachin Ganesh 
---
 MdePkg/Include/Pi/PiHob.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MdePkg/Include/Pi/PiHob.h b/MdePkg/Include/Pi/PiHob.h
index 4605da56e2..f730520e8c 100644
--- a/MdePkg/Include/Pi/PiHob.h
+++ b/MdePkg/Include/Pi/PiHob.h
@@ -297,6 +297,8 @@ typedef UINT32 EFI_RESOURCE_ATTRIBUTE_TYPE;
 #define EFI_RESOURCE_ATTRIBUTE_READ_ONLY_PROTECTED0x0004

 #define EFI_RESOURCE_ATTRIBUTE_READ_ONLY_PROTECTABLE  0x0008



+#define EFI_RESOURCE_ATTRIBUTE_ENCRYPTED0x0400

+#define EFI_RESOURCE_ATTRIBUTE_SPECIAL_PURPOSE  0x0800

 //

 // Physical memory relative reliability attribute. This

 // memory provides higher reliability relative to other

--
2.24.1.windows.2
-The information contained in this message may be confidential and proprietary 
to American Megatrends (AMI). This communication is intended to be read only by 
the individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any distribution of this message, in any form, is strictly prohibited. Please 
promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and 
then delete or destroy all copies of the transmission.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118042): https://edk2.groups.io/g/devel/message/118042
Mute This Topic: https://groups.io/mt/105630620/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 3/7] MdePkg: Define Unaccepted Memory Type

2024-04-19 Thread Sachin Ganesh via groups.io

EFI_RESOURCE_MEMORY_UNACCEPTED has been officially defined in the PI
1.8 specification. So all temporary solutions have been replaced with
the actual definition.

Cc: Felix Polyudov 
Cc: Dhanaraj V 
Cc: Liming Gao 
Signed-off-by: Sachin Ganesh 
---
 MdePkg/Include/Pi/PiDxeCis.h | 13 +
 MdePkg/Include/Pi/PiHob.h| 12 ++--
 2 files changed, 7 insertions(+), 18 deletions(-)

diff --git a/MdePkg/Include/Pi/PiDxeCis.h b/MdePkg/Include/Pi/PiDxeCis.h
index bb7fb2c38a..04410c5a1a 100644
--- a/MdePkg/Include/Pi/PiDxeCis.h
+++ b/MdePkg/Include/Pi/PiDxeCis.h
@@ -56,14 +56,11 @@ typedef enum {
   /// system. If all memory has the same reliability, then this bit is not 
used.

   ///

   EfiGcdMemoryTypeMoreReliable,

-  // ///

-  // /// A memory region that describes system memory that has not been 
accepted

-  // /// by a corresponding call to the underlying isolation architecture.

-  // ///

-  // /// Please be noted:

-  // /// EfiGcdMemoryTypeUnaccepted is defined in PrePiDxeCis.h because it has 
not been

-  // /// defined in PI spec.

-  // EfiGcdMemoryTypeUnaccepted,

+  ///

+  /// A memory region that describes system memory that has not been accepted

+  /// by a corresponding call to the underlying isolation architecture.

+  ///

+  EfiGcdMemoryTypeUnaccepted,

   EfiGcdMemoryTypeMaximum = 7

 } EFI_GCD_MEMORY_TYPE;



diff --git a/MdePkg/Include/Pi/PiHob.h b/MdePkg/Include/Pi/PiHob.h
index f730520e8c..9e49421afa 100644
--- a/MdePkg/Include/Pi/PiHob.h
+++ b/MdePkg/Include/Pi/PiHob.h
@@ -232,16 +232,8 @@ typedef UINT32 EFI_RESOURCE_TYPE;
 #define EFI_RESOURCE_MEMORY_MAPPED_IO_PORT  0x0004

 #define EFI_RESOURCE_MEMORY_RESERVED0x0005

 #define EFI_RESOURCE_IO_RESERVED0x0006

-//

-// BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED is defined for unaccepted memory.

-// But this defitinion has not been officially in the PI spec. Base

-// on the code-first we define BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED at

-// MdeModulePkg/Include/Pi/PrePiHob.h and update EFI_RESOURCE_MAX_MEMORY_TYPE

-// to 8. After BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED is officially published

-// in PI spec, we will re-visit here.

-//

-// #define BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED  0x0007

-#define EFI_RESOURCE_MAX_MEMORY_TYPE  0x0008

+#define EFI_RESOURCE_MEMORY_UNACCEPTED  0x0007

+#define EFI_RESOURCE_MAX_MEMORY_TYPE0x0008



 ///

 /// A type of recount attribute type.

--
2.24.1.windows.2
-The information contained in this message may be confidential and proprietary 
to American Megatrends (AMI). This communication is intended to be read only by 
the individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any distribution of this message, in any form, is strictly prohibited. Please 
promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and 
then delete or destroy all copies of the transmission.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118043): https://edk2.groups.io/g/devel/message/118043
Mute This Topic: https://groups.io/mt/105630622/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 4/7] MdeModulePkg: Use newly defined Unaccepted Memory Type

2024-04-19 Thread Sachin Ganesh via groups.io

EFI_RESOURCE_MEMORY_UNACCEPTED has been officially defined in the PI
1.8 specification. So all temporary solutions have been replaced with
the actual definition.

Cc: Felix Polyudov 
Cc: Dhanaraj V 
Cc: Liming Gao 
Signed-off-by: Sachin Ganesh 
---
 MdeModulePkg/Core/Dxe/Gcd/Gcd.c   | 10 +++
 MdeModulePkg/Core/Dxe/Mem/Page.c  | 38 +--
 MdeModulePkg/Include/Pi/PrePiDxeCis.h | 25 --
 MdeModulePkg/Include/Pi/PrePiHob.h| 20 --
 4 files changed, 24 insertions(+), 69 deletions(-)
 delete mode 100644 MdeModulePkg/Include/Pi/PrePiDxeCis.h
 delete mode 100644 MdeModulePkg/Include/Pi/PrePiHob.h

diff --git a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
index c450d1bf25..fe1bbd6974 100644
--- a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
+++ b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
@@ -8,8 +8,8 @@ SPDX-License-Identifier: BSD-2-Clause-Patent


 **/



-#include 

-#include 

+#include 

+#include 

 #include "DxeMain.h"

 #include "Gcd.h"

 #include "Mem/HeapGuard.h"

@@ -105,7 +105,7 @@ GLOBAL_REMOVE_IF_UNREFERENCED CONST CHAR8  
*mGcdMemoryTypeNames[] = {
   "MMIO ",  // EfiGcdMemoryTypeMemoryMappedIo

   "PersisMem",  // EfiGcdMemoryTypePersistent

   "MoreRelia",  // EfiGcdMemoryTypeMoreReliable

-  "Unaccepte",  // EFI_GCD_MEMORY_TYPE_UNACCEPTED

+  "Unaccepte",  // EfiGcdMemoryTypeUnaccepted

   "Unknown  "   // EfiGcdMemoryTypeMaximum

 };



@@ -2669,8 +2669,8 @@ CoreInitializeGcdServices (
 case EFI_RESOURCE_MEMORY_RESERVED:

   GcdMemoryType = EfiGcdMemoryTypeReserved;

   break;

-case BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED:

-  GcdMemoryType = EFI_GCD_MEMORY_TYPE_UNACCEPTED;

+case EFI_RESOURCE_MEMORY_UNACCEPTED:

+  GcdMemoryType = EfiGcdMemoryTypeUnaccepted;

   break;

 case EFI_RESOURCE_IO:

   GcdIoType = EfiGcdIoTypeIo;

diff --git a/MdeModulePkg/Core/Dxe/Mem/Page.c b/MdeModulePkg/Core/Dxe/Mem/Page.c
index 26584648c2..5a51d9df1a 100644
--- a/MdeModulePkg/Core/Dxe/Mem/Page.c
+++ b/MdeModulePkg/Core/Dxe/Mem/Page.c
@@ -9,7 +9,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 #include "DxeMain.h"

 #include "Imem.h"

 #include "HeapGuard.h"

-#include 

+#include 



 //

 // Entry for tracking the memory regions for each memory type to coalesce 
similar memory types

@@ -70,23 +70,23 @@ EFI_PHYSICAL_ADDRESS  mDefaultMaximumAddress = 
MAX_ALLOC_ADDRESS;
 EFI_PHYSICAL_ADDRESS  mDefaultBaseAddress= MAX_ALLOC_ADDRESS;



 EFI_MEMORY_TYPE_INFORMATION  gMemoryTypeInformation[EfiMaxMemoryType + 1] = {

-  { EfiReservedMemoryType,  0 },

-  { EfiLoaderCode,  0 },

-  { EfiLoaderData,  0 },

-  { EfiBootServicesCode,0 },

-  { EfiBootServicesData,0 },

-  { EfiRuntimeServicesCode, 0 },

-  { EfiRuntimeServicesData, 0 },

-  { EfiConventionalMemory,  0 },

-  { EfiUnusableMemory,  0 },

-  { EfiACPIReclaimMemory,   0 },

-  { EfiACPIMemoryNVS,   0 },

-  { EfiMemoryMappedIO,  0 },

-  { EfiMemoryMappedIOPortSpace, 0 },

-  { EfiPalCode, 0 },

-  { EfiPersistentMemory,0 },

-  { EFI_GCD_MEMORY_TYPE_UNACCEPTED, 0 },

-  { EfiMaxMemoryType,   0 }

+  { EfiReservedMemoryType,  0 },

+  { EfiLoaderCode,  0 },

+  { EfiLoaderData,  0 },

+  { EfiBootServicesCode,0 },

+  { EfiBootServicesData,0 },

+  { EfiRuntimeServicesCode, 0 },

+  { EfiRuntimeServicesData, 0 },

+  { EfiConventionalMemory,  0 },

+  { EfiUnusableMemory,  0 },

+  { EfiACPIReclaimMemory,   0 },

+  { EfiACPIMemoryNVS,   0 },

+  { EfiMemoryMappedIO,  0 },

+  { EfiMemoryMappedIOPortSpace, 0 },

+  { EfiPalCode, 0 },

+  { EfiPersistentMemory,0 },

+  { EfiGcdMemoryTypeUnaccepted, 0 },

+  { EfiMaxMemoryType,   0 }

 };

 //

 // Only used when load module at fixed address feature is enabled. True means 
the memory is alreay successfully allocated

@@ -2083,7 +2083,7 @@ CoreGetMemoryMap (
   MemoryMap = MergeMemoryMapDescriptor (MemoryMapStart, MemoryMap, Size);

 }



-if (MergeGcdMapEntry.GcdMemoryType == EFI_GCD_MEMORY_TYPE_UNACCEPTED) {

+if (MergeGcdMapEntry.GcdMemoryType == EfiGcdMemoryTypeUnaccepted) {

   //

   // Page Align GCD range is required. When it is converted to 
EFI_MEMORY_DESCRIPTOR,

   // it will be recorded as page PhysicalStart and NumberOfPages.

diff --git a/MdeModulePkg/Include/Pi/PrePiDxeCis.h 
b/MdeModulePkg/Include/Pi/PrePiDxeCis.h
deleted file mode 100644
index 9be71d2618..00
--- a/MdeModulePkg/Include/Pi/PrePiDxeCis.h
+++ /dev/null
@@ -1,25 +0,0 @@
-/** @file

-  Include file matches things in PI.

-

-Copyright (c) 2022, Intel Corporation. All rights reserved.

-SPDX-License-Identifier: BSD-2-Clause-Patent

-

-**/

-

-#ifndef

[edk2-devel] [PATCH 1/7] MdePkg: Add definition for NVMe Over Fabric Device Path

2024-04-19 Thread Sachin Ganesh via groups.io

In accordance with UEFI 2.10 Specification:
Adding definition for NVMe Over Fabric (NVMe-oF) Device Path
of Messaging Sub-Type.

Cc: Felix Polyudov 
Cc: Dhanaraj V 
Cc: Liming Gao 
Signed-off-by: Sachin Ganesh 
---
 MdePkg/Include/Protocol/DevicePath.h | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/MdePkg/Include/Protocol/DevicePath.h 
b/MdePkg/Include/Protocol/DevicePath.h
index 9060dd782e..35008ddcdf 100644
--- a/MdePkg/Include/Protocol/DevicePath.h
+++ b/MdePkg/Include/Protocol/DevicePath.h
@@ -837,6 +837,26 @@ typedef struct {
   UINT64  NamespaceUuid;

 } NVME_NAMESPACE_DEVICE_PATH;



+///

+/// NVMe over Fabric (NVMe-oF) Namespace Device Path SubType.

+///

+#define MSG_NVME_OF_NAMESPACE_DP  0x22

+typedef struct {

+  EFI_DEVICE_PATH_PROTOCOLHeader;

+  ///

+  /// Namespace Identifier Type (NIDT)

+  ///

+  UINT8   NamespaceIdType;

+  ///

+  /// Namespace Identifier (NID)

+  ///

+  UINT8   NamespaceId[16];

+  ///

+  /// Unique identifier of an NVM subsystem

+  ///

+  CHAR8   SubsystemNqn[];

+} NVME_OF_NAMESPACE_DEVICE_PATH;

+

 ///

 /// DNS Device Path SubType

 ///

@@ -1287,6 +1307,7 @@ typedef union {
   SAS_DEVICE_PATHSas;

   SASEX_DEVICE_PATH  SasEx;

   NVME_NAMESPACE_DEVICE_PATH NvmeNamespace;

+  NVME_OF_NAMESPACE_DEVICE_PATH  NvmeOfNamespace;

   DNS_DEVICE_PATHDns;

   URI_DEVICE_PATHUri;

   BLUETOOTH_DEVICE_PATH  Bluetooth;

@@ -1343,6 +1364,7 @@ typedef union {
   SAS_DEVICE_PATH*Sas;

   SASEX_DEVICE_PATH  *SasEx;

   NVME_NAMESPACE_DEVICE_PATH *NvmeNamespace;

+  NVME_OF_NAMESPACE_DEVICE_PATH  *NvmeOfNamespace;

   DNS_DEVICE_PATH*Dns;

   URI_DEVICE_PATH*Uri;

   BLUETOOTH_DEVICE_PATH  *Bluetooth;

--
2.24.1.windows.2
-The information contained in this message may be confidential and proprietary 
to American Megatrends (AMI). This communication is intended to be read only by 
the individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any distribution of this message, in any form, is strictly prohibited. Please 
promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and 
then delete or destroy all copies of the transmission.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118041): https://edk2.groups.io/g/devel/message/118041
Mute This Topic: https://groups.io/mt/105630619/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 0/7] General Updates based on UEFI 2.10 and PI 1.8 Specification

2024-04-19 Thread Sachin Ganesh via groups.io

This series of patches are for general updates to MdePkg and MdeModulePkg based 
on
UEFI 2.10 and PI 1.8 Specifications

Sachin Ganesh (7):
  MdePkg: Add definition for NVMe Over Fabric Device Path
  MdePkg: Add new Resource Attributes defined in PI 1.8 Spec
  MdePkg: Define Unaccepted Memory Type
  MdeModulePkg: Use newly defined Unaccepted Memory Type
  MdePkg: Update Delayed Dispatch PPI as per PI 1.8 Spec
  MdePkg: Update to PI 1.8 Revision
  OvmfPkg: Use newly defined Unaccepted Memory Type

 MdeModulePkg/Core/Dxe/Gcd/Gcd.c  | 10 +++---
 MdeModulePkg/Core/Dxe/Mem/Page.c | 38 ++--
 MdeModulePkg/Include/Pi/PrePiDxeCis.h| 25 -
 MdeModulePkg/Include/Pi/PrePiHob.h   | 20 ---
 MdePkg/Include/Pi/PiDxeCis.h | 19 +-
 MdePkg/Include/Pi/PiHob.h| 14 +++-
 MdePkg/Include/Pi/PiMmCis.h  |  6 ++--
 MdePkg/Include/Pi/PiMultiPhase.h |  6 
 MdePkg/Include/Pi/PiPeiCis.h |  6 ++--
 MdePkg/Include/Pi/PiSmmCis.h |  2 +-
 MdePkg/Include/Ppi/DelayedDispatch.h | 24 -
 MdePkg/Include/Protocol/DevicePath.h | 22 
 OvmfPkg/AmdSevDxe/AmdSevDxe.c|  4 +--
 OvmfPkg/IntelTdx/TdxHelperLib/SecTdxHelper.c |  8 ++---
 OvmfPkg/Library/PeilessStartupLib/Hob.c  |  4 +--
 OvmfPkg/Library/PlatformInitLib/IntelTdx.c   |  8 ++---
 OvmfPkg/PlatformPei/AmdSev.c |  4 +--
 17 files changed, 108 insertions(+), 112 deletions(-)
 delete mode 100644 MdeModulePkg/Include/Pi/PrePiDxeCis.h
 delete mode 100644 MdeModulePkg/Include/Pi/PrePiHob.h

--
2.24.1.windows.2
-The information contained in this message may be confidential and proprietary 
to American Megatrends (AMI). This communication is intended to be read only by 
the individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any distribution of this message, in any form, is strictly prohibited. Please 
promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and 
then delete or destroy all copies of the transmission.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118040): https://edk2.groups.io/g/devel/message/118040
Mute This Topic: https://groups.io/mt/105630618/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH] ArmVirtPkg/ArmVirtQemu: always build XIP code with strict alignment

2024-04-19 Thread Ard Biesheuvel via groups.io

From: Ard Biesheuvel 

The optimization that enabled entry with MMU and caches enabled at EL1
removed the strict alignment requirement for XIP code (roughly, any code
that might execute with the MMU and caches off, which means SEC and PEI
phase modules but also *all* BASE libraries), on the basis that QEMU can
only run guest payloads at EL2 in TCG emulation, which used to ignore
alignment violations, and execution at EL1 would always occur with the
MMU enabled.

This assumption no longer holds: not only does QEMU now enforce strict
alignment for memory accesses with device semantics, there are also
cases where this code might execute at EL2 under virtualization (i.e.,
under NV2 nested virtualization) where the strict alignment is required
too.

The latter case could be optimized too, by enabling VHE and pretending
execution is occurring at EL1, which would allow the existing logic for
entry with the MMU enabled to be reused. However, this would leave
non-VHE CPUs behind.

So in summary, strict alignment needs to be enforced for any code that
may execute with the MMU off, so drop the override that sets the XIP
flags to the empty string.

Cc: Jonathan Cameron 
Cc: Richard Henderson 
Cc: Philippe Mathieu-Daud� 
Cc: Idan Horowitz 
Cc: qemu-...@nongnu.org
Signed-off-by: Ard Biesheuvel 
---
 ArmVirtPkg/ArmVirtQemu.dsc | 2 --
 1 file changed, 2 deletions(-)

diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index e48c75b5e99f..f6f78359552d 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -124,8 +124,6 @@ [LibraryClasses.common.UEFI_DRIVER]
 [BuildOptions]

 !if $(CAVIUM_ERRATUM_27456) == TRUE

   GCC:*_*_AARCH64_PP_FLAGS = -DCAVIUM_ERRATUM_27456

-!else

-  GCC:*_*_AARCH64_CC_XIPFLAGS ==

 !endif

 

 !include NetworkPkg/NetworkBuildOptions.dsc.inc

--
2.44.0.769.g3c40516874-goog



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118039): https://edk2.groups.io/g/devel/message/118039
Mute This Topic: https://groups.io/mt/105630615/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v2] OvmfPkg: Harden #VC instruction emulation somewhat (CVE-2024-25742)

2024-04-19 Thread Adam Dunlap via groups.io

Ensure that when a #VC exception happens, the instruction at the
instruction pointer matches the instruction that is expected given the
error code. This is to mitigate the ahoi WeSee attack [1] that could
allow hypervisors to breach integrity and confidentiality of the
firmware by maliciously injecting interrupts. This change is a
translated version of a linux patch e3ef461af35a ("x86/sev: Harden #VC
instruction emulation somewhat")

[1] https://ahoi-attacks.github.io/wesee/

Cc: Borislav Petkov (AMD) 
Cc: Tom Lendacky 
Signed-off-by: Adam Dunlap 
---

Patch changelog:
V1 -> V2: Added the MWAITX/MONITORX opcodes. Added the opcode for INVD.
Added a comment to explain skipping the exit handling if the opcode does
not match.

 OvmfPkg/Library/CcExitLib/CcExitVcHandler.c | 184 ++--
 1 file changed, 173 insertions(+), 11 deletions(-)

diff --git a/OvmfPkg/Library/CcExitLib/CcExitVcHandler.c 
b/OvmfPkg/Library/CcExitLib/CcExitVcHandler.c
index 0fc30f7bc4..31587586fe 100644
--- a/OvmfPkg/Library/CcExitLib/CcExitVcHandler.c
+++ b/OvmfPkg/Library/CcExitLib/CcExitVcHandler.c
@@ -532,8 +532,6 @@ MwaitExit (
   IN CC_INSTRUCTION_DATA *InstructionData
   )
 {
-  CcDecodeModRm (Regs, InstructionData);
-
   Ghcb->SaveArea.Rax = Regs->Rax;
   CcExitVmgSetOffsetValid (Ghcb, GhcbRax);
   Ghcb->SaveArea.Rcx = Regs->Rcx;
@@ -564,8 +562,6 @@ MonitorExit (
   IN CC_INSTRUCTION_DATA *InstructionData
   )
 {
-  CcDecodeModRm (Regs, InstructionData);
-
   Ghcb->SaveArea.Rax = Regs->Rax;  // Identity mapped, so VA = PA
   CcExitVmgSetOffsetValid (Ghcb, GhcbRax);
   Ghcb->SaveArea.Rcx = Regs->Rcx;
@@ -670,8 +666,6 @@ VmmCallExit (
 {
   UINT64  Status;
 
-  CcDecodeModRm (Regs, InstructionData);
-
   Ghcb->SaveArea.Rax = Regs->Rax;
   CcExitVmgSetOffsetValid (Ghcb, GhcbRax);
   Ghcb->SaveArea.Cpl = (UINT8)(Regs->Cs & 0x3);
@@ -1603,8 +1597,6 @@ Dr7WriteExit (
   Ext   = >Ext;
   SevEsData = (SEV_ES_PER_CPU_DATA *)(Ghcb + 1);
 
-  CcDecodeModRm (Regs, InstructionData);
-
   //
   // MOV DRn always treats MOD == 3 no matter how encoded
   //
@@ -1655,8 +1647,6 @@ Dr7ReadExit (
   Ext   = >Ext;
   SevEsData = (SEV_ES_PER_CPU_DATA *)(Ghcb + 1);
 
-  CcDecodeModRm (Regs, InstructionData);
-
   //
   // MOV DRn always treats MOD == 3 no matter how encoded
   //
@@ -1671,6 +1661,170 @@ Dr7ReadExit (
   return 0;
 }
 
+/**
+  Check that the opcode matches the exit code for a #VC.
+
+  Each exit code should only be raised while executing certain instructions.
+  Verify that rIP points to a correct instruction based on the exit code to
+  protect against maliciously injected interrupts via the hypervisor. If it 
does
+  not, report an unsupported event to the hypervisor.
+
+  Decodes the ModRm byte into InstructionData if necessary.
+
+  @param[in, out] Ghcb Pointer to the Guest-Hypervisor 
Communication
+   Block
+  @param[in, out] Regs x64 processor context
+  @param[in, out] InstructionData  Instruction parsing context
+  @param[in]  ExitCode Exit code given by #VC.
+
+  @retval 0No problems detected.
+  @return  New exception value to propagate
+
+
+**/
+STATIC
+UINT64
+VcCheckOpcodeBytes (
+  IN OUT GHCB*Ghcb,
+  IN OUT EFI_SYSTEM_CONTEXT_X64  *Regs,
+  IN OUT CC_INSTRUCTION_DATA *InstructionData,
+  IN UINT64  ExitCode
+  )
+{
+  UINT8  OpCode;
+
+  //
+  // Expected opcodes are either 1 or 2 bytes. If they are 2 bytes, they always
+  // start with TWO_BYTE_OPCODE_ESCAPE (0x0f), so skip over that.
+  //
+  OpCode = *(InstructionData->OpCodes);
+  if (OpCode == TWO_BYTE_OPCODE_ESCAPE) {
+OpCode = *(InstructionData->OpCodes + 1);
+  }
+
+  switch (ExitCode) {
+case SVM_EXIT_IOIO_PROT:
+case SVM_EXIT_NPF:
+  /* handled separately */
+  return 0;
+
+case SVM_EXIT_CPUID:
+  if (OpCode == 0xa2) {
+return 0;
+  }
+
+  break;
+
+case SVM_EXIT_INVD:
+  if (OpCode == 0x08) {
+return 0;
+  }
+
+  break;
+
+case SVM_EXIT_MONITOR:
+  CcDecodeModRm (Regs, InstructionData);
+
+  if ((OpCode == 0x01) &&
+  (  (InstructionData->ModRm.Uint8 == 0xc8)   /* MONITOR */
+  || (InstructionData->ModRm.Uint8 == 0xfa))) /* MONITORX */
+  {
+return 0;
+  }
+
+  break;
+
+case SVM_EXIT_MWAIT:
+  CcDecodeModRm (Regs, InstructionData);
+
+  if ((OpCode == 0x01) &&
+  (  (InstructionData->ModRm.Uint8 == 0xc9)   /* MWAIT */
+  || (InstructionData->ModRm.Uint8 == 0xfb))) /* MWAITX */
+  {
+return 0;
+  }
+
+  break;
+
+case SVM_EXIT_MSR:
+  /* RDMSR */
+  if ((OpCode == 0x32) ||
+  /* WRMSR */
+  (OpCode == 0x30))
+  {
+return 0;
+  }
+
+  break;
+
+case SVM_EXIT_RDPMC:
+  if (OpCode == 0x33) {
+return 0;
+  }
+
+  break;
+
+case

Re: [edk2-devel] [PATCH] OvmfPkg: Harden #VC instruction emulation somewhat (CVE-2024-25742)

2024-04-19 Thread Adam Dunlap via groups.io

On Fri, Apr 19, 2024 at 8:13 AM Tom Lendacky  wrote:
>
> On 4/17/24 11:54, Adam Dunlap wrote:
> > +
> > +case SVM_EXIT_INVD:
> > +  break;
>
> This changes the current behavior today, but I'm ok with that.
>

Whoops, I should've checked that. Should we delete InvdExit() then, if
it's dead code?

> > +
> > +case SVM_EXIT_MONITOR:
> > +  CcDecodeModRm (Regs, InstructionData);
> > +
> > +  if ((OpCode == 0x01) && (InstructionData->ModRm.Uint8 == 0xc8)) {
>
> This should also handle the MONITORX opcode (hmmm... I need to send a
> patch to the kernel).
>
> > +return 0;
> > +  }
> > +
> > +  break;
> > +
> > +case SVM_EXIT_MWAIT:
> > +  CcDecodeModRm (Regs, InstructionData);
> > +
> > +  if ((OpCode == 0x01) && (InstructionData->ModRm.Uint8 == 0xc9)) {
>
> Same here for MWAITX.
>
> Thanks,
> Tom

Got it! I'll send out a new patch shortly if I can figure out how to
use git send-email correctly.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118037): https://edk2.groups.io/g/devel/message/118037
Mute This Topic: https://groups.io/mt/105581633/21656
Mute #vc:https://edk2.groups.io/g/devel/mutehashtag/vc
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v3 5/6] target/arm: Do memory type alignment check when translation disabled

2024-04-19 Thread Ard Biesheuvel

On Fri, 19 Apr 2024 at 18:36, Ard Biesheuvel  wrote:
>
> On Fri, 19 Apr 2024 at 18:09, Jonathan Cameron via groups.io
>  wrote:
> >
> > On Fri, 19 Apr 2024 13:52:07 +0200
> > Gerd Hoffmann  wrote:
> >
> > >   Hi,
> > >
> > > > Gerd, any ideas?  Maybe I needs something subtly different in my
> > > > edk2 build?  I've not looked at this bit of the qemu infrastructure
> > > > before - is there a document on how that image is built?
> > >
> > > There is roms/Makefile for that.
> > >
> > > make -C roms help
> > > make -C roms efi
> > >
> > > So easiest would be to just update the edk2 submodule to what you
> > > need, then rebuild.
> > >
> > > The build is handled by the roms/edk2-build.py script,
> > > with the build configuration being in roms/edk2-build.config.
> > > That is usable outside the qemu source tree too, i.e. like this:
> > >
> > >   python3 /path/to/qemu.git/roms/edk2-build.py \
> > > --config /path/to/qemu.git/roms/edk2-build.config \
> > > --core /path/to/edk2.git \
> > > --match armvirt \
> > > --silent --no-logs
> > >
> > > That'll try to place the images build in "../pc-bios", so maybe better
> > > work with a copy of the config file where you adjust this.
> > >
> > > HTH,
> > >   Gerd
> > >
> >
> > Thanks Gerd!
> >
> > So the builds are very similar via the two method...
> > However - the QEMU build sets -D CAVIUM_ERRATUM_27456=TRUE
> >
> > And that's the difference - with that set for my other builds the alignment
> > problems go away...
> >
> > Any idea why we have that set in roms/edk2-build.config?
> > Superficially it seems rather unlikely anyone cares about thunderx1
> > (if they do we need to get them some new hardware with fresh bugs)
> > bugs now and this config file was only added last year.
> >
> >
> > However, the last comment in Ard's commit message below seems
> > highly likely to be relevant!
> >
> > Chasing through Ard's patch it has the side effect of dropping
> > an override of a requirement for strict alignment.
> > So with out the errata
> > DEFINE GCC_AARCH64_CC_XIPFLAGS = -mstrict-align -mgeneral-regs-only
> > is replaced with
> >  [BuildOptions]
> > +!if $(CAVIUM_ERRATUM_27456) == TRUE^M
> > +  GCC:*_*_AARCH64_PP_FLAGS = -DCAVIUM_ERRATUM_27456^M
> > +!else^M
> >GCC:*_*_AARCH64_CC_XIPFLAGS ==
> > +!endif^M
> >
> > The edk2 commit that added this was the following +CC Ard.
> >
> > Given I wasn't sure of the syntax of that file I set it
> > manually to the original value and indeed it works.
> >
> >
> > commit ec54ce1f1ab41b92782b37ae59e752fff0ef9c41
> > Author: Ard Biesheuvel 
> > Date:   Wed Jan 4 16:51:35 2023 +0100
> >
> > ArmVirtPkg/ArmVirtQemu: Avoid early ID map on ThunderX
> >
> > The early ID map used by ArmVirtQemu uses ASID scoped non-global
> > mappings, as this allows us to switch to the permanent ID map seamlessly
> > without the need for explicit TLB maintenance.
> >
> > However, this triggers a known erratum on ThunderX, which does not
> > tolerate non-global mappings that are executable at EL1, as this appears
> > to result in I-cache corruption. (Linux disables the KPTI based Meltdown
> > mitigation on ThunderX for the same reason)
> >
> > So work around this, by detecting the CPU implementor and part number,
> > and proceeding without the early ID map if a ThunderX CPU is detected.
> >
> > Note that this requires the C code to be built with strict alignment
> > again, as we may end up executing it with the MMU and caches off.
> >
> > Signed-off-by: Ard Biesheuvel 
> > Acked-by: Laszlo Ersek 
> > Tested-by: dann frazier 
> >
> > Test case is
> > qemu-system-aarch64 -M virt,virtualization=true, -m 4g -cpu cortex-a76 \
> > -bios QEMU_EFI.fd -d int
> >
> > Which gets alignment faults since:
> > https://lore.kernel.org/all/20240301204110.656742-6-richard.hender...@linaro.org/
> >
> > So my feeling here is EDK2 should either have yet another config for QEMU 
> > as a host
> > or should always set the alignment without needing to pick the CAVIUM 27456 
> > errata
> > which I suspect will get dropped soonish anyway if anyone ever cleans up
> > old errata.
> >
>
> This code was never really intended for execution at EL2, but it
> happened to work, partially because TCG's lack of strict alignment
> checking when the MMU is off.
>
> Those assumptions no longer hold, so yes, let's get this fixed properly.
>
> Given VHE and nested virt (which will likely imply VHE in practice), I
> would like to extend this functionality (i.e., the use of preliminary
> page tables in NOR flash) to EL2 as well, but with VHE enabled. This
> means we can still elide TLB maintenance (and BBM checks) by using
> different ASIDs, and otherwise, fall back to entering with the MMU off
> if VHE is not available. In that case, we should enforce strict
> alignment too, so that needs to be fixed regardless.
>
> I'll try to code something up and send it round. In the mean time,
> feel free to propose a minimal

Re: [edk2-devel] [edk2-libc Patch v3 1/1] ek2-libc: wrmsr function available in edk2module is not working as expected

2024-04-19 Thread Michael D Kinney

Reviewed-by: Michael D Kinney 

> -Original Message-
> From: Jayaprakash, N 
> Sent: Friday, April 19, 2024 2:01 AM
> To: devel@edk2.groups.io
> Cc: Jayaprakash, N ; Rebecca Cran
> ; Kinney, Michael D 
> Subject: [edk2-libc Patch v3 1/1] ek2-libc: wrmsr function available
> in edk2module is not working as expected
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4745
> 
> This commit fixes the issue reported in the BZ4745.
> The wrmsr was always writing 0 to the higher 32 bits of the msr
> register.
> This was due to a logical flaw in the code, where the input variable
> of
> type unsigned int was left shitted by 32 bits without explicitly
> converting it to a 64 bit value.
> 
> The issue is with the below statement.
> data = vedx << 32 | veax;
> Where the vedx which is an unsigned int, after left shifting by 32
> bits
> its value will be set to 0. Because of this the higher 32 bits of the
> MSR
> are always set to 0. This has been fixed by this commit.
> 
> Cc: Rebecca Cran 
> Cc: Michael D Kinney 
> Cc: Jayaprakash N 
> Signed-off-by: Jayaprakash N 
> ---
>  .../Python/Python-3.6.8/PyMod-3.6.8/Modules/edk2module.c| 2
> +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/AppPkg/Applications/Python/Python-3.6.8/PyMod-
> 3.6.8/Modules/edk2module.c b/AppPkg/Applications/Python/Python-
> 3.6.8/PyMod-3.6.8/Modules/edk2module.c
> index d6af8da..f688b51 100644
> --- a/AppPkg/Applications/Python/Python-3.6.8/PyMod-
> 3.6.8/Modules/edk2module.c
> +++ b/AppPkg/Applications/Python/Python-3.6.8/PyMod-
> 3.6.8/Modules/edk2module.c
> @@ -3886,7 +3886,7 @@ edk2_wrmsr(PyObject *self, PyObject *args)
>UINT64   data = 0;
>if (!PyArg_ParseTuple(args, "III", , , ))
>  return NULL;
> -  data = vedx << 32 | veax;
> +  data = LShiftU64(vedx, 32) | veax;
>Py_BEGIN_ALLOW_THREADS
>AsmWriteMsr64(vecx, data);
>Py_END_ALLOW_THREADS
> --
> 2.44.0.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118035): https://edk2.groups.io/g/devel/message/118035
Mute This Topic: https://groups.io/mt/105614477/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V3 6/6] Maintainers.txt: Update maintainer for SPI modules

2024-04-19 Thread Michael D Kinney

Reviewed-by: Michael D Kinney 

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Chang,
> Abner via groups.io
> Sent: Friday, April 19, 2024 12:40 AM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D ; Andrew Fish
> ; Leif Lindholm ; Attar,
> AbdulLateef (Abdul Lateef) ; Chesley, Brit
> ; Wang, Jian J ; Liming
> Gao ; Wu, Hao A ; Ni,
> Ray ; Liu, Zhiguang 
> Subject: Re: [edk2-devel] [PATCH V3 6/6] Maintainers.txt: Update
> maintainer for SPI modules
> 
> [AMD Official Use Only - General]
> 
> Hi edk2 stewards,
> Per off-line discussion with Ray Ni, he considers Liming's RB is good
> enough for this patch set. Please help to review this and give your RB
> to the maintainship of MdeModulePkg/Bus/Spi If you don't have
> concerns.
> 
> Thank you!
> Abner
> 
> 
> > -Original Message-
> > From: Chang, Abner
> > Sent: Thursday, April 11, 2024 9:38 AM
> > To: devel@edk2.groups.io
> > Cc: Michael D Kinney ; Andrew Fish
> > ; Leif Lindholm ; Attar,
> > AbdulLateef (Abdul Lateef) ; Chesley,
> Brit
> > ; Jian J Wang ; Liming
> Gao
> > ; Hao A Wu ; Ray Ni
> > ; Zhiguang Liu 
> > Subject: RE: [edk2-devel] [PATCH V3 6/6] Maintainers.txt: Update
> maintainer
> > for SPI modules
> >
> > Hi maintainers,
> > Please help to check this update as we added an entry for Bus\Spi
> under
> > MdeModulePkg.
> >
> > Thanks
> > Abner
> >
> > > -Original Message-
> > > From: devel@edk2.groups.io  On Behalf Of
> Chang,
> > > Abner via groups.io
> > > Sent: Sunday, August 13, 2023 12:37 PM
> > > To: devel@edk2.groups.io
> > > Cc: Michael D Kinney ; Andrew Fish
> > > ; Leif Lindholm ;
> Attar,
> > > AbdulLateef (Abdul Lateef) ; Chesley,
> Brit
> > > ; Jian J Wang ;
> Liming Gao
> > > ; Hao A Wu ; Ray Ni
> > > ; Zhiguang Liu 
> > > Subject: [edk2-devel] [PATCH V3 6/6] Maintainers.txt: Update
> maintainer for
> > > SPI modules
> > >
> > > Caution: This message originated from an External Source. Use
> proper
> > > caution when opening attachments, clicking links, or responding.
> > >
> > >
> > > From: Abner Chang 
> > >
> > > Add maintainer entry of MdeModulePkg/Bus/Spi.
> > >
> > > Cc: Michael D Kinney 
> > > Cc: Andrew Fish 
> > > Cc: Leif Lindholm 
> > > Cc: Abdul Lateef Attar 
> > > Cc: Brit Chesley 
> > > Cc: Jian J Wang 
> > > Cc: Liming Gao 
> > > Cc: Hao A Wu 
> > > Cc: Ray Ni 
> > > Cc: Zhiguang Liu 
> > > Signed-off-by: Abner Chang 
> > > ---
> > >  Maintainers.txt | 5 +
> > >  1 file changed, 5 insertions(+)
> > >
> > > diff --git a/Maintainers.txt b/Maintainers.txt
> > > index 5a95929a14b..a6a5a9b4e03 100644
> > > --- a/Maintainers.txt
> > > +++ b/Maintainers.txt
> > > @@ -443,6 +443,11 @@ F:
> > > MdeModulePkg/Include/Protocol/UsbEthernetProtocol.h
> > >  M: Richard Ho  [richardho]
> > >  R: Rebecca Cran  [bcran]
> > >
> > > +MdeModulePkg: SPI Bus modules
> > > +F: MdeModulePkg/Bus/Spi
> > > +M: Abner Chang  [changab]
> > > +R: Brit Chesley  [BritChesley]
> > > +
> > >  MdePkg
> > >  F: MdePkg/
> > >  W: https://github.com/tianocore/tianocore.github.io/wiki/MdePkg
> > > --
> > > 2.37.1.windows.1
> > >
> > >
> > >
> > >
> > >
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118034): https://edk2.groups.io/g/devel/message/118034
Mute This Topic: https://groups.io/mt/105455146/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v3 5/6] target/arm: Do memory type alignment check when translation disabled

2024-04-19 Thread Ard Biesheuvel

On Fri, 19 Apr 2024 at 18:09, Jonathan Cameron via groups.io
 wrote:
>
> On Fri, 19 Apr 2024 13:52:07 +0200
> Gerd Hoffmann  wrote:
>
> >   Hi,
> >
> > > Gerd, any ideas?  Maybe I needs something subtly different in my
> > > edk2 build?  I've not looked at this bit of the qemu infrastructure
> > > before - is there a document on how that image is built?
> >
> > There is roms/Makefile for that.
> >
> > make -C roms help
> > make -C roms efi
> >
> > So easiest would be to just update the edk2 submodule to what you
> > need, then rebuild.
> >
> > The build is handled by the roms/edk2-build.py script,
> > with the build configuration being in roms/edk2-build.config.
> > That is usable outside the qemu source tree too, i.e. like this:
> >
> >   python3 /path/to/qemu.git/roms/edk2-build.py \
> > --config /path/to/qemu.git/roms/edk2-build.config \
> > --core /path/to/edk2.git \
> > --match armvirt \
> > --silent --no-logs
> >
> > That'll try to place the images build in "../pc-bios", so maybe better
> > work with a copy of the config file where you adjust this.
> >
> > HTH,
> >   Gerd
> >
>
> Thanks Gerd!
>
> So the builds are very similar via the two method...
> However - the QEMU build sets -D CAVIUM_ERRATUM_27456=TRUE
>
> And that's the difference - with that set for my other builds the alignment
> problems go away...
>
> Any idea why we have that set in roms/edk2-build.config?
> Superficially it seems rather unlikely anyone cares about thunderx1
> (if they do we need to get them some new hardware with fresh bugs)
> bugs now and this config file was only added last year.
>
>
> However, the last comment in Ard's commit message below seems
> highly likely to be relevant!
>
> Chasing through Ard's patch it has the side effect of dropping
> an override of a requirement for strict alignment.
> So with out the errata
> DEFINE GCC_AARCH64_CC_XIPFLAGS = -mstrict-align -mgeneral-regs-only
> is replaced with
>  [BuildOptions]
> +!if $(CAVIUM_ERRATUM_27456) == TRUE^M
> +  GCC:*_*_AARCH64_PP_FLAGS = -DCAVIUM_ERRATUM_27456^M
> +!else^M
>GCC:*_*_AARCH64_CC_XIPFLAGS ==
> +!endif^M
>
> The edk2 commit that added this was the following +CC Ard.
>
> Given I wasn't sure of the syntax of that file I set it
> manually to the original value and indeed it works.
>
>
> commit ec54ce1f1ab41b92782b37ae59e752fff0ef9c41
> Author: Ard Biesheuvel 
> Date:   Wed Jan 4 16:51:35 2023 +0100
>
> ArmVirtPkg/ArmVirtQemu: Avoid early ID map on ThunderX
>
> The early ID map used by ArmVirtQemu uses ASID scoped non-global
> mappings, as this allows us to switch to the permanent ID map seamlessly
> without the need for explicit TLB maintenance.
>
> However, this triggers a known erratum on ThunderX, which does not
> tolerate non-global mappings that are executable at EL1, as this appears
> to result in I-cache corruption. (Linux disables the KPTI based Meltdown
> mitigation on ThunderX for the same reason)
>
> So work around this, by detecting the CPU implementor and part number,
> and proceeding without the early ID map if a ThunderX CPU is detected.
>
> Note that this requires the C code to be built with strict alignment
> again, as we may end up executing it with the MMU and caches off.
>
> Signed-off-by: Ard Biesheuvel 
> Acked-by: Laszlo Ersek 
> Tested-by: dann frazier 
>
> Test case is
> qemu-system-aarch64 -M virt,virtualization=true, -m 4g -cpu cortex-a76 \
> -bios QEMU_EFI.fd -d int
>
> Which gets alignment faults since:
> https://lore.kernel.org/all/20240301204110.656742-6-richard.hender...@linaro.org/
>
> So my feeling here is EDK2 should either have yet another config for QEMU as 
> a host
> or should always set the alignment without needing to pick the CAVIUM 27456 
> errata
> which I suspect will get dropped soonish anyway if anyone ever cleans up
> old errata.
>

This code was never really intended for execution at EL2, but it
happened to work, partially because TCG's lack of strict alignment
checking when the MMU is off.

Those assumptions no longer hold, so yes, let's get this fixed properly.

Given VHE and nested virt (which will likely imply VHE in practice), I
would like to extend this functionality (i.e., the use of preliminary
page tables in NOR flash) to EL2 as well, but with VHE enabled. This
means we can still elide TLB maintenance (and BBM checks) by using
different ASIDs, and otherwise, fall back to entering with the MMU off
if VHE is not available. In that case, we should enforce strict
alignment too, so that needs to be fixed regardless.

I'll try to code something up and send it round. In the mean time,
feel free to propose a minimal patch that reinstates the strict
alignment if you are pressed for time, and I'll merge it right away.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118033): https://edk2.groups.io/g/devel/message/118033
Mute This Topic:

Re: [edk2-devel] [PATCH v3 5/6] target/arm: Do memory type alignment check when translation disabled

2024-04-19 Thread Jonathan Cameron via groups.io

On Fri, 19 Apr 2024 13:52:07 +0200
Gerd Hoffmann  wrote:

>   Hi,
> 
> > Gerd, any ideas?  Maybe I needs something subtly different in my
> > edk2 build?  I've not looked at this bit of the qemu infrastructure
> > before - is there a document on how that image is built?  
> 
> There is roms/Makefile for that.
> 
> make -C roms help
> make -C roms efi
> 
> So easiest would be to just update the edk2 submodule to what you
> need, then rebuild.
> 
> The build is handled by the roms/edk2-build.py script,
> with the build configuration being in roms/edk2-build.config.
> That is usable outside the qemu source tree too, i.e. like this:
> 
>   python3 /path/to/qemu.git/roms/edk2-build.py \
> --config /path/to/qemu.git/roms/edk2-build.config \
> --core /path/to/edk2.git \
> --match armvirt \
> --silent --no-logs
> 
> That'll try to place the images build in "../pc-bios", so maybe better
> work with a copy of the config file where you adjust this.
> 
> HTH,
>   Gerd
> 

Thanks Gerd!

So the builds are very similar via the two method...
However - the QEMU build sets -D CAVIUM_ERRATUM_27456=TRUE

And that's the difference - with that set for my other builds the alignment
problems go away...

Any idea why we have that set in roms/edk2-build.config?
Superficially it seems rather unlikely anyone cares about thunderx1
(if they do we need to get them some new hardware with fresh bugs)
bugs now and this config file was only added last year.

However, the last comment in Ard's commit message below seems
highly likely to be relevant!

Chasing through Ard's patch it has the side effect of dropping
an override of a requirement for strict alignment. 
So with out the errata 
DEFINE GCC_AARCH64_CC_XIPFLAGS = -mstrict-align -mgeneral-regs-only
is replaced with
 [BuildOptions]
+!if $(CAVIUM_ERRATUM_27456) == TRUE^M
+  GCC:*_*_AARCH64_PP_FLAGS = -DCAVIUM_ERRATUM_27456^M
+!else^M
   GCC:*_*_AARCH64_CC_XIPFLAGS ==
+!endif^M

The edk2 commit that added this was the following +CC Ard.

Given I wasn't sure of the syntax of that file I set it
manually to the original value and indeed it works.

commit ec54ce1f1ab41b92782b37ae59e752fff0ef9c41
Author: Ard Biesheuvel 
Date:   Wed Jan 4 16:51:35 2023 +0100

ArmVirtPkg/ArmVirtQemu: Avoid early ID map on ThunderX

The early ID map used by ArmVirtQemu uses ASID scoped non-global
mappings, as this allows us to switch to the permanent ID map seamlessly
without the need for explicit TLB maintenance.

However, this triggers a known erratum on ThunderX, which does not
tolerate non-global mappings that are executable at EL1, as this appears
to result in I-cache corruption. (Linux disables the KPTI based Meltdown
mitigation on ThunderX for the same reason)

So work around this, by detecting the CPU implementor and part number,
and proceeding without the early ID map if a ThunderX CPU is detected.

Note that this requires the C code to be built with strict alignment
again, as we may end up executing it with the MMU and caches off.

Signed-off-by: Ard Biesheuvel 
Acked-by: Laszlo Ersek 
Tested-by: dann frazier 

Test case is
qemu-system-aarch64 -M virt,virtualization=true, -m 4g -cpu cortex-a76 \
-bios QEMU_EFI.fd -d int

Which gets alignment faults since:
https://lore.kernel.org/all/20240301204110.656742-6-richard.hender...@linaro.org/

So my feeling here is EDK2 should either have yet another config for QEMU as a 
host
or should always set the alignment without needing to pick the CAVIUM 27456 
errata
which I suspect will get dropped soonish anyway if anyone ever cleans up
old errata.

Jonathan

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118032): https://edk2.groups.io/g/devel/message/118032
Mute This Topic: https://groups.io/mt/105602816/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] OvmfPkg: Harden #VC instruction emulation somewhat (CVE-2024-25742)

2024-04-19 Thread Lendacky, Thomas via groups.io


On 4/17/24 11:54, Adam Dunlap wrote:

Ensure that when a #VC exception happens, the instruction at the
instruction pointer matches the instruction that is expected given the
error code. This is to mitigate the ahoi WeSee attack [1] that could
allow hypervisors to breach integrity and confidentiality of the
firmware by maliciously injecting interrupts. This change is a
translated version of a linux patch e3ef461af35a ("x86/sev: Harden #VC
instruction emulation somewhat")

[1] https://ahoi-attacks.github.io/wesee/

Cc: Borislav Petkov (AMD) 
Cc: Tom Lendacky 
Signed-off-by: Adam Dunlap 
---
  OvmfPkg/Library/CcExitLib/CcExitVcHandler.c | 171 ++--
  1 file changed, 160 insertions(+), 11 deletions(-)

diff --git a/OvmfPkg/Library/CcExitLib/CcExitVcHandler.c 
b/OvmfPkg/Library/CcExitLib/CcExitVcHandler.c
index 0fc30f7bc4..bd3e9f304a 100644
--- a/OvmfPkg/Library/CcExitLib/CcExitVcHandler.c
+++ b/OvmfPkg/Library/CcExitLib/CcExitVcHandler.c
@@ -532,8 +532,6 @@ MwaitExit (
IN CC_INSTRUCTION_DATA *InstructionData
)
  {
-  CcDecodeModRm (Regs, InstructionData);
-
Ghcb->SaveArea.Rax = Regs->Rax;
CcExitVmgSetOffsetValid (Ghcb, GhcbRax);
Ghcb->SaveArea.Rcx = Regs->Rcx;
@@ -564,8 +562,6 @@ MonitorExit (
IN CC_INSTRUCTION_DATA *InstructionData
)
  {
-  CcDecodeModRm (Regs, InstructionData);
-
Ghcb->SaveArea.Rax = Regs->Rax;  // Identity mapped, so VA = PA
CcExitVmgSetOffsetValid (Ghcb, GhcbRax);
Ghcb->SaveArea.Rcx = Regs->Rcx;
@@ -670,8 +666,6 @@ VmmCallExit (
  {
UINT64  Status;
  
-  CcDecodeModRm (Regs, InstructionData);

-
Ghcb->SaveArea.Rax = Regs->Rax;
CcExitVmgSetOffsetValid (Ghcb, GhcbRax);
Ghcb->SaveArea.Cpl = (UINT8)(Regs->Cs & 0x3);
@@ -1603,8 +1597,6 @@ Dr7WriteExit (
Ext   = >Ext;
SevEsData = (SEV_ES_PER_CPU_DATA *)(Ghcb + 1);
  
-  CcDecodeModRm (Regs, InstructionData);

-
//
// MOV DRn always treats MOD == 3 no matter how encoded
//
@@ -1655,8 +1647,6 @@ Dr7ReadExit (
Ext   = >Ext;
SevEsData = (SEV_ES_PER_CPU_DATA *)(Ghcb + 1);
  
-  CcDecodeModRm (Regs, InstructionData);

-
//
// MOV DRn always treats MOD == 3 no matter how encoded
//
@@ -1671,6 +1661,160 @@ Dr7ReadExit (
return 0;
  }
  
+/**

+  Check that the opcode matches the exit code for a #VC.
+
+  Each exit code should only be raised while executing certain instructions.
+  Verify that rIP points to a correct instruction based on the exit code to
+  protect against maliciously injected interrupts via the hypervisor. If it 
does
+  not, report an unsupported event to the hypervisor.
+
+  Decodes the ModRm byte into InstructionData if necessary.
+
+  @param[in, out] Ghcb Pointer to the Guest-Hypervisor 
Communication
+   Block
+  @param[in, out] Regs x64 processor context
+  @param[in, out] InstructionData  Instruction parsing context
+  @param[in]  ExitCode Exit code given by #VC.
+
+  @retval 0No problems detected.
+  @return  New exception value to propagate
+
+
+**/
+STATIC
+UINT64
+VcCheckOpcodeBytes (
+  IN OUT GHCB*Ghcb,
+  IN OUT EFI_SYSTEM_CONTEXT_X64  *Regs,
+  IN OUT CC_INSTRUCTION_DATA *InstructionData,
+  IN UINT64  ExitCode
+  )
+{
+  UINT8  OpCode;
+
+  //
+  // Expected opcodes are either 1 or 2 bytes. If they are 2 bytes, they always
+  // start with TWO_BYTE_OPCODE_ESCAPE (0x0f), so skip over that.
+  //
+  OpCode = *(InstructionData->OpCodes);
+  if (OpCode == TWO_BYTE_OPCODE_ESCAPE) {
+OpCode = *(InstructionData->OpCodes + 1);
+  }
+
+  switch (ExitCode) {
+case SVM_EXIT_IOIO_PROT:
+case SVM_EXIT_NPF:
+  /* handled separately */
+  return 0;
+
+case SVM_EXIT_CPUID:
+  if (OpCode == 0xa2) {
+return 0;
+  }
+
+  break;
+
+case SVM_EXIT_INVD:
+  break;


This changes the current behavior today, but I'm ok with that.


+
+case SVM_EXIT_MONITOR:
+  CcDecodeModRm (Regs, InstructionData);
+
+  if ((OpCode == 0x01) && (InstructionData->ModRm.Uint8 == 0xc8)) {


This should also handle the MONITORX opcode (hmmm... I need to send a 
patch to the kernel).



+return 0;
+  }
+
+  break;
+
+case SVM_EXIT_MWAIT:
+  CcDecodeModRm (Regs, InstructionData);
+
+  if ((OpCode == 0x01) && (InstructionData->ModRm.Uint8 == 0xc9)) {


Same here for MWAITX.

Thanks,
Tom


+return 0;
+  }
+
+  break;
+
+case SVM_EXIT_MSR:
+  /* RDMSR */
+  if ((OpCode == 0x32) ||
+  /* WRMSR */
+  (OpCode == 0x30))
+  {
+return 0;
+  }
+
+  break;
+
+case SVM_EXIT_RDPMC:
+  if (OpCode == 0x33) {
+return 0;
+  }
+
+  break;
+
+case SVM_EXIT_RDTSC:
+  if (OpCode == 0x31) {
+return 0;
+  }
+
+  break;
+
+case SVM_EXIT_RDTSCP:
+  CcDecodeModRm (Regs, InstructionData);
+
+

Re: [edk2-devel] [PATCH] OvmfPkg: Harden #VC instruction emulation somewhat (CVE-2024-25742)

2024-04-19 Thread Lendacky, Thomas via groups.io


On 4/18/24 07:15, Gerd Hoffmann via groups.io wrote:

On Wed, Apr 17, 2024 at 09:54:00AM -0700, Adam Dunlap via groups.io wrote:

Ensure that when a #VC exception happens, the instruction at the
instruction pointer matches the instruction that is expected given the
error code. This is to mitigate the ahoi WeSee attack [1] that could
allow hypervisors to breach integrity and confidentiality of the
firmware by maliciously injecting interrupts. This change is a
translated version of a linux patch e3ef461af35a ("x86/sev: Harden #VC
instruction emulation somewhat")



+**/
+STATIC
+UINT64
+VcCheckOpcodeBytes (
+  IN OUT GHCB*Ghcb,
+  IN OUT EFI_SYSTEM_CONTEXT_X64  *Regs,
+  IN OUT CC_INSTRUCTION_DATA *InstructionData,
+  IN UINT64  ExitCode
+  )
+{
+  UINT8  OpCode;


The linux kernel patch uses "unsigned int opcode" and apparently
checks more than just the first byte for multi-byte opcodes.  Why
do it differently here?

On the bigger picture:  I'm wondering why SNP allows external #VC
injections in the first place?


It does and it doesn't. It doesn't allow #VC when injected as an 
exception. But the case of #VC injected as an interrupt was missed (see 
the event injection type field). It will be fixed in hardware going 
forward, but for now...


Thanks,
Tom



take care,
   Gerd









-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118030): https://edk2.groups.io/g/devel/message/118030
Mute This Topic: https://groups.io/mt/105581633/21656
Mute #vc:https://edk2.groups.io/g/devel/mutehashtag/vc
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/2] Platform/AMD: Add AmdSvsmLib to required DSC files

2024-04-19 Thread Ard Biesheuvel

On Fri, 19 Apr 2024 at 15:00, Chang, Abner  wrote:
>
> [AMD Official Use Only - General]
>
> I guess my RB misled contributors thought the patch is good to merge. 
> However, I was thinking Eric's team should give the final RB after the 
> validation as they are the maintainers for the subordinate VanGoghBoard 
> platform. Suppose the impacted packages should be built successfully with the 
> patches applied, as this is considered the base requirement of the code 
> change. Nevertheless, the special build sauce for VanGoghBoard may be not 
> easy for contributors to verify the build.
>
> Eric, I have few suggestions for this failure, for the short term, you can 
> commit another change to remove this change, as the build failure has impacts 
> on our customer support. You can decide to recover this or not depends on 
> your business requirement.

Keeping edk2-platforms synced with edk2 is already complicated enough.
So I object to changes to retain compatibility with downstream forks
of EDK2. Surely, you are not telling your customers to use EDK202208
with whatever the top-of-tree of edk2-platforms is at any given
moment?

In any case, if upstream edk2 is important to you, please fix the
current situation in edk2 first. If it is not important to you, I
don't see a reason to revert anything, and you can fix it in your
downstream.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118029): https://edk2.groups.io/g/devel/message/118029
Mute This Topic: https://groups.io/mt/105537744/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/2] Platform/AMD: Add AmdSvsmLib to required DSC files

2024-04-19 Thread Chang, Abner via groups.io

[AMD Official Use Only - General]

I guess my RB misled contributors thought the patch is good to merge. However, 
I was thinking Eric's team should give the final RB after the validation as 
they are the maintainers for the subordinate VanGoghBoard platform. Suppose the 
impacted packages should be built successfully with the patches applied, as 
this is considered the base requirement of the code change. Nevertheless, the 
special build sauce for VanGoghBoard may be not easy for contributors to verify 
the build.

Eric, I have few suggestions for this failure, for the short term, you can 
commit another change to remove this change, as the build failure has impacts 
on our customer support. You can decide to recover this or not depends on your 
business requirement.
For the long term, besides of code base upgrade, we could consider to revise 
VanGoghBoard to use native edk2 build script. Maybe we can leverage prebuild 
mechanism to cover the platform specific build requirements.

Thanks
Abner


> -Original Message-
> From: Xing, Eric 
> Sent: Friday, April 19, 2024 7:32 PM
> To: Ard Biesheuvel 
> Cc: devel@edk2.groups.io; Zhai, MingXin (Duke) ;
> Lendacky, Thomas ; Chang, Abner
> ; Yao, Ken ; Roth, Michael
> ; Attar, AbdulLateef (Abdul Lateef)
> ; Ard Biesheuvel ;
> Gerd Hoffmann ; Min Xu ; Leif
> Lindholm 
> Subject: RE: [edk2-devel] [PATCH 1/2] Platform/AMD: Add AmdSvsmLib to
> required DSC files
>
> [AMD Official Use Only - General]
>
> Hi Ard,
>
> Agree with you, reverting code looks not a good way now. We will think about
> new method to resolve this issue. Just need a bit more time and I will hold on
> checking in code to VanGoghBoard before it.
> Thanks again for your suggestion and help us improve code in VanGoghBoard.
>
> Thanks,
> Eric
>
>
> > -Original Message-
> > From: Ard Biesheuvel 
> > Sent: Friday, April 19, 2024 5:25 PM
> > To: Xing, Eric 
> > Cc: devel@edk2.groups.io; Zhai, MingXin (Duke) ;
> > Lendacky, Thomas ; Chang, Abner
> > ; Yao, Ken ; Roth, Michael
> > ; Attar, AbdulLateef (Abdul Lateef)
> > ; Ard Biesheuvel
> > ; Gerd Hoffmann ; Min
> > Xu ; Leif Lindholm 
> > Subject: Re: [edk2-devel] [PATCH 1/2] Platform/AMD: Add AmdSvsmLib to
> > required DSC files
> >
> > Caution: This message originated from an External Source. Use proper
> > caution when opening attachments, clicking links, or responding.
> >
> >
> > On Fri, 19 Apr 2024 at 11:06, Xing, Eric  wrote:
> > >
> > > [AMD Official Use Only - General]
> > >
> > > Hi Ard,
> > >
> > > This checkin causes VanGoghBoard build fail now. Would you help revert it?
> > > I will merge PATCH to VanGoghBoard after the code review process done
> > and code changes are verified pass on real board.
> > >
> >
> > Please provide a solution instead that makes upstream edk2 work with
> > upstream edk2-platforms.
> >
> > For downstream builds, you can combine the old EDK2_202208 with an older
> > checkout of edk2-platforms, right?



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118028): https://edk2.groups.io/g/devel/message/118028
Mute This Topic: https://groups.io/mt/105537744/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v2 5/5] OvmfPkg/VirtHstiDxe: add README.md

2024-04-19 Thread Gerd Hoffmann

Cc: Ard Biesheuvel 
Cc: Jiewen Yao 
Cc: Konstantin Kostiuk 
Signed-off-by: Gerd Hoffmann 
---
 OvmfPkg/VirtHstiDxe/README.md | 48 +++
 1 file changed, 48 insertions(+)
 create mode 100644 OvmfPkg/VirtHstiDxe/README.md

diff --git a/OvmfPkg/VirtHstiDxe/README.md b/OvmfPkg/VirtHstiDxe/README.md
new file mode 100644
index ..c3975b854715
--- /dev/null
+++ b/OvmfPkg/VirtHstiDxe/README.md
@@ -0,0 +1,48 @@
+
+# virtual machine platform hsti driver
+
+This driver supports three tests.
+
+## VIRT_HSTI_BYTE0_SMM_SMRAM_LOCK
+
+Verify the SMM memory is properly locked down.
+
+Supported platforms:
+ * Qemu Q35 (SMM_REQUIRE=TRUE builds).
+
+## VIRT_HSTI_BYTE0_SMM_SECURE_VARS_FLASH
+
+Verify the variable store is not writable for normal (not SMM) code.
+
+Supported platforms:
+ * Qemu Q35 (SMM_REQUIRE=TRUE builds).
+
+## VIRT_HSTI_BYTE0_READONLY_CODE_FLASH
+
+Verify the firmware code is not writable for the guest.
+
+Supported platforms:
+ * Qemu Q35
+ * Qemu PC
+
+# qemu flash configuration
+
+With qemu being configured properly flash behavior should be this:
+
+configuration  |  OVMF_CODE.fd  |  OVMF_VARS.fd
+---||---
+SMM_REQUIRE=TRUE, SMM mode |  read-only |  writable
+SMM_REQUIRE=TRUE, normal mode  |  read-only (1) |  read-only (2)
+SMM_REQUIRE=FALSE  |  read-only (3) |  writable
+
+VIRT_HSTI_BYTE0_READONLY_CODE_FLASH will verify (1) + (3).
+VIRT_HSTI_BYTE0_SMM_SECURE_VARS_FLASH will verify (2).
+
+## qemu command line for SMM_REQUIRE=TRUE builds
+```
+qemu-system-x86-64 -M q35,smm=on,pflash0=code,pflash1=vars \
+  -blockdev node-name=code,driver=file,filename=OVMF_CODE.fd,read-only=on \
+  -blockdev node-name=vars,driver=file,filename=OVMF_VARS.fd \
+  -global driver=cfi.pflash01,property=secure,value=on \
+  [ ... more options here ... ]
+```
-- 
2.44.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118027): https://edk2.groups.io/g/devel/message/118027
Mute This Topic: https://groups.io/mt/105616663/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v2 4/5] OvmfPkg/VirtHstiDxe: add code flash check

2024-04-19 Thread Gerd Hoffmann

Detects qemu config issue: code pflash is writable.
Checked for both PC and Q35.

Cc: Ard Biesheuvel 
Cc: Jiewen Yao 
Cc: Konstantin Kostiuk 
Signed-off-by: Gerd Hoffmann 
---
 OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf |  2 ++
 OvmfPkg/VirtHstiDxe/VirtHstiDxe.h   | 13 +++
 OvmfPkg/VirtHstiDxe/QemuCommon.c| 36 +
 OvmfPkg/VirtHstiDxe/VirtHstiDxe.c   |  4 
 4 files changed, 55 insertions(+)
 create mode 100644 OvmfPkg/VirtHstiDxe/QemuCommon.c

diff --git a/OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf 
b/OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf
index 9cb2ed1f0c64..376cd28aeb7e 100644
--- a/OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf
+++ b/OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf
@@ -22,6 +22,7 @@ [Sources]
   VirtHstiDxe.c
   QemuPC.c
   QemuQ35.c
+  QemuCommon.c
   Flash.c
 
 [Packages]
@@ -49,6 +50,7 @@ [FeaturePcd]
 
 [Pcd]
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFdBaseAddress
+  gUefiOvmfPkgTokenSpaceGuid.PcdBfvBase
 
 [Depex]
   TRUE
diff --git a/OvmfPkg/VirtHstiDxe/VirtHstiDxe.h 
b/OvmfPkg/VirtHstiDxe/VirtHstiDxe.h
index ceff41c03711..f8bdcfe8f219 100644
--- a/OvmfPkg/VirtHstiDxe/VirtHstiDxe.h
+++ b/OvmfPkg/VirtHstiDxe/VirtHstiDxe.h
@@ -8,6 +8,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 
 #define VIRT_HSTI_BYTE0_SMM_SMRAM_LOCK BIT0
 #define VIRT_HSTI_BYTE0_SMM_SECURE_VARS_FLASH  BIT1
+#define VIRT_HSTI_BYTE0_READONLY_CODE_FLASHBIT2
 
 typedef struct {
   // ADAPTER_INFO_PLATFORM_SECURITY
@@ -67,6 +68,18 @@ VirtHstiQemuPCVerify (
   VOID
   );
 
+/* QemuCommon.c */
+
+VOID
+VirtHstiQemuCommonInit (
+  VIRT_ADAPTER_INFO_PLATFORM_SECURITY  *VirtHsti
+  );
+
+VOID
+VirtHstiQemuCommonVerify (
+  VOID
+  );
+
 /* Flash.c */
 
 #define QEMU_FIRMWARE_FLASH_UNKNOWN0
diff --git a/OvmfPkg/VirtHstiDxe/QemuCommon.c b/OvmfPkg/VirtHstiDxe/QemuCommon.c
new file mode 100644
index ..4ab3fe2d6e63
--- /dev/null
+++ b/OvmfPkg/VirtHstiDxe/QemuCommon.c
@@ -0,0 +1,36 @@
+/** @file
+
+SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+#include 
+
+#include "VirtHstiDxe.h"
+
+VOID
+VirtHstiQemuCommonInit (
+  VIRT_ADAPTER_INFO_PLATFORM_SECURITY  *VirtHsti
+  )
+{
+  VirtHstiSetSupported (VirtHsti, 0, VIRT_HSTI_BYTE0_READONLY_CODE_FLASH);
+}
+
+VOID
+VirtHstiQemuCommonVerify (
+  VOID
+  )
+{
+  CHAR16  *ErrorMsg;
+
+  switch (VirtHstiQemuFirmwareFlashCheck (PcdGet32 (PcdBfvBase))) {
+case QEMU_FIRMWARE_FLASH_WRITABLE:
+  ErrorMsg = L"qemu code pflash is writable";
+  break;
+default:
+  ErrorMsg = NULL;
+  }
+
+  VirtHstiTestResult (ErrorMsg, 0, VIRT_HSTI_BYTE0_READONLY_CODE_FLASH);
+}
diff --git a/OvmfPkg/VirtHstiDxe/VirtHstiDxe.c 
b/OvmfPkg/VirtHstiDxe/VirtHstiDxe.c
index 74e5e6bd9d4f..b6e53a1219d1 100644
--- a/OvmfPkg/VirtHstiDxe/VirtHstiDxe.c
+++ b/OvmfPkg/VirtHstiDxe/VirtHstiDxe.c
@@ -104,9 +104,11 @@ VirtHstiOnReadyToBoot (
   switch (VirtHstiGetHostBridgeDevId ()) {
 case INTEL_82441_DEVICE_ID:
   VirtHstiQemuPCVerify ();
+  VirtHstiQemuCommonVerify ();
   break;
 case INTEL_Q35_MCH_DEVICE_ID:
   VirtHstiQemuQ35Verify ();
+  VirtHstiQemuCommonVerify ();
   break;
 default:
   ASSERT (FALSE);
@@ -142,9 +144,11 @@ VirtHstiDxeEntrypoint (
   switch (DevId) {
 case INTEL_82441_DEVICE_ID:
   VirtHsti = VirtHstiQemuPCInit ();
+  VirtHstiQemuCommonInit (VirtHsti);
   break;
 case INTEL_Q35_MCH_DEVICE_ID:
   VirtHsti = VirtHstiQemuQ35Init ();
+  VirtHstiQemuCommonInit (VirtHsti);
   break;
 default:
   DEBUG ((DEBUG_INFO, "%a: unknown platform (0x%x)\n", __func__, DevId));
-- 
2.44.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118026): https://edk2.groups.io/g/devel/message/118026
Mute This Topic: https://groups.io/mt/105616662/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v2 1/5] OvmfPkg: Add VirtHstiDxe driver

2024-04-19 Thread Gerd Hoffmann

From: Konstantin Kostiuk 

The driver supports qemu machine types 'pc' and 'q35'.

This patch adds some helper functions to manage the bitmasks.
The implemented features depend on both OVMF build configuration
and qemu VM configuration.

For q35 a single security feature is supported and checked: In
SMM-enabled builds the driver will verify smram is properly locked.
That test should never fail.

Cc: Ard Biesheuvel 
Cc: Jiewen Yao 
Cc: Konstantin Kostiuk 
Initial-patch-by: Konstantin Kostiuk 
Signed-off-by: Gerd Hoffmann 
---
 OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf |  50 
 OvmfPkg/VirtHstiDxe/VirtHstiDxe.h   |  67 +++
 OvmfPkg/VirtHstiDxe/QemuPC.c|  38 +++
 OvmfPkg/VirtHstiDxe/QemuQ35.c   |  58 ++
 OvmfPkg/VirtHstiDxe/VirtHstiDxe.c   | 169 
 5 files changed, 382 insertions(+)
 create mode 100644 OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf
 create mode 100644 OvmfPkg/VirtHstiDxe/VirtHstiDxe.h
 create mode 100644 OvmfPkg/VirtHstiDxe/QemuPC.c
 create mode 100644 OvmfPkg/VirtHstiDxe/QemuQ35.c
 create mode 100644 OvmfPkg/VirtHstiDxe/VirtHstiDxe.c

diff --git a/OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf 
b/OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf
new file mode 100644
index ..8c63ff6a8953
--- /dev/null
+++ b/OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf
@@ -0,0 +1,50 @@
+## @file
+#  Component description file for Virt Hsti Driver
+#
+# Copyright (c) 2017, Intel Corporation. All rights reserved.
+# Copyright (c) Microsoft Corporation.
+# Copyright (c) 2024, Red Hat. Inc
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+  INF_VERSION= 0x00010005
+  BASE_NAME  = VirtHstiDxe
+  FILE_GUID  = 60740CF3-D428-4500-80E6-04A5798241ED
+  MODULE_TYPE= DXE_DRIVER
+  VERSION_STRING = 1.0
+  ENTRY_POINT= VirtHstiDxeEntrypoint
+
+[Sources]
+  VirtHstiDxe.h
+  VirtHstiDxe.c
+  QemuPC.c
+  QemuQ35.c
+
+[Packages]
+  MdePkg/MdePkg.dec
+  OvmfPkg/OvmfPkg.dec
+
+[LibraryClasses]
+  UefiDriverEntryPoint
+  UefiLib
+  BaseLib
+  BaseMemoryLib
+  MemoryAllocationLib
+  DebugLib
+  HobLib
+  HstiLib
+  PcdLib
+  PciLib
+  UefiBootServicesTableLib
+
+[Guids]
+  gUefiOvmfPkgPlatformInfoGuid
+
+[FeaturePcd]
+  gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire
+
+[Depex]
+  TRUE
diff --git a/OvmfPkg/VirtHstiDxe/VirtHstiDxe.h 
b/OvmfPkg/VirtHstiDxe/VirtHstiDxe.h
new file mode 100644
index ..cf0d77fc3af9
--- /dev/null
+++ b/OvmfPkg/VirtHstiDxe/VirtHstiDxe.h
@@ -0,0 +1,67 @@
+/** @file
+
+SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#define VIRT_HSTI_SECURITY_FEATURE_SIZE  2
+
+#define VIRT_HSTI_BYTE0_SMM_SMRAM_LOCK  BIT0
+
+typedef struct {
+  // ADAPTER_INFO_PLATFORM_SECURITY
+  UINT32Version;
+  UINT32Role;
+  CHAR16ImplementationID[256];
+  UINT32SecurityFeaturesSize;
+  // bitfields
+  UINT8 SecurityFeaturesRequired[VIRT_HSTI_SECURITY_FEATURE_SIZE];
+  UINT8 SecurityFeaturesImplemented[VIRT_HSTI_SECURITY_FEATURE_SIZE];
+  UINT8 SecurityFeaturesVerified[VIRT_HSTI_SECURITY_FEATURE_SIZE];
+  CHAR16ErrorString[1];
+} VIRT_ADAPTER_INFO_PLATFORM_SECURITY;
+
+VOID
+VirtHstiSetSupported (
+  VIRT_ADAPTER_INFO_PLATFORM_SECURITY  *VirtHsti,
+  IN UINT32ByteIndex,
+  IN UINT8 BitMask
+  );
+
+BOOLEAN
+VirtHstiIsSupported (
+  VIRT_ADAPTER_INFO_PLATFORM_SECURITY  *VirtHsti,
+  IN UINT32ByteIndex,
+  IN UINT8 BitMask
+  );
+
+VOID
+VirtHstiTestResult (
+  CHAR16 *ErrorMsg,
+  IN UINT32  ByteIndex,
+  IN UINT8   BitMask
+  );
+
+/* QemuQ35.c */
+
+VIRT_ADAPTER_INFO_PLATFORM_SECURITY *
+VirtHstiQemuQ35Init (
+  VOID
+  );
+
+VOID
+VirtHstiQemuQ35Verify (
+  VOID
+  );
+
+/* QemuPC.c */
+
+VIRT_ADAPTER_INFO_PLATFORM_SECURITY *
+VirtHstiQemuPCInit (
+  VOID
+  );
+
+VOID
+VirtHstiQemuPCVerify (
+  VOID
+  );
diff --git a/OvmfPkg/VirtHstiDxe/QemuPC.c b/OvmfPkg/VirtHstiDxe/QemuPC.c
new file mode 100644
index ..aa0459e8b6c6
--- /dev/null
+++ b/OvmfPkg/VirtHstiDxe/QemuPC.c
@@ -0,0 +1,38 @@
+/** @file
+
+SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include "VirtHstiDxe.h"
+
+STATIC VIRT_ADAPTER_INFO_PLATFORM_SECURITY  mHstiPC = {
+  PLATFORM_SECURITY_VERSION_VNEXTCS,
+  PLATFORM_SECURITY_ROLE_PLATFORM_REFERENCE,
+  { L"OVMF (Qemu PC)" },
+  VIRT_HSTI_SECURITY_FEATURE_SIZE,
+};
+
+VIRT_ADAPTER_INFO_PLATFORM_SECURITY *
+VirtHstiQemuPCInit (
+  VOID
+  )
+{
+  return 
+}
+
+VOID
+VirtHstiQemuPCVerify (
+  VOID
+  )
+{
+}
diff --git a/OvmfPkg/VirtHstiDxe/QemuQ35.c b/OvmfPkg/VirtHstiDxe/QemuQ35.c
new file mode 100644
index ..5eab4aab29d1
--- /dev/null
+++ b/OvmfPkg/VirtHstiDxe/QemuQ35.c
@@ -0,0 +1,58 @@
+/** @file
+
+SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+#include 
+#include

[edk2-devel] [PATCH v2 3/5] OvmfPkg/VirtHstiDxe: add varstore flash check

2024-04-19 Thread Gerd Hoffmann

Detects qemu config issue: vars pflash is not in secure mode (write
access restricted to smm).  Applies to Q35 with SMM only.

Cc: Ard Biesheuvel 
Cc: Jiewen Yao 
Cc: Konstantin Kostiuk 
Signed-off-by: Gerd Hoffmann 
---
 OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf |  4 ++
 OvmfPkg/VirtHstiDxe/VirtHstiDxe.h   | 16 -
 OvmfPkg/VirtHstiDxe/Flash.c | 90 +
 OvmfPkg/VirtHstiDxe/QemuQ35.c   | 13 +
 4 files changed, 122 insertions(+), 1 deletion(-)
 create mode 100644 OvmfPkg/VirtHstiDxe/Flash.c

diff --git a/OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf 
b/OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf
index 8c63ff6a8953..9cb2ed1f0c64 100644
--- a/OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf
+++ b/OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf
@@ -22,6 +22,7 @@ [Sources]
   VirtHstiDxe.c
   QemuPC.c
   QemuQ35.c
+  Flash.c
 
 [Packages]
   MdePkg/MdePkg.dec
@@ -46,5 +47,8 @@ [Guids]
 [FeaturePcd]
   gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire
 
+[Pcd]
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFdBaseAddress
+
 [Depex]
   TRUE
diff --git a/OvmfPkg/VirtHstiDxe/VirtHstiDxe.h 
b/OvmfPkg/VirtHstiDxe/VirtHstiDxe.h
index cf0d77fc3af9..ceff41c03711 100644
--- a/OvmfPkg/VirtHstiDxe/VirtHstiDxe.h
+++ b/OvmfPkg/VirtHstiDxe/VirtHstiDxe.h
@@ -6,7 +6,8 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 
 #define VIRT_HSTI_SECURITY_FEATURE_SIZE  2
 
-#define VIRT_HSTI_BYTE0_SMM_SMRAM_LOCK  BIT0
+#define VIRT_HSTI_BYTE0_SMM_SMRAM_LOCK BIT0
+#define VIRT_HSTI_BYTE0_SMM_SECURE_VARS_FLASH  BIT1
 
 typedef struct {
   // ADAPTER_INFO_PLATFORM_SECURITY
@@ -65,3 +66,16 @@ VOID
 VirtHstiQemuPCVerify (
   VOID
   );
+
+/* Flash.c */
+
+#define QEMU_FIRMWARE_FLASH_UNKNOWN0
+#define QEMU_FIRMWARE_FLASH_IS_ROM 1
+#define QEMU_FIRMWARE_FLASH_IS_RAM 2
+#define QEMU_FIRMWARE_FLASH_READ_ONLY  3
+#define QEMU_FIRMWARE_FLASH_WRITABLE   4
+
+UINT32
+VirtHstiQemuFirmwareFlashCheck (
+  UINT32  Address
+  );
diff --git a/OvmfPkg/VirtHstiDxe/Flash.c b/OvmfPkg/VirtHstiDxe/Flash.c
new file mode 100644
index ..e93356793f8c
--- /dev/null
+++ b/OvmfPkg/VirtHstiDxe/Flash.c
@@ -0,0 +1,90 @@
+/** @file
+
+SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+#include 
+
+#include "VirtHstiDxe.h"
+
+#define WRITE_BYTE_CMD   0x10
+#define BLOCK_ERASE_CMD  0x20
+#define CLEAR_STATUS_CMD 0x50
+#define READ_STATUS_CMD  0x70
+#define READ_DEVID_CMD   0x90
+#define BLOCK_ERASE_CONFIRM_CMD  0xd0
+#define READ_ARRAY_CMD   0xff
+#define CLEARED_ARRAY_STATUS 0x00
+
+/* based on QemuFlashDetected (QemuFlashFvbServicesRuntimeDxe) */
+UINT32
+VirtHstiQemuFirmwareFlashCheck (
+  UINT32  Address
+  )
+{
+  volatile UINT8  *Ptr;
+
+  UINTN  Offset;
+  UINT8  OriginalUint8;
+  UINT8  ProbeUint8;
+
+  for (Offset = 0; Offset < EFI_PAGE_SIZE; Offset++) {
+Ptr= (UINT8 *)(UINTN)(Address + Offset);
+ProbeUint8 = *Ptr;
+if ((ProbeUint8 != CLEAR_STATUS_CMD) &&
+(ProbeUint8 != READ_STATUS_CMD) &&
+(ProbeUint8 != CLEARED_ARRAY_STATUS))
+{
+  break;
+}
+  }
+
+  if (Offset >= EFI_PAGE_SIZE) {
+DEBUG ((DEBUG_INFO, "%a: check failed\n", __func__));
+return QEMU_FIRMWARE_FLASH_UNKNOWN;
+  }
+
+  OriginalUint8 = *Ptr;
+  *Ptr  = CLEAR_STATUS_CMD;
+  ProbeUint8= *Ptr;
+  if ((OriginalUint8 != CLEAR_STATUS_CMD) &&
+  (ProbeUint8 == CLEAR_STATUS_CMD))
+  {
+*Ptr = OriginalUint8;
+DEBUG ((DEBUG_INFO, "%a: %p behaves as RAM\n", __func__, Ptr));
+return QEMU_FIRMWARE_FLASH_IS_RAM;
+  }
+
+  *Ptr   = READ_STATUS_CMD;
+  ProbeUint8 = *Ptr;
+  if (ProbeUint8 == OriginalUint8) {
+DEBUG ((DEBUG_INFO, "%a: %p behaves as ROM\n", __func__, Ptr));
+return QEMU_FIRMWARE_FLASH_IS_ROM;
+  }
+
+  if (ProbeUint8 == READ_STATUS_CMD) {
+*Ptr = OriginalUint8;
+DEBUG ((DEBUG_INFO, "%a: %p behaves as RAM\n", __func__, Ptr));
+return QEMU_FIRMWARE_FLASH_IS_RAM;
+  }
+
+  if (ProbeUint8 == CLEARED_ARRAY_STATUS) {
+*Ptr   = WRITE_BYTE_CMD;
+*Ptr   = OriginalUint8;
+*Ptr   = READ_STATUS_CMD;
+ProbeUint8 = *Ptr;
+*Ptr   = READ_ARRAY_CMD;
+if (ProbeUint8 & 0x10 /* programming error */) {
+  DEBUG ((DEBUG_INFO, "%a: %p behaves as FLASH, write-protected\n", 
__func__, Ptr));
+  return QEMU_FIRMWARE_FLASH_READ_ONLY;
+} else {
+  DEBUG ((DEBUG_INFO, "%a: %p behaves as FLASH, writable\n", __func__, 
Ptr));
+  return QEMU_FIRMWARE_FLASH_WRITABLE;
+}
+  }
+
+  DEBUG ((DEBUG_INFO, "%a: check failed\n", __func__));
+  return QEMU_FIRMWARE_FLASH_UNKNOWN;
+}
diff --git a/OvmfPkg/VirtHstiDxe/QemuQ35.c b/OvmfPkg/VirtHstiDxe/QemuQ35.c
index 5eab4aab29d1..33753027060b 100644
--- a/OvmfPkg/VirtHstiDxe/QemuQ35.c
+++ b/OvmfPkg/VirtHstiDxe/QemuQ35.c
@@ -29,6 +29,7 @@ VirtHstiQemuQ35Init (
 {
   if (FeaturePcdGet (PcdSmmSmramRequire)) {
 VirtHstiSetSupported (, 0, VIRT_HSTI_BYTE0_SMM_SMRAM_LOCK);
+VirtHstiSetSupported (, 0, VIRT_HSTI_BYTE0_SMM_SECURE_VARS_FLASH);
   }

[edk2-devel] [PATCH v2 2/5] OvmfPkg: Add VirtHstiDxe to OVMF firmware build

2024-04-19 Thread Gerd Hoffmann

From: Konstantin Kostiuk 

Cc: Ard Biesheuvel 
Cc: Jiewen Yao 
Signed-off-by: Konstantin Kostiuk 
Signed-off-by: Gerd Hoffmann 
---
 OvmfPkg/OvmfPkgIa32.dsc| 2 ++
 OvmfPkg/OvmfPkgIa32X64.dsc | 2 ++
 OvmfPkg/OvmfPkgX64.dsc | 2 ++
 OvmfPkg/OvmfPkgIa32.fdf| 1 +
 OvmfPkg/OvmfPkgIa32X64.fdf | 1 +
 OvmfPkg/OvmfPkgX64.fdf | 1 +
 6 files changed, 9 insertions(+)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 15fadc2fdc6e..9db3ebd0e722 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -188,6 +188,7 @@ [LibraryClasses]
   PeiHardwareInfoLib|OvmfPkg/Library/HardwareInfoLib/PeiHardwareInfoLib.inf
   DxeHardwareInfoLib|OvmfPkg/Library/HardwareInfoLib/DxeHardwareInfoLib.inf
   
ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib/ImagePropertiesRecordLib.inf
+  HstiLib|MdePkg/Library/DxeHstiLib/DxeHstiLib.inf
 !if $(SMM_REQUIRE) == FALSE
   LockBoxLib|OvmfPkg/Library/LockBoxLib/LockBoxBaseLib.inf
 !endif
@@ -829,6 +830,7 @@ [Components]
   OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
   OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf
   OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
+  OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf
 
   #
   # ISA Support
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 6e55b50a9641..43378122925b 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -193,6 +193,7 @@ [LibraryClasses]
   PeiHardwareInfoLib|OvmfPkg/Library/HardwareInfoLib/PeiHardwareInfoLib.inf
   DxeHardwareInfoLib|OvmfPkg/Library/HardwareInfoLib/DxeHardwareInfoLib.inf
   
ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib/ImagePropertiesRecordLib.inf
+  HstiLib|MdePkg/Library/DxeHstiLib/DxeHstiLib.inf
 !if $(SMM_REQUIRE) == FALSE
   LockBoxLib|OvmfPkg/Library/LockBoxLib/LockBoxBaseLib.inf
 !endif
@@ -843,6 +844,7 @@ [Components.X64]
   OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
   OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf
   OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
+  OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf
 
   #
   # ISA Support
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index f2edd3bbc05a..157ae6c0e4b0 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -205,6 +205,7 @@ [LibraryClasses]
   PeiHardwareInfoLib|OvmfPkg/Library/HardwareInfoLib/PeiHardwareInfoLib.inf
   DxeHardwareInfoLib|OvmfPkg/Library/HardwareInfoLib/DxeHardwareInfoLib.inf
   
ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib/ImagePropertiesRecordLib.inf
+  HstiLib|MdePkg/Library/DxeHstiLib/DxeHstiLib.inf
 
 !if $(SMM_REQUIRE) == FALSE
   LockBoxLib|OvmfPkg/Library/LockBoxLib/LockBoxBaseLib.inf
@@ -911,6 +912,7 @@ [Components]
   OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
   OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf
   OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
+  OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf
 
   #
   # ISA Support
diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
index 6c56c5e53f21..6eb26f7d4613 100644
--- a/OvmfPkg/OvmfPkgIa32.fdf
+++ b/OvmfPkg/OvmfPkgIa32.fdf
@@ -316,6 +316,7 @@ [FV.DXEFV]
 INF  OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
 INF  OvmfPkg/PlatformDxe/Platform.inf
 INF  OvmfPkg/IoMmuDxe/IoMmuDxe.inf
+INF  OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf
 
 !if $(SMM_REQUIRE) == TRUE
 INF  OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
index ee8068ad55dc..080784f722a7 100644
--- a/OvmfPkg/OvmfPkgIa32X64.fdf
+++ b/OvmfPkg/OvmfPkgIa32X64.fdf
@@ -323,6 +323,7 @@ [FV.DXEFV]
 INF  OvmfPkg/PlatformDxe/Platform.inf
 INF  OvmfPkg/AmdSevDxe/AmdSevDxe.inf
 INF  OvmfPkg/IoMmuDxe/IoMmuDxe.inf
+INF  OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf
 
 !if $(SMM_REQUIRE) == TRUE
 INF  OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index fecb1fcfda4d..c2d3cc901e94 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -353,6 +353,7 @@ [FV.DXEFV]
 INF  OvmfPkg/PlatformDxe/Platform.inf
 INF  OvmfPkg/AmdSevDxe/AmdSevDxe.inf
 INF  OvmfPkg/IoMmuDxe/IoMmuDxe.inf
+INF  OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf
 
 !if $(SMM_REQUIRE) == TRUE
 INF  OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
-- 
2.44.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118024): https://edk2.groups.io/g/devel/message/118024
Mute This Topic: https://groups.io/mt/105616659/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v2 0/5] OvmfPkg: Add VirtHstiDxe driver

2024-04-19 Thread Gerd Hoffmann

v2:
 - remove 'Q35' from test bits
 - add patch with a README.md

Gerd Hoffmann (3):
  OvmfPkg/VirtHstiDxe: add varstore flash check
  OvmfPkg/VirtHstiDxe: add code flash check
  OvmfPkg/VirtHstiDxe: add README.md

Konstantin Kostiuk (2):
  OvmfPkg: Add VirtHstiDxe driver
  OvmfPkg: Add VirtHstiDxe to OVMF firmware build

 OvmfPkg/OvmfPkgIa32.dsc |   2 +
 OvmfPkg/OvmfPkgIa32X64.dsc  |   2 +
 OvmfPkg/OvmfPkgX64.dsc  |   2 +
 OvmfPkg/OvmfPkgIa32.fdf |   1 +
 OvmfPkg/OvmfPkgIa32X64.fdf  |   1 +
 OvmfPkg/OvmfPkgX64.fdf  |   1 +
 OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf |  56 +
 OvmfPkg/VirtHstiDxe/VirtHstiDxe.h   |  94 +++
 OvmfPkg/VirtHstiDxe/Flash.c |  90 +++
 OvmfPkg/VirtHstiDxe/QemuCommon.c|  36 ++
 OvmfPkg/VirtHstiDxe/QemuPC.c|  38 ++
 OvmfPkg/VirtHstiDxe/QemuQ35.c   |  71 
 OvmfPkg/VirtHstiDxe/VirtHstiDxe.c   | 173 
 OvmfPkg/VirtHstiDxe/README.md   |  48 
 14 files changed, 615 insertions(+)
 create mode 100644 OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf
 create mode 100644 OvmfPkg/VirtHstiDxe/VirtHstiDxe.h
 create mode 100644 OvmfPkg/VirtHstiDxe/Flash.c
 create mode 100644 OvmfPkg/VirtHstiDxe/QemuCommon.c
 create mode 100644 OvmfPkg/VirtHstiDxe/QemuPC.c
 create mode 100644 OvmfPkg/VirtHstiDxe/QemuQ35.c
 create mode 100644 OvmfPkg/VirtHstiDxe/VirtHstiDxe.c
 create mode 100644 OvmfPkg/VirtHstiDxe/README.md

-- 
2.44.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118023): https://edk2.groups.io/g/devel/message/118023
Mute This Topic: https://groups.io/mt/105616658/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V2 1/1] OvmfPkg/IntelTdx: Update TDVF README

2024-04-19 Thread Gerd Hoffmann

On Fri, Apr 19, 2024 at 08:11:27AM +0800, Min Xu wrote:
> From: Min M Xu 
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4756
> 
> There are below updates in this patch:
> 1. Rename README to README.md so that it can be show as markdown
>document.
> 2. Update some information about TDVF.
> 2. Fix some typo.

Acked-by: Gerd Hoffmann 

take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118021): https://edk2.groups.io/g/devel/message/118021
Mute This Topic: https://groups.io/mt/105609363/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v3 5/6] target/arm: Do memory type alignment check when translation disabled

2024-04-19 Thread Gerd Hoffmann

  Hi,

> Gerd, any ideas?  Maybe I needs something subtly different in my
> edk2 build?  I've not looked at this bit of the qemu infrastructure
> before - is there a document on how that image is built?

There is roms/Makefile for that.

make -C roms help
make -C roms efi

So easiest would be to just update the edk2 submodule to what you
need, then rebuild.

The build is handled by the roms/edk2-build.py script,
with the build configuration being in roms/edk2-build.config.
That is usable outside the qemu source tree too, i.e. like this:

  python3 /path/to/qemu.git/roms/edk2-build.py \
--config /path/to/qemu.git/roms/edk2-build.config \
--core /path/to/edk2.git \
--match armvirt \
--silent --no-logs

That'll try to place the images build in "../pc-bios", so maybe better
work with a copy of the config file where you adjust this.

HTH,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118020): https://edk2.groups.io/g/devel/message/118020
Mute This Topic: https://groups.io/mt/105602816/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/2] Platform/AMD: Add AmdSvsmLib to required DSC files

2024-04-19 Thread Xing, Eric via groups.io

[AMD Official Use Only - General]

Hi Ard,

Agree with you, reverting code looks not a good way now. We will think about 
new method to resolve this issue. Just need a bit more time and I will hold on 
checking in code to VanGoghBoard before it.
Thanks again for your suggestion and help us improve code in VanGoghBoard.

Thanks,
Eric


> -Original Message-
> From: Ard Biesheuvel 
> Sent: Friday, April 19, 2024 5:25 PM
> To: Xing, Eric 
> Cc: devel@edk2.groups.io; Zhai, MingXin (Duke) ;
> Lendacky, Thomas ; Chang, Abner
> ; Yao, Ken ; Roth, Michael
> ; Attar, AbdulLateef (Abdul Lateef)
> ; Ard Biesheuvel
> ; Gerd Hoffmann ; Min
> Xu ; Leif Lindholm 
> Subject: Re: [edk2-devel] [PATCH 1/2] Platform/AMD: Add AmdSvsmLib to
> required DSC files
>
> Caution: This message originated from an External Source. Use proper
> caution when opening attachments, clicking links, or responding.
>
>
> On Fri, 19 Apr 2024 at 11:06, Xing, Eric  wrote:
> >
> > [AMD Official Use Only - General]
> >
> > Hi Ard,
> >
> > This checkin causes VanGoghBoard build fail now. Would you help revert it?
> > I will merge PATCH to VanGoghBoard after the code review process done
> and code changes are verified pass on real board.
> >
>
> Please provide a solution instead that makes upstream edk2 work with
> upstream edk2-platforms.
>
> For downstream builds, you can combine the old EDK2_202208 with an older
> checkout of edk2-platforms, right?


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118019): https://edk2.groups.io/g/devel/message/118019
Mute This Topic: https://groups.io/mt/105537744/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] OvmfPkg: Harden #VC instruction emulation somewhat (CVE-2024-25742)

2024-04-19 Thread Gerd Hoffmann

On Thu, Apr 18, 2024 at 08:39:20AM -0700, Adam Dunlap wrote:
> On Thu, Apr 18, 2024 at 5:15 AM Gerd Hoffmann  wrote:
> >
> > On Wed, Apr 17, 2024 at 09:54:00AM -0700, Adam Dunlap via groups.io wrote:
> > > +  UINT8  OpCode;
> >
> > The linux kernel patch uses "unsigned int opcode" and apparently
> > checks more than just the first byte for multi-byte opcodes.  Why
> > do it differently here?
> 
> Good question. This patch does check for two-byte opcodes with this snippet:
> 
> +  OpCode = *(InstructionData->OpCodes);
> +  if (OpCode == TWO_BYTE_OPCODE_ESCAPE) {
> +OpCode = *(InstructionData->OpCodes + 1);
> +  }
> 
> This works because the first byte of two-byte opcodes is always 0x0f in the
> cases that we're checking for.

Ok, missed that little detail.  Thanks for explaining.

Reviewed-by: Gerd Hoffmann 

take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118018): https://edk2.groups.io/g/devel/message/118018
Mute This Topic: https://groups.io/mt/105581633/21656
Mute #vc:https://edk2.groups.io/g/devel/mutehashtag/vc
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2] XiangshanSeriesPkg:Add BOSC NanhuDev platform

2024-04-19 Thread Sunil V L

On Wed, Apr 10, 2024 at 01:50:12PM +0800, WangYang wrote:
> This commit adds the initial support for BOSC's
> nanhu platform which provides up to 2 RISC-V RV64
> processor cores.
> 
> Signed-off-by: Yang Wang 
> Signed-off-by: Ran Wang 
> Signed-off-by: YunFeng Yang 
> Signed-off-by: YaXing Guo 
> Cc: Leif Lindholm 
> Cc: Michael D Kinney 
> Cc: Sunil V L 
> Cc: Daniel Schaefer 
> 
> ---
>  V2:This solution is changed to EDK2 as the payload of opensbi.
> 
>  Platform/Bosc/Readme.md   |  61 ++
>  .../XiangshanSeriesPkg/NanhuDev/NanhuDev.dsc  | 552 ++
>  .../XiangshanSeriesPkg/NanhuDev/NanhuDev.fdf  | 241 
>  .../NanhuDev/NanhuDev.fdf.inc |  62 ++
>  .../NanhuDev/VarStore.fdf.inc |  77 +++
>  Silicon/Bosc/NanHuPkg/NanHuDevPkg.dec |  31 +
>  Silicon/Bosc/NanHuPkg/NanHuPkg.uni|  13 +
>  Silicon/Bosc/NanHuPkg/NanHuPkgExtra.uni   |  13 +
>  8 files changed, 1050 insertions(+)
>  create mode 100644 Platform/Bosc/Readme.md
>  create mode 100644 Platform/Bosc/XiangshanSeriesPkg/NanhuDev/NanhuDev.dsc
>  create mode 100644 Platform/Bosc/XiangshanSeriesPkg/NanhuDev/NanhuDev.fdf
>  create mode 100644 Platform/Bosc/XiangshanSeriesPkg/NanhuDev/NanhuDev.fdf.inc
>  create mode 100644 Platform/Bosc/XiangshanSeriesPkg/NanhuDev/VarStore.fdf.inc
>  create mode 100644 Silicon/Bosc/NanHuPkg/NanHuDevPkg.dec
>  create mode 100644 Silicon/Bosc/NanHuPkg/NanHuPkg.uni
>  create mode 100644 Silicon/Bosc/NanHuPkg/NanHuPkgExtra.uni
> 
Acked-by: Sunil V L  


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118017): https://edk2.groups.io/g/devel/message/118017
Mute This Topic: https://groups.io/mt/105437172/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] NetworkPkg/HttpBootDxe: Correctly uninstall HttpBootCallbackProtocol

2024-04-19 Thread Mike Beaton

Dear Michael,

I don't know if you had time to answer one follow-up question.

Obviously one thing that someone might want to do is to notify on protocol 
installs and trap installs of this protocol - e.g. so that something other than 
UefiBootManagerLib can manage and monitor HTTP boot, but still allowing the 
original callback to occur, by hooking it. Not sure if this counts as 
'supported' or not (possibly not...) though I think it may count as 'quite 
likely to happen'. However, one could hook in such a way that the uninstall 
would succeed anyway, assuming that the function pointer within the original 
installed protocol is writeable.

My question is: was the above is roughly what you were thinking of, that might 
cause the assert to fail, or, if not, if you had the time to give a very brief 
sketch of what else it might be (just a plausible, very rough example)? 
Certainly not saying you're wrong, just that it would be helpful (to me!) to 
understand what sort of thing you were thinking of!

Many thanks in advance for any time you might have to reply.

Mike Beaton


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118016): https://edk2.groups.io/g/devel/message/118016
Mute This Topic: https://groups.io/mt/105368366/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/2] Platform/AMD: Add AmdSvsmLib to required DSC files

2024-04-19 Thread Ard Biesheuvel

On Fri, 19 Apr 2024 at 11:06, Xing, Eric  wrote:
>
> [AMD Official Use Only - General]
>
> Hi Ard,
>
> This checkin causes VanGoghBoard build fail now. Would you help revert it?
> I will merge PATCH to VanGoghBoard after the code review process done and 
> code changes are verified pass on real board.
>

Please provide a solution instead that makes upstream edk2 work with
upstream edk2-platforms.

For downstream builds, you can combine the old EDK2_202208 with an
older checkout of edk2-platforms, right?


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118015): https://edk2.groups.io/g/devel/message/118015
Mute This Topic: https://groups.io/mt/105537744/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/2] Platform/AMD: Add AmdSvsmLib to required DSC files

2024-04-19 Thread Xing, Eric via groups.io

[AMD Official Use Only - General]

Hi Ard,

This checkin causes VanGoghBoard build fail now. Would you help revert it?
I will merge PATCH to VanGoghBoard after the code review process done and code 
changes are verified pass on real board.

Thanks,
Eric

> -Original Message-
> From: Ard Biesheuvel 
> Sent: Friday, April 19, 2024 4:27 PM
> To: devel@edk2.groups.io; Xing, Eric 
> Cc: Zhai, MingXin (Duke) ; Lendacky, Thomas
> ; Chang, Abner ;
> Yao, Ken ; Roth, Michael ;
> Attar, AbdulLateef (Abdul Lateef) ; Ard
> Biesheuvel ; Gerd Hoffmann
> ; Min Xu ; Leif Lindholm
> 
> Subject: Re: [edk2-devel] [PATCH 1/2] Platform/AMD: Add AmdSvsmLib to
> required DSC files
>
> Caution: This message originated from an External Source. Use proper
> caution when opening attachments, clicking links, or responding.
>
>
> On Fri, 19 Apr 2024 at 10:10, Xing, Eric via groups.io
>  wrote:
> >
> > [AMD Official Use Only - General]
> >
> >
> > Thanks Duke.
> >
> >
> >
> > Hi Thomas,
> >
> >
> >
> > PATCH1/2 still cannot be checked in because today’s VanGoghBoard is
> based off EDK2_202208. Please hold on this PATCH check in.
> >
> >
>
> Apologies, but I already merged this patch two days ago.
>
> edk2-platforms should build in combination with edk2. If your platform has
> other dependencies that are not in edk2, edk2-platforms or edk2-non-osi,
> please host and maintain the platform elsewhere.
>
> I also noticed that
> Platform/AMD/VanGoghBoard/ChachaniBoardPkg/build.sh requires that the
> various repo checkouts are inside the workspace, but the BaseTools don't
> actually require this. Personally, I use
>
> $HOME/edk2-workspace for the builds
>
> $HOME/edk2
> $HOME/edk2-platforms
> $HOME/edk2-non-osi
>
> for the checkouts, which keeps things separate, and allow me to wipe the
> workspace entirely without touching the repos.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118014): https://edk2.groups.io/g/devel/message/118014
Mute This Topic: https://groups.io/mt/105537744/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-libc Patch 2 1/1] ek2-libc: wrmsr function available in edk2module is not working as expected

2024-04-19 Thread Jayaprakash, N

Thanks Mike as suggested made the logic simpler.
Sent the updated v3 patch for review.

Regards,
JP

-Original Message-
From: Kinney, Michael D  
Sent: Friday, April 19, 2024 2:35 AM
To: Jayaprakash, N ; devel@edk2.groups.io
Cc: Rebecca Cran ; Kinney, Michael D 

Subject: RE: [edk2-libc Patch 2 1/1] ek2-libc: wrmsr function available in 
edk2module is not working as expected

The use of BitFieldOr64() is really only required when updating a portion of a 
32-bit or 64-bit value that are not aligned on a 32-bit boundary and do not 
have a 32-bit aligned width.  Since this use case is setting the lower 32-bits, 
simpler logic should be used.

  data = LShiftU64(vedx, 32) | veax;

Mike

> -Original Message-
> From: Jayaprakash, N 
> Sent: Thursday, April 18, 2024 5:55 AM
> To: devel@edk2.groups.io
> Cc: Jayaprakash, N ; Rebecca Cran 
> ; Kinney, Michael D 
> Subject: [edk2-libc Patch 2 1/1] ek2-libc: wrmsr function available in 
> edk2module is not working as expected
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4745
> 
> This commit fixes the issue reported in the BZ4745.
> The wrmsr was always writing 0 to the higher 32 bits of the msr 
> register.
> This was due to a logical flaw in the code, where the input variable 
> of type unsigned int was left shitted by 32 bits without explicitly 
> converting it to a 64 bit value.
> 
> The issue is with the below statement.
> data = vedx << 32 | veax;
> Where the vedx which is an unsigned int, after left shifting by 32 
> bits its value will be set to 0. Because of this the higher 32 bits of 
> the MSR are always set to 0. This has been fixed by this commit.
> 
> Cc: Rebecca Cran 
> Cc: Michael D Kinney 
> Cc: Jayaprakash N 
> Signed-off-by: Jayaprakash N 
> ---
>  .../Python/Python-3.6.8/PyMod-3.6.8/Modules/edk2module.c   | 3
> ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/AppPkg/Applications/Python/Python-3.6.8/PyMod-
> 3.6.8/Modules/edk2module.c b/AppPkg/Applications/Python/Python-
> 3.6.8/PyMod-3.6.8/Modules/edk2module.c
> index 8786df8..06bcf82 100644
> --- a/AppPkg/Applications/Python/Python-3.6.8/PyMod-
> 3.6.8/Modules/edk2module.c
> +++ b/AppPkg/Applications/Python/Python-3.6.8/PyMod-
> 3.6.8/Modules/edk2module.c
> @@ -3886,7 +3886,8 @@ edk2_wrmsr(PyObject *self, PyObject *args)
>UINT64   data = 0;
>if (!PyArg_ParseTuple(args, "III", , , ))
>  return NULL;
> -  data = vedx << 32 | veax;
> +  data = LShiftU64(vedx, 32);
> +  data = BitFieldOr64(data, 0, 31, veax);
>Py_BEGIN_ALLOW_THREADS
>AsmWriteMsr64(vecx, data);
>Py_END_ALLOW_THREADS
> --
> 2.44.0.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118013): https://edk2.groups.io/g/devel/message/118013
Mute This Topic: https://groups.io/mt/105597214/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-libc Patch v3 0/1] wrmsr function is not working as expected

2024-04-19 Thread Jayaprakash, N

The wrmsr function always writes 0s to the higher 32 bits of the msr register.
This PR fixes this issue reported through the BZ4745

Jayaprakash N (1):
  ek2-libc: wrmsr function available in edk2module is not working as
expected

 .../Python/Python-3.6.8/PyMod-3.6.8/Modules/edk2module.c| 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.44.0.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118011): https://edk2.groups.io/g/devel/message/118011
Mute This Topic: https://groups.io/mt/105614475/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-libc Patch v3 1/1] ek2-libc: wrmsr function available in edk2module is not working as expected

2024-04-19 Thread Jayaprakash, N

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

This commit fixes the issue reported in the BZ4745.
The wrmsr was always writing 0 to the higher 32 bits of the msr register.
This was due to a logical flaw in the code, where the input variable of
type unsigned int was left shitted by 32 bits without explicitly
converting it to a 64 bit value.

The issue is with the below statement.
data = vedx << 32 | veax;
Where the vedx which is an unsigned int, after left shifting by 32 bits
its value will be set to 0. Because of this the higher 32 bits of the MSR
are always set to 0. This has been fixed by this commit.

Cc: Rebecca Cran 
Cc: Michael D Kinney 
Cc: Jayaprakash N 
Signed-off-by: Jayaprakash N 
---
 .../Python/Python-3.6.8/PyMod-3.6.8/Modules/edk2module.c| 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/AppPkg/Applications/Python/Python-3.6.8/PyMod-3.6.8/Modules/edk2module.c 
b/AppPkg/Applications/Python/Python-3.6.8/PyMod-3.6.8/Modules/edk2module.c
index d6af8da..f688b51 100644
--- a/AppPkg/Applications/Python/Python-3.6.8/PyMod-3.6.8/Modules/edk2module.c
+++ b/AppPkg/Applications/Python/Python-3.6.8/PyMod-3.6.8/Modules/edk2module.c
@@ -3886,7 +3886,7 @@ edk2_wrmsr(PyObject *self, PyObject *args)
   UINT64   data = 0;
   if (!PyArg_ParseTuple(args, "III", , , ))
 return NULL;
-  data = vedx << 32 | veax;
+  data = LShiftU64(vedx, 32) | veax;
   Py_BEGIN_ALLOW_THREADS
   AsmWriteMsr64(vecx, data);
   Py_END_ALLOW_THREADS
-- 
2.44.0.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118012): https://edk2.groups.io/g/devel/message/118012
Mute This Topic: https://groups.io/mt/105614477/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/2] Platform/AMD: Add AmdSvsmLib to required DSC files

2024-04-19 Thread Ard Biesheuvel

On Fri, 19 Apr 2024 at 10:10, Xing, Eric via groups.io
 wrote:
>
> [AMD Official Use Only - General]
>
>
> Thanks Duke.
>
>
>
> Hi Thomas,
>
>
>
> PATCH1/2 still cannot be checked in because today’s VanGoghBoard is based off 
> EDK2_202208. Please hold on this PATCH check in.
>
>

Apologies, but I already merged this patch two days ago.

edk2-platforms should build in combination with edk2. If your platform
has other dependencies that are not in edk2, edk2-platforms or
edk2-non-osi, please host and maintain the platform elsewhere.

I also noticed that
Platform/AMD/VanGoghBoard/ChachaniBoardPkg/build.sh requires that the
various repo checkouts are inside the workspace, but the BaseTools
don't actually require this. Personally, I use

$HOME/edk2-workspace for the builds

$HOME/edk2
$HOME/edk2-platforms
$HOME/edk2-non-osi

for the checkouts, which keeps things separate, and allow me to wipe
the workspace entirely without touching the repos.

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118010): https://edk2.groups.io/g/devel/message/118010
Mute This Topic: https://groups.io/mt/105537744/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/2] Platform/AMD: Add AmdSvsmLib to required DSC files

2024-04-19 Thread Xing, Eric via groups.io

[AMD Official Use Only - General]


Thanks Duke.



Hi Thomas,



PATCH1/2 still cannot be checked in because today’s VanGoghBoard is based off 
EDK2_202208. Please hold on this PATCH check in.



Added my comments below.



Thanks,

Eric



> -Original Message-

> From: Zhai, MingXin (Duke) 

> Sent: Friday, April 19, 2024 3:06 PM

> To: Lendacky, Thomas ; Xing, Eric

> ; Chang, Abner ; Yao, Ken

> ; devel@edk2.groups.io

> Cc: Roth, Michael ; Attar, AbdulLateef (Abdul

> Lateef) ; Ard Biesheuvel

> ; Gerd Hoffmann ; Min

> Xu ; Leif Lindholm ; Leif

> Lindholm 

> Subject: RE: [PATCH 1/2] Platform/AMD: Add AmdSvsmLib to required DSC

> files

>

> [AMD Official Use Only - General]

>

> Hi Thomas,

>

> Yes, I agree with your opinion,  edk2-platforms should be able to build

> against the latest edk2 repo. That is why we plan to update VanGoghBoard to

> support latest EDK2, In fact we are doing QA testing.

[Xing, Eric] It is incorrect for edk2-platforms board code. We will not verify 
edk2-platform build test with latest edk2. See my comments below.

> I think every change on VanGoghBoard need ensure system can works

> properly. But if I apply this patch and use the latest EDK2 version to build, 
> it

> will encounter error because it requires other code changes(Such as including

> new libraries).

> So my point is, Let me upload VanGoghBoard related changes after passing

> full QA testing.

>

>

> Thanks!

>

> -Original Message-

> From: Lendacky, Thomas 
> mailto:thomas.lenda...@amd.com>>

> Sent: Friday, April 19, 2024 12:03 AM

> To: Zhai, MingXin (Duke) mailto:duke.z...@amd.com>>; Xing, 
> Eric

> mailto:eric.x...@amd.com>>; Chang, Abner 
> mailto:abner.ch...@amd.com>>; Yao, Ken

> mailto:ken@amd.com>>

> Cc: Roth, Michael mailto:michael.r...@amd.com>>; Attar, 
> AbdulLateef (Abdul

> Lateef) mailto:abdullateef.at...@amd.com>>

> Subject: Re: [PATCH 1/2] Platform/AMD: Add AmdSvsmLib to required DSC

> files

>

> On 4/18/24 05:02, Zhai, MingXin (Duke) wrote:

> > [AMD Official Use Only - General]

> >

> > Hi Thomas,

> >

> > this patch looks like for newer EDK2 codebase, but VanGoghBoard is based

> on EDK2_202208 now, and will encounter build issues if this patch is applied.

> > We have plans to update the EDK2 codebase to EDK2_202402. So I thought

> > it would be better to add this change when we update the EDK2 code

> > base

>

> I thought the latest edk2-platforms repo was supposed to be able to build

> against the latest edk2 repo.

[Xing, Eric] No. It will easily impact edk2-platforms BIOS if we pull in the 
latest edk2 repo. So, edk2-platforms will pull in a stable edk2 tag instead of 
latest edk2 repo.

>If your VanGoghBoard is based on a particular

> edk2 tag, then you should probably have a tag in edk2-platforms so that you

> can have a version of the edk2-platform code that works with a version of

> the edk2 code, no?

[Xing, Eric] I don’t think we will create tag for VanGoghBoard. Instead, we 
will have user guide/readme to let user know which EDK2 tag is supported in 
current board code.

The board code owner can decide when to update edk2 kernel and which Tage. I 
think it is the same for ALL board code, not only VanGoghBoard.

>

> Why is this a private email? This discussion should be on the list so that the

> maintainer(s) can decide what to do based on the discussion.

>

> Thanks,

> Tom

>

> >

> >

> > Thanks!

> >

> > -Original Message-

> > From: Xing, Eric mailto:eric.x...@amd.com>>

> > Sent: Thursday, April 18, 2024 9:54 AM

> > To: Chang, Abner mailto:abner.ch...@amd.com>>; 
> > Lendacky, Thomas

> > mailto:thomas.lenda...@amd.com>>; 
> > devel@edk2.groups.io; Zhai, MingXin

> (Duke)

> > mailto:duke.z...@amd.com>>; Yao, Ken 
> > mailto:ken@amd.com>>

> > Cc: Ard Biesheuvel 
> > mailto:ardb+tianoc...@kernel.org>>; Gerd Hoffmann

> > mailto:kra...@redhat.com>>; Roth, Michael 
> > mailto:michael.r...@amd.com>>; Min Xu

> > mailto:min.m...@intel.com>>; Leif Lindholm 
> > mailto:quic_llind...@quicinc.com>>;

> > Michael D Kinney 
> > mailto:michael.d.kin...@intel.com>>; Attar, 
> > AbdulLateef

> > (Abdul Lateef) mailto:abdullateef.at...@amd.com>>

> > Subject: RE: [PATCH 1/2] Platform/AMD: Add AmdSvsmLib to required DSC

> > files

> >

> > [AMD Official Use Only - General]

> >

> > Thanks Thomas and Abner.

> > Reviewed-by: mailto:eric.x...@amd.com>>

> >

> > For up-stream, please let us verify it first:

> > @Zhai, MingXin (Duke), Duke, please help verify this change on Chachani

> Board and feedback.

> >

> > Thanks,

> > Eric

> >

> >> -Original Message-

> >> From: Chang, Abner mailto:abner.ch...@amd.com>>

> >> Sent: Thursday, April 18, 2024 8:59 AM

> >> To: Lendacky, Thomas 
> >> mailto:thomas.lenda...@amd.com>>;

> devel@edk2.groups.io

> >> Cc: Ard Biesheuvel 
> >> mailto:ardb+tianoc...@kernel.org>>; Gerd 
> >> Hoffmann

> >>

Re: [edk2-devel] [PATCH V3 6/6] Maintainers.txt: Update maintainer for SPI modules

2024-04-19 Thread Chang, Abner via groups.io

[AMD Official Use Only - General]

Hi edk2 stewards,
Per off-line discussion with Ray Ni, he considers Liming's RB is good enough 
for this patch set. Please help to review this and give your RB to the 
maintainship of MdeModulePkg/Bus/Spi If you don't have concerns.

Thank you!
Abner


> -Original Message-
> From: Chang, Abner
> Sent: Thursday, April 11, 2024 9:38 AM
> To: devel@edk2.groups.io
> Cc: Michael D Kinney ; Andrew Fish
> ; Leif Lindholm ; Attar,
> AbdulLateef (Abdul Lateef) ; Chesley, Brit
> ; Jian J Wang ; Liming Gao
> ; Hao A Wu ; Ray Ni
> ; Zhiguang Liu 
> Subject: RE: [edk2-devel] [PATCH V3 6/6] Maintainers.txt: Update maintainer
> for SPI modules
>
> Hi maintainers,
> Please help to check this update as we added an entry for Bus\Spi under
> MdeModulePkg.
>
> Thanks
> Abner
>
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Chang,
> > Abner via groups.io
> > Sent: Sunday, August 13, 2023 12:37 PM
> > To: devel@edk2.groups.io
> > Cc: Michael D Kinney ; Andrew Fish
> > ; Leif Lindholm ; Attar,
> > AbdulLateef (Abdul Lateef) ; Chesley, Brit
> > ; Jian J Wang ; Liming Gao
> > ; Hao A Wu ; Ray Ni
> > ; Zhiguang Liu 
> > Subject: [edk2-devel] [PATCH V3 6/6] Maintainers.txt: Update maintainer for
> > SPI modules
> >
> > Caution: This message originated from an External Source. Use proper
> > caution when opening attachments, clicking links, or responding.
> >
> >
> > From: Abner Chang 
> >
> > Add maintainer entry of MdeModulePkg/Bus/Spi.
> >
> > Cc: Michael D Kinney 
> > Cc: Andrew Fish 
> > Cc: Leif Lindholm 
> > Cc: Abdul Lateef Attar 
> > Cc: Brit Chesley 
> > Cc: Jian J Wang 
> > Cc: Liming Gao 
> > Cc: Hao A Wu 
> > Cc: Ray Ni 
> > Cc: Zhiguang Liu 
> > Signed-off-by: Abner Chang 
> > ---
> >  Maintainers.txt | 5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/Maintainers.txt b/Maintainers.txt
> > index 5a95929a14b..a6a5a9b4e03 100644
> > --- a/Maintainers.txt
> > +++ b/Maintainers.txt
> > @@ -443,6 +443,11 @@ F:
> > MdeModulePkg/Include/Protocol/UsbEthernetProtocol.h
> >  M: Richard Ho  [richardho]
> >  R: Rebecca Cran  [bcran]
> >
> > +MdeModulePkg: SPI Bus modules
> > +F: MdeModulePkg/Bus/Spi
> > +M: Abner Chang  [changab]
> > +R: Brit Chesley  [BritChesley]
> > +
> >  MdePkg
> >  F: MdePkg/
> >  W: https://github.com/tianocore/tianocore.github.io/wiki/MdePkg
> > --
> > 2.37.1.windows.1
> >
> >
> >
> > 
> >



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118008): https://edk2.groups.io/g/devel/message/118008
Mute This Topic: https://groups.io/mt/105455146/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/2] Platform/AMD: Add AmdSvsmLib to required DSC files

2024-04-19 Thread Zhai, MingXin (Duke) via groups.io

[AMD Official Use Only - General]

Hi Thomas,

Yes, I agree with your opinion,  edk2-platforms should be able to build against 
the latest edk2 repo. That is why we plan to update VanGoghBoard to support 
latest EDK2, In fact we are doing QA testing.
I think every change on VanGoghBoard need ensure system can works properly. But 
if I apply this patch and use the latest EDK2 version to build, it will 
encounter error because it requires other code changes(Such as including new 
libraries).
So my point is, Let me upload VanGoghBoard related changes after passing full 
QA testing.


Thanks!

-Original Message-
From: Lendacky, Thomas 
Sent: Friday, April 19, 2024 12:03 AM
To: Zhai, MingXin (Duke) ; Xing, Eric ; 
Chang, Abner ; Yao, Ken 
Cc: Roth, Michael ; Attar, AbdulLateef (Abdul Lateef) 

Subject: Re: [PATCH 1/2] Platform/AMD: Add AmdSvsmLib to required DSC files

On 4/18/24 05:02, Zhai, MingXin (Duke) wrote:
> [AMD Official Use Only - General]
>
> Hi Thomas,
>
> this patch looks like for newer EDK2 codebase, but VanGoghBoard is based on 
> EDK2_202208 now, and will encounter build issues if this patch is applied.
> We have plans to update the EDK2 codebase to EDK2_202402. So I thought
> it would be better to add this change when we update the EDK2 code
> base

I thought the latest edk2-platforms repo was supposed to be able to build 
against the latest edk2 repo. If your VanGoghBoard is based on a particular 
edk2 tag, then you should probably have a tag in edk2-platforms so that you can 
have a version of the edk2-platform code that works with a version of the edk2 
code, no?

Why is this a private email? This discussion should be on the list so that the 
maintainer(s) can decide what to do based on the discussion.

Thanks,
Tom

>
>
> Thanks!
>
> -Original Message-
> From: Xing, Eric 
> Sent: Thursday, April 18, 2024 9:54 AM
> To: Chang, Abner ; Lendacky, Thomas
> ; devel@edk2.groups.io; Zhai, MingXin (Duke)
> ; Yao, Ken 
> Cc: Ard Biesheuvel ; Gerd Hoffmann
> ; Roth, Michael ; Min Xu
> ; Leif Lindholm ;
> Michael D Kinney ; Attar, AbdulLateef
> (Abdul Lateef) 
> Subject: RE: [PATCH 1/2] Platform/AMD: Add AmdSvsmLib to required DSC
> files
>
> [AMD Official Use Only - General]
>
> Thanks Thomas and Abner.
> Reviewed-by: 
>
> For up-stream, please let us verify it first:
> @Zhai, MingXin (Duke), Duke, please help verify this change on Chachani Board 
> and feedback.
>
> Thanks,
> Eric
>
>> -Original Message-
>> From: Chang, Abner 
>> Sent: Thursday, April 18, 2024 8:59 AM
>> To: Lendacky, Thomas ; devel@edk2.groups.io
>> Cc: Ard Biesheuvel ; Gerd Hoffmann
>> ; Roth, Michael ; Min Xu
>> ; Leif Lindholm ;
>> Michael D Kinney ; Attar, AbdulLateef
>> (Abdul
>> Lateef) ; Xing, Eric 
>> Subject: RE: [PATCH 1/2] Platform/AMD: Add AmdSvsmLib to required DSC
>> files
>>
>> [AMD Official Use Only - General]
>>
>> Reviewed-by: 
>>
>> Thanks
>>
>>> -Original Message-
>>> From: Lendacky, Thomas 
>>> Sent: Monday, April 15, 2024 11:01 PM
>>> To: devel@edk2.groups.io
>>> Cc: Ard Biesheuvel ; Gerd Hoffmann
>>> ; Roth, Michael ; Min Xu
>>> ; Leif Lindholm ;
>>> Michael D Kinney ; Chang, Abner
>>> ; Attar, AbdulLateef (Abdul Lateef)
>>> ; Xing, Eric 
>>> Subject: [PATCH 1/2] Platform/AMD: Add AmdSvsmLib to required DSC
>>> files
>>>
>>> Any DSC file that uses the UefiCpuPkg MpInitLib library now requires
>>> the AmdSvsmLib library. Update the DSC files to include the
>>> AmdSvsmLib NULL library implementation. Also, fix the specification
>>> of VmgExitLib as it was renamed to CcExitLib.
>>>
>>> Cc: Abner Chang 
>>> Cc: Abdul Lateef Attar 
>>> Cc: Eric Xing 
>>> Signed-off-by: Tom Lendacky 
>>> ---
>>>   Platform/AMD/VanGoghBoard/ChachaniBoardPkg/Project.dsc | 3 ++-
>>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/Platform/AMD/VanGoghBoard/ChachaniBoardPkg/Project.dsc
>>> b/Platform/AMD/VanGoghBoard/ChachaniBoardPkg/Project.dsc
>>> index 20f06dd851..e478e0b0c2 100644
>>> --- a/Platform/AMD/VanGoghBoard/ChachaniBoardPkg/Project.dsc
>>> +++ b/Platform/AMD/VanGoghBoard/ChachaniBoardPkg/Project.dsc
>>> @@ -371,7 +371,8 @@
>>>
>>>   [LibraryClasses.common]
>>>
>>> RegisterFilterLib|MdePkg/Library/RegisterFilterLibNull/RegisterFilte
>>> RegisterFilterLib|rL
>>> RegisterFilterLib|ibNull.inf
>>> -  VmgExitLib|UefiCpuPkg/Library/VmgExitLibNull/VmgExitLibNull.inf
>>> +  CcExitLib|UefiCpuPkg/Library/CcExitLibNull/CcExitLibNull.inf
>>> +  AmdSvsmLib|UefiCpuPkg/Library/AmdSvsmLibNull/AmdSvsmLibNull.inf
>>>
>>>   [PcdsFixedAtBuild]
>>>
>> gEfiAmdAgesaPkgTokenSpaceGuid.PcdFchOemBeforePciRestoreSwSmi|0xEA
>>> --
>>> 2.43.2
>>
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118007): https://edk2.groups.io/g/devel/message/118007
Mute This Topic: https://groups.io/mt/105537744/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] MdeModulePkg: Fix MAT SplitRecord() Logic introduce one bug and will cause SUT reset when boot to windows

2024-04-19 Thread Ni, Ray



So this is just junk unallocated memory that we are reporting as
a type it *could* be if an allocation occurs to minimize failures
of ExitBootServices. Which is questionable. But in terms of
attributes, I would expect we either have this unallocated
memory marked the same as the bin type or better, mark it RP
if we can (Taylor is making a change to set RP on free memory
by default, so we would have this in the page table, but we
would need to decide what we tell the OS).

[Ray] When reviewing today's logic of memory protection through page table, I 
feel that it was designed improperly in the beginning.
My rough thought is:
* All memory is RP initially (as you said Taylor will do that)
* Allocated memory is mapped as either RO or XD, depending on code/data. Or RP 
if it's a guard page.

Maybe I am not aware of some limitations of the above idea. The limitations 
prevented the initial design be in this way.
Or what Taylor will do aligns to the idea?

Thanks,
Ray


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118006): https://edk2.groups.io/g/devel/message/118006
Mute This Topic: https://groups.io/mt/105477564/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

42 matches

Mail list logo