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 1 commit
    • 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
  4. 09 Dec, 2021 2 commits
  5. 27 Aug, 2021 1 commit
  6. 17 Aug, 2020 1 commit
  7. 09 Apr, 2019 1 commit
  8. 29 Jun, 2018 1 commit
    • chenc2's avatar
      OvmfPkg: Removing ipf which is no longer supported from edk2. · dbf9cc87
      chenc2 authored
      
      
      Removing rules for Ipf sources file:
      * Remove the source file which path with "ipf" and also listed in
        [Sources.IPF] section of INF file.
      * Remove the source file which listed in [Components.IPF] section
        of DSC file and not listed in any other [Components] section.
      * Remove the embedded Ipf code for MDE_CPU_IPF.
      
      Removing rules for Inf file:
      * Remove IPF from VALID_ARCHITECTURES comments.
      * Remove DXE_SAL_DRIVER from LIBRARY_CLASS in [Defines] section.
      * Remove the INF which only listed in [Components.IPF] section in DSC.
      * Remove statements from [BuildOptions] that provide IPF specific flags.
      * Remove any IPF sepcific sections.
      
      Removing rules for Dec file:
      * Remove [Includes.IPF] section from Dec.
      
      Removing rules for Dsc file:
      * Remove IPF from SUPPORTED_ARCHITECTURES in [Defines] section of DSC.
      * Remove any IPF specific sections.
      * Remove statements from [BuildOptions] that provide IPF specific flags.
      
      Cc: Jordan Justen <jordan.l.justen@intel.com>
      Cc: Laszlo Ersek <lersek@redhat.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Michael D Kinney <michael.d.kinney@intel.com>
      Contributed-under: TianoCore Contribution Agreement 1.1
      Signed-off-by: default avatarChen A Chen <chen.a.chen@intel.com>
      Reviewed-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      dbf9cc87
  9. 17 Nov, 2017 1 commit
    • Laszlo Ersek's avatar
      OvmfPkg/Sec/Ia32: seed the temporary RAM with PcdInitValueInTempStack · 9d9350a5
      Laszlo Ersek authored
      This allows the PEI core to report the maximum temporary SEC/PEI stack
      usage on the DEBUG_INFO level, in the PeiCheckAndSwitchStack() function
      [MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c]:
      
      * Normal boot:
      
      > Temp Stack : BaseAddress=0x814000 Length=0x4000
      > Temp Heap  : BaseAddress=0x810000 Length=0x4000
      > Total temporary memory:    32768 bytes.
      >   temporary memory stack ever used:       3664 bytes. <----
      >   temporary memory heap used for HobList: 5904 bytes.
      >   temporary memory heap occupied by memory pages: 0 bytes.
      
      * S3 resume (with PEI decompression / SMM):
      
      > Temp Stack : BaseAddress=0x814000 Length=0x4000
      > Temp Heap  : BaseAddress=0x810000 Length=0x4000
      > Total temporary memory:    32768 bytes.
      >   temporary memory stack ever used:       3428 bytes. <----
      >   temporary memory heap used for HobList: 4816 bytes.
      >   temporary memory heap occupied by memory pages: 0 bytes.
      
      I unit-tested this change by transitorily adding an infinite loop right
      after the "rep stosd", and dumping the guest's temp SEC/PEI RAM (32KB
      currently) while the guest was stuck in the loop. The dump includes one
      dword from before and after the temp SEC/PEI RAM:
      
      > $ virsh qemu-monitor-command GUEST_NAME --hmp 'xp /8194wx 0x80FFFC'
      >
      > 000000000080fffc: 0x00000000 0x5aa55aa5 0x5aa55aa5 0x5aa55aa5
      > 000000000081000c: 0x5aa55aa5 0x5aa55aa5 0x5aa55aa5 0x5aa55aa5
      > ...
      > 0000000000817fec: 0x5aa55aa5 0x5aa55aa5 0x5aa55aa5 0x5aa55aa5
      > 0000000000817ffc: 0x5aa55aa5 0x00000000
      
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Jordan Justen <jordan.l.justen@intel.com>
      Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=747
      
      
      Contributed-under: TianoCore Contribution Agreement 1.1
      Signed-off-by: default avatarLaszlo Ersek <lersek@redhat.com>
      Reviewed-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Reviewed-by: default avatarJordan Justen <jordan.l.justen@intel.com>
      9d9350a5
  10. 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
  11. 16 Oct, 2015 1 commit
  12. 31 Oct, 2014 2 commits
  13. 21 Jan, 2014 3 commits
    • Jordan Justen's avatar
      OvmfPkg: Split MAINFV into a separate PEI and DXE FVs · b36f701d
      Jordan Justen authored
      
      
      By splitting the PEI and DXE phases into separate FVs,
      we can only reserve the PEI FV for ACPI S3 support.
      This should save about 7MB.
      
      Unfortunately, this all has to happen in a single commit.
      
      DEC:
      * Remove PcdOvmfMemFv(Base|Size)
      * Add PcdOvmfPeiMemFv(Base|Size)
      * Add PcdOvmfDxeMemFv(Base|Size)
      
      FDF:
      * Add new PEIFV. Move PEI modules here.
      * Remove MAINFV
      * Add PEIFV and DXEFV into FVMAIN_COMPACT
         - They are added as 2 sections of a file, and compressed
           together so they should retain good compression
      * PcdOvmf(Pei|Dxe)MemFv(Base|Size) are set
      
      SEC:
      * Find both the PEI and DXE FVs after decompression.
         - Copy them separately to their memory locations.
      
      Platform PEI driver:
      * Fv.c: Publish both FVs as appropriate
      * MemDetect.c: PcdOvmfMemFv(Base|Size) =>
                      PcdOvmfDxeMemFv(Base|Size)
      
      OVMF.fd before:
      
        Non-volatile data storage
        FVMAIN_COMPACT                    uncompressed
          FV FFS file                     LZMA compressed
            MAINFV                        uncompressed
              individual PEI modules      uncompressed
              FV FFS file                 compressed with PI_NONE
                DXEFV                     uncompressed
                  individual DXE modules  uncompressed
        SECFV                             uncompressed
      
      OVMF.fd after:
      
        Non-volatile data storage
        FVMAIN_COMPACT                    uncompressed
          FV FFS file                     LZMA compressed
            PEIFV                         uncompressed
              individual PEI modules      uncompressed
            DXEFV                         uncompressed
              individual DXE modules      uncompressed
        SECFV                             uncompressed
      
      Contributed-under: TianoCore Contribution Agreement 1.0
      Signed-off-by: default avatarJordan Justen <jordan.l.justen@intel.com>
      Reviewed-by: default avatarLaszlo Ersek <lersek@redhat.com>
      
      git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15151 6f19259b-4bc3-4df7-8a09-765794883524
      b36f701d
    • Jordan Justen's avatar
      OvmfPkg: Move SEC/PEI Temporary RAM from 0x70000 to 0x810000 · 7cb6b0e0
      Jordan Justen authored
      
      
      Note: The Temporary RAM memory size is being reduced from
            64KB to 32KB. This still appears to be more than
            adequate for OVMF's early PEI phase. We will be adding
            another 32KB range of RAM just above this range for
            use on S3 resume.
      
      The range is declared as part of MEMFD, so it is easier
      to identify the memory range.
      
      We also now assign PCDs to the memory range.
      
      The PCDs are used to set the initial SEC/PEI stack in
      SEC's assembly code.
      
      The PCDs are also used in the SEC C code to setup
      the Temporary RAM PPI.
      
      Contributed-under: TianoCore Contribution Agreement 1.0
      Signed-off-by: default avatarJordan Justen <jordan.l.justen@intel.com>
      Reviewed-by: default avatarLaszlo Ersek <lersek@redhat.com>
      
      git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15147 6f19259b-4bc3-4df7-8a09-765794883524
      7cb6b0e0
    • Jordan Justen's avatar
      OvmfPkg X64 ResetVector: Move page tables from 512KB to 8MB · b382ede3
      Jordan Justen authored
      
      
      To help consolidate OVMF fixed memory uses, we declare this
      range in MEMFD and thereby move it to 8MB.
      
      We also now declare the table range in the FDF to set
      PCDs. This allows us to ASSERT that CR3 is set as expected
      in OVMF SEC.
      
      OvmfPkgIa32.fdf and OvmfPkgIa32X64.fdf are updated simply
      for consistency.
      
      Contributed-under: TianoCore Contribution Agreement 1.0
      Signed-off-by: default avatarJordan Justen <jordan.l.justen@intel.com>
      Reviewed-by: default avatarLaszlo Ersek <lersek@redhat.com>
      
      git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15146 6f19259b-4bc3-4df7-8a09-765794883524
      b382ede3
  14. 03 Aug, 2010 1 commit
  15. 28 Apr, 2010 1 commit
  16. 23 Feb, 2010 1 commit
  17. 30 Jan, 2010 1 commit
  18. 04 Jan, 2010 1 commit
  19. 16 Dec, 2009 1 commit
  20. 25 Nov, 2009 1 commit
  21. 27 May, 2009 1 commit
  22. 30 Jun, 2008 1 commit
  23. 20 Jul, 2007 1 commit
  24. 16 Jul, 2007 1 commit
  25. 29 Jun, 2007 1 commit
  26. 28 Jun, 2007 1 commit
  27. 26 Jun, 2007 2 commits
  28. 22 Jun, 2007 3 commits