This project is mirrored from https://github.com/tianocore/edk2.git. Pull mirroring updated .
  1. 06 May, 2022 1 commit
  2. 19 Apr, 2022 1 commit
  3. 02 Apr, 2022 2 commits
    • Min Xu's avatar
      OvmfPkg: Update Sec to support Tdx · 2b80269d
      Min Xu authored
      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 <ardb+tianocore@kernel.org>
      Cc: Jordan Justen <jordan.l.justen@intel.com>
      Cc: Brijesh Singh <brijesh.singh@amd.com>
      Cc: Erdem Aktas <erdemaktas@google.com>
      Cc: James Bottomley <jejb@linux.ibm.com>
      Cc: Jiewen Yao <jiewen.yao@intel.com>
      Cc: Tom Lendacky <thomas.lendacky@amd.com>
      Cc: Gerd Hoffmann <kraxel@redhat.com>
      Acked-by: default avatarGerd Hoffmann <kraxel@redhat.com>
      Reviewed-by: default avatarJiewen Yao <jiewen.yao@intel.com>
      Signed-off-by: default avatarMin Xu <min.m.xu@intel.com>
      2b80269d
    • Min Xu's avatar
      OvmfPkg/Sec: Declare local variable as volatile in SecCoreStartupWithStack · ccca1c2d
      Min Xu authored
      RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429
      
      
      
      Declare the local variables in SecCoreStartupWithStack that actually
      move the data elements as volatile to prevent the optimizer from
      replacing this function with the intrinsic memcpy().
      
      Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
      Cc: Jordan Justen <jordan.l.justen@intel.com>
      Cc: Brijesh Singh <brijesh.singh@amd.com>
      Cc: Erdem Aktas <erdemaktas@google.com>
      Cc: James Bottomley <jejb@linux.ibm.com>
      Cc: Jiewen Yao <jiewen.yao@intel.com>
      Cc: Tom Lendacky <thomas.lendacky@amd.com>
      Cc: Gerd Hoffmann <kraxel@redhat.com>
      Acked-by: default avatarGerd Hoffmann <kraxel@redhat.com>
      Reviewed-by: default avatarJiewen Yao <jiewen.yao@intel.com>
      Signed-off-by: default avatarMin Xu <min.m.xu@intel.com>
      ccca1c2d
  4. 09 Dec, 2021 2 commits
  5. 07 Dec, 2021 1 commit
  6. 27 Aug, 2021 1 commit
  7. 07 Jan, 2021 1 commit
  8. 17 Aug, 2020 2 commits
  9. 30 Apr, 2020 1 commit
  10. 04 Oct, 2019 1 commit
  11. 24 Apr, 2019 1 commit
    • Laszlo Ersek's avatar
      OvmfPkg/Sec: fix out-of-bounds reads · b9d4847e
      Laszlo Ersek authored
      RH covscan justifiedly reports that accessing "EFI_FFS_FILE_HEADER.Size"
      and "EFI_COMMON_SECTION_HEADER.Size", which both are of type UINT8[3],
      through (UINT32*), is undefined behavior:
      
      > Error: OVERRUN (CWE-119):
      > edk2-89910a39/OvmfPkg/Sec/SecMain.c:283: overrun-local: Overrunning
      > array of 3 bytes at byte offset 3 by dereferencing pointer
      > "(UINT32 *)File->Size".
      > #  281|
      > #  282|       File = (EFI_FFS_FILE_HEADER*)(UINTN) CurrentAddress;
      > #  283|->     Size = *(UINT32*) File->Size & 0xffffff;
      > #  284|       if (Size < (sizeof (*File) + sizeof (EFI_COMMON_SECTION_HEADER))) {
      > #  285|         return EFI_VOLUME_CORRUPTED;
      >
      > Error: OVERRUN (CWE-119):
      > edk2-89910a39/OvmfPkg/Sec/SecMain.c:614: overrun-local: Overrunning
      > array of 3 bytes at byte offset 3 by dereferencing pointer
      > "(UINT32 *)File->Size".
      > #  612|
      > #  613|       File = (EFI_FFS_FILE_HEADER*)(UINTN) CurrentAddress;
      > #  614|->     Size = *(UINT32*) File->Size & 0xffffff;
      > #  615|       if (Size < sizeof (*File)) {
      > #  616|         return EFI_NOT_FOUND;
      >
      > Error: OVERRUN (CWE-119):
      > edk2-89910a39/OvmfPkg/Sec/SecMain.c:639: overrun-local: Overrunning
      > array of 3 bytes at byte offset 3 by dereferencing pointer
      > "(UINT32 *)Section->Size".
      > #  637|         Section = (EFI_COMMON_SECTION_HEADER*)(UINTN) CurrentAddress;
      > #  638|
      > #  639|->       Size = *(UINT32*) Section->Size & 0xffffff;
      > #  640|         if (Size < sizeof (*Section)) {
      > #  641|           return EFI_NOT_FOUND;
      
      Fix these by invoking the FFS_FILE_SIZE() and SECTION_SIZE() macros, which
      by now have been fixed too.
      
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Jordan Justen <jordan.l.justen@intel.com>
      Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1710
      
      
      Issue: scan-1008.txt
      Issue: scan-1009.txt
      Issue: scan-1010.txt
      Signed-off-by: default avatarLaszlo Ersek <lersek@redhat.com>
      Acked-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Reviewed-by: default avatarPhilippe Mathieu-Daude <philmd@redhat.com>
      Reviewed-by: default avatarMichael D Kinney <michael.d.kinney@intel.com>
      Reviewed-by: default avatarJordan Justen <jordan.l.justen@intel.com>
      b9d4847e
  12. 09 Apr, 2019 1 commit
  13. 06 Sep, 2017 1 commit
    • Ge Song's avatar
      OvmfPkg/SecMain: Fix stack switching to permanent memory · 89796c69
      Ge Song authored
      
      
      In earlier PEI stage, temporary memory at PcdOvmfSecPeiTempRamBase is
      employed as stack and heap. We move them to the new room and do some
      relocation fixup when permanent memory becomes available.
      TemporaryRamMigration() is responsible for switching the stack.
      
      Before entering TemporaryRamMigration(), Ebp/Rbp is populated with the
      content of Esp/Rsp and used as frame pointer.
      
      After the execution of SetJump/LongJump, stack migrates to new position
      while the context keeps unchanged.
      
      But when TemporaryRamMigration() exits, Esp/Rsp is filled with
      the content of Ebp/Rbp to destroy this stack frame.
      
      The result is, stack switches back to previous temporary memory.
      
      When permanent memory becomes available, modules that have registered
      themselves for shadowing will be scheduled to execute. Some of them
      need to consume more memory(heap/stack). Contrast to temporary stack,
      permanent stack possesses larger space.
      
      The potential risk is overflowing the stack if stack staying in
      temporary memory. When it happens, system may crash during S3 resume.
      
      More detailed information:
      > (gdb) disassemble /r
      > Dump of assembler code for function TemporaryRamMigration:
      >   0x00000000fffcd29c <+0>:	55	push   %rbp
      >   0x00000000fffcd29d <+1>:	48 89 e5	mov    %rsp,%rbp
      >   0x00000000fffcd2a0 <+4>:	48 81 ec 70 01 00 00	sub
      > $0x170,%rsp
      >    ...
      >    ...
      >    0x00000000fffcd425 <+393>:	e8 80 10 00 00	callq  0xfffce4aa
      > <SaveAndSetDebugTimerInterrupt>
      > => 0x00000000fffcd42a <+398>:	b8 00 00 00 00	mov    $0x0,%eax
      >    0x00000000fffcd42f <+403>:	c9	leaveq
      >    0x00000000fffcd430 <+404>:	c3	retq
      > End of assembler dump.
      
      See the description of leave(opcode: c9), from
      Intel 64 and IA-32 Architectures Software Developer's Manual, Volume 2A
      
      "Releases the stack frame set up by an earlier ENTER instruction. The
      LEAVE instruction copies the frame pointer (in the EBP register) into
      the stack pointer register (ESP), which releases the stack space
      allocated to the stack frame. The old frame pointer (the frame pointer
      for the calling procedure that was saved by the ENTER instruction) is
      then popped from the stack into the EBP register, restoring the calling
      procedure’s stack frame."
      
      To solve this, update Ebp/Rbp too when Esp/Rsp is updated
      
      Cc: Jordan Justen <jordan.l.justen@intel.com>
      Cc: Laszlo Ersek <lersek@redhat.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Contributed-under: TianoCore Contribution Agreement 1.1
      Signed-off-by: default avatarGe Song <ge.song@hxt-semitech.com>
      Tested-by: default avatarLaszlo Ersek <lersek@redhat.com>
      Reviewed-by: default avatarLaszlo Ersek <lersek@redhat.com>
      Reviewed-by: default avatarJordan Justen <jordan.l.justen@intel.com>
      89796c69
  14. 19 Oct, 2016 1 commit
  15. 27 Jul, 2016 2 commits
  16. 30 Nov, 2015 3 commits
    • Laszlo Ersek's avatar
      OvmfPkg: decompress FVs on S3 resume if SMM_REQUIRE is set · efb0f16e
      Laszlo Ersek authored
      
      
      If OVMF was built with -D SMM_REQUIRE, that implies that the runtime OS is
      not trusted and we should defend against it tampering with the firmware's
      data.
      
      One such datum is the PEI firmware volume (PEIFV). Normally PEIFV is
      decompressed on the first boot by SEC, then the OS preserves it across S3
      suspend-resume cycles; at S3 resume SEC just reuses the originally
      decompressed PEIFV.
      
      However, if we don't trust the OS, then SEC must decompress PEIFV from the
      pristine flash every time, lest we execute OS-injected code or work with
      OS-injected data.
      
      Due to how FVMAIN_COMPACT is organized, we can't decompress just PEIFV;
      the decompression brings DXEFV with itself, plus it uses a temporary
      output buffer and a scratch buffer too, which even reach above the end of
      the finally installed DXEFV. For this reason we must keep away a
      non-malicious OS from DXEFV too, plus the memory up to
      PcdOvmfDecomprScratchEnd.
      
      The delay introduced by the LZMA decompression on S3 resume is negligible.
      
      If -D SMM_REQUIRE is not specified, then PcdSmmSmramRequire remains FALSE
      (from the DEC file), and then this patch has no effect (not counting some
      changed debug messages).
      
      If QEMU doesn't support S3 (or the user disabled it on the QEMU command
      line), then this patch has no effect also.
      
      Contributed-under: TianoCore Contribution Agreement 1.0
      Signed-off-by: default avatarLaszlo Ersek <lersek@redhat.com>
      Reviewed-by: default avatarJordan Justen <jordan.l.justen@intel.com>
      
      git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19037 6f19259b-4bc3-4df7-8a09-765794883524
      efb0f16e
    • Laszlo Ersek's avatar
      OvmfPkg: Sec: assert the build-time calculated end of the scratch buffer · 9beac0d8
      Laszlo Ersek authored
      
      
      The DecompressMemFvs() function in "OvmfPkg/Sec/SecMain.c" uses more
      memory, temporarily, than what PEIFV and DXEFV will ultimately need.
      First, it uses an output buffer for decompression, second, the
      decompression itself needs a scratch buffer (and this scratch buffer is
      the highest area that SEC uses).
      
      DecompressMemFvs() used to be called on normal boots only (ie. not on S3
      resume), which is why the decompression output buffer and the scratch
      buffer were allowed to scribble over RAM. However, we'll soon start to
      worry during S3 resume that the runtime OS might tamper with the
      pre-decompressed PEIFV, and we'll decompress the firmware volumes on S3
      resume too, from pristine flash. For this we'll need to know the end of
      the scratch buffer in advance, so we can prepare a non-malicious OS for
      it.
      
      Calculate the end of the scratch buffer statically in the FDF files, and
      assert in DecompressMemFvs() that the runtime decompression will match it.
      
      Contributed-under: TianoCore Contribution Agreement 1.0
      Signed-off-by: default avatarLaszlo Ersek <lersek@redhat.com>
      Reviewed-by: default avatarJordan Justen <jordan.l.justen@intel.com>
      
      git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19036 6f19259b-4bc3-4df7-8a09-765794883524
      9beac0d8
    • Laszlo Ersek's avatar
      OvmfPkg: Sec: force reinit of BaseExtractGuidedSectionLib handler table · 320b4f08
      Laszlo Ersek authored
      BaseExtractGuidedSectionLib uses a table at the static physical address
      PcdGuidedExtractHandlerTableAddress, and modules that are linked against
      BaseExtractGuidedSectionLib are expected to work together on that table.
      Namely, some modules can register handlers for GUIDed sections, some other
      modules can decode such sections with the pre-registered handlers. The
      table carries persistent information between these modules.
      
      BaseExtractGuidedSectionLib checks a table signature whenever it is used
      (by whichever module that is linked against it), and at the first use
      (identified by a signature mismatch) it initializes the table.
      
      One of the module types that BaseExtractGuidedSectionLib can be used with
      is SEC, if the SEC module in question runs with the platform's RAM already
      available.
      
      In such cases the question emerges whether the initial contents of the RAM
      (ie. contents that predate the very first signature check) can be trusted.
      Normally RAM starts out with all zeroes (leading to a signature mismatch
      on the first check); however a malicious runtime OS can populate the area
      with some payload, then force a warm platform reset or an S3
      suspend-and-resume. In such cases the signature check in the SEC module
      might not fire, and ExtractGuidedSectionDecode() might run code injected
      by the runtime OS, as part of SEC (ie. with high privileges).
      
      Therefore we clear the handler table in SEC.
      
      See also git commit ad43bc6b
      
       (SVN rev 15433) -- this patch secures the
      (d) and (e) code paths examined in that commit. Furthermore, a
      non-malicious runtime OS will observe no change in behavior; see case (c)
      in said commit.
      
      Cc: Michael Kinney <michael.d.kinney@intel.com>
      Cc: Jordan Justen <jordan.l.justen@intel.com>
      Contributed-under: TianoCore Contribution Agreement 1.0
      Signed-off-by: default avatarLaszlo Ersek <lersek@redhat.com>
      [michael.d.kinney@intel.com: prevent VS20xx loop intrinsic with volatile]
      Contributed-under: TianoCore Contribution Agreement 1.0
      Signed-off-by: default avatarMichael Kinney <michael.d.kinney@intel.com>
      Reviewed-by: default avatarMichael Kinney <michael.d.kinney@intel.com>
      Reviewed-by: default avatarJordan Justen <jordan.l.justen@intel.com>
      
      git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19035 6f19259b-4bc3-4df7-8a09-765794883524
      320b4f08
  17. 16 Oct, 2015 1 commit
  18. 28 Jul, 2015 1 commit
  19. 04 Mar, 2014 1 commit
  20. 21 Jan, 2014 7 commits
  21. 24 Sep, 2013 1 commit
  22. 18 Jul, 2013 1 commit
  23. 31 Oct, 2011 1 commit
  24. 14 Mar, 2011 1 commit
  25. 03 Aug, 2010 1 commit
  26. 28 Apr, 2010 1 commit
  27. 06 Jan, 2010 1 commit
  28. 04 Jan, 2010 1 commit