Re: [edk2-devel] [PATCH edk2-platforms 2/4] SbsaQemu: add MM based UEFI secure boot support
On Wed, 17 Feb 2021 at 01:15, Graeme Gregory wrote: > > On 16/02/2021 11:35, Masahisa Kojima wrote: > > Hi Ard, > > > > I am encountering strange behavior when I apply this patch > > "SbsaQemu: add MM based UEFI secure boot support". > > When I start linux kernel, booting secondary cores failed. > > # I don't store any secure boot keys, so UEFI Secure Boot itself > > is disabled. > > > > --- linux kernel log --- > > [0.124805] Remapping and enabling EFI services. > > [0.132850] smp: Bringing up secondary CPUs ... > > [1.294478] CPU1: failed to come online > > [1.295647] CPU1: failed in unknown state : 0x0 > > [2.426489] CPU2: failed to come online > > [2.427112] CPU2: failed in unknown state : 0x0 > > [3.567428] CPU3: failed to come online > > [3.567912] CPU3: failed in unknown state : 0x0 > > [3.569010] smp: Brought up 1 node, 1 CPU > > [3.569555] SMP: Total of 1 processors activated. > > [3.570395] CPU features: detected: GIC system register CPU interface > > [3.571183] CPU features: detected: 32-bit EL0 Support > > [3.587378] CPU: All CPU(s) started at EL2 > > --- > > In my check, arch/arm64/kernel/smp.c::secondary_start_kernel() is never > > called, so wait_for_completion_timeout() is timed out. > > https://github.com/torvalds/linux/blob/v5.11/arch/arm64/kernel/smp.c#L138 > > > > > > If I set "SECURE_BOOT_ENABLE=FALSE" in edk2 build(non-secure side) > > and load the same STANDALONE_MM.fd(Secure Payload) and tf-a binary, > > secondary cores boot successfully. > > Major difference between success and failure cases is the > > existence of UEFI secure variable accesses through Standalone MM framework. > > If edk2 accesses UEFI secure variable through Standalone MM, secondary cores > > boot fails. I don't come up with any possible reason. > > # As a reference, there is no issue on Developerbox. > > > > Do you have any idea about this error? > > > > I don't suppose that we have managed to have conflicting changes and the > memory I used for the expanded PSCI state table for upto 512 cores in > arm-tf is also the memory you are using for secure MM? Hi Graeme, Thank you for your comment. I think PSCI state table for 512 cores you are pointing is located at 0x2000 - 0x20001FFF(8KiB). # 8byte function pointer and (8bytes * 512 cores) state table I realized this area, current StandaloneMM uses the following region. 0x0100_ - 0x010f_(1MiB) Secure Flash : store UEFI variables 0x2000_2000 - 0x2030_1fff(3MiB) SRAM: Secure Payload Code(BL32) 0x2030_2000 - 0x22b0_2000(40MiB) SRAM: BL32 Heap(8MiB) and Stack(32MiB[64KiB * 512cores]) 0x3dcd_1000 - 0x3fcD_0fff(32MiB) SRAM: EL3->S-EL0 shared memory 0x3fcf_e000 - 0x3fcf_efff(4KiB) SRAM : spm shim exception vectors 0x100_3fe0_ - 0x100_3fff_(2MiB) NS DRAM : shared buffer for non-secure world I run QEMU with "-smp 4", PSCI calls seems to be successfully completed in tf-a. pwr_domain_on() called from linux kernel three times with mpidr 1, 2 and 3. Thanks, Masahisa > > Graeme > > > Thanks, > > Masahisa > > > > On Mon, 21 Dec 2020 at 21:52, Masahisa Kojima > > wrote: > >> > >> This implements support for UEFI secure boot on SbsaQemu using > >> the standalone MM framework. This moves all of the software handling > >> of the UEFI authenticated variable store into the standalone MM > >> context residing in a secure partition. > >> > >> Secure variable storage is located at 0x0100 in secure NOR Flash. > >> > >> Non-secure shared memory between UEFI and standalone MM > >> is allocated at the top of DRAM. > >> DRAM size of SbsaQemu varies depends on the QEMU parameter, > >> the non-secure shared memory base address is passed from > >> trusted-firmware through the device tree "/reserved-memory" node. > >> > >> Signed-off-by: Masahisa Kojima > >> --- > >> Platform/Qemu/SbsaQemu/SbsaQemu.dsc | 44 > >> --- > >> Platform/Qemu/SbsaQemu/SbsaQemuStandaloneMm.dsc | 40 ++ > >> Platform/Qemu/SbsaQemu/SbsaQemu.fdf | 82 > >> ++-- > >> Platform/Qemu/SbsaQemu/SbsaQemuStandaloneMm.fdf | 7 +- > >> Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuLib.inf | 2 + > >> Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuMem.c | 37 - > >> 6 files changed, 192 insertions(+), 20 deletions(-) > >> > >> diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc > >> b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc > >> index f6af3f9111ee..83e7cd21e0c6 100644 > >> --- a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc > >> +++ b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc > >> @@ -27,6 +27,8 @@ [Defines] > >> > >> DEFINE DEBUG_PRINT_ERROR_LEVEL = 0x804F > >> > >> + DEFINE SECURE_BOOT_ENABLE = FALSE > >> + > >> # > >> # Network definition > >> # > >> @@ -148,12 +150,10 @@ [LibraryClasses.common] > >> # Secure Boot dependencies > >> # > >> > >>
Re: [edk2-devel] [PATCH edk2-platforms 2/4] SbsaQemu: add MM based UEFI secure boot support
On 16/02/2021 11:35, Masahisa Kojima wrote: Hi Ard, I am encountering strange behavior when I apply this patch "SbsaQemu: add MM based UEFI secure boot support". When I start linux kernel, booting secondary cores failed. # I don't store any secure boot keys, so UEFI Secure Boot itself is disabled. --- linux kernel log --- [0.124805] Remapping and enabling EFI services. [0.132850] smp: Bringing up secondary CPUs ... [1.294478] CPU1: failed to come online [1.295647] CPU1: failed in unknown state : 0x0 [2.426489] CPU2: failed to come online [2.427112] CPU2: failed in unknown state : 0x0 [3.567428] CPU3: failed to come online [3.567912] CPU3: failed in unknown state : 0x0 [3.569010] smp: Brought up 1 node, 1 CPU [3.569555] SMP: Total of 1 processors activated. [3.570395] CPU features: detected: GIC system register CPU interface [3.571183] CPU features: detected: 32-bit EL0 Support [3.587378] CPU: All CPU(s) started at EL2 --- In my check, arch/arm64/kernel/smp.c::secondary_start_kernel() is never called, so wait_for_completion_timeout() is timed out. https://github.com/torvalds/linux/blob/v5.11/arch/arm64/kernel/smp.c#L138 If I set "SECURE_BOOT_ENABLE=FALSE" in edk2 build(non-secure side) and load the same STANDALONE_MM.fd(Secure Payload) and tf-a binary, secondary cores boot successfully. Major difference between success and failure cases is the existence of UEFI secure variable accesses through Standalone MM framework. If edk2 accesses UEFI secure variable through Standalone MM, secondary cores boot fails. I don't come up with any possible reason. # As a reference, there is no issue on Developerbox. Do you have any idea about this error? I don't suppose that we have managed to have conflicting changes and the memory I used for the expanded PSCI state table for upto 512 cores in arm-tf is also the memory you are using for secure MM? Graeme Thanks, Masahisa On Mon, 21 Dec 2020 at 21:52, Masahisa Kojima wrote: This implements support for UEFI secure boot on SbsaQemu using the standalone MM framework. This moves all of the software handling of the UEFI authenticated variable store into the standalone MM context residing in a secure partition. Secure variable storage is located at 0x0100 in secure NOR Flash. Non-secure shared memory between UEFI and standalone MM is allocated at the top of DRAM. DRAM size of SbsaQemu varies depends on the QEMU parameter, the non-secure shared memory base address is passed from trusted-firmware through the device tree "/reserved-memory" node. Signed-off-by: Masahisa Kojima --- Platform/Qemu/SbsaQemu/SbsaQemu.dsc | 44 --- Platform/Qemu/SbsaQemu/SbsaQemuStandaloneMm.dsc | 40 ++ Platform/Qemu/SbsaQemu/SbsaQemu.fdf | 82 ++-- Platform/Qemu/SbsaQemu/SbsaQemuStandaloneMm.fdf | 7 +- Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuLib.inf | 2 + Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuMem.c | 37 - 6 files changed, 192 insertions(+), 20 deletions(-) diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc index f6af3f9111ee..83e7cd21e0c6 100644 --- a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc +++ b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc @@ -27,6 +27,8 @@ [Defines] DEFINE DEBUG_PRINT_ERROR_LEVEL = 0x804F + DEFINE SECURE_BOOT_ENABLE = FALSE + # # Network definition # @@ -148,12 +150,10 @@ [LibraryClasses.common] # Secure Boot dependencies # TpmMeasurementLib|SecurityPkg/Library/DxeTpmMeasurementLib/DxeTpmMeasurementLib.inf - AuthVariableLib|SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf # re-use the UserPhysicalPresent() dummy implementation from the ovmf tree PlatformSecureLib|OvmfPkg/Library/PlatformSecureLib/PlatformSecureLib.inf - VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf VariablePolicyLib|MdeModulePkg/Library/VariablePolicyLib/VariablePolicyLib.inf VariablePolicyHelperLib|MdeModulePkg/Library/VariablePolicyHelperLib/VariablePolicyHelperLib.inf @@ -167,6 +167,7 @@ [LibraryClasses.common] ArmPlatformLib|ArmPlatformPkg/Library/ArmPlatformLibNull/ArmPlatformLibNull.inf TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf + NorFlashPlatformLib|Silicon/Qemu/SbsaQemu/Library/SbsaQemuNorFlashLib/SbsaQemuNorFlashLib.inf CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf @@ -296,6 +297,8 @@ [PcdsFeatureFlag.common] gEfiMdeModulePkgTokenSpaceGuid.PcdConOutGopSupport|TRUE gEfiMdeModulePkgTokenSpaceGuid.PcdConOutUgaSupport|FALSE + gEfiMdeModulePkgTokenSpaceGuid.PcdEnableVariableRuntimeCache|FALSE + [PcdsFixedAtBuild.common] gEfiMdePkgTokenSpaceGuid.PcdMaximumUnicodeStringLength|100 gEfiMdePkgTokenSpaceGuid.PcdMaximumAsciiStringLength|100 @@ -511,6 +514,10 @@ [PcdsDynamicDefault.common]
Re: [edk2-devel] [PATCH edk2-platforms 2/4] SbsaQemu: add MM based UEFI secure boot support
Hi Ard, I am encountering strange behavior when I apply this patch "SbsaQemu: add MM based UEFI secure boot support". When I start linux kernel, booting secondary cores failed. # I don't store any secure boot keys, so UEFI Secure Boot itself is disabled. --- linux kernel log --- [0.124805] Remapping and enabling EFI services. [0.132850] smp: Bringing up secondary CPUs ... [1.294478] CPU1: failed to come online [1.295647] CPU1: failed in unknown state : 0x0 [2.426489] CPU2: failed to come online [2.427112] CPU2: failed in unknown state : 0x0 [3.567428] CPU3: failed to come online [3.567912] CPU3: failed in unknown state : 0x0 [3.569010] smp: Brought up 1 node, 1 CPU [3.569555] SMP: Total of 1 processors activated. [3.570395] CPU features: detected: GIC system register CPU interface [3.571183] CPU features: detected: 32-bit EL0 Support [3.587378] CPU: All CPU(s) started at EL2 --- In my check, arch/arm64/kernel/smp.c::secondary_start_kernel() is never called, so wait_for_completion_timeout() is timed out. https://github.com/torvalds/linux/blob/v5.11/arch/arm64/kernel/smp.c#L138 If I set "SECURE_BOOT_ENABLE=FALSE" in edk2 build(non-secure side) and load the same STANDALONE_MM.fd(Secure Payload) and tf-a binary, secondary cores boot successfully. Major difference between success and failure cases is the existence of UEFI secure variable accesses through Standalone MM framework. If edk2 accesses UEFI secure variable through Standalone MM, secondary cores boot fails. I don't come up with any possible reason. # As a reference, there is no issue on Developerbox. Do you have any idea about this error? Thanks, Masahisa On Mon, 21 Dec 2020 at 21:52, Masahisa Kojima wrote: > > This implements support for UEFI secure boot on SbsaQemu using > the standalone MM framework. This moves all of the software handling > of the UEFI authenticated variable store into the standalone MM > context residing in a secure partition. > > Secure variable storage is located at 0x0100 in secure NOR Flash. > > Non-secure shared memory between UEFI and standalone MM > is allocated at the top of DRAM. > DRAM size of SbsaQemu varies depends on the QEMU parameter, > the non-secure shared memory base address is passed from > trusted-firmware through the device tree "/reserved-memory" node. > > Signed-off-by: Masahisa Kojima > --- > Platform/Qemu/SbsaQemu/SbsaQemu.dsc | 44 --- > Platform/Qemu/SbsaQemu/SbsaQemuStandaloneMm.dsc | 40 ++ > Platform/Qemu/SbsaQemu/SbsaQemu.fdf | 82 > ++-- > Platform/Qemu/SbsaQemu/SbsaQemuStandaloneMm.fdf | 7 +- > Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuLib.inf | 2 + > Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuMem.c | 37 - > 6 files changed, 192 insertions(+), 20 deletions(-) > > diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc > b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc > index f6af3f9111ee..83e7cd21e0c6 100644 > --- a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc > +++ b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc > @@ -27,6 +27,8 @@ [Defines] > >DEFINE DEBUG_PRINT_ERROR_LEVEL = 0x804F > > + DEFINE SECURE_BOOT_ENABLE = FALSE > + > # > # Network definition > # > @@ -148,12 +150,10 @@ [LibraryClasses.common] ># Secure Boot dependencies ># > > TpmMeasurementLib|SecurityPkg/Library/DxeTpmMeasurementLib/DxeTpmMeasurementLib.inf > - AuthVariableLib|SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf > ># re-use the UserPhysicalPresent() dummy implementation from the ovmf tree >PlatformSecureLib|OvmfPkg/Library/PlatformSecureLib/PlatformSecureLib.inf > > - VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf > > VariablePolicyLib|MdeModulePkg/Library/VariablePolicyLib/VariablePolicyLib.inf > > VariablePolicyHelperLib|MdeModulePkg/Library/VariablePolicyHelperLib/VariablePolicyHelperLib.inf > > @@ -167,6 +167,7 @@ [LibraryClasses.common] > > ArmPlatformLib|ArmPlatformPkg/Library/ArmPlatformLibNull/ArmPlatformLibNull.inf > >TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf > + > > NorFlashPlatformLib|Silicon/Qemu/SbsaQemu/Library/SbsaQemuNorFlashLib/SbsaQemuNorFlashLib.inf > >CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf > @@ -296,6 +297,8 @@ [PcdsFeatureFlag.common] >gEfiMdeModulePkgTokenSpaceGuid.PcdConOutGopSupport|TRUE >gEfiMdeModulePkgTokenSpaceGuid.PcdConOutUgaSupport|FALSE > > + gEfiMdeModulePkgTokenSpaceGuid.PcdEnableVariableRuntimeCache|FALSE > + > [PcdsFixedAtBuild.common] >gEfiMdePkgTokenSpaceGuid.PcdMaximumUnicodeStringLength|100 >gEfiMdePkgTokenSpaceGuid.PcdMaximumAsciiStringLength|100 > @@ -511,6 +514,10 @@ [PcdsDynamicDefault.common] >gEfiMdeModulePkgTokenSpaceGuid.PcdSmbiosVersion|0x0300 >gEfiMdeModulePkgTokenSpaceGuid.PcdSmbiosDocRev|0x0 > > +
