tyler.durden
/
audk
mirror of https://github.com/acidanthera/audk.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
audk/OvmfPkg/AmdSevDxe/AmdSevDxe.inf

49 lines
1.3 KiB
INI
Raw Normal View History

OvmfPkg: Add AmdSevDxe driver When SEV is enabled, the MMIO memory range must be mapped as unencrypted (i.e C-bit cleared). We need to clear the C-bit for MMIO GCD entries in order to cover the ranges that were added during the PEI phase (through memory resource descriptor HOBs). Additionally, the NonExistent ranges are processed in order to cover, in advance, MMIO ranges added later in the DXE phase by various device drivers, via the appropriate DXE memory space services. The approach is not transparent for later addition of system memory ranges to the GCD memory space map. (Such ranges should be encrypted.) OVMF does not do such a thing at the moment, so this approach should be OK. The driver is being added to the APRIORI DXE file so that, we clear the C-bit from MMIO regions before any driver accesses it. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Leo Duran <leo.duran@amd.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Suggested-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com>
2017-07-06 15:26:45 +02:00
#/** @file
#
# Driver clears the encryption attribute from MMIO regions when SEV is enabled
#
# Copyright (c) 2017, AMD Inc. All rights reserved.<BR>
#
OvmfPkg/AmdSevDxe: rewrap to 79 characters width There are many overlong lines; it's hard to work with the module like this. Rewrap all files to 79 columns. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
2018-03-01 14:32:23 +01:00
# This program and the accompanying materials are licensed and made available
# under the terms and conditions of the BSD License which accompanies this
# distribution. The full text of the license may be found at
# http://opensource.org/licenses/bsd-license.php
OvmfPkg: Add AmdSevDxe driver When SEV is enabled, the MMIO memory range must be mapped as unencrypted (i.e C-bit cleared). We need to clear the C-bit for MMIO GCD entries in order to cover the ranges that were added during the PEI phase (through memory resource descriptor HOBs). Additionally, the NonExistent ranges are processed in order to cover, in advance, MMIO ranges added later in the DXE phase by various device drivers, via the appropriate DXE memory space services. The approach is not transparent for later addition of system memory ranges to the GCD memory space map. (Such ranges should be encrypted.) OVMF does not do such a thing at the moment, so this approach should be OK. The driver is being added to the APRIORI DXE file so that, we clear the C-bit from MMIO regions before any driver accesses it. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Leo Duran <leo.duran@amd.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Suggested-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com>
2017-07-06 15:26:45 +02:00
#
# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
OvmfPkg/AmdSevDxe: rewrap to 79 characters width There are many overlong lines; it's hard to work with the module like this. Rewrap all files to 79 columns. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
2018-03-01 14:32:23 +01:00
# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
# IMPLIED.
OvmfPkg: Add AmdSevDxe driver When SEV is enabled, the MMIO memory range must be mapped as unencrypted (i.e C-bit cleared). We need to clear the C-bit for MMIO GCD entries in order to cover the ranges that were added during the PEI phase (through memory resource descriptor HOBs). Additionally, the NonExistent ranges are processed in order to cover, in advance, MMIO ranges added later in the DXE phase by various device drivers, via the appropriate DXE memory space services. The approach is not transparent for later addition of system memory ranges to the GCD memory space map. (Such ranges should be encrypted.) OVMF does not do such a thing at the moment, so this approach should be OK. The driver is being added to the APRIORI DXE file so that, we clear the C-bit from MMIO regions before any driver accesses it. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Leo Duran <leo.duran@amd.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Suggested-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com>
2017-07-06 15:26:45 +02:00
#
#**/
[Defines]
INF_VERSION = 1.25
BASE_NAME = AmdSevDxe
FILE_GUID = 2ec9da37-ee35-4de9-86c5-6d9a81dc38a7
MODULE_TYPE = DXE_DRIVER
VERSION_STRING = 1.0
ENTRY_POINT = AmdSevDxeEntryPoint
[Sources]
AmdSevDxe.c
[Packages]
MdeModulePkg/MdeModulePkg.dec
OvmfPkg/AmdSevDxe: sort #includes, and entries in INF file sections Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
2018-03-01 15:02:11 +01:00
MdePkg/MdePkg.dec
OvmfPkg: Add AmdSevDxe driver When SEV is enabled, the MMIO memory range must be mapped as unencrypted (i.e C-bit cleared). We need to clear the C-bit for MMIO GCD entries in order to cover the ranges that were added during the PEI phase (through memory resource descriptor HOBs). Additionally, the NonExistent ranges are processed in order to cover, in advance, MMIO ranges added later in the DXE phase by various device drivers, via the appropriate DXE memory space services. The approach is not transparent for later addition of system memory ranges to the GCD memory space map. (Such ranges should be encrypted.) OVMF does not do such a thing at the moment, so this approach should be OK. The driver is being added to the APRIORI DXE file so that, we clear the C-bit from MMIO regions before any driver accesses it. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Leo Duran <leo.duran@amd.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Suggested-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com>
2017-07-06 15:26:45 +02:00
OvmfPkg/OvmfPkg.dec
[LibraryClasses]
OvmfPkg/AmdSevDxe: decrypt the pages of the initial SMRAM save state map Based on the following patch from Brijesh Singh <brijesh.singh@amd.com>: [PATCH v2 1/2] OvmfPkg/AmdSevDxe: Clear the C-bit from SMM Saved State http://mid.mail-archive.com/20180228161415.28723-2-brijesh.singh@amd.com https://lists.01.org/pipermail/edk2-devel/2018-February/022016.html Original commit message from Brijesh: > When OVMF is built with SMM, SMMSaved State area (SMM_DEFAULT_SMBASE + > SMRAM_SAVE_STATE_MAP_OFFSET) contains data which need to be accessed by > both guest and hypervisor. Since the data need to be accessed by both > hence we must map the SMMSaved State area as unencrypted (i.e C-bit > cleared). > > This patch clears the SavedStateArea address before SMBASE relocation. > Currently, we do not clear the SavedStateArea address after SMBASE is > relocated due to the following reasons: > > 1) Guest BIOS never access the relocated SavedStateArea. > > 2) The C-bit works on page-aligned address, but the SavedStateArea > address is not a page-aligned. Theoretically, we could roundup the > address and clear the C-bit of aligned address but looking carefully we > found that some portion of the page contains code -- which will causes a > bigger issue for the SEV guest. When SEV is enabled, all the code must > be encrypted otherwise hardware will cause trap. Changes by Laszlo: - separate AmdSevDxe bits from SmmCpuFeaturesLib bits; - spell out PcdLib dependency with #include and in LibraryClasses; - replace (SMM_DEFAULT_SMBASE + SMRAM_SAVE_STATE_MAP_OFFSET) calculation with call to new MemEncryptSevLocateInitialSmramSaveStateMapPages() function; - consequently, pass page-aligned BaseAddress to MemEncryptSevClearPageEncMask(); - zero the pages before clearing the C-bit; - pass Flush=TRUE to MemEncryptSevClearPageEncMask(); - harden the treatment of MemEncryptSevClearPageEncMask() failure. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
2018-03-01 22:05:55 +01:00
BaseLib
BaseMemoryLib
OvmfPkg: Add AmdSevDxe driver When SEV is enabled, the MMIO memory range must be mapped as unencrypted (i.e C-bit cleared). We need to clear the C-bit for MMIO GCD entries in order to cover the ranges that were added during the PEI phase (through memory resource descriptor HOBs). Additionally, the NonExistent ranges are processed in order to cover, in advance, MMIO ranges added later in the DXE phase by various device drivers, via the appropriate DXE memory space services. The approach is not transparent for later addition of system memory ranges to the GCD memory space map. (Such ranges should be encrypted.) OVMF does not do such a thing at the moment, so this approach should be OK. The driver is being added to the APRIORI DXE file so that, we clear the C-bit from MMIO regions before any driver accesses it. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Leo Duran <leo.duran@amd.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Suggested-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com>
2017-07-06 15:26:45 +02:00
DebugLib
OvmfPkg/AmdSevDxe: sort #includes, and entries in INF file sections Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
2018-03-01 15:02:11 +01:00
DxeServicesTableLib
OvmfPkg: Add AmdSevDxe driver When SEV is enabled, the MMIO memory range must be mapped as unencrypted (i.e C-bit cleared). We need to clear the C-bit for MMIO GCD entries in order to cover the ranges that were added during the PEI phase (through memory resource descriptor HOBs). Additionally, the NonExistent ranges are processed in order to cover, in advance, MMIO ranges added later in the DXE phase by various device drivers, via the appropriate DXE memory space services. The approach is not transparent for later addition of system memory ranges to the GCD memory space map. (Such ranges should be encrypted.) OVMF does not do such a thing at the moment, so this approach should be OK. The driver is being added to the APRIORI DXE file so that, we clear the C-bit from MMIO regions before any driver accesses it. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Leo Duran <leo.duran@amd.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Suggested-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com>
2017-07-06 15:26:45 +02:00
MemEncryptSevLib
OvmfPkg/AmdSevDxe: refresh #includes and LibraryClasses List those and only those libraries that are used. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
2018-03-01 21:43:09 +01:00
MemoryAllocationLib
OvmfPkg/AmdSevDxe: decrypt the pages of the initial SMRAM save state map Based on the following patch from Brijesh Singh <brijesh.singh@amd.com>: [PATCH v2 1/2] OvmfPkg/AmdSevDxe: Clear the C-bit from SMM Saved State http://mid.mail-archive.com/20180228161415.28723-2-brijesh.singh@amd.com https://lists.01.org/pipermail/edk2-devel/2018-February/022016.html Original commit message from Brijesh: > When OVMF is built with SMM, SMMSaved State area (SMM_DEFAULT_SMBASE + > SMRAM_SAVE_STATE_MAP_OFFSET) contains data which need to be accessed by > both guest and hypervisor. Since the data need to be accessed by both > hence we must map the SMMSaved State area as unencrypted (i.e C-bit > cleared). > > This patch clears the SavedStateArea address before SMBASE relocation. > Currently, we do not clear the SavedStateArea address after SMBASE is > relocated due to the following reasons: > > 1) Guest BIOS never access the relocated SavedStateArea. > > 2) The C-bit works on page-aligned address, but the SavedStateArea > address is not a page-aligned. Theoretically, we could roundup the > address and clear the C-bit of aligned address but looking carefully we > found that some portion of the page contains code -- which will causes a > bigger issue for the SEV guest. When SEV is enabled, all the code must > be encrypted otherwise hardware will cause trap. Changes by Laszlo: - separate AmdSevDxe bits from SmmCpuFeaturesLib bits; - spell out PcdLib dependency with #include and in LibraryClasses; - replace (SMM_DEFAULT_SMBASE + SMRAM_SAVE_STATE_MAP_OFFSET) calculation with call to new MemEncryptSevLocateInitialSmramSaveStateMapPages() function; - consequently, pass page-aligned BaseAddress to MemEncryptSevClearPageEncMask(); - zero the pages before clearing the C-bit; - pass Flush=TRUE to MemEncryptSevClearPageEncMask(); - harden the treatment of MemEncryptSevClearPageEncMask() failure. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
2018-03-01 22:05:55 +01:00
PcdLib
OvmfPkg/AmdSevDxe: sort #includes, and entries in INF file sections Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
2018-03-01 15:02:11 +01:00
UefiDriverEntryPoint
OvmfPkg: Add AmdSevDxe driver When SEV is enabled, the MMIO memory range must be mapped as unencrypted (i.e C-bit cleared). We need to clear the C-bit for MMIO GCD entries in order to cover the ranges that were added during the PEI phase (through memory resource descriptor HOBs). Additionally, the NonExistent ranges are processed in order to cover, in advance, MMIO ranges added later in the DXE phase by various device drivers, via the appropriate DXE memory space services. The approach is not transparent for later addition of system memory ranges to the GCD memory space map. (Such ranges should be encrypted.) OVMF does not do such a thing at the moment, so this approach should be OK. The driver is being added to the APRIORI DXE file so that, we clear the C-bit from MMIO regions before any driver accesses it. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Leo Duran <leo.duran@amd.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Suggested-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com>
2017-07-06 15:26:45 +02:00
[Depex]
TRUE
OvmfPkg/AmdSevDxe: decrypt the pages of the initial SMRAM save state map Based on the following patch from Brijesh Singh <brijesh.singh@amd.com>: [PATCH v2 1/2] OvmfPkg/AmdSevDxe: Clear the C-bit from SMM Saved State http://mid.mail-archive.com/20180228161415.28723-2-brijesh.singh@amd.com https://lists.01.org/pipermail/edk2-devel/2018-February/022016.html Original commit message from Brijesh: > When OVMF is built with SMM, SMMSaved State area (SMM_DEFAULT_SMBASE + > SMRAM_SAVE_STATE_MAP_OFFSET) contains data which need to be accessed by > both guest and hypervisor. Since the data need to be accessed by both > hence we must map the SMMSaved State area as unencrypted (i.e C-bit > cleared). > > This patch clears the SavedStateArea address before SMBASE relocation. > Currently, we do not clear the SavedStateArea address after SMBASE is > relocated due to the following reasons: > > 1) Guest BIOS never access the relocated SavedStateArea. > > 2) The C-bit works on page-aligned address, but the SavedStateArea > address is not a page-aligned. Theoretically, we could roundup the > address and clear the C-bit of aligned address but looking carefully we > found that some portion of the page contains code -- which will causes a > bigger issue for the SEV guest. When SEV is enabled, all the code must > be encrypted otherwise hardware will cause trap. Changes by Laszlo: - separate AmdSevDxe bits from SmmCpuFeaturesLib bits; - spell out PcdLib dependency with #include and in LibraryClasses; - replace (SMM_DEFAULT_SMBASE + SMRAM_SAVE_STATE_MAP_OFFSET) calculation with call to new MemEncryptSevLocateInitialSmramSaveStateMapPages() function; - consequently, pass page-aligned BaseAddress to MemEncryptSevClearPageEncMask(); - zero the pages before clearing the C-bit; - pass Flush=TRUE to MemEncryptSevClearPageEncMask(); - harden the treatment of MemEncryptSevClearPageEncMask() failure. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
2018-03-01 22:05:55 +01:00
[FeaturePcd]
gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire