Tdvf One Binary #8
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
mxu9
force-pushed
the
tdvf_dev
branch
3 times, most recently
from
55b2df9 to
10b16da
Compare
mxu9
force-pushed
the
tdvf_dev
branch
11 times, most recently
from
4907ed9 to
e64fa50
Compare
In NOOPT and DEBUG builds, if "PcdMaximumLinkedListLength" is nonzero, then several LIST_ENTRY *node* APIs in BaseLib compare the *full* list length against the PCD. This turns the time complexity of node-level APIs from constant to linear, and that of full-list manipulations from linear to quadratic. (See some example OVMF numbers in the previous patch.) Checking list lengths against an arbitrary maximum -- default value, and current ArmVirtPkg setting: 1,000,000 -- seems useless even in NOOPT and DEBUG builds, while the cost is significant; so set the PCD to 0. Cc: Ard Biesheuvel <[email protected]> Cc: Julien Grall <[email protected]> Cc: Leif Lindholm <[email protected]> Cc: Philippe Mathieu-Daudé <[email protected]> Cc: Sami Mujawar <[email protected]> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3152 Signed-off-by: Laszlo Ersek <[email protected]> Acked-by: Ard Biesheuvel <[email protected]> Message-Id: <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
The Td guest firmware is designed to publish a multiprocessor-wakeup structure to let the guest BSP wake up guest AP with a mailbox. The mailbox is memory that the guest firmware can reserve so each guest, virtual processor can have the guest OS send a message to them. TDX only supports on X64 architecture, so OvmfPkgX64.fdf is updated to reserve a 4K-aligned, 4K-size memory block.
Some of the EDK2 driver/lib need to detect the running guest is of Td or Non-Td. For example, the IO operation is different in Td or Non-Td guest. TdxProbeLib is such library to probe the Td or Non-Td guest. A NULL instance of TdxProbeLib is implemented in MdePkg and it always returns FALSE when ProbeTdGuest() is called. It is expected that other packages (like OvmfPkg) will create a version of the library to fully support the ProbeTdGuest().
For Td guest the initial mode on ResetVector is 32bit protected mode. While for Non-Td guest the initial mode is 16bit real mode. Based on this difference a TD flag is written to the Mailbox[0x10] in ResetVector. So that the TdxProbeLib can probe this flag for Td or Non-Td guest. This is a temporary solution to probe Td or Non-Td. When the related TDX CPUID leaf is ready, this library will be refined to invoke CPUID to probe the Td or Non-Td.
Intel Trust Domain Extension (Intel TDX) refers to an Intel technology that extends Virtual Machines Extensions (VMX) and Multi-Key Total Memory Encryption (MKTME) with a new kind of virtual machine guest called a Trust Domain (TD). TdxLib is created with functions to perform the related Tdx operation. It includes functions for: - TdCall : Cause a VM exit to the Intel TDX module - TdVmCall : It is a leaf function 0 for TDCALL - TdVmCallCpuid : Enable the TD guest to request VMM to emulate CPUID - TdAcceptPages : Accept pending private pages - TdExtendRtmr : Extend one of the RTMR registers - TdSharedPageMask: Get the Td guest shared page mask The valid architecture of TdxLib is X64 because Intel TDX only supports X64 architecture.
TDX architecture does not prescribe a specific software convention to perform I/O from the guest TD. The guest TD providers have many choices to provide I/O to the guest. The common I/O models are emulated devices, para-virtualized devices, SRIOV devices and Direct Device assignments. In BaseIoLibIntrinsicTdx Para-Virtualized I/O model is used. It replaces IO/MMIO access with TDCALL(TDVMCALL) to invoke VMM provided IO/MMIO emulation functions.
BaseIoLibIntrinsicTdx support both Td and Non-Td guest, including SEV and TDX.
1. Add PCD definition for TDX layout 2. Update the OvmfPkgX64.fdf to add TdHob
When upstream to edk2 master, this commit should be split into small ones.
This commit should be split into 2 paches later.
TODO: Understand the mechanism
TODO: Add more description
Intel TDX doesn't support TPM. So Tcg2Dxe returns EFI_UNSUPPORTED in Td guest.
HashLib for Tdx guest
In Td guest, Configuration FV need to be copied to FVB. TODO: Add more justification here.
PcdTdxSharedPageMask indicates the GPA Width which is defined in OvmfPkg. But this PCD is used in MdePkg. We can call TdSharedPageMask() to do the same job as PcdTdxSharedPageMask.
Structure definition should be surrounded by #pragma pack(1), otherwise in Release version the structure may be not correct as design.
Some TDX configuration need be measured and extended to Rtmr in SEC phase. For example, the TdHob, CFV, QemuCfg, etc. Then the measurement should be recorded to the TdEventlog in DXE phase.
The PCD of PcdTdxAcceptPageSize is used to control the page accept size in Td guest. The valid value is 0x1000, 0x200000 and 0x40000000, i.e. 4k/2M/1G.
TDX doesn't support eoi intercept because cpu state is protected and the way to inject interrupt into vcpu is only posted interrupt. It implies level trigger interrupt can't be emulated and only edge trigger is supported. So forcibly report edge trigger for all legacy interrupt via interrupt source override entry in MADT. Signed-off-by: Isaku Yamahata <[email protected]>
TDCALL(ACCEPT_PAGE) supports the accept page size of 4k and 2M. To simplify the implementation, the Memory to be accpeted is splitted into 3 parts: ----------------- <-- StartAddress1 (not 2M aligned) | part 1 | Length1 < 2M |---------------| <-- StartAddress2 (2M aligned) | | Length2 = Integer multiples of 2M | part 2 | | | |---------------| <-- StartAddress3 | part 3 | Length3 < 2M |---------------| part 1) will be accepted in 4k and by BSP. part 2) will be accepted in 2M and by BSP/AP. Part 3) will be accepted in 4k and by BSP.
mxu9
force-pushed
the
master
branch
2 times, most recently
from
8979383 to
2ebf5ca
Compare
mxu9
pushed a commit
that referenced
this pull request
Jul 11, 2024
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4541 REF: https://www.rfc-editor.org/rfc/rfc1948.txt REF: https://www.rfc-editor.org/rfc/rfc6528.txt REF: https://www.rfc-editor.org/rfc/rfc9293.txt Bug Overview: PixieFail Bug #8 CVE-2023-45236 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N CWE-200 Exposure of Sensitive Information to an Unauthorized Actor Updates TCP ISN generation to use a cryptographic hash of the connection's identifying parameters and a secret key. This prevents an attacker from guessing the ISN used for some other connection. This is follows the guidance in RFC 1948, RFC 6528, and RFC 9293. RFC: 9293 Section 3.4.1. Initial Sequence Number Selection A TCP implementation MUST use the above type of "clock" for clock- driven selection of initial sequence numbers (MUST-8), and SHOULD generate its initial sequence numbers with the expression: ISN = M + F(localip, localport, remoteip, remoteport, secretkey) where M is the 4 microsecond timer, and F() is a pseudorandom function (PRF) of the connection's identifying parameters ("localip, localport, remoteip, remoteport") and a secret key ("secretkey") (SHLD-1). F() MUST NOT be computable from the outside (MUST-9), or an attacker could still guess at sequence numbers from the ISN used for some other connection. The PRF could be implemented as a cryptographic hash of the concatenation of the TCP connection parameters and some secret data. For discussion of the selection of a specific hash algorithm and management of the secret key data, please see Section 3 of [42]. For each connection there is a send sequence number and a receive sequence number. The initial send sequence number (ISS) is chosen by the data sending TCP peer, and the initial receive sequence number (IRS) is learned during the connection-establishing procedure. For a connection to be established or initialized, the two TCP peers must synchronize on each other's initial sequence numbers. This is done in an exchange of connection-establishing segments carrying a control bit called "SYN" (for synchronize) and the initial sequence numbers. As a shorthand, segments carrying the SYN bit are also called "SYNs". Hence, the solution requires a suitable mechanism for picking an initial sequence number and a slightly involved handshake to exchange the ISNs. Cc: Saloni Kasbekar <[email protected]> Cc: Zachary Clark-williams <[email protected]> Signed-off-by: Doug Flick [MSFT] <[email protected]> Reviewed-by: Saloni Kasbekar <[email protected]>
mxu9
pushed a commit
that referenced
this pull request
Nov 4, 2024
This patch does not impact functionality. It aims to clarify the synchronization flow between the BSP and APs to enhance code readability and understanding: Steps #6 and #11 are the basic synchronization requirements for all cases. Steps #1 is additional requirements if the MmCpuSyncModeTradition mode is selected. Steps #1, #2, #3, #4, #5, #7, #8, #9, and #10 are additional requirements if the system needs to configure the MTRR. Steps #9 and #10 are additional requirements if the system needs to support the mSmmDebugAgentSupport. Signed-off-by: Jiaxin Wu <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Tdvf one binary is required to be upstream to edk2-master branch. Before the upstream, it needs to be integrated with the latest edk2-master code tree and run the full test.
This PR contains the full tdvf features, including the Uefi Secure Boot and Measured boot.