Re: [edk2-devel] [edk2-discuss] GSoC Proposal
Hi Marvin, > -Original Message- > From: Marvin Häuser > Sent: Friday, April 15, 2022 9:44 AM > To: disc...@edk2.groups.io; Johnson, Brian ; > Desimone, Nathaniel L ; Andrew Fish > ; devel@edk2.groups.io > Cc: Pedro Falcato ; adachristin...@gmail.com; > Shi, Steven > Subject: Re: [edk2-devel] [edk2-discuss] GSoC Proposal > > Hey Brian, > > On 15.04.22 18:22, Brian J. Johnson wrote: > > Nate, Andrew, Marvin, Pedro, Ada, et al, > > > > This is a great discussion. I've been debating where to weigh in... > > Personally, I don't think this topic can get enough attention. Thanks! :) > > > > > I agree that some sort of library sharing to reduce image size would > > be very helpful. Although some parts of the BIOS are built > > separately, large parts of it are compiled at the same time, so there > > should be ample opportunity for tool-directed sharing. Some form of > > pre-linking modules together may be the easiest way to do that. But > > however it gets implemented, we should try to make it automatic: > > requiring library writers to manually add a lot of metadata or write > > thunks or shims would be a barrier to adoption. > > My suggestion to use a private function array would indeed require shims, > however this would be the "better than nothing I guess" solution where only > the most used and most painful to duplicate functions are shared, e.g., > memory and maybe common string printing functions. This would quickly and > efficiently achieve the goal of "reduce size". And some form of sophisticated > prelinking would be my proposal for something more systematic, which > might come a lot cheaper with the security features to be added. > > > > > I also agree that PEI has acquired far too much functionality over > > time, and we badly need to find some way to reverse that. PEI is > > pulling in more and more of the h/w initialization, leaving DXE mainly > > to provide the boot interface (ACPI, UEFI services, setup screens, > > etc.) That puts more and more pressure on XIP storage and > > cache-as-RAM. How can we encourage a change? > > I'm not in the loop enough to comment on the XIP and CAR issues. > However, HW init moving to PEI (or more generally, into a single stage) is not > necessarily a bad thing, is it? As I've said before, I'm not sure what else to > think of PEI than "DXE light". Both "initialise some of the hardware" with no > clear scope boundary but with similar interfaces. If they were sort of fused > to > provide a minimal "pre-memory PEI" and a more DXE-like "post-memory PEI" > without having a clear boundary between HW init steps, would that be too > bad? Now I'm *really* just blindly guessing because I barely looked into this > project, but isn't that somewhat the idea of SlimBootloader? > > Your description of DXE sort of is it collapsing into an advanced BDS. > Nate earlier said he'd like a clear distinction between DXE and BDS, which I > didn't really get the point of. I guess what I'm trying to express is where does DXE end and where does BDS begin? A lot of drivers that are only used in BDS get dispatched early in DXE. Conversely, it is entirely possible for some DXE drivers to only run after we have technically entered the BDS phase. The line where DXE ends and BDS begins is blurry and not really a line but more like a rectangle. To Isaac's point, there is a good argument to be made for beefing up PEI's capabilities to the point that DXE and BDS more or less become one thing. But what does that mean for PEI? Do we change from the 1-D PPI database to the 2-D Handle database in order to express device topologies better for example? That would be useful for stuff like the PEI UFS drivers as they run into difficulties expressing LUN IDs that the DXE version does not for example. Not sure if I would actually formally propose that in the PI WG but interesting stuff to think about regardless. > But if PEI consumed the HW init portions of DXE, > a more advanced BDS (which also powers e.g. the HID stuff on the way) > would be the logical remainder stage to separately support UEFI booting as a > payload (for SlimBootloader, coreboot, ...). > > All of that was logically speaking. Even if the development was driven to its > extreme, PEI and DXE cores would still share a bunch of code and it might > make sense to share a foundation technically. > > Best regards, > Marvin > > > > > Thanks, > > Brian J. Johnson > > > > > > On 4/15/22 03:15, Nate DeSimone wrote: > >> Hi Andrew, > >> > >> On 4/14/22, 7:43 PM, "Andrew Fish" wrote: > >>> > >>> > On Apr 14, 2022, at 6:06 PM, Nate DeSimone > wrote: > > Hi Marvin, > > > -Original Message- > > From: devel@edk2.groups.io On Behalf Of > > Marvin Häuser > > Sent: Thursday, April 14, 2022 12:56 AM > > To: disc...@edk2.groups.io; Desimone, Nathaniel L > > > > Cc: Pedro Falcato ; edk2-devel-groups-io > > ; adachristin...@gmail.com; Shi, Steven > >
Re: [edk2-devel][PATCH v5 0/8] Support PEI 64bit in IntelFsp2Pkg and IntelFsp2WrapperPkg
The series has been pushed as ~630df8c..91a03f7
Thanks,
Nate
-Original Message-
From: devel@edk2.groups.io On Behalf Of Kuo, Ted
Sent: Friday, April 15, 2022 1:38 AM
To: devel@edk2.groups.io
Subject: [edk2-devel][PATCH v5 0/8] Support PEI 64bit in IntelFsp2Pkg and
IntelFsp2WrapperPkg
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3893
Currently PEI drivers/libraries only support 32bit in IntelFsp2Pkg and
IntelFsp2WrapperPkg. The patches below are needed to support these
drivers/libraries in 64bit.
V2 changes:
1.Change FSPM_UPD_COMMON2 to FSPM_UPD_COMMON_FSP24 in FspApiEntryM.nasm.
2.Add FSPx_UPD_COMMON_FSP24 in FspApi.h.
3.Add 3 additional patches for supporting X64 in IntelFsp2WrapperPkg.
V3 changes:
1.Update FSPT_ARCH2_UPD and add FSPT_CORE_UPD back.
2.Use 0x instead of MAX_ADDRESS to reflect the default of FspData.
3.Remove EnableMultiPhaseMemoryInit from FSPM_ARCH2_UPD.
4.Bump GenCfgOpt version to 0.57.
V4 changes:
1.Added EFIAPI to SwapStack and PEI_CORE_ENTRY.
2.Cast FspData from pointer to UINTN and then from UINTN to UINT32.
3.Corrected few typos.
Ted Kuo (8):
IntelFsp2Pkg: X64 compatible changes to support PEI in 64bit
IntelFsp2Pkg: Add FSPx_ARCH2_UPD support for X64
IntelFsp2Pkg: Update FSP_GLOBAL_DATA and FSP_PLAT_DATA for X64
IntelFsp2Pkg: FspSecCore support for X64
IntelFsp2Pkg: SecFspSecPlatformLibNull support for X64
IntelFsp2WrapperPkg: Adopt FSPM_UPD_COMMON_FSP24 for X64
IntelFsp2WrapperPkg: BaseFspWrapperApiLib support for X64
IntelFsp2WrapperPkg: SecFspWrapperPlatformSecLibSample support for X64
V5
1.Extend Copyright year to 2022 for the modified files 2.Check
FSPM_UPD_COMMON_FSP24.Revision before configuring FSP stack.
3.Treat both MAX_ADDRESS and MAX_UINT32 as invalid address for FSP global data
in FspApiCallingCheck().
4.Remove EnableMultiPhaseSiliconInit from FSPS_ARCH2_UPD.
5.Add an additional ExcludedSpecificUpd1 to exclude FSPx_ARCH2_UPD in
GenCfgOpt.py tool.
IntelFsp2Pkg/FspNotifyPhase/FspNotifyPhasePeim.c | 3 +-
IntelFsp2Pkg/FspSecCore/Fsp22SecCoreS.inf | 10 +-
IntelFsp2Pkg/FspSecCore/FspSecCoreM.inf| 11 +-
IntelFsp2Pkg/FspSecCore/FspSecCoreS.inf| 10 +-
IntelFsp2Pkg/FspSecCore/FspSecCoreT.inf| 12 +-
.../FspSecCore/Ia32/FspApiEntryCommon.nasm | 6 +-
IntelFsp2Pkg/FspSecCore/Ia32/FspApiEntryM.nasm | 32 +-
IntelFsp2Pkg/FspSecCore/Ia32/FspApiEntryT.nasm | 98 +++-
IntelFsp2Pkg/FspSecCore/Ia32/ReadEsp.nasm | 10 +-
IntelFsp2Pkg/FspSecCore/Ia32/Stack.nasm| 12 +-
IntelFsp2Pkg/FspSecCore/SecFsp.c | 12 +-
IntelFsp2Pkg/FspSecCore/SecFsp.h | 4 +-
IntelFsp2Pkg/FspSecCore/SecFspApiChk.c | 10 +-
IntelFsp2Pkg/FspSecCore/SecMain.c | 10 +-
IntelFsp2Pkg/FspSecCore/SecMain.h | 20 +-
IntelFsp2Pkg/FspSecCore/X64/Fsp22ApiEntryS.nasm| 103 +
IntelFsp2Pkg/FspSecCore/X64/FspApiEntryCommon.nasm | 76
IntelFsp2Pkg/FspSecCore/X64/FspApiEntryM.nasm | 271 +++
IntelFsp2Pkg/FspSecCore/X64/FspApiEntryS.nasm | 67 +++
IntelFsp2Pkg/FspSecCore/X64/FspApiEntryT.nasm | 495 +
IntelFsp2Pkg/FspSecCore/X64/FspHelper.nasm | 34 ++
IntelFsp2Pkg/FspSecCore/X64/MicrocodeLoadNasm.inc | 11 +
IntelFsp2Pkg/FspSecCore/X64/ReadRsp.nasm | 22 +
IntelFsp2Pkg/FspSecCore/X64/Stack.nasm | 73 +++
IntelFsp2Pkg/Include/FspEas/FspApi.h | 139 +-
IntelFsp2Pkg/Include/FspGlobalData.h | 53 ++-
IntelFsp2Pkg/Include/Guid/FspHeaderFile.h | 16 +-
IntelFsp2Pkg/Include/SaveRestoreSseAvxNasm.inc | 284
IntelFsp2Pkg/IntelFsp2Pkg.dsc | 4 +-
.../Library/BaseFspCommonLib/FspCommonLib.c| 6 +-
.../BaseFspSwitchStackLib/FspSwitchStackLib.c | 3 +-
.../Library/BaseFspSwitchStackLib/X64/Stack.nasm | 5 +-
.../SecFspSecPlatformLibNull/Ia32/Flat32.nasm | 4 +-
.../SecFspSecPlatformLibNull.inf | 8 +-
.../SecFspSecPlatformLibNull/X64/Long64.nasm | 31 ++
.../SecFspSecPlatformLibNull/X64/SecCarInit.nasm | 40 ++
IntelFsp2Pkg/Tools/GenCfgOpt.py| 7 +-
.../FspmWrapperPeim/FspmWrapperPeim.c | 27 +-
.../BaseFspWrapperApiLib/FspWrapperApiLib.c| 44 +-
.../BaseFspWrapperApiLib/IA32/DispatchExecute.c| 23 +-
.../BaseFspWrapperApiLib/X64/DispatchExecute.c | 47 +-
.../{Ia32 => }/Fsp.h | 0
.../Ia32/Stack.nasm| 8 +-
.../SecFspWrapperPlatformSecLibSample.inf | 9 +-
.../SecRamInitData.c | 24 +-
.../X64/PeiCoreEntry.nasm | 149 +++
.../X64/SecEntry.nasm | 171 +++
.../X64/Stack.nasm | 73 +++
48 files changed, 2446 insertions(+), 14
Re: [edk2-devel] [PATCH V12 42/47] OvmfPkg: Add TdxDxe driver
On April 16, 2022 4:52 AM, Lendacky, Thomas wrote: > > Unfortunately, this driver also breaks SEV-ES. I bypassed the TDX code in the > SEC library, but then hit an issue because this driver is loaded before the > AmdSevDxe driver. The AmdSevDxe driver performs a > MemEncryptSevClearMmioPageEncMask() call against the > PcdPciExpressBaseAddress range to mark it shared/unencrypted. However, > the TdxDxe driver is loaded before the AmdSevDxe driver, and it appears the > dependencies result in an MMIO being performed to an address in the > PcdPciExpressBaseAddress range. Since the range has not been marked > shared/unencrypted, the #VC handler terminates the guest for trying to do > MMIO to an encrypted region. > I carefully check the code TdxDxeEntryPoint@TdxDxe.c. If the working guest is NOT td guest, before it returns, it just does below: 1. check if the GuidHob exists 2. Set PcdOvmfHostBridgePciDevId with the information in the GuidHob SetMmioSharedBit() is called if the working guest is Td guest. So if it is sev guest, SetMmioSharedBit will not be called. I don't have a SEV-ES in hand. Can you help to add some debug information in TdxDxe to see what the last code before the exception is triggered? BTW, have you tried to load AmdSev.inf before TdxDxe.inf? I tried it in my TDX guest and it works fine. Thanks Min -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#88958): https://edk2.groups.io/g/devel/message/88958 Mute This Topic: https://groups.io/mt/90495224/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH V12 33/47] OvmfPkg: Update Sec to support Tdx
On April 16, 2022 4:05 AM, Tom Lendacky wrote:
> > #define SEC_IDT_ENTRY_COUNT 34
> > @@ -738,6 +737,20 @@ SecCoreStartupWithStack (
> > UINT32Index;
> > volatile UINT8*Table;
> >
> > + #if defined (TDX_GUEST_SUPPORTED)
> > + if (TdIsEnabled ()) {
>
> I wish I had caught this earlier, but this patch breaks SEV-ES support.
> TdIsEnabled() uses the CPUID instruction. At this point, exception handling is
> not established and a CPUID instruction will generate a #VC and cause the
> booting guest to crash.
>
Sorry for the broken.
>
> That is why the SevEsIsEnabled() function checks the work area to determine
> if SEV-ES is supported. In the early boot code we established a temporary
> #VC handler to specifically handle CPUID and then set the work area
> indicator that SEV-ES is enabled.
>
> I think you'll need to do something similar for this area. Haven't you already
> set the workarea from calling InitTdx before this point?
TDX has set the workarea in ResetVector.
I am working on a patch-set (now it is v2) which is to fix the issues caused by
TdIsEnabled. Please see https://edk2.groups.io/g/devel/message/88916
This patch-set introduce CcProbe() which checks the Ovmf work area to return
the guest type.
In the next version CcProbe will be called instead of TdIsEnabled in SecMain.c.
Please help to review the above patch-set so that there will not be more broken
in the future.
Thanks much
Min
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#88957): https://edk2.groups.io/g/devel/message/88957
Mute This Topic: https://groups.io/mt/90121245/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/1] OvmfPkg/OvmfPkg*.dsc: Increase ACPI Reclaim memory size
The current ACPI Reclaim memory size is set as 0x10(64k). The ACPI table size will be increased if the memory slots' number of the guest gets increased. In the guest with more memory slots, the ACPI Reclaim memory size may not be sufficient for hibernation. This may cause resume failure of the hibernated guest that was booted up with a fresh copied writable OVMF_VARS file. However, the failure doesn't happen in following hibernation/resume cycles. The ACPI_MAX_RAM_SLOTS is set as 256 in the current QEMU. With ACPI_MAX_RAM_SLOTS, 18 pages are required to be allocated in ACPI Reclaim memory. However, due to the 0x10(16 pages) setting, 2 extra pages will be allocated in other space. This may break the hibernation/resume in the above scenario. This patch increases the ACPI Reclaim memory size to 0x12, i.e. PcdMemoryTypeEfiACPIReclaimMemory is set as 0x12(18 pages). Signed-off-by: Annie Li --- OvmfPkg/OvmfPkgIa32.dsc| 2 +- OvmfPkg/OvmfPkgIa32X64.dsc | 2 +- OvmfPkg/OvmfPkgX64.dsc | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc index 29eea82571..fb158f98c9 100644 --- a/OvmfPkg/OvmfPkgIa32.dsc +++ b/OvmfPkg/OvmfPkgIa32.dsc @@ -547,7 +547,7 @@ # unknown) workloads / boot paths. # gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIMemoryNVS|0x80 - gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory|0x10 + gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory|0x12 gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiReservedMemoryType|0x80 gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesCode|0x100 gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesData|0x100 diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc index 56d3c49ab2..30d47ca28a 100644 --- a/OvmfPkg/OvmfPkgIa32X64.dsc +++ b/OvmfPkg/OvmfPkgIa32X64.dsc @@ -552,7 +552,7 @@ # unknown) workloads / boot paths. # gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIMemoryNVS|0x80 - gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory|0x10 + gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory|0x12 gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiReservedMemoryType|0x80 gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesCode|0x100 gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesData|0x100 diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc index f0924c0f9d..6c10ceedd7 100644 --- a/OvmfPkg/OvmfPkgX64.dsc +++ b/OvmfPkg/OvmfPkgX64.dsc @@ -552,7 +552,7 @@ # unknown) workloads / boot paths. # gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIMemoryNVS|0x80 - gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory|0x10 + gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory|0x12 gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiReservedMemoryType|0x80 gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesCode|0x100 gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesData|0x100 -- 2.31.1 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#88956): https://edk2.groups.io/g/devel/message/88956 Mute This Topic: https://groups.io/mt/90495713/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/1] Increase ACPI Reclaim memory size
Oops! This patch title misses the module name, I'll post a V2 version to include it. Thanks Annie On 4/15/2022 1:11 PM, annie li wrote: The current ACPI Reclaim memory size is set as 0x10(64k). The ACPI table size will be increased if the memory slots' number of the guest gets increased. In the guest with more memory slots, the ACPI Reclaim memory size may not be sufficient for hibernation. This may cause resume failure of the hibernated guest that was booted up with a fresh copied writable OVMF_VARS file. However, the failure doesn't happen in following hibernation/resume cycles. The ACPI_MAX_RAM_SLOTS is set as 256 in the current QEMU. With ACPI_MAX_RAM_SLOTS, 18 pages are required to be allocated in ACPI Reclaim memory. However, due to the 0x10(16 pages) setting, 2 extra pages will be allocated in other space. This may break the hibernation/resume in the above scenario. This patch increases the ACPI Reclaim memory size to 0x12, i.e. PcdMemoryTypeEfiACPIReclaimMemory is set as 0x12(18 pages). Signed-off-by: Annie Li --- OvmfPkg/OvmfPkgIa32.dsc| 2 +- OvmfPkg/OvmfPkgIa32X64.dsc | 2 +- OvmfPkg/OvmfPkgX64.dsc | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc index 29eea82571..fb158f98c9 100644 --- a/OvmfPkg/OvmfPkgIa32.dsc +++ b/OvmfPkg/OvmfPkgIa32.dsc @@ -547,7 +547,7 @@ # unknown) workloads / boot paths. # gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIMemoryNVS|0x80 - gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory|0x10 + gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory|0x12 gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiReservedMemoryType|0x80 gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesCode|0x100 gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesData|0x100 diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc index 56d3c49ab2..30d47ca28a 100644 --- a/OvmfPkg/OvmfPkgIa32X64.dsc +++ b/OvmfPkg/OvmfPkgIa32X64.dsc @@ -552,7 +552,7 @@ # unknown) workloads / boot paths. # gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIMemoryNVS|0x80 - gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory|0x10 + gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory|0x12 gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiReservedMemoryType|0x80 gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesCode|0x100 gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesData|0x100 diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc index f0924c0f9d..6c10ceedd7 100644 --- a/OvmfPkg/OvmfPkgX64.dsc +++ b/OvmfPkg/OvmfPkgX64.dsc @@ -552,7 +552,7 @@ # unknown) workloads / boot paths. # gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIMemoryNVS|0x80 - gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory|0x10 + gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory|0x12 gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiReservedMemoryType|0x80 gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesCode|0x100 gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesData|0x100 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#88955): https://edk2.groups.io/g/devel/message/88955 Mute This Topic: https://groups.io/mt/90491849/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH V12 42/47] OvmfPkg: Add TdxDxe driver
On 3/29/22 18:46, Min Xu wrote: RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429 TdxDxe driver is dispatched early in DXE, due to being list in APRIORI. This module is responsible for below features: - Sets max logical cpus based on TDINFO - Sets PCI PCDs based on resource hobs - Set shared bit in MMIO region - Relocate Td mailbox and set its address in MADT table. 1. Set shared bit in MMIO region Qemu allows a ROM device to set to ROMD mode (default) or MMIO mode. When it is in ROMD mode, the device is mapped to guest memory and satisfies read access directly. In EDK2 Option ROM is treated as MMIO region. So Tdx guest access Option ROM via TDVMCALL(MMIO). But as explained above, since Qemu set the Option ROM to ROMD mode, the call of TDVMCALL(MMIO) always return INVALID_OPERAND. Tdvf then falls back to direct access. This requires to set the shared bit to corresponding PageTable entry. Otherwise it triggers GP fault. TdxDxe's entry point is the right place to set the shared bit in MMIO region because Option ROM has not been discoverd yet. 2. Relocate Td mailbox and set the new address in MADT Mutiprocessor Wakeup Table. In TDX the guest firmware is designed to publish a multiprocessor-wakeup structure to let the guest-bootstrap processor wake up guest-application processors with a mailbox. The mailbox is memory that the guest firmware can reserve so each guest virtual processor can have the guest OS send a message to them. The address of the mailbox is recorded in the MADT table. See [ACPI]. TdxDxe registers for protocol notification (gQemuAcpiTableNotifyProtocolGuid) to call the AlterAcpiTable(), in which MADT table is altered by the above Mailbox address. The protocol will be installed in AcpiPlatformDxe when the MADT table provided by Qemu is ready. This is to maintain the simplicity of the AcpiPlatformDxe. AlterAcpiTable is the registered function which traverses the ACPI table list to find the original MADT from Qemu. After the new MADT is configured and installed, the original one will be uninstalled. [ACPI] https://uefi.org/specs/ACPI/6.4/05_ACPI_Software_Programming_Model /ACPI_Software_Programming_Model.html#multiprocessor-wakeup-structure Cc: Ard Biesheuvel Cc: Jordan Justen Cc: Brijesh Singh Cc: Erdem Aktas Cc: James Bottomley Cc: Jiewen Yao Cc: Tom Lendacky Cc: Gerd Hoffmann Acked-by: Gerd Hoffmann Signed-off-by: Min Xu Unfortunately, this driver also breaks SEV-ES. I bypassed the TDX code in the SEC library, but then hit an issue because this driver is loaded before the AmdSevDxe driver. The AmdSevDxe driver performs a MemEncryptSevClearMmioPageEncMask() call against the PcdPciExpressBaseAddress range to mark it shared/unencrypted. However, the TdxDxe driver is loaded before the AmdSevDxe driver, and it appears the dependencies result in an MMIO being performed to an address in the PcdPciExpressBaseAddress range. Since the range has not been marked shared/unencrypted, the #VC handler terminates the guest for trying to do MMIO to an encrypted region. Here is the error information: Loading driver at 0x0003F1A5000 EntryPoint=0x0003F1A6BF2 TdxDxe.efi InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 3F1AFA98 ProtectUefiImageCommon - 0x3F1AFB40 - 0x3F1A5000 - 0x4300 MMIO using encrypted memory: B00F8040 X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - ExceptionData - RIP - 3F1A6E86, CS - 0018, RFLAGS - 00010002 RAX - B000, RCX - 3F4EAD18, RDX - 3F4EAD01 RBX - 0001, RSP - 3FBA5B60, RBP - RSI - , RDI - 3F1AFB18 R8 - B00F8040, R9 - 29C0, R10 - R11 - , R12 - , R13 - R14 - 3FBCC6D0, R15 - 3FBC43E6 DS - 0008, ES - 0008, FS - 0008 GS - 0008, SS - 0008 CR0 - 80010033, CR2 - , CR3 - 3F801000 CR4 - 0668, CR8 - DR0 - , DR1 - , DR2 - DR3 - , DR6 - , DR7 - GDTR - 3FBFE000 0027, LDTR - IDTR - 3BF95D70 021F, TR - FXSAVE_STATE - 3FBA57C0 Find image based on IP(0x3F1A6E86) /root/kernels/ovmf-build-X64/Build/OvmfX64/DEBUG_GCC5/X64/OvmfPkg/TdxDxe/TdxDxe/DEBUG/TdxDxe.dll (ImageBase=3F1A5000, EntryPoint=3F1A6BF2) Not sure what the best way forward is on this. Thanks, Tom --- -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#88954): https://edk2.groups.io/g/devel/message/88954 Mute This Topic: https://groups.io/mt/90495224/21656 Group Owner: devel+ow...@edk2.groups.io
Re: [edk2-devel] [PATCH V12 33/47] OvmfPkg: Update Sec to support Tdx
On 3/29/22 18:46, Min Xu wrote:
RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429
There are below major changes in this commit.
1. SecEntry.nasm
In TDX BSP and APs goes to the same entry point in SecEntry.nasm.
BSP initialize the temporary stack and then jumps to SecMain, just as
legacy Ovmf does.
APs spin in a modified mailbox loop using initial mailbox structure.
Its structure defition is in OvmfPkg/Include/IndustryStandard/IntelTdx.h.
APs wait for command to see if the command is for me. If so execute the
command.
2. Sec/SecMain.c
When host VMM create the Td guest, the system memory informations are
stored in TdHob, which is a memory region described in Tdx metadata.
The system memory region in TdHob should be accepted before it can be
accessed. So the major task of this patch is to process the TdHobList
to accept the memory. After that TDVF follow the standard OVMF flow
and jump to PEI phase.
PcdUse1GPageTable is set to FALSE by default in OvmfPkgX64.dsc. It gives
no chance for Intel TDX to support 1G page table. To support 1G page
table this PCD is set to TRUE in OvmfPkgX64.dsc.
TDX_GUEST_SUPPORTED is defined in OvmfPkgX64.dsc. This macro wraps the
Tdx specific code.
TDX only works on X64, so the code is only valid in X64 arch.
Cc: Ard Biesheuvel
Cc: Jordan Justen
Cc: Brijesh Singh
Cc: Erdem Aktas
Cc: James Bottomley
Cc: Jiewen Yao
Cc: Tom Lendacky
Cc: Gerd Hoffmann
Acked-by: Gerd Hoffmann
Signed-off-by: Min Xu
diff --git a/OvmfPkg/Sec/SecMain.c b/OvmfPkg/Sec/SecMain.c
index 02520e25ab9a..ca9717a7b526 100644
--- a/OvmfPkg/Sec/SecMain.c
+++ b/OvmfPkg/Sec/SecMain.c
@@ -26,9 +26,8 @@
#include
#include
#include
-
#include
-
+#include
#include "AmdSev.h"
#define SEC_IDT_ENTRY_COUNT 34
@@ -738,6 +737,20 @@ SecCoreStartupWithStack (
UINT32Index;
volatile UINT8*Table;
+ #if defined (TDX_GUEST_SUPPORTED)
+ if (TdIsEnabled ()) {
I wish I had caught this earlier, but this patch breaks SEV-ES support.
TdIsEnabled() uses the CPUID instruction. At this point, exception
handling is not established and a CPUID instruction will generate a #VC
and cause the booting guest to crash.
That is why the SevEsIsEnabled() function checks the work area to
determine if SEV-ES is supported. In the early boot code we established a
temporary #VC handler to specifically handle CPUID and then set the work
area indicator that SEV-ES is enabled.
I think you'll need to do something similar for this area. Haven't you
already set the workarea from calling InitTdx before this point?
Thanks,
Tom
+//
+// For Td guests, the memory map info is in TdHobLib. It should be
processed
+// first so that the memory is accepted. Otherwise access to the unaccepted
+// memory will trigger tripple fault.
+//
+if (ProcessTdxHobList () != EFI_SUCCESS) {
+ CpuDeadLoop ();
+}
+ }
+
+ #endif
+
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#88953): https://edk2.groups.io/g/devel/message/88953
Mute This Topic: https://groups.io/mt/90121245/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel][PATCH v5 0/8] Support PEI 64bit in IntelFsp2Pkg and IntelFsp2WrapperPkg
Great work thanks Ted!
Reviewed-by: Nate DeSimone
From: devel@edk2.groups.io on behalf of Kuo, Ted
Date: Friday, April 15, 2022 at 1:38 AM
To: devel@edk2.groups.io
Subject: [edk2-devel][PATCH v5 0/8] Support PEI 64bit in IntelFsp2Pkg and
IntelFsp2WrapperPkg
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3893
Currently PEI drivers/libraries only support 32bit in IntelFsp2Pkg and
IntelFsp2WrapperPkg. The patches below are needed to support these
drivers/libraries in 64bit.
V2 changes:
1.Change FSPM_UPD_COMMON2 to FSPM_UPD_COMMON_FSP24 in FspApiEntryM.nasm.
2.Add FSPx_UPD_COMMON_FSP24 in FspApi.h.
3.Add 3 additional patches for supporting X64 in IntelFsp2WrapperPkg.
V3 changes:
1.Update FSPT_ARCH2_UPD and add FSPT_CORE_UPD back.
2.Use 0x instead of MAX_ADDRESS to reflect the default of FspData.
3.Remove EnableMultiPhaseMemoryInit from FSPM_ARCH2_UPD.
4.Bump GenCfgOpt version to 0.57.
V4 changes:
1.Added EFIAPI to SwapStack and PEI_CORE_ENTRY.
2.Cast FspData from pointer to UINTN and then from UINTN to UINT32.
3.Corrected few typos.
Ted Kuo (8):
IntelFsp2Pkg: X64 compatible changes to support PEI in 64bit
IntelFsp2Pkg: Add FSPx_ARCH2_UPD support for X64
IntelFsp2Pkg: Update FSP_GLOBAL_DATA and FSP_PLAT_DATA for X64
IntelFsp2Pkg: FspSecCore support for X64
IntelFsp2Pkg: SecFspSecPlatformLibNull support for X64
IntelFsp2WrapperPkg: Adopt FSPM_UPD_COMMON_FSP24 for X64
IntelFsp2WrapperPkg: BaseFspWrapperApiLib support for X64
IntelFsp2WrapperPkg: SecFspWrapperPlatformSecLibSample support for X64
V5
1.Extend Copyright year to 2022 for the modified files
2.Check FSPM_UPD_COMMON_FSP24.Revision before configuring FSP stack.
3.Treat both MAX_ADDRESS and MAX_UINT32 as invalid address for FSP global data
in FspApiCallingCheck().
4.Remove EnableMultiPhaseSiliconInit from FSPS_ARCH2_UPD.
5.Add an additional ExcludedSpecificUpd1 to exclude FSPx_ARCH2_UPD in
GenCfgOpt.py tool.
IntelFsp2Pkg/FspNotifyPhase/FspNotifyPhasePeim.c | 3 +-
IntelFsp2Pkg/FspSecCore/Fsp22SecCoreS.inf | 10 +-
IntelFsp2Pkg/FspSecCore/FspSecCoreM.inf| 11 +-
IntelFsp2Pkg/FspSecCore/FspSecCoreS.inf| 10 +-
IntelFsp2Pkg/FspSecCore/FspSecCoreT.inf| 12 +-
.../FspSecCore/Ia32/FspApiEntryCommon.nasm | 6 +-
IntelFsp2Pkg/FspSecCore/Ia32/FspApiEntryM.nasm | 32 +-
IntelFsp2Pkg/FspSecCore/Ia32/FspApiEntryT.nasm | 98 +++-
IntelFsp2Pkg/FspSecCore/Ia32/ReadEsp.nasm | 10 +-
IntelFsp2Pkg/FspSecCore/Ia32/Stack.nasm| 12 +-
IntelFsp2Pkg/FspSecCore/SecFsp.c | 12 +-
IntelFsp2Pkg/FspSecCore/SecFsp.h | 4 +-
IntelFsp2Pkg/FspSecCore/SecFspApiChk.c | 10 +-
IntelFsp2Pkg/FspSecCore/SecMain.c | 10 +-
IntelFsp2Pkg/FspSecCore/SecMain.h | 20 +-
IntelFsp2Pkg/FspSecCore/X64/Fsp22ApiEntryS.nasm| 103 +
IntelFsp2Pkg/FspSecCore/X64/FspApiEntryCommon.nasm | 76
IntelFsp2Pkg/FspSecCore/X64/FspApiEntryM.nasm | 271 +++
IntelFsp2Pkg/FspSecCore/X64/FspApiEntryS.nasm | 67 +++
IntelFsp2Pkg/FspSecCore/X64/FspApiEntryT.nasm | 495 +
IntelFsp2Pkg/FspSecCore/X64/FspHelper.nasm | 34 ++
IntelFsp2Pkg/FspSecCore/X64/MicrocodeLoadNasm.inc | 11 +
IntelFsp2Pkg/FspSecCore/X64/ReadRsp.nasm | 22 +
IntelFsp2Pkg/FspSecCore/X64/Stack.nasm | 73 +++
IntelFsp2Pkg/Include/FspEas/FspApi.h | 139 +-
IntelFsp2Pkg/Include/FspGlobalData.h | 53 ++-
IntelFsp2Pkg/Include/Guid/FspHeaderFile.h | 16 +-
IntelFsp2Pkg/Include/SaveRestoreSseAvxNasm.inc | 284
IntelFsp2Pkg/IntelFsp2Pkg.dsc | 4 +-
.../Library/BaseFspCommonLib/FspCommonLib.c| 6 +-
.../BaseFspSwitchStackLib/FspSwitchStackLib.c | 3 +-
.../Library/BaseFspSwitchStackLib/X64/Stack.nasm | 5 +-
.../SecFspSecPlatformLibNull/Ia32/Flat32.nasm | 4 +-
.../SecFspSecPlatformLibNull.inf | 8 +-
.../SecFspSecPlatformLibNull/X64/Long64.nasm | 31 ++
.../SecFspSecPlatformLibNull/X64/SecCarInit.nasm | 40 ++
IntelFsp2Pkg/Tools/GenCfgOpt.py| 7 +-
.../FspmWrapperPeim/FspmWrapperPeim.c | 27 +-
.../BaseFspWrapperApiLib/FspWrapperApiLib.c| 44 +-
.../BaseFspWrapperApiLib/IA32/DispatchExecute.c| 23 +-
.../BaseFspWrapperApiLib/X64/DispatchExecute.c | 47 +-
.../{Ia32 => }/Fsp.h | 0
.../Ia32/Stack.nasm| 8 +-
.../SecFspWrapperPlatformSecLibSample.inf | 9 +-
.../SecRamInitData.c | 24 +-
.../X64/PeiCoreEntry.nasm | 149 +++
.../X64/SecEntry.nasm | 171 +++
.../X64/Stack.nasm | 73 +++
48 files changed, 2446 insertions(+), 141 deletions(-)
create mode 100644 I
Re: [edk2-devel] [edk2-discuss] GSoC Proposal
Hey Isaac, Thanks for your input! :) On 15.04.22 20:47, Oram, Isaac W wrote: In practice, it feels like we have evolved far beyond original PEI scope for natural and good reasons. Initially, it was very resource constrained. 8KB CAR for data only. That is no longer a real constraint for most HW. And thus we get things like MP services early, writable variables early, complex PCD databases, and such. Looking at the amount of things that are duplicated from DXE to PEI (MP, variable services, PCD, GOP, ...), this sounds like all the more reason to me to have some unified technological foundation for PEI and DXE core. With mixed-architecture execution decaying (at least for the time being), what'd be the point of duplicating this code in both stages? Of course this hypothetical shared foundation should be flexible enough to be able to build distinct PEI and DXE cores to allow for UEFI PI and UEFI to be implemented separately from each other. I don't think it is bad. The PEI environment is much friendlier for developing and debugging ubiquitous silicon initialization than DXE. Ubiquitous meaning you pretty much need to do it on any boot path to any boot device. Pre Memory PEI and Post Memory PEI seem to be the right design for many things. It generally simplifies handshaking between early and later silicon code. Thus I like: SEC:Basics PEI Pre-Mem:Get memory PEI Post-Mem: Complete all "always required" silicon init. Can also do silicon init for more optional platform features. Should not do silicon init for dynamically optional features. Standalone MM: Kicked off from post memory PEI. DXE:Setup driver and UEFI environments BDS:Initialize boot target specific required HW, provide any required user interface, boot OS Yes! :) I think that this kind of design division makes a solution very flexible for supporting a wide range of designs. It allows more generic/reusable DXE and BDS. It makes SMM a more optional solution. We have launched Linux as an embedded OS or target OS from DXE IPL, DXE Core, BDS, etc. It supports that kind of flexibility. It enables LinuxBoot @ BDS and one day in place of DXE (Universal Payload). In that hypothetical model, yeah, I think DXE and BDS are *mostly* the same thing. BDS of course is a distinctly defined sub-process of determining the boot option, but the whole DXE+BDS stage combination would just be the generic "user experience" portion of UEFI. And I totally see things being interchangeable both ways, be that e.g. Slimbootloader + UEFI DXE/BDS or UEFI PEI + LinuxBoot. And fundamentally, it can reduce complexity because we can reduce the handshaking across phases. That tends to introduce complexity that the above helps reduce. We tried to incorporate a lot of this in the Minimum Platform Architecture spec and it has been working fairly well. It is hard to migrate the large mass of existing code, so we don't have a perfect example of this in action. But the vision is that you can design such that the phases are well bounded and very testable. And this will help silicon development, board porting, and adding features. If we succeed, we probably come back to ask for changes to make the pre-memory to post-memory handoff better. I find few people really know that well and we have repeated performance problems. But generally, there is plenty of flexibility in the existing architecture and phases to tune this for many answers. Specific to the discussion of DLL like behavior. I agree it should be handled by tools and not a unique and complex answer. It is actually a trivial change to take existing PEIM (for example) and just add the entry point as a library class constructor and then you can link a bunch of PEIM into a single image. It would be pretty minor to make this easy and supported I would think. You lose dynamic dispatch, obviously. But it is a short hack to eliminate early library duplication. This would actually be a great thing to have upstream (as in, something more straight-forward that'd allow modules to be merged without modifications, especially taking Depex into account somehow)! Amaranth will purge any sort of linking (at the very least downstream) and will mostly be just one monolith. I do not see that as an alternative to the previously discussed implementations of and alternatives to dynamic linking however, but as something complementary. Has there been any prior work on this? Best regards, Marvin Regards, Isaac -Original Message- From: devel@edk2.groups.io On Behalf Of Marvin Häuser Sent: Friday, April 15, 2022 9:44 AM To: disc...@edk2.groups.io; Johnson, Brian ; Desimone, Nathaniel L ; Andrew Fish ; devel@edk2.groups.io Cc: Pedro Falcato ; adachristin...@gmail.com; Shi, Steven Subject: Re: [edk2-devel] [edk2-discuss] GSoC Proposal Hey Brian, On 15.04.22 1
Re: [edk2-devel] [edk2-discuss] GSoC Proposal
In practice, it feels like we have evolved far beyond original PEI scope for natural and good reasons. Initially, it was very resource constrained. 8KB CAR for data only. That is no longer a real constraint for most HW. And thus we get things like MP services early, writable variables early, complex PCD databases, and such. I don't think it is bad. The PEI environment is much friendlier for developing and debugging ubiquitous silicon initialization than DXE. Ubiquitous meaning you pretty much need to do it on any boot path to any boot device. Pre Memory PEI and Post Memory PEI seem to be the right design for many things. It generally simplifies handshaking between early and later silicon code. Thus I like: SEC:Basics PEI Pre-Mem:Get memory PEI Post-Mem: Complete all "always required" silicon init. Can also do silicon init for more optional platform features. Should not do silicon init for dynamically optional features. Standalone MM: Kicked off from post memory PEI. DXE:Setup driver and UEFI environments BDS:Initialize boot target specific required HW, provide any required user interface, boot OS I think that this kind of design division makes a solution very flexible for supporting a wide range of designs. It allows more generic/reusable DXE and BDS. It makes SMM a more optional solution. We have launched Linux as an embedded OS or target OS from DXE IPL, DXE Core, BDS, etc. It supports that kind of flexibility. It enables LinuxBoot @ BDS and one day in place of DXE (Universal Payload). And fundamentally, it can reduce complexity because we can reduce the handshaking across phases. That tends to introduce complexity that the above helps reduce. We tried to incorporate a lot of this in the Minimum Platform Architecture spec and it has been working fairly well. It is hard to migrate the large mass of existing code, so we don't have a perfect example of this in action. But the vision is that you can design such that the phases are well bounded and very testable. And this will help silicon development, board porting, and adding features. If we succeed, we probably come back to ask for changes to make the pre-memory to post-memory handoff better. I find few people really know that well and we have repeated performance problems. But generally, there is plenty of flexibility in the existing architecture and phases to tune this for many answers. Specific to the discussion of DLL like behavior. I agree it should be handled by tools and not a unique and complex answer. It is actually a trivial change to take existing PEIM (for example) and just add the entry point as a library class constructor and then you can link a bunch of PEIM into a single image. It would be pretty minor to make this easy and supported I would think. You lose dynamic dispatch, obviously. But it is a short hack to eliminate early library duplication. Regards, Isaac -Original Message- From: devel@edk2.groups.io On Behalf Of Marvin Häuser Sent: Friday, April 15, 2022 9:44 AM To: disc...@edk2.groups.io; Johnson, Brian ; Desimone, Nathaniel L ; Andrew Fish ; devel@edk2.groups.io Cc: Pedro Falcato ; adachristin...@gmail.com; Shi, Steven Subject: Re: [edk2-devel] [edk2-discuss] GSoC Proposal Hey Brian, On 15.04.22 18:22, Brian J. Johnson wrote: > Nate, Andrew, Marvin, Pedro, Ada, et al, > > This is a great discussion. I've been debating where to weigh in... Personally, I don't think this topic can get enough attention. Thanks! :) > > I agree that some sort of library sharing to reduce image size would > be very helpful. Although some parts of the BIOS are built > separately, large parts of it are compiled at the same time, so there > should be ample opportunity for tool-directed sharing. Some form of > pre-linking modules together may be the easiest way to do that. But > however it gets implemented, we should try to make it automatic: > requiring library writers to manually add a lot of metadata or write > thunks or shims would be a barrier to adoption. My suggestion to use a private function array would indeed require shims, however this would be the "better than nothing I guess" solution where only the most used and most painful to duplicate functions are shared, e.g., memory and maybe common string printing functions. This would quickly and efficiently achieve the goal of "reduce size". And some form of sophisticated prelinking would be my proposal for something more systematic, which might come a lot cheaper with the security features to be added. > > I also agree that PEI has acquired far too much functionality over > time, and we badly need to find some way to reverse that. PEI is > pulling in more and more of the h/w initialization, leaving DXE mainly > to provide the boot interface (ACPI, UEFI services, setup screens, > etc.) That puts more and m
[edk2-devel] [PATCH 1/1] Increase ACPI Reclaim memory size
The current ACPI Reclaim memory size is set as 0x10(64k). The ACPI table size will be increased if the memory slots' number of the guest gets increased. In the guest with more memory slots, the ACPI Reclaim memory size may not be sufficient for hibernation. This may cause resume failure of the hibernated guest that was booted up with a fresh copied writable OVMF_VARS file. However, the failure doesn't happen in following hibernation/resume cycles. The ACPI_MAX_RAM_SLOTS is set as 256 in the current QEMU. With ACPI_MAX_RAM_SLOTS, 18 pages are required to be allocated in ACPI Reclaim memory. However, due to the 0x10(16 pages) setting, 2 extra pages will be allocated in other space. This may break the hibernation/resume in the above scenario. This patch increases the ACPI Reclaim memory size to 0x12, i.e. PcdMemoryTypeEfiACPIReclaimMemory is set as 0x12(18 pages). Signed-off-by: Annie Li --- OvmfPkg/OvmfPkgIa32.dsc| 2 +- OvmfPkg/OvmfPkgIa32X64.dsc | 2 +- OvmfPkg/OvmfPkgX64.dsc | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc index 29eea82571..fb158f98c9 100644 --- a/OvmfPkg/OvmfPkgIa32.dsc +++ b/OvmfPkg/OvmfPkgIa32.dsc @@ -547,7 +547,7 @@ # unknown) workloads / boot paths. # gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIMemoryNVS|0x80 - gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory|0x10 + gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory|0x12 gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiReservedMemoryType|0x80 gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesCode|0x100 gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesData|0x100 diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc index 56d3c49ab2..30d47ca28a 100644 --- a/OvmfPkg/OvmfPkgIa32X64.dsc +++ b/OvmfPkg/OvmfPkgIa32X64.dsc @@ -552,7 +552,7 @@ # unknown) workloads / boot paths. # gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIMemoryNVS|0x80 - gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory|0x10 + gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory|0x12 gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiReservedMemoryType|0x80 gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesCode|0x100 gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesData|0x100 diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc index f0924c0f9d..6c10ceedd7 100644 --- a/OvmfPkg/OvmfPkgX64.dsc +++ b/OvmfPkg/OvmfPkgX64.dsc @@ -552,7 +552,7 @@ # unknown) workloads / boot paths. # gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIMemoryNVS|0x80 - gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory|0x10 + gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory|0x12 gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiReservedMemoryType|0x80 gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesCode|0x100 gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesData|0x100 -- 2.31.1 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#88949): https://edk2.groups.io/g/devel/message/88949 Mute This Topic: https://groups.io/mt/90491849/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] TDX patches have broken edk2 bisectability in OVMF
On 4/12/22 16:00, James Bottomley via groups.io wrote: I've identified a serious performance regression in recent edk2, so I've been trying to identify it by bisection, but it seems that the TDX patches have broken bisection in edk2. You can see this by trying to checkout b6b2de884864 and build it. It will give you Active Platform = /home/jejb/git/edk2/OvmfPkg/OvmfPkgX64.dsc . build.py... /home/jejb/git/edk2/OvmfPkg/OvmfPkgX64.dsc(...): error 4000: Instance of library class [TdxLib] is not found in [/home/jejb/git/edk2/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf] [X64] consumed by module [/home/jejb/git/edk2/OvmfPkg/Sec/SecMain.inf] I think I can work around this, but it makes bisection extremely painful, please don't do it again ... +1 for this as I'm trying to bisect an SEV-ES breakage on latest tree. Thanks, Tom James -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#88948): https://edk2.groups.io/g/devel/message/88948 Mute This Topic: https://groups.io/mt/90427519/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [edk2-discuss] GSoC Proposal
Hey Brian, On 15.04.22 18:22, Brian J. Johnson wrote: Nate, Andrew, Marvin, Pedro, Ada, et al, This is a great discussion. I've been debating where to weigh in... Personally, I don't think this topic can get enough attention. Thanks! :) I agree that some sort of library sharing to reduce image size would be very helpful. Although some parts of the BIOS are built separately, large parts of it are compiled at the same time, so there should be ample opportunity for tool-directed sharing. Some form of pre-linking modules together may be the easiest way to do that. But however it gets implemented, we should try to make it automatic: requiring library writers to manually add a lot of metadata or write thunks or shims would be a barrier to adoption. My suggestion to use a private function array would indeed require shims, however this would be the "better than nothing I guess" solution where only the most used and most painful to duplicate functions are shared, e.g., memory and maybe common string printing functions. This would quickly and efficiently achieve the goal of "reduce size". And some form of sophisticated prelinking would be my proposal for something more systematic, which might come a lot cheaper with the security features to be added. I also agree that PEI has acquired far too much functionality over time, and we badly need to find some way to reverse that. PEI is pulling in more and more of the h/w initialization, leaving DXE mainly to provide the boot interface (ACPI, UEFI services, setup screens, etc.) That puts more and more pressure on XIP storage and cache-as-RAM. How can we encourage a change? I'm not in the loop enough to comment on the XIP and CAR issues. However, HW init moving to PEI (or more generally, into a single stage) is not necessarily a bad thing, is it? As I've said before, I'm not sure what else to think of PEI than "DXE light". Both "initialise some of the hardware" with no clear scope boundary but with similar interfaces. If they were sort of fused to provide a minimal "pre-memory PEI" and a more DXE-like "post-memory PEI" without having a clear boundary between HW init steps, would that be too bad? Now I'm *really* just blindly guessing because I barely looked into this project, but isn't that somewhat the idea of SlimBootloader? Your description of DXE sort of is it collapsing into an advanced BDS. Nate earlier said he'd like a clear distinction between DXE and BDS, which I didn't really get the point of. But if PEI consumed the HW init portions of DXE, a more advanced BDS (which also powers e.g. the HID stuff on the way) would be the logical remainder stage to separately support UEFI booting as a payload (for SlimBootloader, coreboot, ...). All of that was logically speaking. Even if the development was driven to its extreme, PEI and DXE cores would still share a bunch of code and it might make sense to share a foundation technically. Best regards, Marvin Thanks, Brian J. Johnson On 4/15/22 03:15, Nate DeSimone wrote: Hi Andrew, On 4/14/22, 7:43 PM, "Andrew Fish" wrote: On Apr 14, 2022, at 6:06 PM, Nate DeSimone wrote: Hi Marvin, -Original Message- From: devel@edk2.groups.io On Behalf Of Marvin Häuser Sent: Thursday, April 14, 2022 12:56 AM To: disc...@edk2.groups.io; Desimone, Nathaniel L Cc: Pedro Falcato ; edk2-devel-groups-io ; adachristin...@gmail.com; Shi, Steven Subject: Re: [edk2-devel] [edk2-discuss] GSoC Proposal I feel like there are so many much easier solutions to this problem that are at most limited by the clear specification. The UEFI specification with regards to booting and all of that obviously is of utmost importance. If you have a better idea that retains compatibility with the existing UEFI PI then I would be happy to hear it. Ultimately anything we do needs to be a pure extension that retains compatibility with old code. Given that restriction having the ability to coalesce all the LibraryClasses into a single module and have cross-module linking seems like the best way to handle it to me. The UEFI PI specification parts that deal about internal structure, as far as I know, are only in place to make it easy to integrate Intel IP. Its not just for Intel. The biggest reason for it to increase the standardization of the boot flow across the PC ecosystem. We have learned from experience that firmware is super critical to get a product out the door but it is also difficult to write. So we try to make it as reusable as humanly possible. In fact, I don’t *know*, but I’m pretty sure the very strict separation between PEI and DXE was preserved mostly because MRC was 32-bit-only for a long time. Glad that seems to have been resolved, AMD does memory init by PSP nowadays. Having less complex early stages chain load more complex later stages is a common design pattern in firmware, not just UEFI. For example, your typical ARM system loads kind
Re: [edk2-devel] [edk2-discuss] GSoC Proposal
Nate, Andrew, Marvin, Pedro, Ada, et al, This is a great discussion. I've been debating where to weigh in... I agree that some sort of library sharing to reduce image size would be very helpful. Although some parts of the BIOS are built separately, large parts of it are compiled at the same time, so there should be ample opportunity for tool-directed sharing. Some form of pre-linking modules together may be the easiest way to do that. But however it gets implemented, we should try to make it automatic: requiring library writers to manually add a lot of metadata or write thunks or shims would be a barrier to adoption. I also agree that PEI has acquired far too much functionality over time, and we badly need to find some way to reverse that. PEI is pulling in more and more of the h/w initialization, leaving DXE mainly to provide the boot interface (ACPI, UEFI services, setup screens, etc.) That puts more and more pressure on XIP storage and cache-as-RAM. How can we encourage a change? Thanks, Brian J. Johnson On 4/15/22 03:15, Nate DeSimone wrote: Hi Andrew, On 4/14/22, 7:43 PM, "Andrew Fish" wrote: On Apr 14, 2022, at 6:06 PM, Nate DeSimone wrote: Hi Marvin, -Original Message- From: devel@edk2.groups.io On Behalf Of Marvin Häuser Sent: Thursday, April 14, 2022 12:56 AM To: disc...@edk2.groups.io; Desimone, Nathaniel L Cc: Pedro Falcato ; edk2-devel-groups-io ; adachristin...@gmail.com; Shi, Steven Subject: Re: [edk2-devel] [edk2-discuss] GSoC Proposal I feel like there are so many much easier solutions to this problem that are at most limited by the clear specification. The UEFI specification with regards to booting and all of that obviously is of utmost importance. If you have a better idea that retains compatibility with the existing UEFI PI then I would be happy to hear it. Ultimately anything we do needs to be a pure extension that retains compatibility with old code. Given that restriction having the ability to coalesce all the LibraryClasses into a single module and have cross-module linking seems like the best way to handle it to me. The UEFI PI specification parts that deal about internal structure, as far as I know, are only in place to make it easy to integrate Intel IP. Its not just for Intel. The biggest reason for it to increase the standardization of the boot flow across the PC ecosystem. We have learned from experience that firmware is super critical to get a product out the door but it is also difficult to write. So we try to make it as reusable as humanly possible. In fact, I don’t *know*, but I’m pretty sure the very strict separation between PEI and DXE was preserved mostly because MRC was 32-bit-only for a long time. Glad that seems to have been resolved, AMD does memory init by PSP nowadays. Having less complex early stages chain load more complex later stages is a common design pattern in firmware, not just UEFI. For example, your typical ARM system loads kinda like this: PBL (SoC ROM) --> SBL (RAM Init) --> ARM Trust Zone --> Hypervisor --> EDK II or U-Boot or LittleKernel (which runs android fastboot) Comparing relative complexity I believe the Intel UEFI PI design is actually pretty simple when you consider how much it gets done: Ucode ROM --> SEC + PEI --> DXE + SMM + BDS My biggest criticism of the design is that the strict separation between PEI and DXE doesn't exist between DXE, SMM, and BDS 😊 There are a few reasons why PEI was 32-bit for quite some time. The biggest one is the code size increase, 64-bit x86 code is 20-30% larger than 32-bit x86 code. Since the only RAM Pre-Memory code has access to is the cache onboard the processor and for security reasons all that code has to fit within that RAM we generally do everything we can to make that image as small as possible. Second, 64-bit requires a page table and since we desired to keep PEI simple we tried to avoid that. Finally, the PI spec didn't allow a 64-bit PEI until recently. MRC is 32-bit code just because that is what PEI happens to be. Porting it to 64-bit is not terribly difficult. Ultimately the mix of 32/64-bit does cause some difficulties. Any data structures that get shared between PEI and DXE (HOBs, PCDs, etc.) need to resolve to the same size and packing. LibraryClasses need to be written to compile properly in both modes. In the case of FSP API mode you need to resort to thunking between 32 and 64-bit modes during DXE. More or less we decided that the costs are starting to outweigh the advantages. I’d also point out that x86 VMs use X64 (x86-64) PEI today and it works so the 32-bit/64-bit mix has nothing to do with UEFI/PI/edk2. In the PC ecosystem a single chipset family can power thousands of unique designs. So the DRAM memory needs to be external, support lots of different chipset packages(signal integrity...), support the lowest cost through the highest cost DRAM and thousands of different board layout
Re: [edk2-devel] [edk2-discuss] GSoC Proposal
On 15.04.22 17:02, Yao, Jiewen wrote: Exactly. Lacking of doc from different compilers is very painful. The Asan or UBsan support is just a hack - https://github.com/jyao1/SecurityEx/blob/master/StackCheckPkg/Library/StackCheckLib/ASanStub.c https://github.com/jyao1/SecurityEx/blob/master/StackCheckPkg/Library/StackCheckLib/UBSanStub.c Another challenge is: What do we do in case of violation? If you just want a POC or debug purpose, it is easy to use deadloop. I mean, did you plan to deploy ASan in production? I'm not sure a full implementation is performant or compatible with space constraints. Being a debug feature, I'm surprised this is a reason for rejection. There is toolchain-specific debug stuff live already (e.g. symbols support for the RVCT debugger). If you want to a production, then what do we do in RT driver? deadloop in OS is not a good idea. As for what to do with RT drivers, I wonder whether Windows can cooperate? With Virtualisation-Based Security, there is a (hopefully) trusted core that can still intervene kernel-mode drivers from acting up. I.e., on fault, can one just fail the RT service call and report to the OS for it to apply whatever policy it considers appropriate, like force-unload the calling driver (if any)? If you do not consider the special-case of SMM-guarded security a malicious OS may want to exploit (which is a reason why the Amaranth downstream will outright deprecate SMM guarding), a malicious OS could just perform any action it may provoke the firmware to do itself, so I feel like it's fair if the OS was trusted, it cooperated, and it took handling authority. I guess the only other alternatives are tolerant failure (continue business as usual after returning an error) and intolerant failure (shut down RT services till reboot). Of course this should be configurable, so that high-security platforms can indeed deadloop or reset the platform. Best regards, Marvin Thank you Yao Jiewen -Original Message- From: disc...@edk2.groups.io On Behalf Of Zimmer, Vincent Sent: Friday, April 15, 2022 10:54 PM To: disc...@edk2.groups.io; mhaeu...@posteo.de; Ada Christine ; edk2-devel-groups-io ; Desimone, Nathaniel L ; Mike Wolan ; Kinney, Michael D Cc: Andrew Fish ; Pedro Falcato ; Shi, Steven Subject: Re: [edk2-devel] [edk2-discuss] GSoC Proposal Historically the challenge we had w/ upstreaming some features was if the compiler intrinsic for which a particular feature was dependent didn't have public documentation or wasn't supported by all of the compilers that EDKII supported. For the former, this lack of info would lead to the patches being rejected. Vincent -Original Message- From: disc...@edk2.groups.io On Behalf Of Marvin Häuser Sent: Friday, April 15, 2022 6:40 AM To: disc...@edk2.groups.io; Zimmer, Vincent ; Ada Christine ; edk2-devel-groups-io ; Desimone, Nathaniel L ; Mike Wolan ; Kinney, Michael D Cc: Andrew Fish ; Pedro Falcato ; Shi, Steven Subject: Re: [edk2-devel] [edk2-discuss] GSoC Proposal Hey Vincent, In fact I haven't, thanks a lot! Are there any known blockers for these outside development resources? Except for C++, they are things we'd want asap downstream. I guess rather than OverflowDetectionPkg, ASan has higher priority here. Best regards, Marvin On 15.04.22 15:31, Zimmer, Vincent wrote: Fyi There is a running list of some edk2 defense-in-depth work at https://github.com/jyao1/SecurityEx/blob/master/Summary.md, too, including ASLR, if you haven't already seen that material -Original Message- From: disc...@edk2.groups.io On Behalf Of Marvin Häuser Sent: Friday, April 15, 2022 5:31 AM To: Ada Christine ; edk2-devel-groups-io ; Desimone, Nathaniel L ; Mike Wolan ; Kinney, Michael D Cc: Andrew Fish ; disc...@edk2.groups.io; Pedro Falcato ; Shi, Steven Subject: Re: [edk2-devel] [edk2-discuss] GSoC Proposal CC Mike (proposal review as per announcement mail) Hey Ada, I can neither decide on nor even view your proposal (I think that's up to Nate and Mike?), but I had a brief conversation with Vitaly about the Amaranth downstream. There are other potentially technologically related topics Vitaly's team wants to deploy, including driver sandboxing and ASLR (both will probably significantly impact paging). The easiest route for these two is likely to let go of identity mapping. *If* this is feasible and will be accepted upstream, prelinking might become a much simpler matter. For memory protection, all PE/COFF image sections must be page-aligned anyway, so depending on how the more sophisticated paging would actually work, there may be a lot of wiggle room for where to load modules wrt virtual addresses. In *simple and naive* theory, they could all be assigned a virtual base address at UEFI image construction (which will be free from any physical memory layout constraints due to non-identity mapping) and ASLR could just be a slide value that shifts the entire executable UEFI address
Re: [edk2-devel] [edk2-discuss] GSoC Proposal
Exactly. Lacking of doc from different compilers is very painful. The Asan or UBsan support is just a hack - https://github.com/jyao1/SecurityEx/blob/master/StackCheckPkg/Library/StackCheckLib/ASanStub.c https://github.com/jyao1/SecurityEx/blob/master/StackCheckPkg/Library/StackCheckLib/UBSanStub.c Another challenge is: What do we do in case of violation? If you just want a POC or debug purpose, it is easy to use deadloop. If you want to a production, then what do we do in RT driver? deadloop in OS is not a good idea. Thank you Yao Jiewen > -Original Message- > From: disc...@edk2.groups.io On Behalf Of Zimmer, > Vincent > Sent: Friday, April 15, 2022 10:54 PM > To: disc...@edk2.groups.io; mhaeu...@posteo.de; Ada Christine > ; edk2-devel-groups-io ; > Desimone, Nathaniel L ; Mike Wolan > ; Kinney, Michael D > Cc: Andrew Fish ; Pedro Falcato > ; Shi, Steven > Subject: Re: [edk2-devel] [edk2-discuss] GSoC Proposal > > Historically the challenge we had w/ upstreaming some features was if the > compiler intrinsic for which a particular feature was dependent didn't have > public documentation or wasn't supported by all of the compilers that EDKII > supported. For the former, this lack of info would lead to the patches being > rejected. > > Vincent > > -Original Message- > From: disc...@edk2.groups.io On Behalf Of Marvin > Häuser > Sent: Friday, April 15, 2022 6:40 AM > To: disc...@edk2.groups.io; Zimmer, Vincent ; Ada > Christine ; edk2-devel-groups-io > ; Desimone, Nathaniel L > ; Mike Wolan ; > Kinney, Michael D > Cc: Andrew Fish ; Pedro Falcato > ; Shi, Steven > Subject: Re: [edk2-devel] [edk2-discuss] GSoC Proposal > > Hey Vincent, > > In fact I haven't, thanks a lot! Are there any known blockers for these > outside > development resources? Except for C++, they are things we'd want asap > downstream. I guess rather than OverflowDetectionPkg, ASan has higher priority > here. > > Best regards, > Marvin > > On 15.04.22 15:31, Zimmer, Vincent wrote: > > Fyi > > There is a running list of some edk2 defense-in-depth work at > > https://github.com/jyao1/SecurityEx/blob/master/Summary.md, too, > > including ASLR, if you haven't already seen that material > > > > -Original Message- > > From: disc...@edk2.groups.io On Behalf Of > > Marvin Häuser > > Sent: Friday, April 15, 2022 5:31 AM > > To: Ada Christine ; edk2-devel-groups-io > > ; Desimone, Nathaniel L > > ; Mike Wolan ; > > Kinney, Michael D > > Cc: Andrew Fish ; disc...@edk2.groups.io; Pedro > > Falcato ; Shi, Steven > > Subject: Re: [edk2-devel] [edk2-discuss] GSoC Proposal > > > > CC Mike (proposal review as per announcement mail) > > > > Hey Ada, > > > > I can neither decide on nor even view your proposal (I think that's up to > > Nate > and Mike?), but I had a brief conversation with Vitaly about the Amaranth > downstream. There are other potentially technologically related topics > Vitaly's > team wants to deploy, including driver sandboxing and ASLR (both will probably > significantly impact paging). The easiest route for these two is likely to > let go of > identity mapping. *If* this is feasible and will be accepted upstream, > prelinking > might become a much simpler matter. For memory protection, all PE/COFF > image sections must be page-aligned anyway, so depending on how the more > sophisticated paging would actually work, there may be a lot of wiggle room > for > where to load modules wrt virtual addresses. In *simple and naive* theory, > they > could all be assigned a virtual base address at UEFI image construction (which > will be free from any physical memory layout constraints due to non-identity > mapping) and ASLR could just be a slide value that shifts the entire > executable > UEFI address space around (randomised). With (virtual) addresses known at > build-time, none of that "custom relocation" madness I mentioned before is > relevant (gladly). Of course, there needs to be discussion whether > fine-grained > ASLR would be worth the trouble first. > > > > To get more input on the "ecosystem" of security features mentioned (ASLR, > sandboxing, prelinking), we will try to discuss it with Microsoft next week. > If you > are interested in a prelinking route, I can let you know. This would unlikely > be > quick to deploy, however, and it would need strong support from Intel. I think > the overall pool of ideas is clear now and I'll leave it to you and Nate. > Good luck! > > > > Best regards, > > Marvin > > > > On 15.04.22 14:09, Ada Christine wrote: > >> Hi Everybody > >> > >> I've read all the discussion here and condensed my plan into a short > >> project proposal. It's a little short and light on detail at the > >> moment because I'm pressed for time for other matters today, but I > >> wanted to get something in before EOD today as requested. Anybody > >> else's input or a change in the overall strategy to allow for code > >> sharing between DXE modules, whether it be prelinking or so
Re: [edk2-devel] [edk2-discuss] GSoC Proposal
Historically the challenge we had w/ upstreaming some features was if the compiler intrinsic for which a particular feature was dependent didn't have public documentation or wasn't supported by all of the compilers that EDKII supported. For the former, this lack of info would lead to the patches being rejected. Vincent -Original Message- From: disc...@edk2.groups.io On Behalf Of Marvin Häuser Sent: Friday, April 15, 2022 6:40 AM To: disc...@edk2.groups.io; Zimmer, Vincent ; Ada Christine ; edk2-devel-groups-io ; Desimone, Nathaniel L ; Mike Wolan ; Kinney, Michael D Cc: Andrew Fish ; Pedro Falcato ; Shi, Steven Subject: Re: [edk2-devel] [edk2-discuss] GSoC Proposal Hey Vincent, In fact I haven't, thanks a lot! Are there any known blockers for these outside development resources? Except for C++, they are things we'd want asap downstream. I guess rather than OverflowDetectionPkg, ASan has higher priority here. Best regards, Marvin On 15.04.22 15:31, Zimmer, Vincent wrote: > Fyi > There is a running list of some edk2 defense-in-depth work at > https://github.com/jyao1/SecurityEx/blob/master/Summary.md, too, > including ASLR, if you haven't already seen that material > > -Original Message- > From: disc...@edk2.groups.io On Behalf Of > Marvin Häuser > Sent: Friday, April 15, 2022 5:31 AM > To: Ada Christine ; edk2-devel-groups-io > ; Desimone, Nathaniel L > ; Mike Wolan ; > Kinney, Michael D > Cc: Andrew Fish ; disc...@edk2.groups.io; Pedro > Falcato ; Shi, Steven > Subject: Re: [edk2-devel] [edk2-discuss] GSoC Proposal > > CC Mike (proposal review as per announcement mail) > > Hey Ada, > > I can neither decide on nor even view your proposal (I think that's up to > Nate and Mike?), but I had a brief conversation with Vitaly about the > Amaranth downstream. There are other potentially technologically related > topics Vitaly's team wants to deploy, including driver sandboxing and ASLR > (both will probably significantly impact paging). The easiest route for these > two is likely to let go of identity mapping. *If* this is feasible and will > be accepted upstream, prelinking might become a much simpler matter. For > memory protection, all PE/COFF image sections must be page-aligned anyway, so > depending on how the more sophisticated paging would actually work, there may > be a lot of wiggle room for where to load modules wrt virtual addresses. In > *simple and naive* theory, they could all be assigned a virtual base address > at UEFI image construction (which will be free from any physical memory > layout constraints due to non-identity mapping) and ASLR could just be a > slide value that shifts the entire executable UEFI address space around > (randomised). With (virtual) addresses known at build-time, none of that > "custom relocation" madness I mentioned before is relevant (gladly). Of > course, there needs to be discussion whether fine-grained ASLR would be worth > the trouble first. > > To get more input on the "ecosystem" of security features mentioned (ASLR, > sandboxing, prelinking), we will try to discuss it with Microsoft next week. > If you are interested in a prelinking route, I can let you know. This would > unlikely be quick to deploy, however, and it would need strong support from > Intel. I think the overall pool of ideas is clear now and I'll leave it to > you and Nate. Good luck! > > Best regards, > Marvin > > On 15.04.22 14:09, Ada Christine wrote: >> Hi Everybody >> >> I've read all the discussion here and condensed my plan into a short >> project proposal. It's a little short and light on detail at the >> moment because I'm pressed for time for other matters today, but I >> wanted to get something in before EOD today as requested. Anybody >> else's input or a change in the overall strategy to allow for code >> sharing between DXE modules, whether it be prelinking or some kind of >> function pointer table is absolutely welcome and I'm not attached to >> any particular way of solving the code repetition problem. You can >> find my proposal here >> https://summerofcode.withgoogle.com/proposals/details/whGX9tXL >> >> Looking forward to your commentary! >> >> Thanks! >> - Ada Christine > > > > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#88943): https://edk2.groups.io/g/devel/message/88943 Mute This Topic: https://groups.io/mt/90435699/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [edk2-discuss] GSoC Proposal
Hey Vincent, In fact I haven't, thanks a lot! Are there any known blockers for these outside development resources? Except for C++, they are things we'd want asap downstream. I guess rather than OverflowDetectionPkg, ASan has higher priority here. Best regards, Marvin On 15.04.22 15:31, Zimmer, Vincent wrote: Fyi There is a running list of some edk2 defense-in-depth work at https://github.com/jyao1/SecurityEx/blob/master/Summary.md, too, including ASLR, if you haven't already seen that material -Original Message- From: disc...@edk2.groups.io On Behalf Of Marvin Häuser Sent: Friday, April 15, 2022 5:31 AM To: Ada Christine ; edk2-devel-groups-io ; Desimone, Nathaniel L ; Mike Wolan ; Kinney, Michael D Cc: Andrew Fish ; disc...@edk2.groups.io; Pedro Falcato ; Shi, Steven Subject: Re: [edk2-devel] [edk2-discuss] GSoC Proposal CC Mike (proposal review as per announcement mail) Hey Ada, I can neither decide on nor even view your proposal (I think that's up to Nate and Mike?), but I had a brief conversation with Vitaly about the Amaranth downstream. There are other potentially technologically related topics Vitaly's team wants to deploy, including driver sandboxing and ASLR (both will probably significantly impact paging). The easiest route for these two is likely to let go of identity mapping. *If* this is feasible and will be accepted upstream, prelinking might become a much simpler matter. For memory protection, all PE/COFF image sections must be page-aligned anyway, so depending on how the more sophisticated paging would actually work, there may be a lot of wiggle room for where to load modules wrt virtual addresses. In *simple and naive* theory, they could all be assigned a virtual base address at UEFI image construction (which will be free from any physical memory layout constraints due to non-identity mapping) and ASLR could just be a slide value that shifts the entire executable UEFI address space around (randomised). With (virtual) addresses known at build-time, none of that "custom relocation" madness I mentioned before is relevant (gladly). Of course, there needs to be discussion whether fine-grained ASLR would be worth the trouble first. To get more input on the "ecosystem" of security features mentioned (ASLR, sandboxing, prelinking), we will try to discuss it with Microsoft next week. If you are interested in a prelinking route, I can let you know. This would unlikely be quick to deploy, however, and it would need strong support from Intel. I think the overall pool of ideas is clear now and I'll leave it to you and Nate. Good luck! Best regards, Marvin On 15.04.22 14:09, Ada Christine wrote: Hi Everybody I've read all the discussion here and condensed my plan into a short project proposal. It's a little short and light on detail at the moment because I'm pressed for time for other matters today, but I wanted to get something in before EOD today as requested. Anybody else's input or a change in the overall strategy to allow for code sharing between DXE modules, whether it be prelinking or some kind of function pointer table is absolutely welcome and I'm not attached to any particular way of solving the code repetition problem. You can find my proposal here https://summerofcode.withgoogle.com/proposals/details/whGX9tXL Looking forward to your commentary! Thanks! - Ada Christine -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#88942): https://edk2.groups.io/g/devel/message/88942 Mute This Topic: https://groups.io/mt/90435699/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [edk2-discuss] GSoC Proposal
Fyi There is a running list of some edk2 defense-in-depth work at https://github.com/jyao1/SecurityEx/blob/master/Summary.md, too, including ASLR, if you haven't already seen that material -Original Message- From: disc...@edk2.groups.io On Behalf Of Marvin Häuser Sent: Friday, April 15, 2022 5:31 AM To: Ada Christine ; edk2-devel-groups-io ; Desimone, Nathaniel L ; Mike Wolan ; Kinney, Michael D Cc: Andrew Fish ; disc...@edk2.groups.io; Pedro Falcato ; Shi, Steven Subject: Re: [edk2-devel] [edk2-discuss] GSoC Proposal CC Mike (proposal review as per announcement mail) Hey Ada, I can neither decide on nor even view your proposal (I think that's up to Nate and Mike?), but I had a brief conversation with Vitaly about the Amaranth downstream. There are other potentially technologically related topics Vitaly's team wants to deploy, including driver sandboxing and ASLR (both will probably significantly impact paging). The easiest route for these two is likely to let go of identity mapping. *If* this is feasible and will be accepted upstream, prelinking might become a much simpler matter. For memory protection, all PE/COFF image sections must be page-aligned anyway, so depending on how the more sophisticated paging would actually work, there may be a lot of wiggle room for where to load modules wrt virtual addresses. In *simple and naive* theory, they could all be assigned a virtual base address at UEFI image construction (which will be free from any physical memory layout constraints due to non-identity mapping) and ASLR could just be a slide value that shifts the entire executable UEFI address space around (randomised). With (virtual) addresses known at build-time, none of that "custom relocation" madness I mentioned before is relevant (gladly). Of course, there needs to be discussion whether fine-grained ASLR would be worth the trouble first. To get more input on the "ecosystem" of security features mentioned (ASLR, sandboxing, prelinking), we will try to discuss it with Microsoft next week. If you are interested in a prelinking route, I can let you know. This would unlikely be quick to deploy, however, and it would need strong support from Intel. I think the overall pool of ideas is clear now and I'll leave it to you and Nate. Good luck! Best regards, Marvin On 15.04.22 14:09, Ada Christine wrote: > Hi Everybody > > I've read all the discussion here and condensed my plan into a short > project proposal. It's a little short and light on detail at the > moment because I'm pressed for time for other matters today, but I > wanted to get something in before EOD today as requested. Anybody > else's input or a change in the overall strategy to allow for code > sharing between DXE modules, whether it be prelinking or some kind of > function pointer table is absolutely welcome and I'm not attached to > any particular way of solving the code repetition problem. You can > find my proposal here > https://summerofcode.withgoogle.com/proposals/details/whGX9tXL > > Looking forward to your commentary! > > Thanks! > - Ada Christine -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#88941): https://edk2.groups.io/g/devel/message/88941 Mute This Topic: https://groups.io/mt/90435699/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [edk2-discuss] GSoC Proposal
CC Mike (proposal review as per announcement mail) Hey Ada, I can neither decide on nor even view your proposal (I think that's up to Nate and Mike?), but I had a brief conversation with Vitaly about the Amaranth downstream. There are other potentially technologically related topics Vitaly's team wants to deploy, including driver sandboxing and ASLR (both will probably significantly impact paging). The easiest route for these two is likely to let go of identity mapping. *If* this is feasible and will be accepted upstream, prelinking might become a much simpler matter. For memory protection, all PE/COFF image sections must be page-aligned anyway, so depending on how the more sophisticated paging would actually work, there may be a lot of wiggle room for where to load modules wrt virtual addresses. In *simple and naive* theory, they could all be assigned a virtual base address at UEFI image construction (which will be free from any physical memory layout constraints due to non-identity mapping) and ASLR could just be a slide value that shifts the entire executable UEFI address space around (randomised). With (virtual) addresses known at build-time, none of that "custom relocation" madness I mentioned before is relevant (gladly). Of course, there needs to be discussion whether fine-grained ASLR would be worth the trouble first. To get more input on the "ecosystem" of security features mentioned (ASLR, sandboxing, prelinking), we will try to discuss it with Microsoft next week. If you are interested in a prelinking route, I can let you know. This would unlikely be quick to deploy, however, and it would need strong support from Intel. I think the overall pool of ideas is clear now and I'll leave it to you and Nate. Good luck! Best regards, Marvin On 15.04.22 14:09, Ada Christine wrote: Hi Everybody I've read all the discussion here and condensed my plan into a short project proposal. It's a little short and light on detail at the moment because I'm pressed for time for other matters today, but I wanted to get something in before EOD today as requested. Anybody else's input or a change in the overall strategy to allow for code sharing between DXE modules, whether it be prelinking or some kind of function pointer table is absolutely welcome and I'm not attached to any particular way of solving the code repetition problem. You can find my proposal here https://summerofcode.withgoogle.com/proposals/details/whGX9tXL Looking forward to your commentary! Thanks! - Ada Christine -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#88940): https://edk2.groups.io/g/devel/message/88940 Mute This Topic: https://groups.io/mt/90435699/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [edk2-discuss] GSoC Proposal
Hi Everybody I've read all the discussion here and condensed my plan into a short project proposal. It's a little short and light on detail at the moment because I'm pressed for time for other matters today, but I wanted to get something in before EOD today as requested. Anybody else's input or a change in the overall strategy to allow for code sharing between DXE modules, whether it be prelinking or some kind of function pointer table is absolutely welcome and I'm not attached to any particular way of solving the code repetition problem. You can find my proposal here https://summerofcode.withgoogle.com/proposals/details/whGX9tXL Looking forward to your commentary! Thanks! - Ada Christine -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#88939): https://edk2.groups.io/g/devel/message/88939 Mute This Topic: https://groups.io/mt/90435699/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v1 1/1] MdeModulePkg: Use SmmWaitForAllProcessor() in VariableSmm driver.
I see the configuration in MdeModulePkg\MdeModulePkg.ci.yaml. I add SmmCpuRendezvousLib.h in MdeModulePkg/Include/Library folder so that it doesn't need add UefiCpuPkg.dec in [Packages] and bypass the check. For the second point, due to the patch pass the CI test, it also pass the PlatformCI_ArmVirtPkg. I don't realize that any problem in Arm platform build. Leif and Ard Does the patch has any influence on arm platform build? Liming: If the solution is not acceptable, how about I create NULL version of SmmCpuRendezvousLib in MdeModulePkg and use it in MdeModulePkg.dsc? Is that a acceptable solution for you? > -Original Message- > From: gaoliming > Sent: Wednesday, April 13, 2022 9:30 AM > To: Li, Zhihao ; devel@edk2.groups.io; 'Michael Kubacki' > ; 'Ard Biesheuvel' > ; 'Leif Lindholm' ; 'Sean > Brogan' > Cc: Wang, Jian J ; Fu, Siyuan ; > Ni, > Ray ; Kinney, Michael D ; Yao, > Jiewen > Subject: 回复: [edk2-devel] [PATCH v1 1/1] MdeModulePkg: Use > SmmWaitForAllProcessor() in VariableSmm driver. > > Zhihao: > I remember CI has the check for the package dependency. If this patch passes > CI, seemly this checker doesn't do. You can see DependencyCheck in > MdeModulePkg\MdeModulePkg.ci.yaml. > And, this patch introduces new dependency in VariableStandaloneMm. It has > been used in edk2 platform ARM platform. This change will break these platform > build. Please notify the platform owners. > > Sean and Michael: > This patch adds UefiCpuPkg library instance SmmCpuRendezvousLib into > MdeModulePkg.dsc. But, CI can pass. Is this the expected behavior? > > Thanks > Liming > > -邮件原件- > > 发件人: Li, Zhihao > > 发送时间: 2022年4月13日 2:14 > > 收件人: Gao, Liming ; devel@edk2.groups.io > > 抄送: Wang, Jian J ; Fu, Siyuan > > ; Ni, Ray ; Kinney, Michael D > > > > 主题: RE: [edk2-devel] [PATCH v1 1/1] MdeModulePkg: Use > > SmmWaitForAllProcessor() in VariableSmm driver. > > > > 1. Although SmmCpuRendezvousLib in UefiCpuPkg, add SmmRendezvousLib.h > > into MdeModulePkg/Include/Library folder bypass the check. > > 2. The SmmRendezvousLib is a standalone MM library and doesn’t have > > any DXE service dependency. It can be used by SMM variable module and > > MM variable module. > > > > As the patch following, it have passed the Edk2 CI test. The code can > > run successfully in practice, but I'm not sure if this is acceptable > > in terms of the standard. > > > > -Original Message- > > From: gaoliming > > Sent: Tuesday, April 12, 2022 9:00 AM > > To: devel@edk2.groups.io; Li, Zhihao > > Cc: Wang, Jian J ; Fu, Siyuan > > ; Ni, Ray ; Kinney, Michael D > > > > Subject: 回复: [edk2-devel] [PATCH v1 1/1] MdeModulePkg: Use > > SmmWaitForAllProcessor() in VariableSmm driver. > > > > Zhihao: > > This patch breaks two things. One is to let MdeModulePkg depend on > > UefiCpuPkg, another is to let VariableStandaloneMm depend on > > UefiCpuPkg SmmCpuRendezvousLib. Please provide your proposal to > > resolve these two dependency first. > > > > Thanks > > Liming > > > -邮件原件- > > > 发件人: devel@edk2.groups.io 代表 Li, Zhihao > > > 发送时间: 2022年4月11日 15:07 > > > 收件人: devel@edk2.groups.io > > > 抄送: Jian J Wang ; Liming Gao > > > ; Siyuan Fu ; Ni Ray > > > ; Michael D Kinney > > > 主题: [edk2-devel] [PATCH v1 1/1] MdeModulePkg: Use > > > SmmWaitForAllProcessor() in VariableSmm driver. > > > > > > REF： https://bugzilla.tianocore.org/show_bug.cgi?id=3854 > > > > > > In UefiCpuPkg, there are a new Protocol with the new service > > > SmmWaitForAllProcessor(), which can be used by SMI handler to > > > optionally wait for other APs to complete SMM rendezvous in relaxed > > > AP mode. > > > > > > This patch use the new service to let VariableSmm driver work > > > normally in relaxed AP mode. > > > > > > Cc: Jian J Wang > > > Cc: Liming Gao > > > Cc: Siyuan Fu > > > Cc: Ni Ray > > > Cc: Michael D Kinney > > > > > > Signed-off-by: Zhihao Li > > > --- > > > MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c > > > | 10 +++- > > > MdeModulePkg/Include/Library/SmmCpuRendezvousLib.h > > > | 27 > > > MdeModulePkg/MdeModulePkg.dec > > > | 5 +++- > > > MdeModulePkg/MdeModulePkg.dsc > > > | 4 ++- > > > MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf > > > | 3 ++- > > > > > MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf > > > | 3 ++- > > > 6 files changed, 47 insertions(+), 5 deletions(-) > > > > > > diff --git > > > a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c > > > b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c > > > index 517cae7b00f8..52a9b0e6b202 100644 > > > --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c > > > +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c > > > @@ -14,7 +14,7 @@ > > >VariableServiceSetVariable(), VariableServiceQueryVariableInfo(), > > > ReclaimForOS(), > > > > > >SmmVariableGetStatistics() should also do validation based on its > > > own knowledge. > > > > > >
Re: [edk2-devel][PATCH v5 0/8] Support PEI 64bit in IntelFsp2Pkg and IntelFsp2WrapperPkg
Thanks for fixing issues Ted!
For this patch series: Reviewed-by: Chasel Chiu
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Kuo,
> Ted
> Sent: Friday, April 15, 2022 4:38 PM
> To: devel@edk2.groups.io
> Subject: [edk2-devel][PATCH v5 0/8] Support PEI 64bit in IntelFsp2Pkg and
> IntelFsp2WrapperPkg
>
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3893
>
> Currently PEI drivers/libraries only support 32bit in IntelFsp2Pkg and
> IntelFsp2WrapperPkg. The patches below are needed to support these
> drivers/libraries in 64bit.
>
> V2 changes:
> 1.Change FSPM_UPD_COMMON2 to FSPM_UPD_COMMON_FSP24 in
> FspApiEntryM.nasm.
> 2.Add FSPx_UPD_COMMON_FSP24 in FspApi.h.
> 3.Add 3 additional patches for supporting X64 in IntelFsp2WrapperPkg.
>
> V3 changes:
> 1.Update FSPT_ARCH2_UPD and add FSPT_CORE_UPD back.
> 2.Use 0x instead of MAX_ADDRESS to reflect the default of
> FspData.
> 3.Remove EnableMultiPhaseMemoryInit from FSPM_ARCH2_UPD.
> 4.Bump GenCfgOpt version to 0.57.
>
> V4 changes:
> 1.Added EFIAPI to SwapStack and PEI_CORE_ENTRY.
> 2.Cast FspData from pointer to UINTN and then from UINTN to UINT32.
> 3.Corrected few typos.
>
> Ted Kuo (8):
> IntelFsp2Pkg: X64 compatible changes to support PEI in 64bit
> IntelFsp2Pkg: Add FSPx_ARCH2_UPD support for X64
> IntelFsp2Pkg: Update FSP_GLOBAL_DATA and FSP_PLAT_DATA for X64
> IntelFsp2Pkg: FspSecCore support for X64
> IntelFsp2Pkg: SecFspSecPlatformLibNull support for X64
> IntelFsp2WrapperPkg: Adopt FSPM_UPD_COMMON_FSP24 for X64
> IntelFsp2WrapperPkg: BaseFspWrapperApiLib support for X64
> IntelFsp2WrapperPkg: SecFspWrapperPlatformSecLibSample support for
> X64
>
> V5
> 1.Extend Copyright year to 2022 for the modified files 2.Check
> FSPM_UPD_COMMON_FSP24.Revision before configuring FSP stack.
> 3.Treat both MAX_ADDRESS and MAX_UINT32 as invalid address for FSP
> global data in FspApiCallingCheck().
> 4.Remove EnableMultiPhaseSiliconInit from FSPS_ARCH2_UPD.
> 5.Add an additional ExcludedSpecificUpd1 to exclude FSPx_ARCH2_UPD in
> GenCfgOpt.py tool.
>
> IntelFsp2Pkg/FspNotifyPhase/FspNotifyPhasePeim.c | 3 +-
> IntelFsp2Pkg/FspSecCore/Fsp22SecCoreS.inf | 10 +-
> IntelFsp2Pkg/FspSecCore/FspSecCoreM.inf| 11 +-
> IntelFsp2Pkg/FspSecCore/FspSecCoreS.inf| 10 +-
> IntelFsp2Pkg/FspSecCore/FspSecCoreT.inf| 12 +-
> .../FspSecCore/Ia32/FspApiEntryCommon.nasm | 6 +-
> IntelFsp2Pkg/FspSecCore/Ia32/FspApiEntryM.nasm | 32 +-
> IntelFsp2Pkg/FspSecCore/Ia32/FspApiEntryT.nasm | 98 +++-
> IntelFsp2Pkg/FspSecCore/Ia32/ReadEsp.nasm | 10 +-
> IntelFsp2Pkg/FspSecCore/Ia32/Stack.nasm| 12 +-
> IntelFsp2Pkg/FspSecCore/SecFsp.c | 12 +-
> IntelFsp2Pkg/FspSecCore/SecFsp.h | 4 +-
> IntelFsp2Pkg/FspSecCore/SecFspApiChk.c | 10 +-
> IntelFsp2Pkg/FspSecCore/SecMain.c | 10 +-
> IntelFsp2Pkg/FspSecCore/SecMain.h | 20 +-
> IntelFsp2Pkg/FspSecCore/X64/Fsp22ApiEntryS.nasm| 103 +
> IntelFsp2Pkg/FspSecCore/X64/FspApiEntryCommon.nasm | 76
> IntelFsp2Pkg/FspSecCore/X64/FspApiEntryM.nasm | 271 +++
> IntelFsp2Pkg/FspSecCore/X64/FspApiEntryS.nasm | 67 +++
> IntelFsp2Pkg/FspSecCore/X64/FspApiEntryT.nasm | 495
> +
> IntelFsp2Pkg/FspSecCore/X64/FspHelper.nasm | 34 ++
> IntelFsp2Pkg/FspSecCore/X64/MicrocodeLoadNasm.inc | 11 +
> IntelFsp2Pkg/FspSecCore/X64/ReadRsp.nasm | 22 +
> IntelFsp2Pkg/FspSecCore/X64/Stack.nasm | 73 +++
> IntelFsp2Pkg/Include/FspEas/FspApi.h | 139 +-
> IntelFsp2Pkg/Include/FspGlobalData.h | 53 ++-
> IntelFsp2Pkg/Include/Guid/FspHeaderFile.h | 16 +-
> IntelFsp2Pkg/Include/SaveRestoreSseAvxNasm.inc | 284
> IntelFsp2Pkg/IntelFsp2Pkg.dsc | 4 +-
> .../Library/BaseFspCommonLib/FspCommonLib.c| 6 +-
> .../BaseFspSwitchStackLib/FspSwitchStackLib.c | 3 +-
> .../Library/BaseFspSwitchStackLib/X64/Stack.nasm | 5 +-
> .../SecFspSecPlatformLibNull/Ia32/Flat32.nasm | 4 +-
> .../SecFspSecPlatformLibNull.inf | 8 +-
> .../SecFspSecPlatformLibNull/X64/Long64.nasm | 31 ++
> .../SecFspSecPlatformLibNull/X64/SecCarInit.nasm | 40 ++
> IntelFsp2Pkg/Tools/GenCfgOpt.py| 7 +-
> .../FspmWrapperPeim/FspmWrapperPeim.c | 27 +-
> .../BaseFspWrapperApiLib/FspWrapperApiLib.c| 44 +-
> .../BaseFspWrapperApiLib/IA32/DispatchExecute.c| 23 +-
> .../BaseFspWrapperApiLib/X64/DispatchExecute.c | 47 +-
> .../{Ia32 => }/Fsp.h | 0
> .../Ia32/Stack.nasm| 8 +-
> .../SecFspWrapperPlatformSecLibSample.inf | 9 +-
> .../SecRamInitData.c | 24 +-
> .../X64/PeiCoreEntry.nas
[edk2-devel][PATCH v5 8/8] IntelFsp2WrapperPkg: SecFspWrapperPlatformSecLibSample support for X64
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3893
1.Added SecFspWrapperPlatformSecLibSample support for X64.
2.Adopted FSPT_ARCH2_UPD in SecFspWrapperPlatformSecLibSample.
3.Moved Fsp.h up one level to be shared across IA32 and X64.
Cc: Chasel Chiu
Cc: Nate DeSimone
Cc: Star Zeng
Cc: Ashraf Ali S
Signed-off-by: Ted Kuo
---
.../{Ia32 => }/Fsp.h | 0
.../Ia32/Stack.nasm| 8 +-
.../SecFspWrapperPlatformSecLibSample.inf | 9 +-
.../SecRamInitData.c | 24 +--
.../X64/PeiCoreEntry.nasm | 149 ++
.../X64/SecEntry.nasm | 171 +
.../X64/Stack.nasm | 73 +
7 files changed, 418 insertions(+), 16 deletions(-)
rename IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/{Ia32 =>
}/Fsp.h (100%)
create mode 100644
IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/X64/PeiCoreEntry.nasm
create mode 100644
IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/X64/SecEntry.nasm
create mode 100644
IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/X64/Stack.nasm
diff --git
a/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/Ia32/Fsp.h
b/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/Fsp.h
similarity index 100%
rename from
IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/Ia32/Fsp.h
rename to IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/Fsp.h
diff --git
a/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/Ia32/Stack.nasm
b/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/Ia32/Stack.nasm
index d7394cf286..eb5b120816 100644
---
a/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/Ia32/Stack.nasm
+++
b/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/Ia32/Stack.nasm
@@ -1,6 +1,6 @@
;--
;
-; Copyright (c) 2016, Intel Corporation. All rights reserved.
+; Copyright (c) 2016 - 2022, Intel Corporation. All rights reserved.
; SPDX-License-Identifier: BSD-2-Clause-Patent
;
; Abstract:
@@ -22,7 +22,7 @@
global ASM_PFX(SecSwitchStack)
ASM_PFX(SecSwitchStack):
;
-; Save three register: eax, ebx, ecx
+; Save four register: eax, ebx, ecx, edx
;
push eax
push ebx
@@ -55,7 +55,7 @@ ASM_PFX(SecSwitchStack):
mov dword [eax + 12], edx
mov edx, dword [esp + 16]; Update this function's return address
into permanent memory
mov dword [eax + 16], edx
-mov esp, eax ; From now, esp is pointed to permanent
memory
+mov esp, eax ; From now, esp is pointed to permanent
memory
;
; Fixup the ebp point to permanent memory
@@ -63,7 +63,7 @@ ASM_PFX(SecSwitchStack):
mov eax, ebp
sub eax, ebx
add eax, ecx
-mov ebp, eax; From now, ebp is pointed to permanent
memory
+mov ebp, eax ; From now, ebp is pointed to permanent
memory
pop edx
pop ecx
diff --git
a/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecFspWrapperPlatformSecLibSample.inf
b/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecFspWrapperPlatformSecLibSample.inf
index 027b127724..28a8602b03 100644
---
a/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecFspWrapperPlatformSecLibSample.inf
+++
b/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecFspWrapperPlatformSecLibSample.inf
@@ -1,7 +1,7 @@
## @file
# Sample to provide FSP wrapper platform sec related function.
#
-# Copyright (c) 2014 - 2021, Intel Corporation. All rights reserved.
+# Copyright (c) 2014 - 2022, Intel Corporation. All rights reserved.
#
# SPDX-License-Identifier: BSD-2-Clause-Patent
#
@@ -39,13 +39,18 @@
SecGetPerformance.c
SecTempRamDone.c
PlatformInit.c
+ Fsp.h
[Sources.IA32]
- Ia32/Fsp.h
Ia32/SecEntry.nasm
Ia32/PeiCoreEntry.nasm
Ia32/Stack.nasm
+[Sources.X64]
+ X64/SecEntry.nasm
+ X64/PeiCoreEntry.nasm
+ X64/Stack.nasm
+
#
# Package Dependency Section - list of Package files that are required for
diff --git
a/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecRamInitData.c
b/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecRamInitData.c
index 03616cb418..d2acb2fd46 100644
---
a/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecRamInitData.c
+++
b/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecRamInitData.c
@@ -1,7 +1,7 @@
/** @file
Sample to provide TempRamInitParams data.
- Copyright (c) 2014 - 2021, Intel Corporation. All rights reserved.
+ Copyright (c) 2014 - 2022, Intel Corporation. All ri
[edk2-devel][PATCH v5 7/8] IntelFsp2WrapperPkg: BaseFspWrapperApiLib support for X64
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3893
Add Execute64BitCode to execute 64bit code from long mode directly
in PEI 64bit.
Cc: Chasel Chiu
Cc: Nate DeSimone
Cc: Star Zeng
Cc: Ashraf Ali S
Signed-off-by: Ted Kuo
---
.../BaseFspWrapperApiLib/FspWrapperApiLib.c| 44 +---
.../BaseFspWrapperApiLib/IA32/DispatchExecute.c| 23 ++-
.../BaseFspWrapperApiLib/X64/DispatchExecute.c | 47 --
3 files changed, 104 insertions(+), 10 deletions(-)
diff --git
a/IntelFsp2WrapperPkg/Library/BaseFspWrapperApiLib/FspWrapperApiLib.c
b/IntelFsp2WrapperPkg/Library/BaseFspWrapperApiLib/FspWrapperApiLib.c
index 67faad927c..5b5beb5c65 100644
--- a/IntelFsp2WrapperPkg/Library/BaseFspWrapperApiLib/FspWrapperApiLib.c
+++ b/IntelFsp2WrapperPkg/Library/BaseFspWrapperApiLib/FspWrapperApiLib.c
@@ -1,7 +1,7 @@
/** @file
Provide FSP API related function.
- Copyright (c) 2014 - 2017, Intel Corporation. All rights reserved.
+ Copyright (c) 2014 - 2022, Intel Corporation. All rights reserved.
SPDX-License-Identifier: BSD-2-Clause-Patent
**/
@@ -13,7 +13,7 @@
#include
/**
- Wrapper for a thunk to transition from long mode to compatibility mode to
execute 32-bit code and then transit back to
+ Wrapper for a thunk to transition from long mode to compatibility mode to
execute 32-bit code and then transit back to
long mode.
@param[in] Function The 32bit code entry to be executed.
@@ -29,6 +29,22 @@ Execute32BitCode (
IN UINT64 Param2
);
+/**
+ Wrapper to execute 64-bit code directly from long mode.
+
+ @param[in] Function The 64bit code entry to be executed.
+ @param[in] Param1 The first parameter to pass to 64bit code.
+ @param[in] Param2 The second parameter to pass to 64bit code.
+
+ @return EFI_STATUS.
+**/
+EFI_STATUS
+Execute64BitCode (
+ IN UINT64 Function,
+ IN UINT64 Param1,
+ IN UINT64 Param2
+ );
+
/**
Find FSP header pointer.
@@ -94,7 +110,11 @@ CallFspNotifyPhase (
NotifyPhaseApi = (FSP_NOTIFY_PHASE)((UINTN)FspHeader->ImageBase +
FspHeader->NotifyPhaseEntryOffset);
InterruptState = SaveAndDisableInterrupts ();
- Status = Execute32BitCode ((UINTN)NotifyPhaseApi,
(UINTN)NotifyPhaseParams, (UINTN)NULL);
+ if ((FspHeader->ImageAttribute & IMAGE_ATTRIBUTE_64BIT_MODE_SUPPORT) ==
FSP_IA32) {
+Status = Execute32BitCode ((UINTN)NotifyPhaseApi,
(UINTN)NotifyPhaseParams, (UINTN)NULL);
+ } else {
+Status = Execute64BitCode ((UINTN)NotifyPhaseApi,
(UINTN)NotifyPhaseParams, (UINTN)NULL);
+ }
SetInterruptState (InterruptState);
return Status;
@@ -127,7 +147,11 @@ CallFspMemoryInit (
FspMemoryInitApi = (FSP_MEMORY_INIT)((UINTN)FspHeader->ImageBase +
FspHeader->FspMemoryInitEntryOffset);
InterruptState = SaveAndDisableInterrupts ();
- Status = Execute32BitCode ((UINTN)FspMemoryInitApi,
(UINTN)FspmUpdDataPtr, (UINTN)HobListPtr);
+ if ((FspHeader->ImageAttribute & IMAGE_ATTRIBUTE_64BIT_MODE_SUPPORT) ==
FSP_IA32) {
+Status = Execute32BitCode ((UINTN)FspMemoryInitApi, (UINTN)FspmUpdDataPtr,
(UINTN)HobListPtr);
+ } else {
+Status = Execute64BitCode ((UINTN)FspMemoryInitApi, (UINTN)FspmUpdDataPtr,
(UINTN)HobListPtr);
+ }
SetInterruptState (InterruptState);
return Status;
@@ -158,7 +182,11 @@ CallTempRamExit (
TempRamExitApi = (FSP_TEMP_RAM_EXIT)((UINTN)FspHeader->ImageBase +
FspHeader->TempRamExitEntryOffset);
InterruptState = SaveAndDisableInterrupts ();
- Status = Execute32BitCode ((UINTN)TempRamExitApi,
(UINTN)TempRamExitParam, (UINTN)NULL);
+ if ((FspHeader->ImageAttribute & IMAGE_ATTRIBUTE_64BIT_MODE_SUPPORT) ==
FSP_IA32) {
+Status = Execute32BitCode ((UINTN)TempRamExitApi, (UINTN)TempRamExitParam,
(UINTN)NULL);
+ } else {
+Status = Execute64BitCode ((UINTN)TempRamExitApi, (UINTN)TempRamExitParam,
(UINTN)NULL);
+ }
SetInterruptState (InterruptState);
return Status;
@@ -189,7 +217,11 @@ CallFspSiliconInit (
FspSiliconInitApi = (FSP_SILICON_INIT)((UINTN)FspHeader->ImageBase +
FspHeader->FspSiliconInitEntryOffset);
InterruptState= SaveAndDisableInterrupts ();
- Status= Execute32BitCode ((UINTN)FspSiliconInitApi,
(UINTN)FspsUpdDataPtr, (UINTN)NULL);
+ if ((FspHeader->ImageAttribute & IMAGE_ATTRIBUTE_64BIT_MODE_SUPPORT) ==
FSP_IA32) {
+Status = Execute32BitCode ((UINTN)FspSiliconInitApi,
(UINTN)FspsUpdDataPtr, (UINTN)NULL);
+ } else {
+Status = Execute64BitCode ((UINTN)FspSiliconInitApi,
(UINTN)FspsUpdDataPtr, (UINTN)NULL);
+ }
SetInterruptState (InterruptState);
return Status;
diff --git
a/IntelFsp2WrapperPkg/Library/BaseFspWrapperApiLib/IA32/DispatchExecute.c
b/IntelFsp2WrapperPkg/Library/BaseFspWrapperApiLib/IA32/DispatchExecute.c
index 4f6a8dd1a7..a17ca7dcab 100644
--- a/IntelFsp2WrapperPkg/Library/BaseFspWrapperApiLib/IA32/DispatchExecute.c
+++ b/IntelFsp2WrapperPkg/Library/BaseFspWrapperApiLib/IA32/DispatchExecute.c
@@ -
[edk2-devel][PATCH v5 6/8] IntelFsp2WrapperPkg: Adopt FSPM_UPD_COMMON_FSP24 for X64
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3893
Adopt FSPM_UPD_COMMON_FSP24 in FspmWrapperPeim to support X64.
Cc: Chasel Chiu
Cc: Nate DeSimone
Cc: Star Zeng
Cc: Ashraf Ali S
Signed-off-by: Ted Kuo
---
.../FspmWrapperPeim/FspmWrapperPeim.c | 27 ++
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
index b0c6b2f8a6..047c2965a3 100644
--- a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
+++ b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
@@ -3,7 +3,7 @@
register TemporaryRamDonePpi to call TempRamExit API, and register
MemoryDiscoveredPpi
notify to call FspSiliconInit API.
- Copyright (c) 2014 - 2021, Intel Corporation. All rights reserved.
+ Copyright (c) 2014 - 2022, Intel Corporation. All rights reserved.
SPDX-License-Identifier: BSD-2-Clause-Patent
**/
@@ -71,7 +71,7 @@ PeiFspMemoryInit (
UINT64 TimeStampCounterStart;
VOID *FspHobListPtr;
VOID *HobData;
- FSPM_UPD_COMMON *FspmUpdDataPtr;
+ VOID *FspmUpdDataPtr;
UINTN*SourceData;
DEBUG ((DEBUG_INFO, "PeiFspMemoryInit enter\n"));
@@ -89,7 +89,7 @@ PeiFspMemoryInit (
//
// Copy default FSP-M UPD data from Flash
//
-FspmUpdDataPtr = (FSPM_UPD_COMMON *)AllocateZeroPool
((UINTN)FspmHeaderPtr->CfgRegionSize);
+FspmUpdDataPtr = AllocateZeroPool ((UINTN)FspmHeaderPtr->CfgRegionSize);
ASSERT (FspmUpdDataPtr != NULL);
SourceData = (UINTN *)((UINTN)FspmHeaderPtr->ImageBase +
(UINTN)FspmHeaderPtr->CfgRegionOffset);
CopyMem (FspmUpdDataPtr, SourceData, (UINTN)FspmHeaderPtr->CfgRegionSize);
@@ -97,17 +97,24 @@ PeiFspMemoryInit (
//
// External UPD is ready, get the buffer from PCD pointer.
//
-FspmUpdDataPtr = (FSPM_UPD_COMMON *) GetFspmUpdDataAddress();
+FspmUpdDataPtr = (VOID *) GetFspmUpdDataAddress();
ASSERT (FspmUpdDataPtr != NULL);
}
DEBUG ((DEBUG_INFO, "UpdateFspmUpdData enter\n"));
- UpdateFspmUpdData ((VOID *)FspmUpdDataPtr);
- DEBUG ((DEBUG_INFO, " NvsBufferPtr- 0x%x\n",
FspmUpdDataPtr->FspmArchUpd.NvsBufferPtr));
- DEBUG ((DEBUG_INFO, " StackBase - 0x%x\n",
FspmUpdDataPtr->FspmArchUpd.StackBase));
- DEBUG ((DEBUG_INFO, " StackSize - 0x%x\n",
FspmUpdDataPtr->FspmArchUpd.StackSize));
- DEBUG ((DEBUG_INFO, " BootLoaderTolumSize - 0x%x\n",
FspmUpdDataPtr->FspmArchUpd.BootLoaderTolumSize));
- DEBUG ((DEBUG_INFO, " BootMode- 0x%x\n",
FspmUpdDataPtr->FspmArchUpd.BootMode));
+ UpdateFspmUpdData (FspmUpdDataPtr);
+ if (((FSPM_UPD_COMMON *)FspmUpdDataPtr)->FspmArchUpd.Revision >= 3) {
+DEBUG ((DEBUG_INFO, " StackBase - 0x%lx\n",
((FSPM_UPD_COMMON_FSP24 *)FspmUpdDataPtr)->FspmArchUpd.StackBase));
+DEBUG ((DEBUG_INFO, " StackSize - 0x%lx\n",
((FSPM_UPD_COMMON_FSP24 *)FspmUpdDataPtr)->FspmArchUpd.StackSize));
+DEBUG ((DEBUG_INFO, " BootLoaderTolumSize - 0x%x\n",
((FSPM_UPD_COMMON_FSP24 *)FspmUpdDataPtr)->FspmArchUpd.BootLoaderTolumSize));
+DEBUG ((DEBUG_INFO, " BootMode- 0x%x\n",
((FSPM_UPD_COMMON_FSP24 *)FspmUpdDataPtr)->FspmArchUpd.BootMode));
+ } else {
+DEBUG ((DEBUG_INFO, " NvsBufferPtr- 0x%x\n", ((FSPM_UPD_COMMON
*)FspmUpdDataPtr)->FspmArchUpd.NvsBufferPtr));
+DEBUG ((DEBUG_INFO, " StackBase - 0x%x\n", ((FSPM_UPD_COMMON
*)FspmUpdDataPtr)->FspmArchUpd.StackBase));
+DEBUG ((DEBUG_INFO, " StackSize - 0x%x\n", ((FSPM_UPD_COMMON
*)FspmUpdDataPtr)->FspmArchUpd.StackSize));
+DEBUG ((DEBUG_INFO, " BootLoaderTolumSize - 0x%x\n", ((FSPM_UPD_COMMON
*)FspmUpdDataPtr)->FspmArchUpd.BootLoaderTolumSize));
+DEBUG ((DEBUG_INFO, " BootMode- 0x%x\n", ((FSPM_UPD_COMMON
*)FspmUpdDataPtr)->FspmArchUpd.BootMode));
+ }
DEBUG ((DEBUG_INFO, " HobListPtr - 0x%x\n", &FspHobListPtr));
TimeStampCounterStart = AsmReadTsc ();
--
2.16.2.windows.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#88934): https://edk2.groups.io/g/devel/message/88934
Mute This Topic: https://groups.io/mt/90482853/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel][PATCH v5 5/8] IntelFsp2Pkg: SecFspSecPlatformLibNull support for X64
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3893 1.Added SecFspSecPlatformLibNull support for X64. 2.Added X64 support to IntelFsp2Pkg.dsc. Cc: Chasel Chiu Cc: Nate DeSimone Cc: Star Zeng Cc: Ashraf Ali S Signed-off-by: Ted Kuo --- IntelFsp2Pkg/IntelFsp2Pkg.dsc | 4 +-- .../SecFspSecPlatformLibNull.inf | 8 +++-- .../SecFspSecPlatformLibNull/X64/Long64.nasm | 31 + .../SecFspSecPlatformLibNull/X64/SecCarInit.nasm | 40 ++ 4 files changed, 79 insertions(+), 4 deletions(-) create mode 100644 IntelFsp2Pkg/Library/SecFspSecPlatformLibNull/X64/Long64.nasm create mode 100644 IntelFsp2Pkg/Library/SecFspSecPlatformLibNull/X64/SecCarInit.nasm diff --git a/IntelFsp2Pkg/IntelFsp2Pkg.dsc b/IntelFsp2Pkg/IntelFsp2Pkg.dsc index c1414f7e75..7cf7e88245 100644 --- a/IntelFsp2Pkg/IntelFsp2Pkg.dsc +++ b/IntelFsp2Pkg/IntelFsp2Pkg.dsc @@ -1,7 +1,7 @@ ## @file # Provides driver and definitions to build fsp. # -# Copyright (c) 2014 - 2021, Intel Corporation. All rights reserved. +# Copyright (c) 2014 - 2022, Intel Corporation. All rights reserved. # SPDX-License-Identifier: BSD-2-Clause-Patent # ## @@ -12,7 +12,7 @@ PLATFORM_VERSION = 0.1 DSC_SPECIFICATION = 0x00010005 OUTPUT_DIRECTORY = Build/IntelFsp2Pkg - SUPPORTED_ARCHITECTURES= IA32 + SUPPORTED_ARCHITECTURES= IA32|X64 BUILD_TARGETS = DEBUG|RELEASE|NOOPT SKUID_IDENTIFIER = DEFAULT diff --git a/IntelFsp2Pkg/Library/SecFspSecPlatformLibNull/SecFspSecPlatformLibNull.inf b/IntelFsp2Pkg/Library/SecFspSecPlatformLibNull/SecFspSecPlatformLibNull.inf index 42e7d83c32..55ee1b98a2 100644 --- a/IntelFsp2Pkg/Library/SecFspSecPlatformLibNull/SecFspSecPlatformLibNull.inf +++ b/IntelFsp2Pkg/Library/SecFspSecPlatformLibNull/SecFspSecPlatformLibNull.inf @@ -1,7 +1,7 @@ ## @file # NULL instance of Platform Sec Lib. # -# Copyright (c) 2014 - 2016, Intel Corporation. All rights reserved. +# Copyright (c) 2014 - 2022, Intel Corporation. All rights reserved. # # SPDX-License-Identifier: BSD-2-Clause-Patent # @@ -23,7 +23,7 @@ # # The following information is for reference only and not required by the build tools. # -# VALID_ARCHITECTURES = IA32 +# VALID_ARCHITECTURES = IA32 X64 # @@ -39,6 +39,10 @@ Ia32/Flat32.nasm Ia32/SecCarInit.nasm +[Sources.X64] + X64/Long64.nasm + X64/SecCarInit.nasm + # # Package Dependency Section - list of Package files that are required for diff --git a/IntelFsp2Pkg/Library/SecFspSecPlatformLibNull/X64/Long64.nasm b/IntelFsp2Pkg/Library/SecFspSecPlatformLibNull/X64/Long64.nasm new file mode 100644 index 00..836257f962 --- /dev/null +++ b/IntelFsp2Pkg/Library/SecFspSecPlatformLibNull/X64/Long64.nasm @@ -0,0 +1,31 @@ +;; @file +; This is the code that performs early platform initialization. +; It consumes the reset vector, configures the stack. +; +; Copyright (c) 2022, Intel Corporation. All rights reserved. +; SPDX-License-Identifier: BSD-2-Clause-Patent +;; + +; +; Define assembler characteristics +; + +extern ASM_PFX(TempRamInitApi) + +SECTION .text + +%macro RET_RSI 0 + + movdrsi, mm7 ; restore RSI from MM7 + jmp rsi + +%endmacro + +; +; Perform early platform initialization +; +global ASM_PFX(SecPlatformInit) +ASM_PFX(SecPlatformInit): + + RET_RSI + diff --git a/IntelFsp2Pkg/Library/SecFspSecPlatformLibNull/X64/SecCarInit.nasm b/IntelFsp2Pkg/Library/SecFspSecPlatformLibNull/X64/SecCarInit.nasm new file mode 100644 index 00..e64c77ed18 --- /dev/null +++ b/IntelFsp2Pkg/Library/SecFspSecPlatformLibNull/X64/SecCarInit.nasm @@ -0,0 +1,40 @@ +;; @file +; SEC CAR function +; +; Copyright (c) 2022, Intel Corporation. All rights reserved. +; SPDX-License-Identifier: BSD-2-Clause-Patent +;; + +; +; Define assembler characteristics +; + +%macro RET_RSI 0 + + movdrsi, mm7 ; move ReturnAddress from MM7 to RSI + jmp rsi + +%endmacro + +SECTION .text + +;- +; +; Section: SecCarInit +; +; Description: This function initializes the Cache for Data, Stack, and Code +; +;- +global ASM_PFX(SecCarInit) +ASM_PFX(SecCarInit): + + ; + ; Set up CAR + ; + + xorrax, rax + +SecCarInitExit: + + RET_RSI + -- 2.16.2.windows.1 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#88933): https://edk2.groups.io/g/devel/message/88933 Mute This Topic: https://groups.io/mt/90482852/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/u
[edk2-devel][PATCH v5 3/8] IntelFsp2Pkg: Update FSP_GLOBAL_DATA and FSP_PLAT_DATA for X64
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3893
Updated FSP_GLOBAL_DATA and FSP_PLAT_DATA structures to support
both IA32 and X64.
Cc: Chasel Chiu
Cc: Nate DeSimone
Cc: Star Zeng
Cc: Ashraf Ali S
Signed-off-by: Ted Kuo
---
IntelFsp2Pkg/FspSecCore/SecFsp.c | 2 +-
IntelFsp2Pkg/Include/FspGlobalData.h | 53 +---
2 files changed, 38 insertions(+), 17 deletions(-)
diff --git a/IntelFsp2Pkg/FspSecCore/SecFsp.c b/IntelFsp2Pkg/FspSecCore/SecFsp.c
index 04b43c10d0..7fde6e7f41 100644
--- a/IntelFsp2Pkg/FspSecCore/SecFsp.c
+++ b/IntelFsp2Pkg/FspSecCore/SecFsp.c
@@ -130,7 +130,7 @@ FspGlobalDataInit (
ZeroMem ((VOID *)PeiFspData, sizeof (FSP_GLOBAL_DATA));
PeiFspData->Signature = FSP_GLOBAL_DATA_SIGNATURE;
- PeiFspData->Version = 0;
+ PeiFspData->Version = FSP_GLOBAL_DATA_VERSION;
PeiFspData->CoreStack = BootLoaderStack;
PeiFspData->PerfIdx = 2;
PeiFspData->PerfSig = FSP_PERFORMANCE_DATA_SIGNATURE;
diff --git a/IntelFsp2Pkg/Include/FspGlobalData.h
b/IntelFsp2Pkg/Include/FspGlobalData.h
index 2b534075ae..445540abfa 100644
--- a/IntelFsp2Pkg/Include/FspGlobalData.h
+++ b/IntelFsp2Pkg/Include/FspGlobalData.h
@@ -1,6 +1,6 @@
/** @file
- Copyright (c) 2014 - 2020, Intel Corporation. All rights reserved.
+ Copyright (c) 2014 - 2022, Intel Corporation. All rights reserved.
SPDX-License-Identifier: BSD-2-Clause-Patent
**/
@@ -10,8 +10,9 @@
#include
-#define FSP_IN_API_MODE 0
-#define FSP_IN_DISPATCH_MODE 1
+#define FSP_IN_API_MODE 0
+#define FSP_IN_DISPATCH_MODE1
+#define FSP_GLOBAL_DATA_VERSION 1
#pragma pack(1)
@@ -28,10 +29,11 @@ typedef enum {
typedef struct {
VOID *DataPtr;
- UINT32MicrocodeRegionBase;
- UINT32MicrocodeRegionSize;
- UINT32CodeRegionBase;
- UINT32CodeRegionSize;
+ UINTN MicrocodeRegionBase;
+ UINTN MicrocodeRegionSize;
+ UINTN CodeRegionBase;
+ UINTN CodeRegionSize;
+ UINTN Reserved;
} FSP_PLAT_DATA;
#define FSP_GLOBAL_DATA_SIGNATURESIGNATURE_32 ('F', 'S', 'P', 'D')
@@ -42,15 +44,15 @@ typedef struct {
UINT32 Signature;
UINT8 Version;
UINT8 Reserved1[3];
+ ///
+ /// Offset 0x08
+ ///
UINTN CoreStack;
+ UINTN Reserved2;
+ ///
+ /// IA32: Offset 0x10; X64: Offset 0x18
+ ///
UINT32 StatusCode;
- UINT32 Reserved2[8];
- FSP_PLAT_DATA PlatformData;
- FSP_INFO_HEADER*FspInfoHeader;
- VOID *UpdDataPtr;
- VOID *TempRamInitUpdPtr;
- VOID *MemoryInitUpdPtr;
- VOID *SiliconInitUpdPtr;
UINT8 ApiIdx;
///
/// 0: FSP in API mode; 1: FSP in DISPATCH mode
@@ -60,15 +62,34 @@ typedef struct {
UINT8 Reserved3;
UINT32 NumberOfPhases;
UINT32 PhasesExecuted;
+ UINT32 Reserved4[8];
///
+ /// IA32: Offset 0x40; X64: Offset 0x48
+ /// Start of UINTN and pointer section
+ /// All UINTN and pointer members must be put in this section
+ /// except CoreStack and Reserved2. In addition, the number of
+ /// UINTN and pointer members must be even for natural alignment
+ /// in both IA32 and X64.
+ ///
+ FSP_PLAT_DATA PlatformData;
+ VOID *TempRamInitUpdPtr;
+ VOID *MemoryInitUpdPtr;
+ VOID *SiliconInitUpdPtr;
+ ///
+ /// IA32: Offset 0x64; X64: Offset 0x90
/// To store function parameters pointer
/// so it can be retrieved after stack switched.
///
VOID *FunctionParameterPtr;
- UINT8 Reserved4[16];
+ FSP_INFO_HEADER*FspInfoHeader;
+ VOID *UpdDataPtr;
+ ///
+ /// End of UINTN and pointer section
+ ///
+ UINT8 Reserved5[16];
UINT32 PerfSig;
UINT16 PerfLen;
- UINT16 Reserved5;
+ UINT16 Reserved6;
UINT32 PerfIdx;
UINT64 PerfData[32];
} FSP_GLOBAL_DATA;
--
2.16.2.windows.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#88932): https://edk2.groups.io/g/devel/message/88932
Mute This Topic: https://groups.io/mt/90482851/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel][PATCH v5 4/8] IntelFsp2Pkg: FspSecCore support for X64
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3893 1.Added FspSecCore support for X64. 2.Bumped FSP header revision to 7 to indicate FSP 64bit is supported. 3.Corrected few typos. Cc: Chasel Chiu Cc: Nate DeSimone Cc: Star Zeng Cc: Ashraf Ali S Signed-off-by: Ted Kuo --- IntelFsp2Pkg/FspSecCore/Fsp22SecCoreS.inf | 10 +- IntelFsp2Pkg/FspSecCore/FspSecCoreM.inf| 11 +- IntelFsp2Pkg/FspSecCore/FspSecCoreS.inf| 10 +- IntelFsp2Pkg/FspSecCore/FspSecCoreT.inf| 12 +- .../FspSecCore/Ia32/FspApiEntryCommon.nasm | 6 +- IntelFsp2Pkg/FspSecCore/X64/Fsp22ApiEntryS.nasm| 103 + IntelFsp2Pkg/FspSecCore/X64/FspApiEntryCommon.nasm | 76 IntelFsp2Pkg/FspSecCore/X64/FspApiEntryM.nasm | 271 +++ IntelFsp2Pkg/FspSecCore/X64/FspApiEntryS.nasm | 67 +++ IntelFsp2Pkg/FspSecCore/X64/FspApiEntryT.nasm | 495 + IntelFsp2Pkg/FspSecCore/X64/FspHelper.nasm | 34 ++ IntelFsp2Pkg/FspSecCore/X64/MicrocodeLoadNasm.inc | 11 + IntelFsp2Pkg/FspSecCore/X64/ReadRsp.nasm | 22 + IntelFsp2Pkg/FspSecCore/X64/Stack.nasm | 73 +++ IntelFsp2Pkg/Include/Guid/FspHeaderFile.h | 16 +- IntelFsp2Pkg/Include/SaveRestoreSseAvxNasm.inc | 284 .../Library/BaseFspCommonLib/FspCommonLib.c| 6 +- .../Library/BaseFspSwitchStackLib/X64/Stack.nasm | 5 +- 18 files changed, 1493 insertions(+), 19 deletions(-) create mode 100644 IntelFsp2Pkg/FspSecCore/X64/Fsp22ApiEntryS.nasm create mode 100644 IntelFsp2Pkg/FspSecCore/X64/FspApiEntryCommon.nasm create mode 100644 IntelFsp2Pkg/FspSecCore/X64/FspApiEntryM.nasm create mode 100644 IntelFsp2Pkg/FspSecCore/X64/FspApiEntryS.nasm create mode 100644 IntelFsp2Pkg/FspSecCore/X64/FspApiEntryT.nasm create mode 100644 IntelFsp2Pkg/FspSecCore/X64/FspHelper.nasm create mode 100644 IntelFsp2Pkg/FspSecCore/X64/MicrocodeLoadNasm.inc create mode 100644 IntelFsp2Pkg/FspSecCore/X64/ReadRsp.nasm create mode 100644 IntelFsp2Pkg/FspSecCore/X64/Stack.nasm create mode 100644 IntelFsp2Pkg/Include/SaveRestoreSseAvxNasm.inc diff --git a/IntelFsp2Pkg/FspSecCore/Fsp22SecCoreS.inf b/IntelFsp2Pkg/FspSecCore/Fsp22SecCoreS.inf index 0a24eb2a8b..4a67388ddf 100644 --- a/IntelFsp2Pkg/FspSecCore/Fsp22SecCoreS.inf +++ b/IntelFsp2Pkg/FspSecCore/Fsp22SecCoreS.inf @@ -1,7 +1,7 @@ ## @file # Sec Core for FSP to support MultiPhase (SeparatePhase) SiInitialization. # -# Copyright (c) 2020, Intel Corporation. All rights reserved. +# Copyright (c) 2020 - 2022, Intel Corporation. All rights reserved. # # SPDX-License-Identifier: BSD-2-Clause-Patent # @@ -17,7 +17,7 @@ # # The following information is for reference only and not required by the build tools. # -# VALID_ARCHITECTURES = IA32 +# VALID_ARCHITECTURES = IA32 X64 # [Sources] @@ -30,6 +30,12 @@ Ia32/FspApiEntryCommon.nasm Ia32/FspHelper.nasm +[Sources.X64] + X64/Stack.nasm + X64/Fsp22ApiEntryS.nasm + X64/FspApiEntryCommon.nasm + X64/FspHelper.nasm + [Binaries.Ia32] RAW|Vtf0/Bin/ResetVec.ia32.raw |GCC diff --git a/IntelFsp2Pkg/FspSecCore/FspSecCoreM.inf b/IntelFsp2Pkg/FspSecCore/FspSecCoreM.inf index 7b05cae641..a7fc07dc61 100644 --- a/IntelFsp2Pkg/FspSecCore/FspSecCoreM.inf +++ b/IntelFsp2Pkg/FspSecCore/FspSecCoreM.inf @@ -1,7 +1,7 @@ ## @file # Sec Core for FSP # -# Copyright (c) 2016 - 2021, Intel Corporation. All rights reserved. +# Copyright (c) 2016 - 2022, Intel Corporation. All rights reserved. # # SPDX-License-Identifier: BSD-2-Clause-Patent # @@ -17,7 +17,7 @@ # # The following information is for reference only and not required by the build tools. # -# VALID_ARCHITECTURES = IA32 +# VALID_ARCHITECTURES = IA32 X64 # [Sources] @@ -34,6 +34,13 @@ Ia32/FspHelper.nasm Ia32/ReadEsp.nasm +[Sources.X64] + X64/Stack.nasm + X64/FspApiEntryM.nasm + X64/FspApiEntryCommon.nasm + X64/FspHelper.nasm + X64/ReadRsp.nasm + [Binaries.Ia32] RAW|Vtf0/Bin/ResetVec.ia32.raw |GCC diff --git a/IntelFsp2Pkg/FspSecCore/FspSecCoreS.inf b/IntelFsp2Pkg/FspSecCore/FspSecCoreS.inf index 1d9c2554d1..fb80c0e339 100644 --- a/IntelFsp2Pkg/FspSecCore/FspSecCoreS.inf +++ b/IntelFsp2Pkg/FspSecCore/FspSecCoreS.inf @@ -1,7 +1,7 @@ ## @file # Sec Core for FSP # -# Copyright (c) 2016 - 2019, Intel Corporation. All rights reserved. +# Copyright (c) 2016 - 2022, Intel Corporation. All rights reserved. # # SPDX-License-Identifier: BSD-2-Clause-Patent # @@ -17,7 +17,7 @@ # # The following information is for reference only and not required by the build tools. # -# VALID_ARCHITECTURES = IA32 +# VALID_ARCHITECTURES = IA32 X64 # [Sources] @@ -30,6 +30,12 @@ Ia32/FspApiEntryCommon.nasm Ia32/FspHelper.nasm +[Sources.X64] + X64/Stack.nasm + X64/FspApiEntryS.nasm + X64/FspApiEntryCommon.nasm + X64/FspHelper.nasm + [Binaries.Ia32] RAW|Vtf0/Bin/ResetVec.ia32.raw |GCC
[edk2-devel][PATCH v5 2/8] IntelFsp2Pkg: Add FSPx_ARCH2_UPD support for X64
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3893
1.Added FSPx_ARCH2_UPD structures which support both IA32 and X64.
2.Added FSPx_UPD_COMMON_FSP24 structures.
Cc: Chasel Chiu
Cc: Nate DeSimone
Cc: Star Zeng
Cc: Ashraf Ali S
Signed-off-by: Ted Kuo
---
IntelFsp2Pkg/FspSecCore/Ia32/FspApiEntryM.nasm | 32 +-
IntelFsp2Pkg/FspSecCore/Ia32/FspApiEntryT.nasm | 98 ++---
IntelFsp2Pkg/Include/FspEas/FspApi.h | 139 -
IntelFsp2Pkg/Tools/GenCfgOpt.py| 7 +-
4 files changed, 252 insertions(+), 24 deletions(-)
diff --git a/IntelFsp2Pkg/FspSecCore/Ia32/FspApiEntryM.nasm
b/IntelFsp2Pkg/FspSecCore/Ia32/FspApiEntryM.nasm
index e7261b41cd..5dada2af54 100644
--- a/IntelFsp2Pkg/FspSecCore/Ia32/FspApiEntryM.nasm
+++ b/IntelFsp2Pkg/FspSecCore/Ia32/FspApiEntryM.nasm
@@ -1,7 +1,7 @@
;; @file
; Provide FSP API entry points.
;
-; Copyright (c) 2016 - 2019, Intel Corporation. All rights reserved.
+; Copyright (c) 2016 - 2022, Intel Corporation. All rights reserved.
; SPDX-License-Identifier: BSD-2-Clause-Patent
;;
@@ -32,6 +32,24 @@ struc FSPM_UPD_COMMON
.size:
endstruc
+struc FSPM_UPD_COMMON_FSP24
+; FSP_UPD_HEADER {
+.FspUpdHeader: resd 8
+; }
+; FSPM_ARCH2_UPD {
+.Revision: resb 1
+.Reserved: resb 3
+.Length resd 1
+.StackBase: resq 1
+.StackSize: resq 1
+.BootLoaderTolumSize: resd 1
+.BootMode: resd 1
+.FspEventHandlerresq 1
+.Reserved1: resb 24
+; }
+.size:
+endstruc
+
;
; Following functions will be provided in C
;
@@ -124,12 +142,22 @@ ASM_PFX(FspApiCommonContinue):
popeax
FspStackSetup:
+ movecx, [edx + FSPM_UPD_COMMON.Revision]
+ cmpecx, 3
+ jaeFspmUpdCommon2
+
;
; StackBase = temp memory base, StackSize = temp memory size
;
movedi, [edx + FSPM_UPD_COMMON.StackBase]
movecx, [edx + FSPM_UPD_COMMON.StackSize]
+ jmpChkFspHeapSize
+
+FspmUpdCommon2:
+ movedi, [edx + FSPM_UPD_COMMON_FSP24.StackBase]
+ movecx, [edx + FSPM_UPD_COMMON_FSP24.StackSize]
+ChkFspHeapSize:
;
; Keep using bootloader stack if heap size % is 0
;
@@ -219,7 +247,7 @@ exit:
global ASM_PFX(FspPeiCoreEntryOff)
ASM_PFX(FspPeiCoreEntryOff):
;
- ; This value will be pached by the build script
+ ; This value will be patched by the build script
;
DD0x12345678
diff --git a/IntelFsp2Pkg/FspSecCore/Ia32/FspApiEntryT.nasm
b/IntelFsp2Pkg/FspSecCore/Ia32/FspApiEntryT.nasm
index 7fd3d6d843..61030a843b 100644
--- a/IntelFsp2Pkg/FspSecCore/Ia32/FspApiEntryT.nasm
+++ b/IntelFsp2Pkg/FspSecCore/Ia32/FspApiEntryT.nasm
@@ -1,7 +1,7 @@
;; @file
; Provide FSP API entry points.
;
-; Copyright (c) 2016 - 2020, Intel Corporation. All rights reserved.
+; Copyright (c) 2016 - 2022, Intel Corporation. All rights reserved.
; SPDX-License-Identifier: BSD-2-Clause-Patent
;;
@@ -84,8 +84,10 @@ struc LoadMicrocodeParamsFsp22
.FspUpdHeaderRevision:resb1
.FspUpdHeaderReserved:resb 23
; }
-; FSPT_ARCH_UPD{
-.FsptArchUpd: resd8
+; FSPT_ARCH_UPD {
+.FsptArchRevision:resb1
+.FsptArchReserved:resb3
+.FsptArchUpd: resd7
; }
; FSPT_CORE_UPD {
.MicrocodeCodeAddr: resd1
@@ -96,6 +98,28 @@ struc LoadMicrocodeParamsFsp22
.size:
endstruc
+struc LoadMicrocodeParamsFsp24
+; FSP_UPD_HEADER {
+.FspUpdHeaderSignature: resd2
+.FspUpdHeaderRevision:resb1
+.FspUpdHeaderReserved:resb 23
+; }
+; FSPT_ARCH2_UPD {
+.FsptArchRevision:resb1
+.FsptArchReserved:resb3
+.FsptArchLength: resd1
+.FspDebugHandler resq1
+.FsptArchUpd: resd4
+; }
+; FSPT_CORE_UPD {
+.MicrocodeCodeAddr: resq1
+.MicrocodeCodeSize: resq1
+.CodeRegionBase: resq1
+.CodeRegionSize: resq1
+; }
+.size:
+endstruc
+
;
; Define SSE macros
;
@@ -172,9 +196,9 @@ ASM_PFX(LoadMicrocodeDefault):
; Executed by SBSP and NBSP
; Beginning of microcode update region starts on paragraph boundary
- ;
;
; Save return address to EBP
+ ;
movd ebp, mm7
cmpesp, 0
@@ -188,8 +212,12 @@ ASM_PFX(LoadMicrocodeDefault):
; and report error if size is less than 2k
; first check UPD header revision
cmpbyte [esp + LoadMicrocodeParamsFsp22.FspUpdHeaderRevision], 2
- jaeFsp22UpdHeader
+ jb Fsp20UpdHeader
+ cmpbyte [esp + LoadMicrocodeParamsFsp22.FsptArchRevision], 2
+ je Fsp24UpdHeader
+ jmpFsp22UpdHeader
+Fsp20UpdHeader:
; UPD structure is compliant with FSP spec 2.0/2.1
moveax, dword [esp + LoadMicrocodeParams.Micr
[edk2-devel][PATCH v5 0/8] Support PEI 64bit in IntelFsp2Pkg and IntelFsp2WrapperPkg
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3893
Currently PEI drivers/libraries only support 32bit in IntelFsp2Pkg and
IntelFsp2WrapperPkg. The patches below are needed to support these
drivers/libraries in 64bit.
V2 changes:
1.Change FSPM_UPD_COMMON2 to FSPM_UPD_COMMON_FSP24 in FspApiEntryM.nasm.
2.Add FSPx_UPD_COMMON_FSP24 in FspApi.h.
3.Add 3 additional patches for supporting X64 in IntelFsp2WrapperPkg.
V3 changes:
1.Update FSPT_ARCH2_UPD and add FSPT_CORE_UPD back.
2.Use 0x instead of MAX_ADDRESS to reflect the default of FspData.
3.Remove EnableMultiPhaseMemoryInit from FSPM_ARCH2_UPD.
4.Bump GenCfgOpt version to 0.57.
V4 changes:
1.Added EFIAPI to SwapStack and PEI_CORE_ENTRY.
2.Cast FspData from pointer to UINTN and then from UINTN to UINT32.
3.Corrected few typos.
Ted Kuo (8):
IntelFsp2Pkg: X64 compatible changes to support PEI in 64bit
IntelFsp2Pkg: Add FSPx_ARCH2_UPD support for X64
IntelFsp2Pkg: Update FSP_GLOBAL_DATA and FSP_PLAT_DATA for X64
IntelFsp2Pkg: FspSecCore support for X64
IntelFsp2Pkg: SecFspSecPlatformLibNull support for X64
IntelFsp2WrapperPkg: Adopt FSPM_UPD_COMMON_FSP24 for X64
IntelFsp2WrapperPkg: BaseFspWrapperApiLib support for X64
IntelFsp2WrapperPkg: SecFspWrapperPlatformSecLibSample support for X64
V5
1.Extend Copyright year to 2022 for the modified files
2.Check FSPM_UPD_COMMON_FSP24.Revision before configuring FSP stack.
3.Treat both MAX_ADDRESS and MAX_UINT32 as invalid address for FSP global data
in FspApiCallingCheck().
4.Remove EnableMultiPhaseSiliconInit from FSPS_ARCH2_UPD.
5.Add an additional ExcludedSpecificUpd1 to exclude FSPx_ARCH2_UPD in
GenCfgOpt.py tool.
IntelFsp2Pkg/FspNotifyPhase/FspNotifyPhasePeim.c | 3 +-
IntelFsp2Pkg/FspSecCore/Fsp22SecCoreS.inf | 10 +-
IntelFsp2Pkg/FspSecCore/FspSecCoreM.inf| 11 +-
IntelFsp2Pkg/FspSecCore/FspSecCoreS.inf| 10 +-
IntelFsp2Pkg/FspSecCore/FspSecCoreT.inf| 12 +-
.../FspSecCore/Ia32/FspApiEntryCommon.nasm | 6 +-
IntelFsp2Pkg/FspSecCore/Ia32/FspApiEntryM.nasm | 32 +-
IntelFsp2Pkg/FspSecCore/Ia32/FspApiEntryT.nasm | 98 +++-
IntelFsp2Pkg/FspSecCore/Ia32/ReadEsp.nasm | 10 +-
IntelFsp2Pkg/FspSecCore/Ia32/Stack.nasm| 12 +-
IntelFsp2Pkg/FspSecCore/SecFsp.c | 12 +-
IntelFsp2Pkg/FspSecCore/SecFsp.h | 4 +-
IntelFsp2Pkg/FspSecCore/SecFspApiChk.c | 10 +-
IntelFsp2Pkg/FspSecCore/SecMain.c | 10 +-
IntelFsp2Pkg/FspSecCore/SecMain.h | 20 +-
IntelFsp2Pkg/FspSecCore/X64/Fsp22ApiEntryS.nasm| 103 +
IntelFsp2Pkg/FspSecCore/X64/FspApiEntryCommon.nasm | 76
IntelFsp2Pkg/FspSecCore/X64/FspApiEntryM.nasm | 271 +++
IntelFsp2Pkg/FspSecCore/X64/FspApiEntryS.nasm | 67 +++
IntelFsp2Pkg/FspSecCore/X64/FspApiEntryT.nasm | 495 +
IntelFsp2Pkg/FspSecCore/X64/FspHelper.nasm | 34 ++
IntelFsp2Pkg/FspSecCore/X64/MicrocodeLoadNasm.inc | 11 +
IntelFsp2Pkg/FspSecCore/X64/ReadRsp.nasm | 22 +
IntelFsp2Pkg/FspSecCore/X64/Stack.nasm | 73 +++
IntelFsp2Pkg/Include/FspEas/FspApi.h | 139 +-
IntelFsp2Pkg/Include/FspGlobalData.h | 53 ++-
IntelFsp2Pkg/Include/Guid/FspHeaderFile.h | 16 +-
IntelFsp2Pkg/Include/SaveRestoreSseAvxNasm.inc | 284
IntelFsp2Pkg/IntelFsp2Pkg.dsc | 4 +-
.../Library/BaseFspCommonLib/FspCommonLib.c| 6 +-
.../BaseFspSwitchStackLib/FspSwitchStackLib.c | 3 +-
.../Library/BaseFspSwitchStackLib/X64/Stack.nasm | 5 +-
.../SecFspSecPlatformLibNull/Ia32/Flat32.nasm | 4 +-
.../SecFspSecPlatformLibNull.inf | 8 +-
.../SecFspSecPlatformLibNull/X64/Long64.nasm | 31 ++
.../SecFspSecPlatformLibNull/X64/SecCarInit.nasm | 40 ++
IntelFsp2Pkg/Tools/GenCfgOpt.py| 7 +-
.../FspmWrapperPeim/FspmWrapperPeim.c | 27 +-
.../BaseFspWrapperApiLib/FspWrapperApiLib.c| 44 +-
.../BaseFspWrapperApiLib/IA32/DispatchExecute.c| 23 +-
.../BaseFspWrapperApiLib/X64/DispatchExecute.c | 47 +-
.../{Ia32 => }/Fsp.h | 0
.../Ia32/Stack.nasm| 8 +-
.../SecFspWrapperPlatformSecLibSample.inf | 9 +-
.../SecRamInitData.c | 24 +-
.../X64/PeiCoreEntry.nasm | 149 +++
.../X64/SecEntry.nasm | 171 +++
.../X64/Stack.nasm | 73 +++
48 files changed, 2446 insertions(+), 141 deletions(-)
create mode 100644 IntelFsp2Pkg/FspSecCore/X64/Fsp22ApiEntryS.nasm
create mode 100644 IntelFsp2Pkg/FspSecCore/X64/FspApiEntryCommon.nasm
create mode 100644 IntelFsp2Pkg/FspSecCore/X64/FspApiEntryM.nasm
create mode 100644 IntelFsp2Pkg/FspSecCore/X64/FspApiEntryS.nasm
create mode 10
[edk2-devel][PATCH v5 1/8] IntelFsp2Pkg: X64 compatible changes to support PEI in 64bit
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3893 1.Added EFIAPI to FspNotifyPhasePeimEntryPoint, SwapStack and PEI_CORE_ENTRY. 2.Treat both MAX_ADDRESS and MAX_UINT32 as invalid address for FSP global data in FspApiCallingCheck(). 3.Changed AsmReadEsp to AsmReadStackPointer. 4.Changed the type of the return value of AsmReadStackPointer from UINT32 to UINTN. 5.Changed the type of TemporaryMemoryBase, PermenentMemoryBase and BootLoaderStack from UINT32 to UINTN. 6.Some type casting to pointers are UINT32. Changed them to UINTN to accommodate both IA32 and X64. 7.Corrected some typos. Cc: Chasel Chiu Cc: Nate DeSimone Cc: Star Zeng Cc: Ashraf Ali S Signed-off-by: Ted Kuo --- IntelFsp2Pkg/FspNotifyPhase/FspNotifyPhasePeim.c | 3 ++- IntelFsp2Pkg/FspSecCore/Ia32/ReadEsp.nasm| 10 +- IntelFsp2Pkg/FspSecCore/Ia32/Stack.nasm | 12 ++-- IntelFsp2Pkg/FspSecCore/SecFsp.c | 10 +- IntelFsp2Pkg/FspSecCore/SecFsp.h | 4 ++-- IntelFsp2Pkg/FspSecCore/SecFspApiChk.c | 10 +- IntelFsp2Pkg/FspSecCore/SecMain.c| 10 +- IntelFsp2Pkg/FspSecCore/SecMain.h| 20 +++- .../BaseFspSwitchStackLib/FspSwitchStackLib.c| 3 ++- .../SecFspSecPlatformLibNull/Ia32/Flat32.nasm| 4 ++-- 10 files changed, 45 insertions(+), 41 deletions(-) diff --git a/IntelFsp2Pkg/FspNotifyPhase/FspNotifyPhasePeim.c b/IntelFsp2Pkg/FspNotifyPhase/FspNotifyPhasePeim.c index 88f5540fef..c3ba9f168c 100644 --- a/IntelFsp2Pkg/FspNotifyPhase/FspNotifyPhasePeim.c +++ b/IntelFsp2Pkg/FspNotifyPhase/FspNotifyPhasePeim.c @@ -1,7 +1,7 @@ /** @file Source file for FSP notify phase PEI module - Copyright (c) 2016 - 2018, Intel Corporation. All rights reserved. + Copyright (c) 2016 - 2022, Intel Corporation. All rights reserved. SPDX-License-Identifier: BSD-2-Clause-Patent **/ @@ -112,6 +112,7 @@ WaitForNotify ( @retval EFI_OUT_OF_RESOURCES Insufficient resources to create database **/ EFI_STATUS +EFIAPI FspNotifyPhasePeimEntryPoint ( IN EFI_PEI_FILE_HANDLE FileHandle, IN CONST EFI_PEI_SERVICES **PeiServices diff --git a/IntelFsp2Pkg/FspSecCore/Ia32/ReadEsp.nasm b/IntelFsp2Pkg/FspSecCore/Ia32/ReadEsp.nasm index 8046b43745..d6bbf9cc75 100644 --- a/IntelFsp2Pkg/FspSecCore/Ia32/ReadEsp.nasm +++ b/IntelFsp2Pkg/FspSecCore/Ia32/ReadEsp.nasm @@ -1,7 +1,7 @@ ;; @file ; Provide read ESP function ; -; Copyright (c) 2019, Intel Corporation. All rights reserved. +; Copyright (c) 2019 - 2022, Intel Corporation. All rights reserved. ; SPDX-License-Identifier: BSD-2-Clause-Patent ;; ;-- @@ -9,14 +9,14 @@ SECTION .text ;-- -; UINT32 +; UINTN ; EFIAPI -; AsmReadEsp ( +; AsmReadStackPointer ( ; VOID ; ); ;-- -global ASM_PFX(AsmReadEsp) -ASM_PFX(AsmReadEsp): +global ASM_PFX(AsmReadStackPointer) +ASM_PFX(AsmReadStackPointer): mov eax, esp ret diff --git a/IntelFsp2Pkg/FspSecCore/Ia32/Stack.nasm b/IntelFsp2Pkg/FspSecCore/Ia32/Stack.nasm index 5a7e27c240..5cb2424bc8 100644 --- a/IntelFsp2Pkg/FspSecCore/Ia32/Stack.nasm +++ b/IntelFsp2Pkg/FspSecCore/Ia32/Stack.nasm @@ -1,6 +1,6 @@ ;-- ; -; Copyright (c) 2015 - 2019, Intel Corporation. All rights reserved. +; Copyright (c) 2015 - 2022, Intel Corporation. All rights reserved. ; SPDX-License-Identifier: BSD-2-Clause-Patent ; ; Abstract: @@ -9,20 +9,20 @@ ; ;-- -SECTION .text +SECTION .text ;-- ; VOID ; EFIAPI ; SecSwitchStack ( ; UINT32 TemporaryMemoryBase, -; UINT32 PermenentMemoryBase +; UINT32 PermanentMemoryBase ; ); ;-- global ASM_PFX(SecSwitchStack) ASM_PFX(SecSwitchStack): ; -; Save three register: eax, ebx, ecx +; Save four register: eax, ebx, ecx, edx ; push eax push ebx @@ -55,7 +55,7 @@ ASM_PFX(SecSwitchStack): mov dword [eax + 12], edx mov edx, dword [esp + 16]; Update this function's return address into permanent memory mov dword [eax + 16], edx -mov esp, eax ; From now, esp is pointed to permanent memory +mov esp, eax ; From now, esp is pointed to permanent memory ; ; Fixup the ebp point to permanent memory @@ -63,7 +63,7 @@ ASM_PFX(SecSwitchStack): mov eax, ebp sub eax, ebx add eax, ecx -mov ebp, eax; From now, ebp is po
Re: [edk2-devel] [PATCH v2] MdePkg: Update smbiosview type 9 with SMBIOS 3.5 fields
Add Kinney, Michael D and Gao, Liming
Best Regards.
-Original Message-
From: Gao, Zhichao
Sent: Thursday, April 14, 2022 10:25 AM
To: Ke, Bo-ChangX ; devel@edk2.groups.io
Cc: Liu, Zhiguang ; Bi, Dandan ;
Zeng, Star
Subject: RE: [PATCH v2] MdePkg: Update smbiosview type 9 with SMBIOS 3.5 fields
Reviewed-by: Zhichao Gao
Thanks,
Zhichao
> -Original Message-
> From: Ke, Bo-ChangX
> Sent: Wednesday, April 13, 2022 11:14 AM
> To: devel@edk2.groups.io
> Cc: Liu, Zhiguang ; Gao, Zhichao
> ; Bi, Dandan ; Zeng, Star
>
> Subject: [PATCH v2] MdePkg: Update smbiosview type 9 with SMBIOS 3.5
> fields
>
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3896
>
> update smbiosview type 9 related fileds.
>
> Signed-off-by: Bo Chang Ke
> Cc: Zhiguang Liu
> Cc: Zhichao Gao
> Cc: Dandan Bi
> Cc: Star Zeng
> ---
> MdePkg/Include/IndustryStandard/SmBios.h | 49
> +++-
> 1 file changed, 48 insertions(+), 1 deletion(-)
>
> diff --git a/MdePkg/Include/IndustryStandard/SmBios.h
> b/MdePkg/Include/IndustryStandard/SmBios.h
> index 2b1567b052..52f2e35ee9 100644
> --- a/MdePkg/Include/IndustryStandard/SmBios.h
> +++ b/MdePkg/Include/IndustryStandard/SmBios.h
> @@ -1306,6 +1306,11 @@ typedef enum {
>SlotTypePciExpressMini52pinWithBSKO= 0x21,///< PCI Express Mini
> 52-pin
> (CEM spec. 2.0) with bottom-side keep-outs.
>SlotTypePciExpressMini52pinWithoutBSKO = 0x22,///< PCI Express Mini 52-
> pin (CEM spec. 2.0) without bottom-side keep-outs.
>SlotTypePciExpressMini76pin= 0x23,///< PCI Express Mini
> 76-pin (CEM
> spec. 2.0) Corresponds to Display-Mini card.
> + SlotTypePCIExpressGen4SFF_8639 = 0x24,///< U.2
> + SlotTypePCIExpressGen5SFF_8639 = 0x25,///< U.2
> + SlotTypeOCPNIC30SmallFormFactor= 0x26,///< SFF
> + SlotTypeOCPNIC30LargeFormFactor= 0x27,///< LFF
> + SlotTypeOCPNICPriorto30= 0x28,
>SlotTypeCXLFlexbus10 = 0x30,
>SlotTypePC98C20= 0xA0,
>SlotTypePC98C24= 0xA1,
> @@ -1335,7 +1340,16 @@ typedef enum {
>SlotTypePciExpressGen4X2 = 0xBA,
>SlotTypePciExpressGen4X4 = 0xBB,
>SlotTypePciExpressGen4X8 = 0xBC,
> - SlotTypePciExpressGen4X16 = 0xBD
> + SlotTypePciExpressGen4X16 = 0xBD,
> + SlotTypePCIExpressGen5 = 0xBE,
> + SlotTypePCIExpressGen5X1 = 0xBF,
> + SlotTypePCIExpressGen5X2 = 0xC0,
> + SlotTypePCIExpressGen5X4 = 0xC1,
> + SlotTypePCIExpressGen5X8 = 0xC2,
> + SlotTypePCIExpressGen5X16 = 0xC3,
> + SlotTypePCIExpressGen6andBeyond= 0xC4,
> + SlotTypeEnterpriseandDatacenter1UE1FormFactorSlot = 0xC5,
> + SlotTypeEnterpriseandDatacenter3E3FormFactorSlot = 0xC6
> } MISC_SLOT_TYPE;
>
> ///
> @@ -1358,6 +1372,39 @@ typedef enum {
>SlotDataBusWidth32X = 0x0E ///< Or X32
> } MISC_SLOT_DATA_BUS_WIDTH;
>
> +///
> +/// System Slots - Slot Physical Width.
> +///
> +typedef enum {
> + SlotPhysicalWidthOther = 0x01,
> + SlotPhysicalWidthUnknown = 0x02,
> + SlotPhysicalWidth8Bit= 0x03,
> + SlotPhysicalWidth16Bit = 0x04,
> + SlotPhysicalWidth32Bit = 0x05,
> + SlotPhysicalWidth64Bit = 0x06,
> + SlotPhysicalWidth128Bit = 0x07,
> + SlotPhysicalWidth1X = 0x08,///< Or X1
> + SlotPhysicalWidth2X = 0x09,///< Or X2
> + SlotPhysicalWidth4X = 0x0A,///< Or X4
> + SlotPhysicalWidth8X = 0x0B,///< Or X8
> + SlotPhysicalWidth12X = 0x0C,///< Or X12
> + SlotPhysicalWidth16X = 0x0D,///< Or X16
> + SlotPhysicalWidth32X = 0x0E ///< Or X32
> +} MISC_SLOT_PHYSICAL_WIDTH;
> +
> +///
> +/// System Slots - Slot Information.
> +///
> +typedef enum {
> + others = 0x00,
> + Gen1 = 0x01,
> + Gen2 = 0x01,
> + Gen3 = 0x03,
> + Gen4 = 0x04,
> + Gen5 = 0x05,
> + Gen6 = 0x06
> +} MISC_SLOT_INFORMATION;
> +
> ///
> /// System Slots - Current Usage.
> ///
> --
> 2.32.0.windows.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#88927): https://edk2.groups.io/g/devel/message/88927
Mute This Topic: https://groups.io/mt/90433755/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [edk2-discuss] GSoC Proposal
Hi Andrew, On 4/14/22, 7:43 PM, "Andrew Fish" wrote: > > >> On Apr 14, 2022, at 6:06 PM, Nate DeSimone >> wrote: >> >> Hi Marvin, >> >>> -Original Message- >>> From: devel@edk2.groups.io On Behalf Of Marvin >>> Häuser >>> Sent: Thursday, April 14, 2022 12:56 AM >>> To: disc...@edk2.groups.io; Desimone, Nathaniel L >>> >>> Cc: Pedro Falcato ; edk2-devel-groups-io >>> ; adachristin...@gmail.com; Shi, Steven >>> >>> Subject: Re: [edk2-devel] [edk2-discuss] GSoC Proposal >>> >>> I feel like there are so many much easier solutions to this problem that >>> are at >>> most limited by the clear specification. The UEFI specification with >>> regards to >>> booting and all of that obviously is of utmost importance. >> >> If you have a better idea that retains compatibility with the existing UEFI >> PI then I would be happy to hear it. Ultimately anything we do needs to be a >> pure extension that retains compatibility with old code. Given that >> restriction having the ability to coalesce all the LibraryClasses into a >> single module and have cross-module linking seems like the best way to >> handle it to me. >> >>> The UEFI PI specification parts that deal about internal structure, as far >>> as I know, are >>> only in place to make it easy to integrate Intel IP. >> >> Its not just for Intel. The biggest reason for it to increase the >> standardization of the boot flow across the PC ecosystem. We have learned >> from experience that firmware is super critical to get a product out the >> door but it is also difficult to write. So we try to make it as reusable as >> humanly possible. >> >>> In fact, I don’t *know*, but I’m pretty sure the very strict separation >>> between PEI and DXE was >>> preserved mostly because MRC was 32-bit-only for a long time. Glad that >>> seems to have been resolved, AMD does memory init by PSP nowadays. >> >> Having less complex early stages chain load more complex later stages is a >> common design pattern in firmware, not just UEFI. For example, your typical >> ARM system loads kinda like this: >> >> PBL (SoC ROM) --> SBL (RAM Init) --> ARM Trust Zone --> Hypervisor --> EDK >> II or U-Boot or LittleKernel (which runs android fastboot) >> >> Comparing relative complexity I believe the Intel UEFI PI design is actually >> pretty simple when you consider how much it gets done: >> >> Ucode ROM --> SEC + PEI --> DXE + SMM + BDS >> >> My biggest criticism of the design is that the strict separation between PEI >> and DXE doesn't exist between DXE, SMM, and BDS 😊 >> >> There are a few reasons why PEI was 32-bit for quite some time. The biggest >> one is the code size increase, 64-bit x86 code is 20-30% larger than 32-bit >> x86 code. Since the only RAM Pre-Memory code has access to is the cache >> onboard the processor and for security reasons all that code has to fit >> within that RAM we generally do everything we can to make that image as >> small as possible. Second, 64-bit requires a page table and since we desired >> to keep PEI simple we tried to avoid that. Finally, the PI spec didn't allow >> a 64-bit PEI until recently. MRC is 32-bit code just because that is what >> PEI happens to be. Porting it to 64-bit is not terribly difficult. >> >> Ultimately the mix of 32/64-bit does cause some difficulties. Any data >> structures that get shared between PEI and DXE (HOBs, PCDs, etc.) need to >> resolve to the same size and packing. LibraryClasses need to be written to >> compile properly in both modes. In the case of FSP API mode you need to >> resort to thunking between 32 and 64-bit modes during DXE. More or less we >> decided that the costs are starting to outweigh the advantages. >> > >I’d also point out that x86 VMs use X64 (x86-64) PEI today and it works so the >32-bit/64-bit mix has nothing to do with UEFI/PI/edk2. > >In the PC ecosystem a single chipset family can power thousands of unique >designs. So the DRAM memory needs to be external, support lots of different >chipset packages(signal integrity...), support the lowest cost through the >highest cost DRAM and thousands of different board layouts. So programing DRAM >takes a masters degree in antenna design. I’ve seen MRC (Memory Reference >Code) with over a MiB of DEBUG prints in it, and it literally is printing >histograms of what it is tuning. So all this code has to run before the system >has any DRAM, thus it is running using the cache as RAM. I’ve not looked at >the x86 architecture specs form the vendors in a while, but back in the day >they did not support page tables in ROM or pinned cached. Now it might work, >but if it breaks your CPU vendor blames you so you don’t code PEI in X64…. > >We contributed the 1st edk2 ARM platform, Beagle Board, and It was a long time >ago but I seem to remember the mask ROM used a table in NOR FLASH to init >memory and then copied an image from NOR FLASH into DRAM and jumped to it. So >PEI is kind of not really nee
