[edk2-devel] Call for TianoCore Community Meeting topics
Hi, Are there any topics for the TianoCore community meeting this month? Thanks, Mike -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#119468): https://edk2.groups.io/g/devel/message/119468 Mute This Topic: https://groups.io/mt/106498468/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [edk2-platforms][PATCH 1/1] Ampere/JadePkg: Add secure boot default keys initialization
Could you help push my patch to Tianocore/edk2-platforms once approved, while I don't have write permission? Thanks, Nhi On 6/5/2024 11:10 AM, Rebecca Cran wrote: Reviewed-by: Rebecca Cran -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#119467): https://edk2.groups.io/g/devel/message/119467 Mute This Topic: https://groups.io/mt/106495161/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] Cancelled Event: TianoCore Bug Triage - APAC / NAMO - Wednesday, June 5, 2024 #cal-cancelled
BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Groups.io Inc//Groups.io Calendar//EN METHOD:CANCEL REFRESH-INTERVAL;VALUE=DURATION:PT1H X-PUBLISHED-TTL:PT1H CALSCALE:GREGORIAN BEGIN:VTIMEZONE TZID:America/Los_Angeles LAST-MODIFIED:20240422T053451Z TZURL:https://www.tzurl.org/zoneinfo-outlook/America/Los_Angeles X-LIC-LOCATION:America/Los_Angeles BEGIN:DAYLIGHT TZNAME:PDT TZOFFSETFROM:-0800 TZOFFSETTO:-0700 DTSTART:19700308T02 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU END:DAYLIGHT BEGIN:STANDARD TZNAME:PST TZOFFSETFROM:-0700 TZOFFSETTO:-0800 DTSTART:19701101T02 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU END:STANDARD END:VTIMEZONE BEGIN:VEVENT X-GIOIDS:Event:2324065 UID:mlda.1580078539586725120.r...@groups.io DTSTAMP:20240605T042042Z ORGANIZER;CN=Liming Gao;SENT-BY="mailto:gaolim...@byosoft.com.cn":mailto: gaolim...@byosoft.com.cn DTSTART:20240606T003000Z DTEND:20240606T013000Z SUMMARY:TianoCore Bug Triage - APAC / NAMO DESCRIPTION:TianoCore Bug Triage - APAC / NAMO\n\nHosted by Liming Gao\n\ n \n\nMicrosoft Teams meeting\n\n*Join on your computer or mobile a pp*\n\nClick here to join the meeting ( https://teams.microsoft.com/l/mee tup-join/19%3ameeting_OTk1YzJhN2UtOGQwNi00NjY4LWEwMTktY2JiODRlYTY1NmY0%40 thread.v2/0?context=%7b%22Tid%22%3a%2246c98d88-e344-4ed4-8496-4ed7712e255 d%22%2c%22Oid%22%3a%226e4ce4c4-1242-431b-9a51-92cd01a5df3c%22%7d )\n\n*Jo in with a video conferencing device*\n\nte...@conf.intel.com\n\nVideo Con ference ID: 116 062 094 0\n\nAlternate VTC dialing instructions ( https:/ /conf.intel.com/teams/?conf=1160620940&ivr=teams&d=conf.intel.com&test=te st_call )\n\n*Or call in (audio only)*\n\n+1 916-245-6934\,\,77463821# ( tel:+19162456934\,\,77463821# ) United States\, Sacramento\n\nPhone Confe rence ID: 774 638 21#\n\nFind a local number ( https://dialin.teams.micro soft.com/d195d438-2daa-420e-b9ea-da26f9d1d6d5?id=77463821 ) | Reset PIN ( https://mysettings.lync.com/pstnconferencing )\n\nLearn More ( https://a ka.ms/JoinTeamsMeeting ) | Meeting options ( https://teams.microsoft.com/ meetingOptions/?organizerId=b286b53a-1218-4db3-bfc9-3d4c5aa7669e&tenantId =46c98d88-e344-4ed4-8496-4ed7712e255d&threadId=19_meeting_OTUyZTg2NjgtNDh lNS00ODVlLTllYTUtYzg1OTNjNjdiZjFh@thread.v2&messageId=0&language=en-US ) LOCATION:https://teams.microsoft.com/l/meetup-join/19%3ameeting_OTk1YzJhN 2UtOGQwNi00NjY4LWEwMTktY2JiODRlYTY1NmY0%40thread.v2/0?context=%7b%22Tid%2 2%3a%2246c98d88-e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%226e4ce4c4- 1242-431b-9a51-92cd01a5df3c%22%7d SEQUENCE:1 STATUS:CANCELLED END:VEVENT END:VCALENDAR invite.ics Description: application/ics
Re: [edk2-devel] [edk2-platforms][PATCH 1/1] Ampere/JadePkg: Add secure boot default keys initialization
Reviewed-by: Rebecca Cran -- Rebecca Cran On 6/4/2024 6:57 PM, Nhi Pham wrote: This allows to initialize secure boot with the default factory keys embedded in firmware flash image. For example, to incorporate PK, KEK, and DB default keys, specify the corresponding key files in the Jade.dsc as follows: DEFINE DEFAULT_KEYS= TRUE DEFINE PK_DEFAULT_FILE = path/to/PK.crt DEFINE KEK_DEFAULT_FILE1 = path/to/KEK.crt DEFINE DB_DEFAULT_FILE1= path/to/DB1.crt DEFINE DB_DEFAULT_FILE2= path/to/DB2.crt Signed-off-by: Nhi Pham --- Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc | 2 ++ Platform/Ampere/JadePkg/Jade.fdf | 2 ++ 2 files changed, 4 insertions(+) diff --git a/Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc b/Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc index 23579497661d..93b4d1d99dcd 100644 --- a/Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc +++ b/Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc @@ -590,6 +590,8 @@ [Components.common] !if $(SECURE_BOOT_ENABLE) == TRUE SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf + SecurityPkg/EnrollFromDefaultKeysApp/EnrollFromDefaultKeysApp.inf + SecurityPkg/VariableAuthenticated/SecureBootDefaultKeysDxe/SecureBootDefaultKeysDxe.inf !endif MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf diff --git a/Platform/Ampere/JadePkg/Jade.fdf b/Platform/Ampere/JadePkg/Jade.fdf index 7795f0e5..1e2df5ba6142 100644 --- a/Platform/Ampere/JadePkg/Jade.fdf +++ b/Platform/Ampere/JadePkg/Jade.fdf @@ -219,7 +219,9 @@ [FV.FvMain] INF MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf INF MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf !if $(SECURE_BOOT_ENABLE) == TRUE +!include ArmPlatformPkg/SecureBootDefaultKeys.fdf.inc INF SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf + INF SecurityPkg/VariableAuthenticated/SecureBootDefaultKeysDxe/SecureBootDefaultKeysDxe.inf !endif INF MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf INF EmbeddedPkg/ResetRuntimeDxe/ResetRuntimeDxe.inf -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#119465): https://edk2.groups.io/g/devel/message/119465 Mute This Topic: https://groups.io/mt/106495161/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH ovmf v4 5/5] OvmfPkf: Enable AMD SEV-ES DebugVirtualization
Write the feature bit into PcdConfidentialComputingGuestAttr
and enable DebugVirtualization in PEI, SEC, DXE.
Cc: Ard Biesheuvel
Cc: Erdem Aktas
Cc: Gerd Hoffmann
Cc: Jiewen Yao
Cc: Michael Roth
Cc: Min Xu
Cc: Tom Lendacky
Signed-off-by: Alexey Kardashevskiy
---
Changes:
v4:
* s/DebugSwap/DebugVirtualization/g
* the feature is enabled here for all modes
---
OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLibInternal.c | 6 +-
OvmfPkg/Library/BaseMemEncryptSevLib/SecMemEncryptSevLibInternal.c | 6 +-
OvmfPkg/PlatformPei/AmdSev.c | 13
++---
3 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLibInternal.c
b/OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLibInternal.c
index 7d823ad639f4..f381b9255bb7 100644
--- a/OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLibInternal.c
+++ b/OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLibInternal.c
@@ -154,5 +154,9 @@ MemEncryptSevEsDebugVirtualizationIsEnabled (
VOID
)
{
- return FALSE;
+ MSR_SEV_STATUS_REGISTER Msr;
+
+ Msr.Uint32 = InternalMemEncryptSevStatus ();
+
+ return Msr.Bits.DebugVirtualization ? TRUE : FALSE;
}
diff --git a/OvmfPkg/Library/BaseMemEncryptSevLib/SecMemEncryptSevLibInternal.c
b/OvmfPkg/Library/BaseMemEncryptSevLib/SecMemEncryptSevLibInternal.c
index 33a326ac1571..946bed2ada13 100644
--- a/OvmfPkg/Library/BaseMemEncryptSevLib/SecMemEncryptSevLibInternal.c
+++ b/OvmfPkg/Library/BaseMemEncryptSevLib/SecMemEncryptSevLibInternal.c
@@ -154,7 +154,11 @@ MemEncryptSevEsDebugVirtualizationIsEnabled (
VOID
)
{
- return FALSE;
+ MSR_SEV_STATUS_REGISTER Msr;
+
+ Msr.Uint32 = InternalMemEncryptSevStatus ();
+
+ return Msr.Bits.DebugVirtualization ? TRUE : FALSE;
}
/**
diff --git a/OvmfPkg/PlatformPei/AmdSev.c b/OvmfPkg/PlatformPei/AmdSev.c
index 88ca14507f5e..8562787035db 100644
--- a/OvmfPkg/PlatformPei/AmdSev.c
+++ b/OvmfPkg/PlatformPei/AmdSev.c
@@ -434,6 +434,7 @@ AmdSevInitialize (
)
{
UINT64 EncryptionMask;
+ UINT64 CCGuestAttr;
RETURN_STATUS PcdStatus;
//
@@ -517,13 +518,19 @@ AmdSevInitialize (
// technology is active.
//
if (MemEncryptSevSnpIsEnabled ()) {
-PcdStatus = PcdSet64S (PcdConfidentialComputingGuestAttr, CCAttrAmdSevSnp);
+CCGuestAttr = CCAttrAmdSevSnp;
} else if (MemEncryptSevEsIsEnabled ()) {
-PcdStatus = PcdSet64S (PcdConfidentialComputingGuestAttr, CCAttrAmdSevEs);
+CCGuestAttr = CCAttrAmdSevEs;
} else {
-PcdStatus = PcdSet64S (PcdConfidentialComputingGuestAttr, CCAttrAmdSev);
+CCGuestAttr = CCAttrAmdSev;
}
+ if (MemEncryptSevEsDebugVirtualizationIsEnabled ()) {
+CCGuestAttr |= CCAttrFeatureAmdSevEsDebugVirtualization;
+ }
+
+ PcdStatus = PcdSet64S (PcdConfidentialComputingGuestAttr, CCGuestAttr);
+
ASSERT_RETURN_ERROR (PcdStatus);
}
--
2.44.0
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119463): https://edk2.groups.io/g/devel/message/119463
Mute This Topic: https://groups.io/mt/106496092/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH ovmf v4 4/5] UefiCpuPkg: Add AMD SEV-ES features support
CONFIDENTIAL_COMPUTING_GUEST_ATTR is not a simple SEV level anymore
and includes a feature mask since the previous commit.
Fix AmdMemEncryptionAttrCheck to check the level and feature
correctly and add DebugVirtualization support.
Since the actual feature flag is not set yet, this should cause
no behavioural change.
Cc: Gerd Hoffmann
Cc: Jiaxin Wu
Cc: Rahul Kumar
Cc: Ray Ni
Cc: Tom Lendacky
Signed-off-by: Alexey Kardashevskiy
---
UefiCpuPkg/Library/MpInitLib/MpLib.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c
b/UefiCpuPkg/Library/MpInitLib/MpLib.c
index f97298887f96..444df2abdc1d 100644
--- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
+++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
@@ -3196,19 +3196,25 @@ AmdMemEncryptionAttrCheck (
IN CONFIDENTIAL_COMPUTING_GUEST_ATTR Attr
)
{
+ UINT64 CurrentLevel;
+
+ CurrentLevel = CurrentAttr & CCAttrTypeMask;
+
switch (Attr) {
case CCAttrAmdSev:
//
// SEV is automatically enabled if SEV-ES or SEV-SNP is active.
//
- return CurrentAttr >= CCAttrAmdSev;
+ return CurrentLevel >= CCAttrAmdSev;
case CCAttrAmdSevEs:
//
// SEV-ES is automatically enabled if SEV-SNP is active.
//
- return CurrentAttr >= CCAttrAmdSevEs;
+ return CurrentLevel >= CCAttrAmdSevEs;
case CCAttrAmdSevSnp:
- return CurrentAttr == CCAttrAmdSevSnp;
+ return CurrentLevel == CCAttrAmdSevSnp;
+case CCAttrFeatureAmdSevEsDebugVirtualization:
+ return !!(CurrentAttr & CCAttrFeatureAmdSevEsDebugVirtualization);
default:
return FALSE;
}
--
2.44.0
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119462): https://edk2.groups.io/g/devel/message/119462
Mute This Topic: https://groups.io/mt/106496089/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH ovmf v4 3/5] OvmfPkg: Add AMD SEV-ES DebugVirtualization feature support
The SEV-ES DebugVirtualization feature enables type B swapping of
debug registers on #VMEXIT and makes #DB and DR7 intercepts
unnecessary and unwanted.
When DebugVirtualization is enabled, this stops booting if
#VC for #DB or DB7 read/write occurs as this signals unwanted
interaction from the HV.
Add new API to PEI, SEC, DXE.
This does not change the existing behaviour yet.
Cc: Ard Biesheuvel
Cc: Erdem Aktas
Cc: Gerd Hoffmann
Cc: Jiewen Yao
Cc: Michael Roth
Cc: Min Xu
Cc: Tom Lendacky
Signed-off-by: Alexey Kardashevskiy
---
Changes:
v4:
* s/DebugSwap/DebugVirtualization/
---
OvmfPkg/Include/Library/MemEncryptSevLib.h | 12
+
OvmfPkg/Library/BaseMemEncryptSevLib/DxeMemEncryptSevLibInternal.c | 27
+---
OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLibInternal.c | 15
+++
OvmfPkg/Library/BaseMemEncryptSevLib/SecMemEncryptSevLibInternal.c | 15
+++
OvmfPkg/Library/CcExitLib/CcExitVcHandler.c| 8 ++
5 files changed, 74 insertions(+), 3 deletions(-)
diff --git a/OvmfPkg/Include/Library/MemEncryptSevLib.h
b/OvmfPkg/Include/Library/MemEncryptSevLib.h
index 4fa9c0d70083..c5653539d8d8 100644
--- a/OvmfPkg/Include/Library/MemEncryptSevLib.h
+++ b/OvmfPkg/Include/Library/MemEncryptSevLib.h
@@ -166,6 +166,18 @@ MemEncryptSevGetEncryptionMask (
VOID
);
+/**
+ Returns a boolean to indicate whether DebugVirtualization is enabled.
+
+ @retval TRUE DebugVirtualization is enabled
+ @retval FALSE DebugVirtualization is not enabled
+**/
+BOOLEAN
+EFIAPI
+MemEncryptSevEsDebugVirtualizationIsEnabled (
+ VOID
+ );
+
/**
Returns the encryption state of the specified virtual address range.
diff --git a/OvmfPkg/Library/BaseMemEncryptSevLib/DxeMemEncryptSevLibInternal.c
b/OvmfPkg/Library/BaseMemEncryptSevLib/DxeMemEncryptSevLibInternal.c
index 4aba0075b9e2..9947d663deae 100644
--- a/OvmfPkg/Library/BaseMemEncryptSevLib/DxeMemEncryptSevLibInternal.c
+++ b/OvmfPkg/Library/BaseMemEncryptSevLib/DxeMemEncryptSevLibInternal.c
@@ -40,19 +40,25 @@ AmdMemEncryptionAttrCheck (
IN CONFIDENTIAL_COMPUTING_GUEST_ATTR Attr
)
{
+ UINT64 CurrentLevel;
+
+ CurrentLevel = CurrentAttr & CCAttrTypeMask;
+
switch (Attr) {
case CCAttrAmdSev:
//
// SEV is automatically enabled if SEV-ES or SEV-SNP is active.
//
- return CurrentAttr >= CCAttrAmdSev;
+ return CurrentLevel >= CCAttrAmdSev;
case CCAttrAmdSevEs:
//
// SEV-ES is automatically enabled if SEV-SNP is active.
//
- return CurrentAttr >= CCAttrAmdSevEs;
+ return CurrentLevel >= CCAttrAmdSevEs;
case CCAttrAmdSevSnp:
- return CurrentAttr == CCAttrAmdSevSnp;
+ return CurrentLevel == CCAttrAmdSevSnp;
+case CCAttrFeatureAmdSevEsDebugVirtualization:
+ return !!(CurrentAttr & CCAttrFeatureAmdSevEsDebugVirtualization);
default:
return FALSE;
}
@@ -159,3 +165,18 @@ MemEncryptSevGetEncryptionMask (
return mSevEncryptionMask;
}
+
+/**
+ Returns a boolean to indicate whether DebugVirtualization is enabled.
+
+ @retval TRUE DebugVirtualization is enabled
+ @retval FALSE DebugVirtualization is not enabled
+**/
+BOOLEAN
+EFIAPI
+MemEncryptSevEsDebugVirtualizationIsEnabled (
+ VOID
+ )
+{
+ return ConfidentialComputingGuestHas
(CCAttrFeatureAmdSevEsDebugVirtualization);
+}
diff --git a/OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLibInternal.c
b/OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLibInternal.c
index 41d1246a5b31..7d823ad639f4 100644
--- a/OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLibInternal.c
+++ b/OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLibInternal.c
@@ -141,3 +141,18 @@ MemEncryptSevGetEncryptionMask (
return SevEsWorkArea->EncryptionMask;
}
+
+/**
+ Returns a boolean to indicate whether DebugVirtualization is enabled.
+
+ @retval TRUE DebugVirtualization is enabled
+ @retval FALSE DebugVirtualization is not enabled
+**/
+BOOLEAN
+EFIAPI
+MemEncryptSevEsDebugVirtualizationIsEnabled (
+ VOID
+ )
+{
+ return FALSE;
+}
diff --git a/OvmfPkg/Library/BaseMemEncryptSevLib/SecMemEncryptSevLibInternal.c
b/OvmfPkg/Library/BaseMemEncryptSevLib/SecMemEncryptSevLibInternal.c
index 27148c7e337a..33a326ac1571 100644
--- a/OvmfPkg/Library/BaseMemEncryptSevLib/SecMemEncryptSevLibInternal.c
+++ b/OvmfPkg/Library/BaseMemEncryptSevLib/SecMemEncryptSevLibInternal.c
@@ -142,6 +142,21 @@ MemEncryptSevGetEncryptionMask (
return SevEsWorkArea->EncryptionMask;
}
+/**
+ Returns a boolean to indicate whether DebugVirtualization is enabled.
+
+ @retval TRUE DebugVirtualization is enabled
+ @retval FALSE DebugVirtualization is not enabled
+**/
+BOOLEAN
+EFIAPI
+MemEncryptSevEsDebugVirtualizationIsEnabled (
+ VOID
+ )
+{
+ return FALSE;
+}
+
/**
Locate the page range that covers the initial (pre-SMBASE-relocation) SMRA
[edk2-devel] [PATCH ovmf v4 2/5] MdePkg: Add AMD SEV features to PcdConfidentialComputingGuestAttr
PcdConfidentialComputingGuestAttr so far only contained an SEV mode bit
but there are more other features which do not translate to levels
such as DebugVirtualization or SecureTsc.
Add the feature mask and the DebugVirtualization feature bit to the PCD.
Cc: Liming Gao
Cc: Michael D Kinney
Cc: Zhiguang Liu
Reviewed-by: Tom Lendacky
Signed-off-by: Alexey Kardashevskiy
---
Changes:
v4:
* s/CCAttrFeatureAmdSevDebugSwap/CCAttrFeatureAmdSevEsDebugVirtualization/
v2:
* expanded features mask
* added type mask
---
MdePkg/Include/ConfidentialComputingGuestAttr.h | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/MdePkg/Include/ConfidentialComputingGuestAttr.h
b/MdePkg/Include/ConfidentialComputingGuestAttr.h
index 44e6df800207..f62158f77e03 100644
--- a/MdePkg/Include/ConfidentialComputingGuestAttr.h
+++ b/MdePkg/Include/ConfidentialComputingGuestAttr.h
@@ -29,9 +29,20 @@ typedef enum {
/* The guest is running with Intel TDX memory encryption enabled. */
CCAttrIntelTdx = 0x200,
+
+ CCAttrTypeMask = 0x,
+
+ /* Features */
+
+ /* The AMD SEV-ES DebugVirtualization feature is enabled in SEV_STATUS */
+ CCAttrFeatureAmdSevEsDebugVirtualization = 0x0001,
+
+ CCAttrFeatureMask = 0x,
} CONFIDENTIAL_COMPUTING_GUEST_ATTR;
-#define CC_GUEST_IS_TDX(x) ((x) == CCAttrIntelTdx)
-#define CC_GUEST_IS_SEV(x) ((x) == CCAttrAmdSev || (x) == CCAttrAmdSevEs ||
(x) == CCAttrAmdSevSnp)
+#define _CC_GUEST_IS_TDX(x) ((x) == CCAttrIntelTdx)
+#define CC_GUEST_IS_TDX(x) _CC_GUEST_IS_TDX((x) & CCAttrTypeMask)
+#define _CC_GUEST_IS_SEV(x) ((x) == CCAttrAmdSev || (x) == CCAttrAmdSevEs ||
(x) == CCAttrAmdSevSnp)
+#define CC_GUEST_IS_SEV(x) _CC_GUEST_IS_SEV((x) & CCAttrTypeMask)
#endif
--
2.44.0
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119460): https://edk2.groups.io/g/devel/message/119460
Mute This Topic: https://groups.io/mt/106496083/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH ovmf v4 1/5] MdePkg/Register/Amd: Define all bits from MSR_SEV_STATUS_REGISTER
For now we need DebugSwap but others are likely to be needed too.
Cc: Tom Lendacky
Cc: Liming Gao
Cc: Michael D Kinney
Cc: Zhiguang Liu
Signed-off-by: Alexey Kardashevskiy
---
Changes:
v4:
* added more from April/2024 APM
---
MdePkg/Include/Register/Amd/Fam17Msr.h | 95 +++-
1 file changed, 91 insertions(+), 4 deletions(-)
diff --git a/MdePkg/Include/Register/Amd/Fam17Msr.h
b/MdePkg/Include/Register/Amd/Fam17Msr.h
index f2d5ccb39dc7..286b337f70fa 100644
--- a/MdePkg/Include/Register/Amd/Fam17Msr.h
+++ b/MdePkg/Include/Register/Amd/Fam17Msr.h
@@ -126,19 +126,106 @@ typedef union {
///
/// [Bit 0] Secure Encrypted Virtualization (Sev) is enabled
///
-UINT32SevBit: 1;
+UINT32SevBit : 1;
///
/// [Bit 1] Secure Encrypted Virtualization Encrypted State (SevEs) is
enabled
///
-UINT32SevEsBit : 1;
+UINT32SevEsBit: 1;
///
/// [Bit 2] Secure Nested Paging (SevSnp) is enabled
///
-UINT32SevSnpBit : 1;
+UINT32SevSnpBit : 1;
-UINT32Reserved2 : 29;
+///
+/// [Bit 3] Virtual TOM feature is enabled in SEV_FEATURES[1]
+///
+UINT32vTOM: 1;
+
+///
+/// [Bit 4] ReflectVC feature is enabled in SEV_FEATURES[2]
+///
+UINT32ReflectVC : 1;
+
+///
+/// [Bit 5] Restricted Injection feature is enabled in SEV_FEATURES[3]
+///
+UINT32RestrictedInjection : 1;
+
+///
+/// [Bit 6] Alternate Injection feature is enabled in SEV_FEATURES[4]
+///
+UINT32AlternateInjection : 1;
+
+///
+/// [Bit 7] Debug Virtualization feature is enabled in SEV_FEATURES[5]
+///
+UINT32DebugVirtualization : 1;
+
+///
+/// [Bit 8] PreventHostIBS feature is enabled in SEV_FEATURES[6]
+///
+UINT32PreventHostIBS : 1;
+
+///
+/// [Bit 9] BTB isolation feature is enabled in SEV_FEATURES[7]
+///
+UINT32SNPBTBIsolation : 1;
+
+///
+/// [Bit 10] VMPL SSS feature is enabled in SEV_FEATURES[8]
+///
+UINT32VmplSSS : 1;
+
+///
+/// [Bit 11] Secure TSC feature is enabled in SEV_FEATURES[9]
+///
+UINT32SecureTsc : 1;
+
+///
+/// [Bit 12] VMGEXIT Parameter feature is enabled in SEV_FEATURES[10]
+///
+UINT32VmgexitParameter: 1;
+
+///
+/// [Bit 13] PMC Virtualization feature is enabled in SEV_FEATURES[11]
+///
+UINT32PmcVirtualization : 1;
+
+///
+/// [Bit 14] IBS Virtualization feature is enabled in SEV_FEATURES[12]
+///
+UINT32IbsVirtualization : 1;
+
+///
+/// [Bit 15]
+///
+UINT32Reserved1 : 1;
+
+///
+/// [Bit 16] VMSA Register Protection feature is enabled in
SEV_FEATURES[14]
+///
+UINT32VmsaRegProt : 1;
+
+///
+/// [Bit 17] SMT Protection feature is enabled in SEV_FEATURES[15]
+///
+UINT32SmtProtection : 1;
+///
+///
+/// [Bit 18] Secure AVIC feature is enabled in SEV_FEATURES[16]
+///
+UINT32SecureAVIC : 1;
+
+UINT32Reserved2 : 4;
+
+///
+/// [Bit 23] IBPB on Entry feature is enabled in SEV_FEATURES[21]
+///
+UINT32IbpbOnEntry : 1;
+
+UINT32Reserved3 : 8;
} Bits;
///
/// All bit fields as a 32-bit value
--
2.44.0
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119459): https://edk2.groups.io/g/devel/message/119459
Mute This Topic: https://groups.io/mt/106496074/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH ovmf v4 0/5] Enable AMD SEV-ES DebugVirtualization
This is to prevent #DB interception on SEV-ES VM with enabled DebugVirtualization feature. The previous conversation is here: https://edk2.groups.io/g/devel/topic/patch_ovmf_v3_0_5_enable/105863808 This is based on sha1 7772e339bdbb Chao Li "ArmVirtPkg: Enable the non-hardcode version FdtNorFlashQemuLib". Please comment. Thanks. Alexey Kardashevskiy (5): MdePkg/Register/Amd: Define all bits from MSR_SEV_STATUS_REGISTER MdePkg: Add AMD SEV features to PcdConfidentialComputingGuestAttr OvmfPkg: Add AMD SEV-ES DebugVirtualization feature support UefiCpuPkg: Add AMD SEV-ES features support OvmfPkf: Enable AMD SEV-ES DebugVirtualization MdePkg/Include/ConfidentialComputingGuestAttr.h| 15 +++- MdePkg/Include/Register/Amd/Fam17Msr.h | 95 +++- OvmfPkg/Include/Library/MemEncryptSevLib.h | 12 +++ OvmfPkg/Library/BaseMemEncryptSevLib/DxeMemEncryptSevLibInternal.c | 27 +- OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLibInternal.c | 19 OvmfPkg/Library/BaseMemEncryptSevLib/SecMemEncryptSevLibInternal.c | 19 OvmfPkg/Library/CcExitLib/CcExitVcHandler.c| 8 ++ OvmfPkg/PlatformPei/AmdSev.c | 13 ++- UefiCpuPkg/Library/MpInitLib/MpLib.c | 12 ++- 9 files changed, 205 insertions(+), 15 deletions(-) -- 2.44.0 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#119458): https://edk2.groups.io/g/devel/message/119458 Mute This Topic: https://groups.io/mt/106496065/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [edk2-platforms][PATCH 1/1] Ampere/JadePkg: Add secure boot default keys initialization
This allows to initialize secure boot with the default factory keys embedded in firmware flash image. For example, to incorporate PK, KEK, and DB default keys, specify the corresponding key files in the Jade.dsc as follows: DEFINE DEFAULT_KEYS= TRUE DEFINE PK_DEFAULT_FILE = path/to/PK.crt DEFINE KEK_DEFAULT_FILE1 = path/to/KEK.crt DEFINE DB_DEFAULT_FILE1= path/to/DB1.crt DEFINE DB_DEFAULT_FILE2= path/to/DB2.crt Signed-off-by: Nhi Pham --- Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc | 2 ++ Platform/Ampere/JadePkg/Jade.fdf | 2 ++ 2 files changed, 4 insertions(+) diff --git a/Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc b/Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc index 23579497661d..93b4d1d99dcd 100644 --- a/Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc +++ b/Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc @@ -590,6 +590,8 @@ [Components.common] !if $(SECURE_BOOT_ENABLE) == TRUE SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf + SecurityPkg/EnrollFromDefaultKeysApp/EnrollFromDefaultKeysApp.inf + SecurityPkg/VariableAuthenticated/SecureBootDefaultKeysDxe/SecureBootDefaultKeysDxe.inf !endif MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf diff --git a/Platform/Ampere/JadePkg/Jade.fdf b/Platform/Ampere/JadePkg/Jade.fdf index 7795f0e5..1e2df5ba6142 100644 --- a/Platform/Ampere/JadePkg/Jade.fdf +++ b/Platform/Ampere/JadePkg/Jade.fdf @@ -219,7 +219,9 @@ [FV.FvMain] INF MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf INF MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf !if $(SECURE_BOOT_ENABLE) == TRUE +!include ArmPlatformPkg/SecureBootDefaultKeys.fdf.inc INF SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf + INF SecurityPkg/VariableAuthenticated/SecureBootDefaultKeysDxe/SecureBootDefaultKeysDxe.inf !endif INF MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf INF EmbeddedPkg/ResetRuntimeDxe/ResetRuntimeDxe.inf -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#119455): https://edk2.groups.io/g/devel/message/119455 Mute This Topic: https://groups.io/mt/106495161/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] Event: TianoCore Bug Triage - APAC / NAMO - Wednesday, June 5, 2024 #cal-reminder
*Reminder: TianoCore Bug Triage - APAC / NAMO* *When:* Wednesday, June 5, 2024 5:30pm to 6:30pm (UTC-07:00) America/Los Angeles *Where:* https://teams.microsoft.com/l/meetup-join/19%3ameeting_OTk1YzJhN2UtOGQwNi00NjY4LWEwMTktY2JiODRlYTY1NmY0%40thread.v2/0?context=%7b%22Tid%22%3a%2246c98d88-e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%226e4ce4c4-1242-431b-9a51-92cd01a5df3c%22%7d *Organizer:* Liming Gao gaolim...@byosoft.com.cn ( gaolim...@byosoft.com.cn?subject=Re:%20Event:%20TianoCore%20Bug%20Triage%20-%20APAC%20%2F%20NAMO ) View Event ( https://edk2.groups.io/g/devel/viewevent?eventid=2324065 ) *Description:* TianoCore Bug Triage - APAC / NAMO Hosted by Liming Gao Microsoft Teams meeting *Join on your computer or mobile app* Click here to join the meeting ( https://teams.microsoft.com/l/meetup-join/19%3ameeting_OTk1YzJhN2UtOGQwNi00NjY4LWEwMTktY2JiODRlYTY1NmY0%40thread.v2/0?context=%7b%22Tid%22%3a%2246c98d88-e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%226e4ce4c4-1242-431b-9a51-92cd01a5df3c%22%7d ) *Join with a video conferencing device* te...@conf.intel.com Video Conference ID: 116 062 094 0 Alternate VTC dialing instructions ( https://conf.intel.com/teams/?conf=1160620940&ivr=teams&d=conf.intel.com&test=test_call ) *Or call in (audio only)* +1 916-245-6934,,77463821# ( tel:+19162456934,,77463821# ) United States, Sacramento Phone Conference ID: 774 638 21# Find a local number ( https://dialin.teams.microsoft.com/d195d438-2daa-420e-b9ea-da26f9d1d6d5?id=77463821 ) | Reset PIN ( https://mysettings.lync.com/pstnconferencing ) Learn More ( https://aka.ms/JoinTeamsMeeting ) | Meeting options ( https://teams.microsoft.com/meetingOptions/?organizerId=b286b53a-1218-4db3-bfc9-3d4c5aa7669e&tenantId=46c98d88-e344-4ed4-8496-4ed7712e255d&threadId=19_meeting_OTUyZTg2NjgtNDhlNS00ODVlLTllYTUtYzg1OTNjNjdiZjFh@thread.v2&messageId=0&language=en-US ) -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#119454): https://edk2.groups.io/g/devel/message/119454 Mute This Topic: https://groups.io/mt/106494771/21656 Mute #cal-reminder:https://edk2.groups.io/g/devel/mutehashtag/cal-reminder Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v1 0/1] EDK2-Test: Bug 4244 - SCT improvement - Print out the PCIe device path
Here's the PR for your convenience: https://github.com/tianocore/edk2-test/pull/96 From: devel@edk2.groups.io on behalf of Prachotan Bathi via groups.io Sent: Monday, June 3, 2024 1:27 PM To: devel@edk2.groups.io Cc: G Edhaya Chandran ; Barton Gao ; Carolyn Gjertsen ; Samer El-Haj-Mahmoud ; Eric Jin ; Arvin Chen ; Supreeth Venkatesh Subject: [edk2-devel] [PATCH v1 0/1] EDK2-Test: Bug 4244 - SCT improvement - Print out the PCIe device path Worked on the following protocols’ test cases as we have seen PCIe card UEFI driver related failures with these test cases: EFI_HII_CONFIG_ACCESS_PROTOCOL EFI_ADAPTER_INFORMATION_PROTOCOL EFI_SIMPLE_NETWORK_PROTOCOL EFI_PXE_BASE_CODE_PROTOCOL Output of a failed PCIe test Auto Conformance Test for Arp Logfile: "\EFI\BOOT\bbr\SCT\Overall\Summary.log" Test Started: 02/16/23 05:04p EFI_PXE_BASE_CODE_PROTOCOL.Start - Check Return Code -- FAILURE 6A8CAA83-B9DA-46C7-98F6-D4969DABDAA0 /home/cherat01/ATEG/SystemReady/SystemReady/arm-systemready/SR/scripts/edk2-test/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/PxeBaseCode/BlackBoxTest/PxeBaseCodeBBTestConformance.c:2140:Status - Unsupported Returned Status Code: Unsupported Arp_Conf: [FAILED] Passes... 0 Warnings. 0 Errors... 1 We want to see message like COMPONENT_NAME2_PROTOCOL test case having the message in red to show what device/driver was tested. Conformance Test for GetControllerName Logfile: "\EFI\BOOT\bbr\SCT\Overall\Summary.log" Test Started: 02/16/23 05:14p Device Path: Fv(5C60F367-A505-419A-859E-2A4FF6CA6FE5)/FvFile(F2AD0AD0-D4B6-11E3-9C1A-0800200C9A66) COMPONENT_NAME2_PROTOCOL.GetControllerName - GetControllerName() returns EFI_INVALID_PARAMETER with a NULL ControllerHandle -- FAILURE C38A85AF-2D0A-4BFA-8F44-A247F1FD7B94 /home/cherat01/ATEG/SystemReady/SystemReady/arm-systemready/SR/scripts/edk2-test/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/ComponentName2/BlackBoxTest/ComponentName2BBTestConformance.c:551: Language - en, Status - Success, NULL Found the device path from the protocol handle. Used SctDevicePathToStr(DevicePath) to print as str. Tested on rpi and AADP systems. https://github.com/PrachotanReddy/edk2-test Cc: G Edhaya Chandran Cc: Barton Gao Cc: Carolyn Gjertsen Cc: Samer El-Haj-Mahmoud Cc: Eric Jin Cc: Arvin Chen Cc: Supreeth Venkatesh Prachotan Bathi (1): EDK2-Test: Bug 4244 - SCT improvement - Print out the PCIe device path for PCIe card/device related SCT failures. uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/AdapterInfo/BlackBoxTest/AdapterInfoProtocolBBTest.inf |2 + uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/PxeBaseCode/BlackBoxTest/PxeBBTest.inf |3 +- uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleNetwork/BlackBoxTest/SimpleNetworkBBTest.inf |4 +- uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/AdapterInfo/BlackBoxTest/AdapterInfoBBTestMain.h | 17 +- uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/HIIConfigAccess/BlackBoxTest/HIIConfigAccessBBTestMain.h |6 + uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/PxeBaseCode/BlackBoxTest/PxeBaseCodeBBTestMain.h |6 + uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleNetwork/BlackBoxTest/SimpleNetworkBBTestMain.h |6 + uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/AdapterInfo/BlackBoxTest/AdapterInfoBBTestConformance.c | 63 +- uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/AdapterInfo/BlackBoxTest/AdapterInfoBBTestMain.c | 96 ++ uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/HIIConfigAccess/BlackBoxTest/HIIConfigAccessBBTestConformance.c | 48 +- uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/HIIConfigAccess/BlackBoxTest/HIIConfigAccessBBTestMain.c | 67 +- uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/PxeBaseCode/BlackBoxTest/PxeBaseCodeBBTestConformance.c | 305 +- uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/PxeBaseCode/BlackBoxTest/PxeBaseCodeBBTestMain.c | 1158 +--- uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleNetwork/BlackBoxTest/SimpleNetworkBBTestConformance.c | 258 - uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleNetwork/BlackBoxTest/SimpleNetworkBBTestMain.c | 96 ++ 15 files changed, 1451 insertions(+), 684 deletions(-) -- 2.34.1 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any
Re: [edk2-devel] [PATCH v4 6/6] UefiPayloadPkg: Update UefiPayload driver for FDT support.
I also believe this code needs to go through crustify etc to ensure it
follows all edk2 standards?
On Mon, Jun 3, 2024 at 4:57 PM Dhaval Sharma wrote:
> BuildFitLoadablesFvHob:
>
>- Fdt variable is not initialized.
>- It ONLY gets initialized if GuidHob is found. What if it is not
>found?
>- FdtCheckHeader still evaluating it?
>
>
> On Mon, Jun 3, 2024 at 7:49 AM Linus Liu wrote:
>
>> Add FDT detection and comsume FDT when needed.
>> Move some x86 specific function in the x86 folder.
>> Create HandOffHob via FDT memory node.
>>
>> Cc: Benny Lin
>> Cc: Gua Guo
>> Cc: Chasel Chiu
>> Cc: James Lu
>> Cc: Dhaval Sharma
>>
>> Signed-off-by: Linus Liu
>> ---
>> UefiPayloadPkg/UefiPayloadEntry/FitUniversalPayloadEntry.c
>> | 428 +---
>> UefiPayloadPkg/UefiPayloadEntry/Ia32/DxeLoadFunc.c
>> | 12 +
>> UefiPayloadPkg/UefiPayloadEntry/Ia32/{DxeLoadFunc.c => DxeLoadFuncFit.c}
>> | 32 +-
>> UefiPayloadPkg/UefiPayloadEntry/MemoryAllocation.c
>> | 50 +++
>> UefiPayloadPkg/UefiPayloadEntry/PrintHob.c
>> | 6 +-
>> UefiPayloadPkg/UefiPayloadEntry/UniversalPayloadEntry.c
>> | 6 -
>> UefiPayloadPkg/UefiPayloadEntry/X64/DxeLoadFunc.c
>> | 12 +
>> UefiPayloadPkg/UefiPayloadEntry/X64/{DxeLoadFunc.c => DxeLoadFuncFit.c}
>> | 31 +-
>> UefiPayloadPkg/UefiPayloadEntry/FitUniversalPayloadEntry.inf
>> | 20 +-
>> UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.h
>> | 68
>> UefiPayloadPkg/UefiPayloadEntry/UniversalPayloadEntry.inf
>> | 16 +-
>> UefiPayloadPkg/UefiPayloadPkg.dsc
>> | 29 +-
>> 12 files changed, 443 insertions(+), 267 deletions(-)
>>
>> diff --git a/UefiPayloadPkg/UefiPayloadEntry/FitUniversalPayloadEntry.c
>> b/UefiPayloadPkg/UefiPayloadEntry/FitUniversalPayloadEntry.c
>> index eb0b325369a0..813d656950d1 100644
>> --- a/UefiPayloadPkg/UefiPayloadEntry/FitUniversalPayloadEntry.c
>> +++ b/UefiPayloadPkg/UefiPayloadEntry/FitUniversalPayloadEntry.c
>> @@ -6,6 +6,8 @@
>> #include "UefiPayloadEntry.h"
>> #include
>> #include
>> +#include
>> +#include
>>
>> #define MEMORY_ATTRIBUTE_MASK (EFI_RESOURCE_ATTRIBUTE_PRESENT
>>|\
>>
>> EFI_RESOURCE_ATTRIBUTE_INITIALIZED | \
>> @@ -23,6 +25,15 @@
>>
>> EFI_RESOURCE_ATTRIBUTE_INITIALIZED | \
>> EFI_RESOURCE_ATTRIBUTE_TESTED
>> )
>>
>> +EFI_MEMORY_TYPE_INFORMATION mDefaultMemoryTypeInformation[] = {
>> + { EfiACPIReclaimMemory, FixedPcdGet32
>> (PcdMemoryTypeEfiACPIReclaimMemory) },
>> + { EfiACPIMemoryNVS, FixedPcdGet32
>> (PcdMemoryTypeEfiACPIMemoryNVS) },
>> + { EfiReservedMemoryType, FixedPcdGet32
>> (PcdMemoryTypeEfiReservedMemoryType) },
>> + { EfiRuntimeServicesData, FixedPcdGet32
>> (PcdMemoryTypeEfiRuntimeServicesData) },
>> + { EfiRuntimeServicesCode, FixedPcdGet32
>> (PcdMemoryTypeEfiRuntimeServicesCode) },
>> + { EfiMaxMemoryType, 0
>>}
>> +};
>> +
>> extern VOID *mHobList;
>>
>> CHAR8 *mLineBuffer = NULL;
>> @@ -36,6 +47,78 @@ PrintHob (
>>IN CONST VOID *HobStart
>>);
>>
>> +/**
>> + Add HOB into HOB list
>> + @param[in] HobThe HOB to be added into the HOB list.
>> +**/
>> +VOID
>> +AddNewHob (
>> + IN EFI_PEI_HOB_POINTERS *Hob
>> + );
>> +
>> +/**
>> + Found the Resource Descriptor HOB that contains a range (Base, Top)
>> + @param[in] HobListHob start address
>> + @param[in] Base Memory start address
>> + @param[in] TopMemory end address.
>> + @retval The pointer to the Resource Descriptor HOB.
>> +**/
>> +EFI_HOB_RESOURCE_DESCRIPTOR *
>> +FindResourceDescriptorByRange (
>> + IN VOID *HobList,
>> + IN EFI_PHYSICAL_ADDRESS Base,
>> + IN EFI_PHYSICAL_ADDRESS Top
>> + );
>> +
>> +/**
>> + Find the highest below 4G memory resource descriptor, except the input
>> Resource Descriptor.
>> + @param[in] HobList Hob start address
>> + @param[in] MinimalNeededSize Minimal needed size.
>> + @param[in] ExceptResourceHob Ignore this Resource Descriptor.
>> + @retval The pointer to the Resource Descriptor HOB.
>> +**/
>> +EFI_HOB_RESOURCE_DESCRIPTOR *
>> +FindAnotherHighestBelow4GResourceDescriptor (
>> + IN VOID *HobList,
>> + IN UINTNMinimalNeededSize,
>> + IN EFI_HOB_RESOURCE_DESCRIPTOR *ExceptResourceHob
>> + );
>> +
>> +/**
>> + Check the HOB and decide if it is need inside Payload
>> + Payload maintainer may make decision which HOB is need or needn't
>> + Then add the check logic in the function.
>> + @param[in] Hob The HOB to check
>> + @retval TRUE If HOB is need inside Payload
>> + @retval FALSE If HOB is needn't inside Payload
>> +**/
>> +BOOLEAN
>> +FitIsHobNeed (
>> + EFI_PEI_HOB_POINTERS Hob
>> + );
>> +
>> +/**
>> + Check the HOB and decide if it is need inside Payload
>> +
>> + Payload maintainer may make decision which HOB is need or needn't
>> + Then add the check logic in the function.
>> +
>> + @param[in] Hob Th
[edk2-devel] Steps in using RamDiskDxe?
Hello All, I am new to working with EDK2 and have just been able to compile it up on my Ubuntu 22.04 (x64) system. Some of my initial interest is in that I am wanting to learn all about using EDK2 as well as am seeming a UEFI Ramdisk in which I was able to build up the edk2 RamDiskDxe.efi and was able to load it from an uefi shell.efi cli which showed up a "FS2:" (in my case). The problem that I have is that I could not find any documentation as to anything like command-line parameters (i.e. set disk size, etc.) not could I locate any information on how to utilize the ramdisk since I would have to assume that it is not formatted for FAT, extFAT, or other filesystems and would need to be done before use, unless the RamDiskDxe code does that as part of the initialization which I do not know. Can someone please give me some guidance and steps to utilize the ramdisk from the shell.efi or from another efi that I will load as well? Any help would be greatly appreciated. Thanks in advance, Lonnie -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#119450): https://edk2.groups.io/g/devel/message/119450 Mute This Topic: https://groups.io/mt/106486224/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH] MdePkg: Remove non-ASCII characters from header file (BZ# 4775)
[AMD Official Use Only - AMD Internal Distribution Only]
Hi Liming,
Sorry for the late response. I already created a pull request for it.
https://github.com/tianocore/edk2/pull/5737
Regards,
Neo
From: gaoliming
Sent: Wednesday, May 15, 2024 8:08 PM
To: devel@edk2.groups.io ; Chang, Abner
; Hsueh, Hong-Chih (Neo)
Cc: michael.d.kin...@intel.com ;
zhiguang@intel.com ; He, Jiangang
Subject: 回复: [edk2-devel] [PATCH] MdePkg: Remove non-ASCII characters from
header file (BZ# 4775)
Caution: This message originated from an External Source. Use proper caution
when opening attachments, clicking links, or responding.
Abner:
This change is good to me. Reviewed-by: Liming Gao
But, this is not critical issue. So, I suggest to merge it after the stable
tag.
Thanks
Liming
> -邮件原件-
> 发件人: devel@edk2.groups.io 代表 Chang, Abner via
> groups.io
> 发送时间: 2024年5月16日 8:50
> 收件人: Hsueh, Hong-Chih (Neo) ;
> devel@edk2.groups.io
> 抄送: michael.d.kin...@intel.com; gaolim...@byosoft.com.cn;
> zhiguang@intel.com; He, Jiangang
> 主题: Re: [edk2-devel] [PATCH] MdePkg: Remove non-ASCII characters from
> header file (BZ# 4775)
>
> [AMD Official Use Only - AMD Internal Distribution Only]
>
> Hi Mike, Liming and Zhiguang,
> Could you please check this patch sent two weeks ago? The corresponding BZ
> ticket is 4775. We overlooked tracking this issue and missed the 202405 stable
> release. As this impacts the build, do you think we can have a quick review
> and
> approve it; having this change pulled in 202405 stable release? Otherwise we
> will
> have to wait until next stable release.
>
> Thanks
> Abner
>
> > -Original Message-
> > From: Hsueh, Hong-Chih (Neo)
> > Sent: Thursday, May 2, 2024 3:31 AM
> > To: devel@edk2.groups.io
> > Cc: michael.d.kin...@intel.com; gaolim...@byosoft.com.cn;
> > zhiguang@intel.com; He, Jiangang ; Chang,
> > Abner ; Hsueh, Hong-Chih (Neo) > chih.hs...@amd.com>
> > Subject: [PATCH] MdePkg: Remove non-ASCII characters from header file
> >
> > Cc: Jiangang He
> > Signed-off-by: Neo Hsueh
> > ---
> > MdePkg/Include/Register/Amd/Cpuid.h | 4 ++--
> > MdePkg/Include/Register/Intel/ArchitecturalMsr.h | 8
> > 2 files changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/MdePkg/Include/Register/Amd/Cpuid.h
> > b/MdePkg/Include/Register/Amd/Cpuid.h
> > index add43c40aa..51fa9f235c 100644
> > --- a/MdePkg/Include/Register/Amd/Cpuid.h
> > +++ b/MdePkg/Include/Register/Amd/Cpuid.h
> > @@ -46,9 +46,9 @@ CPUID Signature Information
> >CPUID Extended Topology Enumeration
> >
> >@note
> > - Reference: AMD64 Architecture Programmer’s Manual Volume 3: General-
> > Purpose and System Instructions,
> > + Reference: AMD64 Architecture Programmer's Manual Volume 3: General-
> > Purpose and System Instructions,
> > Revision 3.35 Appendix E,
> > - E.4.24 Function 8000_0026―Extended CPU Topology:
> > + E.4.24 Function 8000_0026-Extended CPU Topology:
> > CPUID Fn8000_0026 reports extended topology information for logical
> > processors, including
> > asymmetric and heterogenous topology descriptions. Individual logical
> > processors may report
> > different values in systems with asynchronous and heterogeneous
> > topologies.
> > diff --git a/MdePkg/Include/Register/Intel/ArchitecturalMsr.h
> > b/MdePkg/Include/Register/Intel/ArchitecturalMsr.h
> > index 756e7c86ec..4715c59dc4 100644
> > --- a/MdePkg/Include/Register/Intel/ArchitecturalMsr.h
> > +++ b/MdePkg/Include/Register/Intel/ArchitecturalMsr.h
> > @@ -5733,9 +5733,9 @@ typedef union {
> > /// [Bit 7:4] TME Policy/Encryption Algorithm: Only algorithms
> enumerated
> > in
> > /// IA32_TME_CAPABILITY are allowed.
> > /// For example:
> > -/// �C AES-XTS-128.
> > -/// 0001 �C AES-XTS-128 with integrity.
> > -/// 0010 �C AES-XTS-256.
> > +/// - AES-XTS-128.
> > +/// 0001 - AES-XTS-128 with integrity.
> > +/// 0010 - AES-XTS-256.
> > /// Other values are invalid.
> > ///
> > UINT32TmePolicy : 4;
> > @@ -5756,7 +5756,7 @@ typedef union {
> > /// Similar to enumeration, this is an encoded value.
> > /// Writing a value greater than MK_TME_MAX_KEYID_BITS will result in
> > #GP.
> > /// Writing a non-zero value to this field will #GP if bit 1 of EAX
> > (Hardware
> > -/// Encryption Enable) is not also set to ‘1, as encryption hardware
> > must
> be
> > +/// Encryption Enable) is not also set to 1, as encryption hardware
> > must
> be
> > /// enabled to use MKTME.
> > /// Example: To support 255 keys, this field would be set to a value
> > of 8.
> > ///
> > --
> > 2.40.0.windows.1
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119449): https://edk2.groups.io/g/devel/message/119449
Mute This Topic: https://groups.io/mt/106484939/21656
Group
Re: [edk2-devel] ArmCallSmc() and SMCCC specification
On Tue, 4 Jun 2024 at 14:37, Marcin Juszkiewicz
wrote:
>
> W dniu 3.06.2024 o 18:47, Leif Lindholm via groups.io pisze:
>
> >> In 2020 we got version C of spec (and then D, E, F) which allows to
> >> use more registers:
> >>
> >> > Allow R4—R7 (SMC32/HVC32) to be used as result registers.
> >> > Allow X8—X17 to be used as parameter registers in SMC64/HVC64.
> >> > Allow X4—X17 to be used as result registers in SMC64/HVC64.
> >>
> >> And I started to wonder how to update EDK2 to newer version of SMCCC
> >> spec as one of in-progress QemuSbsa SMC calls may return more than 4
> >> values.
> >
> > Yes, definitely. This has been a wishlist item for some time, but in
> > reality we've only ever updated these when we needed new functionality.
>
>
>
> >> ARM_SMC_ARGS in ArmSmcLib.h can be expanded to handle up to Arg17 in
> >> an easy way and guarded by "#if defined(__aarch64__)" to not change it
> >> on Arm32.
>
> My example code for it (including comment update):
>
> diff --git a/ArmPkg/Include/Library/ArmSmcLib.h
> b/ArmPkg/Include/Library/ArmSmcLib.h
> index beef0175c35c..af27781b72f6 100644
> --- a/ArmPkg/Include/Library/ArmSmcLib.h
> +++ b/ArmPkg/Include/Library/ArmSmcLib.h
> @@ -23,14 +23,31 @@ typedef struct {
> UINTNArg5;
> UINTNArg6;
> UINTNArg7;
> +#if defined(__aarch64__)
> + UINTNArg8;
> + UINTNArg9;
> + UINTNArg10;
> + UINTNArg11;
> + UINTNArg12;
> + UINTNArg13;
> + UINTNArg14;
> + UINTNArg15;
> + UINTNArg16;
> + UINTNArg17;
> +#endif
> } ARM_SMC_ARGS;
>
> /**
> Trigger an SMC call
>
> - SMC calls can take up to 7 arguments and return up to 4 return values.
> - Therefore, the 4 first fields in the ARM_SMC_ARGS structure are used
> - for both input and output values.
> + on SMC32/HVC32
> + - R0 is a function identifier, R1-R7 are arguments
> + - R0-R7 are results, R4-R7 must be preserved unless they contain results
> +
> +
> + on SMC64/HVC64
> + - W0 is a function identifier, X1-X17 are arguments
> + - X0-X17 are results, X4-X17 must be preserved unless they contain results
>
> **/
> VOID
>
>
> >> Then ArmCallSmc() in {AArch64,Arm}/ArmSmc.S needs changes. But here it
> >> gets tricky.
> >>
> >> On Arm we preserve r4-r8 and restore them after call like spec says.
> >> Which we do not do on AArch64 as version B of spec did not required
> >> that (and this changed in version C).
> >>
> >> If we start handling more than 4 results then we need to know how many
> >> results are expected and restore rest of r4-r7/x4-x17 registers:
> >
> > Yeah, it feels like we may want to add a version field or/and number of
> > registers to save/restore to a new struct. And we should definitely
> > align Arm/AArch64 behaviour.
>
>
>
>
> >> From what I saw in both edk2/ and edk2-platforms/ most of code uses
> >> ArmCallSmc() function with ARM_SMC_ARGS structure populared with
> >> arguments. ArmCallSmc[0-3]() are used by Smbios, Psci and QemuSbsa
> >> code only.
> >
> > The ArmCallSmc[0-3] helpers were only added as shorthand for most common
> > cases. I don't think we should worry about how those work for making any
> > design decisions. Everything they do can be described by the main
> > ArmCallSmc functions and a few lines of struct stuffing.
>
> >> Now the question is: how to handle change?
> >
> > It could be that it would be easiest to add a new call function, and
> > maybe even ra new egister struct, than trying to adapt the existing ones
> > in ways that doesn't break existing users?
> >
> > That is if we care about existing users. We could always modify it to
> > guarantee breakage and expect users to update their code. Since this is
> > a library, and not a protocol, we *mostly* don't need to worry about
> > users mixing prebuilt binaries using old structs with new functions.
>
> >> We could add ArmCallSmc[4-17] but that name only tells how many
> >> arguments we pass to SMC call, not how many results we expect. Or
> >> should we add NumberOfResults argument to ArmCallSmc() to know which
> >> registers we should preserve and which are results? And how
> >> complicated this assembly function will become?
> >
> > I don't think the assembly function needs to be that complicated. It'd
> > be a bit tedious with a bunch of tests, but...
>
> Note: I do not know aarch64 assembly. Did some changes to ArmCallSmc().
> I moved to use x18 register (preserved on stack) instead of x9 one. And
> changed code to handle 8 results (without preserving x4-x7).
>
You shouldn't use X18 - it is the so-called 'platform register' and
has a special meaning.
For example, this code could be called inside a runtime service
invoked by the OS with interrupts enabled, and the OS's interrupt
handler might misbehave if X18 was modified.
> diff --git a/ArmPkg/Library/ArmSmcLib/AArch64/ArmSmc.S
> b/ArmPkg/Library/ArmSmcLib/AArch64/ArmSmc.S
> index 4a8c2a8f59ea..0525a0a7887f 100644
> --- a/ArmPkg/Library/ArmSmcLib/AArch64/ArmSmc.S
> +++ b/ArmPkg/L
Re: [edk2-devel] GitHub PR Code Review process now active
On Mon, Jun 03, 2024 at 02:46:30PM GMT, Neal Gompa wrote: > That said, draft PRs cannot be reviewed, so we should not be telling > people to make draft PRs. It makes sense to open draft PRs, work in the PR until CI is clean, only then flip the PR to 'ready' and bother maintainers to review. take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#119447): https://edk2.groups.io/g/devel/message/119447 Mute This Topic: https://groups.io/mt/106355103/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] ArmCallSmc() and SMCCC specification
W dniu 3.06.2024 o 18:47, Leif Lindholm via groups.io pisze:
In 2020 we got version C of spec (and then D, E, F) which allows to
use more registers:
> Allow R4—R7 (SMC32/HVC32) to be used as result registers.
> Allow X8—X17 to be used as parameter registers in SMC64/HVC64.
> Allow X4—X17 to be used as result registers in SMC64/HVC64.
And I started to wonder how to update EDK2 to newer version of SMCCC
spec as one of in-progress QemuSbsa SMC calls may return more than 4
values.
Yes, definitely. This has been a wishlist item for some time, but in
reality we've only ever updated these when we needed new functionality.
ARM_SMC_ARGS in ArmSmcLib.h can be expanded to handle up to Arg17 in
an easy way and guarded by "#if defined(__aarch64__)" to not change it
on Arm32.
My example code for it (including comment update):
diff --git a/ArmPkg/Include/Library/ArmSmcLib.h
b/ArmPkg/Include/Library/ArmSmcLib.h
index beef0175c35c..af27781b72f6 100644
--- a/ArmPkg/Include/Library/ArmSmcLib.h
+++ b/ArmPkg/Include/Library/ArmSmcLib.h
@@ -23,14 +23,31 @@ typedef struct {
UINTNArg5;
UINTNArg6;
UINTNArg7;
+#if defined(__aarch64__)
+ UINTNArg8;
+ UINTNArg9;
+ UINTNArg10;
+ UINTNArg11;
+ UINTNArg12;
+ UINTNArg13;
+ UINTNArg14;
+ UINTNArg15;
+ UINTNArg16;
+ UINTNArg17;
+#endif
} ARM_SMC_ARGS;
/**
Trigger an SMC call
- SMC calls can take up to 7 arguments and return up to 4 return values.
- Therefore, the 4 first fields in the ARM_SMC_ARGS structure are used
- for both input and output values.
+ on SMC32/HVC32
+ - R0 is a function identifier, R1-R7 are arguments
+ - R0-R7 are results, R4-R7 must be preserved unless they contain results
+
+
+ on SMC64/HVC64
+ - W0 is a function identifier, X1-X17 are arguments
+ - X0-X17 are results, X4-X17 must be preserved unless they contain results
**/
VOID
Then ArmCallSmc() in {AArch64,Arm}/ArmSmc.S needs changes. But here it
gets tricky.
On Arm we preserve r4-r8 and restore them after call like spec says.
Which we do not do on AArch64 as version B of spec did not required
that (and this changed in version C).
If we start handling more than 4 results then we need to know how many
results are expected and restore rest of r4-r7/x4-x17 registers:
Yeah, it feels like we may want to add a version field or/and number of
registers to save/restore to a new struct. And we should definitely
align Arm/AArch64 behaviour.
From what I saw in both edk2/ and edk2-platforms/ most of code uses
ArmCallSmc() function with ARM_SMC_ARGS structure populared with
arguments. ArmCallSmc[0-3]() are used by Smbios, Psci and QemuSbsa
code only.
The ArmCallSmc[0-3] helpers were only added as shorthand for most common
cases. I don't think we should worry about how those work for making any
design decisions. Everything they do can be described by the main
ArmCallSmc functions and a few lines of struct stuffing.
Now the question is: how to handle change?
It could be that it would be easiest to add a new call function, and
maybe even ra new egister struct, than trying to adapt the existing ones
in ways that doesn't break existing users?
That is if we care about existing users. We could always modify it to
guarantee breakage and expect users to update their code. Since this is
a library, and not a protocol, we *mostly* don't need to worry about
users mixing prebuilt binaries using old structs with new functions.
We could add ArmCallSmc[4-17] but that name only tells how many
arguments we pass to SMC call, not how many results we expect. Or
should we add NumberOfResults argument to ArmCallSmc() to know which
registers we should preserve and which are results? And how
complicated this assembly function will become?
I don't think the assembly function needs to be that complicated. It'd
be a bit tedious with a bunch of tests, but...
Note: I do not know aarch64 assembly. Did some changes to ArmCallSmc().
I moved to use x18 register (preserved on stack) instead of x9 one. And
changed code to handle 8 results (without preserving x4-x7).
diff --git a/ArmPkg/Library/ArmSmcLib/AArch64/ArmSmc.S
b/ArmPkg/Library/ArmSmcLib/AArch64/ArmSmc.S
index 4a8c2a8f59ea..0525a0a7887f 100644
--- a/ArmPkg/Library/ArmSmcLib/AArch64/ArmSmc.S
+++ b/ArmPkg/Library/ArmSmcLib/AArch64/ArmSmc.S
@@ -8,8 +8,10 @@
#include
ASM_FUNC(ArmCallSmc)
+ // preserve x18
+ str x18, [sp, #-16]!
// Push x0 on the stack - The stack must always be quad-word aligned
- str x0, [sp, #-16]!
+ str x0, [sp, #-32]!
// Load the SMC arguments values into the appropriate registers
ldp x6, x7, [x0, #48]
@@ -19,14 +21,18 @@ ASM_FUNC(ArmCallSmc)
smc #0
- // Pop the ARM_SMC_ARGS structure address from the stack into x9
- ldr x9, [sp], #16
+ // Pop the ARM_SMC_ARGS structure address from the stack into x18
+ ldr x18, [sp], #32
// Store the SMC returned values into the ARM_SMC_ARGS struc
Re: [edk2-devel] [PATCH edk2-platforms v2 0/3] SbsaQemu: support multiple PCI Express buses
On Tue, Jun 04, 2024 at 09:23:30AM GMT, Marcin Juszkiewicz wrote: > W dniu 28.05.2024 o 16:31, Ard Biesheuvel pisze: > > I would expect each host bridge to have its own separate resource > > windows for config space, buses and MMIO regions. That isn't how qemu pxb-pcie host bridge works on x86 though. It does *not* create a separate pci domain and resources such as bus numbers are shared. > OK. I have to admit that I never checked how physical NUMA system handles > PCI Express. The code in patches was done by comparing with other QEMU > targets. It's probably not that easy. On x86 initialization works like this: (1) the firmware sets up bridge windows and pci bars. (2) qemu generates acpi tables with matching _CRS ranges. (3) the firmware downloads and installs the acpi tables. On arm qemu does the resource allocation for the root bridge windows and communicates them to the firmware via FDT, so stealing ideas from x86 probably isn't going to work very well. I think one option would be to have the firmware split the ranges it got and distribute them across the root bridges, program the root windows accordingly, generate acpi tables accordingly. Going for a separate pci domain with separate ecam and separate bus namespace and separate mmio ressources should be possible too, but that most likely will need a bunch of changes on the qemu side. HTH & take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#119445): https://edk2.groups.io/g/devel/message/119445 Mute This Topic: https://groups.io/mt/106345969/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH] CryptoPkg: Fix BaseCryptLib CrtWrapper strcpy
Ok thanks, I'll look at the other wrappers and do a PR.
Regards,
Sebastian
On Tue, 2024-06-04 at 07:28 +, Li, Yi1 wrote:
> Thanks for your patch, this is a known issue:
> https://bugzilla.tianocore.org/show_bug.cgi?id=2817
>
> Could you also update other wrappers in CrtWrapper.h and add BZ link to
> commit message?
>
> Edk2 has switched to github pr code review process, you can raise PR in
> https://github.com/tianocore/edk2/pulls
> directly.
>
> Regards,
> Yi
>
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Witt,
> Sebastian via groups.io
> Sent: Tuesday, June 4, 2024 12:19 AM
> To: devel@edk2.groups.io
> Subject: [edk2-devel] [PATCH] CryptoPkg: Fix BaseCryptLib CrtWrapper strcpy
>
>
> strcpy fails when strSource is closer than 4096 bytes after strDest.
>
> This is caused by an overlap check in AsciiStrCpyS:
> //
> // 5. Copying shall not take place between objects that overlap.
> //
> SAFE_STRING_CONSTRAINT_CHECK (InternalSafeStringNoAsciiStrOverlap
> (Destination, DestMax, (CHAR8 *)Source, SourceLen + 1), RETURN_ACCESS_DENIED);
>
> Since DestMax is MAX_STRING_SIZE (0x1000) and with a Source that is in this
> area behind Destination, AsciiStrCpyS will fail and strcpy will do nothing.
>
> When called by CRYPTO_strdup in openssl this leads to uninitialzed memory
> that gets accessed instead of the copied string.
>
> Signed-of-by: Sebastian Witt
> ---
> CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c
> b/CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c
> index 37cdecc9bd..880ed140fd 100644
> --- a/CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c
> +++ b/CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c
> @@ -271,7 +271,7 @@ strcpy (
>const char *strSource
>)
> {
> - AsciiStrCpyS (strDest, MAX_STRING_SIZE, strSource);
> + AsciiStrCpyS (strDest, AsciiStrnSizeS (strSource, MAX_STRING_SIZE),
> + strSource);
>return strDest;
> }
>
> --
> 2.39.2
>
>
>
>
>
>
--
Sebastian Witt
Siemens AG
http://www.siemens.com/
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119444): https://edk2.groups.io/g/devel/message/119444
Mute This Topic: https://groups.io/mt/106471263/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH] CryptoPkg: Fix BaseCryptLib CrtWrapper strcpy
Thanks for your patch, this is a known issue:
https://bugzilla.tianocore.org/show_bug.cgi?id=2817
Could you also update other wrappers in CrtWrapper.h and add BZ link to commit
message?
Edk2 has switched to github pr code review process, you can raise PR in
https://github.com/tianocore/edk2/pulls directly.
Regards,
Yi
-Original Message-
From: devel@edk2.groups.io On Behalf Of Witt, Sebastian
via groups.io
Sent: Tuesday, June 4, 2024 12:19 AM
To: devel@edk2.groups.io
Subject: [edk2-devel] [PATCH] CryptoPkg: Fix BaseCryptLib CrtWrapper strcpy
strcpy fails when strSource is closer than 4096 bytes after strDest.
This is caused by an overlap check in AsciiStrCpyS:
//
// 5. Copying shall not take place between objects that overlap.
//
SAFE_STRING_CONSTRAINT_CHECK (InternalSafeStringNoAsciiStrOverlap
(Destination, DestMax, (CHAR8 *)Source, SourceLen + 1), RETURN_ACCESS_DENIED);
Since DestMax is MAX_STRING_SIZE (0x1000) and with a Source that is in this
area behind Destination, AsciiStrCpyS will fail and strcpy will do nothing.
When called by CRYPTO_strdup in openssl this leads to uninitialzed memory that
gets accessed instead of the copied string.
Signed-of-by: Sebastian Witt
---
CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c
b/CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c
index 37cdecc9bd..880ed140fd 100644
--- a/CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c
+++ b/CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c
@@ -271,7 +271,7 @@ strcpy (
const char *strSource
)
{
- AsciiStrCpyS (strDest, MAX_STRING_SIZE, strSource);
+ AsciiStrCpyS (strDest, AsciiStrnSizeS (strSource, MAX_STRING_SIZE),
+ strSource);
return strDest;
}
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119443): https://edk2.groups.io/g/devel/message/119443
Mute This Topic: https://groups.io/mt/106471263/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH edk2-platforms v2 0/3] SbsaQemu: support multiple PCI Express buses
W dniu 28.05.2024 o 16:31, Ard Biesheuvel pisze: I would expect each host bridge to have its own separate resource windows for config space, buses and MMIO regions. So each host bridge gets a different segment number, and each segment is associated with a different ECAM region. That also means the bus range can start at 0x0 for each segment, as they are completely disjoint. This is a more accurate representation of the physical topology, given that each host bridge has its own link to the CPU side interconnect, and so things like peer-to-peer DMA between endpoints does not generally work unless the endpoints share a segment, especially in the presence of SMMUs. OK. I have to admit that I never checked how physical NUMA system handles PCI Express. The code in patches was done by comparing with other QEMU targets. To make PCIe in a way you describe we probably need to go to QEMU devel ML and discuss how it can be done there. Or I did not got deep enough into PCIe world to notice how to make it happen with current implementation. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#119442): https://edk2.groups.io/g/devel/message/119442 Mute This Topic: https://groups.io/mt/106345969/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
