mirror of https://github.com/acidanthera/audk.git
ac79397267
The CSM-based VideoDxe driver is a special UEFI_DRIVER module that both follows and doesn't follow the UEFI driver model. Namely, in the Supported and Start members of its Driver Binding Protocol instance, it consumes the Legacy Bios Protocol directly from the UEFI protocol database, as opposed to (only) opening protocols on the handle that it is supposed to bind. Furthermore, the driver "marks" its own image handle with the NULL-interface "Legacy Bios" (pseudo-protocol) GUID, in order to "inform back" the provider of the Legacy Bios Protocol, i.e., LegacyBiosDxe, that VideoDxe is a "BIOS Thunk Driver" in the system. Quoting "OvmfPkg/Csm/Include/Guid/LegacyBios.h", such a driver follows the UEFI Driver Model, but still uses the Int86() or FarCall() services of the Legacy Bios Protocol as the basis for the UEFI protocol it produces. In a sense, there is a circular dependency between VideoDxe and LegacyBiosDxe; each knows about the other. However, VideoDxe is a UEFI_DRIVER, while LegacyBiosDxe is a platform DXE_DRIVER with a very long DEPEX. Therefore, for keeping dependencies conceptually intact, first exclude VideoDxe from the OVMF platforms. Always include the hypervisor-specific real UEFI video driver. --*-- Note that the pathname "IntelFrameworkModulePkg/Csm/BiosThunk/VideoDxe/VideoDxe.inf" in the bhyve platform DSC and FDF files is bogus anyway. Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Corvin Köhne <corvink@freebsd.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Rebecca Cran <rebecca@bsdio.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20231110235820.644381-9-lersek@redhat.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Corvin Köhne <corvink@FreeBSD.org> Acked-by: Gerd Hoffmann <kraxel@redhat.com> |
||
|---|---|---|
| .. | ||
| PrePiHobListPointerLibTdx | ||
| Sec | ||
| TdxHelperLib | ||
| IntelTdxX64.dsc | ||
| IntelTdxX64.fdf | ||
| README | ||
README
TDVF Overview ------------- <b>Intel Trust Domain Extension (TDX)</b> is Intel Architecture extension to provide trusted, isolated VM execution by removing CSP software (hypervisor etc) from the TCB. <b>TDX Virtual Firmware (TDVF)</b> is an EDK II based project to enable UEFI support for TDX based Virtual Machines. It provides the capability to launch a TD. The <b>Intel? TDX Virtual Firmware Design Guide</b> is at https://www.intel.com/content/dam/develop/external/us/en/documents/tdx-virtual-firmware-design-guide-rev-1.01.pdf. More information can be found at: https://www.intel.com/content/www/us/en/developer/articles/technical/intel-trust-domain-extensions.html Configurations and Features ---------------------------- There are 2 configurations for TDVF. <b>Config-A:</b> - Merge the *basic* TDVF feature to existing OvmfX64Pkg.dsc. (Align with existing SEV) - Threat model: VMM is NOT out of TCB. (We don?t make things worse) - The OvmfX64Pkg.dsc includes SEV/TDX/normal OVMF basic boot capability. The final binary can run on SEV/TDX/normal OVMF. - No changes to existing OvmfPkgX64 image layout. - No need to remove features if they exist today. - PEI phase is NOT skipped in either Td or Non-Td. - RTMR based measurement is supported. - External inputs from Host VMM are measured, such as TdHob, CFV. - Other external inputs are measured, such as FW_CFG data, os loader, initrd, etc. <b>Config-B:</b> - Add a standalone IntelTdx.dsc to a TDX specific directory for a *full* feature TDVF.(Align with existing SEV) - Threat model: VMM is out of TCB. (We need necessary change to prevent attack from VMM) - IntelTdx.dsc includes TDX/normal OVMF basic boot capability. The final binary can run on TDX/normal OVMF. - It might eventually merge with AmdSev.dsc, but NOT at this point of time. And we don?t know when it will happen. We need sync with AMD in the community after both of us think the solutions are mature to merge. - Need to add necessary security feature as mandatory requirement, such as RTMR based Trusted Boot support. - Need to measure the external input from Host VMM, such as TdHob, CFV. - Need to measure other external input, such as FW_CFG data, os loader, initrd, etc. - Need to remove unnecessary attack surfaces, such as network stack. Build ------ - Build the TDVF (Config-A) target: `cd /path/to/edk2` `source edksetup.sh` `build.sh -p OvmfPkg/OvmfPkgX64.dsc -a X64 -t GCC5` - Build the TDVF (Config-B) target: `cd /path/to/edk2` `set PACKAGES_PATH=/path/to/edk2/OvmfPkg` `source edksetup.sh` `build.sh -p OvmfPkg/IntelTdx/IntelTdxX64.dsc -a X64 -t GCC5` Usage ----- Assuming TDX-QEMU/TDX-KVM are already built, one can start a TD virtual machine as [launching-td-guest](https://github.com/intel/qemu-tdx/blob/tdx-qemu-upstream-rfc-v3/docs/system/i386/tdx.rst#launching-a-td-tdx-vm): `qemu_system_x86 \` ` -machine ...,confidential-guest-support=tdx0 \` ` -object tdx-guest,id=tdx0,[sept-ve-disable=off] \` ` -drive if=pflash,format=raw,unit=0,file=/path/to/OVMF_CODE.fd \` ` -drive if=pflash,format=raw,unit=1,file=/path/to/OVMF_VARS.fd \` Note: TDX-QEMU/TDX-KVM are still in upstreaming progress. Please refer to: - kvm : https://github.com/intel/tdx/tree/kvm-upstream - qemu : https://github.com/intel/qemu-tdx/blob/tdx-qemu-upstream-rfc-v3 Once above 2 upstreaming are completed a minimum qemu/kvm version will be updated here.