Rust based Shim-Firmware for confidential container
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 542 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/61469 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
FirmwareIntelCategory of beingClient (computing)Local GroupSoftwareSoftware developerInformation securityCodeVirtual realityKernel (computing)HypercubePoint cloudVector spaceFingerprintInterface (computing)Interior (topology)BootingCommunications protocolMemory managementRead-only memoryData managementData structureMeasurementRun time (program lifecycle phase)Integrated development environmentInformationBefehlsprozessorPhase transitionBootingModule (mathematics)BuildingChainComa BerenicesComputer wormTable (information)Shared memoryInformationRule of inferenceLattice (order)Integrated development environmentBootingService (economics)Fluid staticsFirmwareVirtualizationSemiconductor memoryGreatest elementChainDirection (geometry)Denial-of-service attackModule (mathematics)Virtual machineSoftware developerHydraulic jumpStructural loadBefehlsprozessorNeuroinformatikFigurate numberPrincipal idealParameter (computer programming)Point cloudProgramming languageVirtual memoryCASE <Informatik>Kernel (computing)MeasurementConnectivity (graph theory)Pairwise comparisonoutputAttribute grammarDependent and independent variablesPhysical systemData structureDataflowINTEGRALVector spaceComputer wormSensitivity analysisBootingWorkloadExtension (kinesiology)State of matterOpen setPoint (geometry)Computer hardwareCoprocessorSystem on a chipWindowCuboidMobile appHill differential equationStatisticsForcing (mathematics)Right angleOperational amplifierSpacetimeCalculationComputerAuthorizationSource codeSoftwareContent (media)Beat (acoustics)CAN busPerspective (visual)40 (number)Software testingMusical ensembleTable (information)Nichtlineares GleichungssystemType theoryMessage passingComputer animation
06:35
Default (computer science)Computer-generated imageryService (economics)Run time (program lifecycle phase)Device driverBootingTable (information)Daylight saving timeFluid staticsFormal languageAbstract state machinesRead-only memoryComputer wormHydraulic jumpStructural loadInformationMeasurementParsingHuman migrationCore dumpBootingCommunications protocolDirected setKernel (computing)Coma BerenicesEvent horizonInformationLatent heatSemiconductor memoryTable (information)MereologyDigitizingBootstrap aggregatingIntegrated development environmentCoprocessorPairwise comparisonGame controllerMeasurementConnectivity (graph theory)Event horizonHash functionInformation securityCASE <Informatik>VirtualizationDataflowVirtual memoryTracing (software)Assembly languageFormal verificationService (economics)Computer architectureHuman migrationElectronic signatureHeat transferCore dumpBootingKernel (computing)Level (video gaming)Communications protocolRun time (program lifecycle phase)Computer wormNeuroinformatikBefehlsprozessorFormal languageDifferent (Kate Ryan album)Normal (geometry)FirmwareoutputStructural loadVector spaceArithmetic progressionCodeFunctional (mathematics)Fluid staticsMedical imagingSubject indexingCartesian coordinate systemOrder (biology)Interface (computing)Parameter (computer programming)Group actionData managementWorkstation <Musikinstrument>Execution unitCubeRight angleView (database)Adventure gameExtension (kinesiology)Process (computing)Physical lawMessage passingUsabilityMultiplication signData structureState of matterVideo game40 (number)Projective planeMultilaterationBridging (networking)Doubling the cubeComputer animation
12:12
MeasurementFirmwareBootingBlock (periodic table)Mobile appComputer wormFormal verificationEuclidean vectorRevision controlComputer-generated imageryHash functionDigital signalIntelKontrollflussWeb pageCodeReading (process)Control flowAcoustic shadowStack (abstract data type)Branch (computer science)Video trackingCompilerSoftware testingFuzzy logicExecution unitMeasurementMappingInformationFormal verificationCartesian coordinate systemMetadataComputer wormKernel (computing)Unit testingComputer fileInformation securityControl flowBootingAcoustic shadowPublic-key cryptographyParameter (computer programming)Branch (computer science)Buffer overflowHash functionTrailVulnerability (computing)CodeDifferent (Kate Ryan album)Web pageExploit (computer security)Latent heatIntegrated development environmentCalculationStack (abstract data type)Remote procedure callFirmwareSoftware testingProjective planeFuzzy logicFluid staticsSet (mathematics)Event horizonTraffic reportingMaxima and minimaRollback (data management)Decision theoryMedical imaging1 (number)Electronic signatureArithmetic progressionConnectivity (graph theory)Mathematical analysisGame controllerOrder (biology)Heat transferRevision controlSheaf (mathematics)Shape (magazine)Optical disc driveDesign by contractState of matterCuboidOffice suiteChannel capacityLevel (video gaming)NumberNatural numberPhysical lawMusical ensembleCivil engineeringFile formatChemical equationGastropod shellRoboticsComputer animation
17:49
IntelVirtual realityTime domainFirmwareExtension (kinesiology)Computer animationProgram flowchart
Transcript: English(auto-generated)
00:05
Hello everyone, today I am happy to join Confidential Computing Dev Room to share the information Rust-based shim firmware for confidential container. I am Jiawen Yao, Principal Engineer in Intel. I have been engaged as a firmware developer for about 20 years, working on UEFI, TCG,
00:26
DMTF, Industrial Standard Working Group. I am an architect for the TDEX virtual firmware. Here is today's agenda. First, I will introduce some background of the firmware, why we need the shim firmware and the TD shim internals.
00:45
Today, the industrial is adding hardware-based confidential computing support, for example AMD SEV or Intel TDEX. This figure demonstrates the concept of confidential computing. A hypervisor VMM is on the bottom.
01:01
On the left-hand side, the red box shows the legacy VMs. This is the traditional VM hypervisor environment. The hypervisor has the highest privilege, it can access or modify the VM environment. On the right-hand side, the green box is the confidential computing environment,
01:21
we call TEE trusted execution environment. Like a virtual machine, it includes the virtual firmware, guest OS and user APP. The VMM on the bottom is untrusted with half of our hardware SoC such as TDEX or SEV.
01:40
The TEE is isolated from the VMM and other TEEs. Inside the TEE, the memory and CPU state confidentiality and integrity is provided to keep the sensitive IP or workload data secure from the most software-based tech.
02:01
Since the VMM is still the owner of the whole system resource such as memory and CPU, also the VMM manages the TEE launch and teardown, so the denial of service tech is out of scope. In a traditional VM hypervisor environment, we need a virtual firmware to provide the services to the guest OS.
02:23
For example, the EDK2-OVMF, the open virtual machine firmware, provides the UEFI services in the virtual firmware. This is also true for the TEE environment. For example, we need to modify the OVMF to add the TEE support. The TEE virtual firmware owns its first instruction of the TEE, which is a reset vector at OS.
02:47
Similar to the traditional virtual firmware, the TEE virtual firmware loads the guest OS loader and jumps to the OS loader. The TEE virtual firmware enables a trusted boot capability to rebuild the chain of trust from the hardware to the TEE OS.
03:05
Here, we list the existing virtual firmware solution as an example. The CBIOS is a legacy 16-bit BIOS solution. It is used to boot the legacy guest OS, such as Windows XP or non-UEFI Linux.
03:23
Currently, the most widely used EFI solution is OVMF, the open virtual machine firmware. Zen and KVM are using OVMF to boot the guest UEFI OS, UEFI Linux. The Cloud Hypervisor firmware is used by the Cloud Hypervisor as a lightweight solution.
03:43
It does not have UEFI services. The TEE hardware solution may have special requirements for the TEE virtual firmware. Take TDX as an example. The entry point must be 32-bit. It needs a special module processor wake-up structure for the guest OS.
04:03
The TEE needs explicit accept the assigned memory for usage. The DMA for the virtual device needs a shared private memory attribute switch. The TEE virtual firmware must support the measurement extension to the nested component to build the chain of trust for the TEE.
04:22
To meet those special requirements, the UEFI solution OVMF needs TDX support and ACV support. We call it TDVF, which stands for the TDX virtual firmware. The TD-SHIM is the guest firmware solution to replace the Cloud Hypervisor firmware to support the confidential container use case.
04:49
TD-SHIM is a lightweight virtual firmware for a confidential container environment. It is written in Rust program language. Currently, it supports Intel TDX.
05:01
It is located in the confidential container community. All development work is open-sourced. We have three release tags now. The responsibility of the TD-SHIM is to own the first instruction, or reset vector, of a TD. It provides the required boot information, such as memory map virtual CPU information,
05:23
to the next phase, which we call the payload. The payload could be the OS kernel or a bare-metal execution environment for the service TD. The TD-SHIM needs to build the chain of trust from the Intel TDX module to the payload.
05:42
Here is the boot flow comparison between the TD-SHIM and the TDVF. The right-hand side is a TDVF-based solution. The VMM passes TD-HOP to the TDVF as input parameter. It includes the memory information. The TDVF builds the UEFI memory map, reads the UEFI services and ACPR tables,
06:07
then loads and launches the UEFI OS loader and the UEFI OS. The left-hand side is the TD-SHIM. VMM passes the TD-HOP to the TD-SHIM, same as the TDVF.
06:21
The TD-SHIM builds the E820 memory map and creates a static ACPR table, then loads and jumps to the Linux guest kernel directly. The OS loader in the middle can be skipped. Here is the comparison between TD-SHIM and the TDVF features.
06:41
From a use case perspective, TDVF is for the confidential VM or the rich service TD environment, while TD-SHIM can be used for the confidential container and bare metal small service TD. The TDVF is written in C, while the TD-SHIM is written in Rust without STD support.
07:06
The TD-SHIM does not provide any UEFI services, OS runtime or device drivers, which is different from TDVF. In order to support multiple processors, the TD-SHIM still provides the static ACPR table,
07:21
such as MADT and P-WAKUP structure, which is the same as TDVF. The virtual device RFQ information is in DSTT in the TDVF case, but DSTT is not required in the TD-SHIM use case. As such, the virtual RFQ information can be parsed as part of boot parameter in the TD-SHIM.
07:48
For memory map, the TD-SHIM uses E820 table to provide the TE memory map information, while the TDVF uses EFI memory map. The transit boot support is same between TD-SHIM and TDVF.
08:04
Both solutions need to extend the next component to the RTMR and build the event log for the measurement. secure boot is also supported in both TD-SHIM and TDVF. The difference is that TDVF uses standard and UEFI secure boot,
08:22
while the TD-SHIM uses a customized secure boot solution. We will introduce that later. The size of the image is different. By default, the TDVF OBMF is 4 MB. It keeps increasing recently. But the TD-SHIM without secure boot only has 140 KB.
08:44
Even with secure boot, it is only 270 KB. That's why we call it as a SHIM firmware. Now we can introduce more TD-SHIM internal information. In TD-SHIM project, we defined the TD-SHIM specification
09:03
to standardize the interface between VMM and TD-SHIM, and the interface between TD-SHIM and the payload. The TD-SHIM itself includes a reset vector. The reset vector is written in assembly language. The code runs by the bootstrap processor BSP,
09:24
whose virtual CPU index is always zero. The BSP will park other application processor APs and switch to x64 long mode, set stack for the RUST code, then jump to the SHIM main function.
09:43
The SHIM main function is written in the RUST language. It will pass the TD-HOB input from the VMM. It measures the TD-HOB, gets the memory map information, and builds the memory H20 table.
10:00
Then it accepts the memory and loads the payload and jumps to the payload. People may use different payloads in a different use case. For example, in a normal confidential container use case, the TD-SHIM can boot a Linux kernel directly based upon the Linux boot protocol.
10:23
A service TD use case, the TD-SHIM can boot through a migration TD core to make it a full migration TD. The migration TD is a service TD used in TDX 1.5 to support the guest OS live migration. Now we will introduce two important features in the TD-SHIM,
10:46
TRUSTBOOT and SECUREBOOT. They are all documented in the TD-SHIM specifications. First, let's take a look at TRUSTBOOT. In the TRUSTBOOT flow, one component must measure the next level component
11:02
before transfer control to it. Later, a remote verifier can get the measurement data with digital signature signed by the trusted entity and verify the TD environment launch is expected. This flow is called remote hesitation.
11:20
The TD-SHIM supports the boot flow by extending the measurement to the TD runtime measurement register. The TD measured component includes the TD-OB payload and the boot parameter, etc. At same time, TD-SHIM provides a confidential computing event log called CCEL
11:41
to the verifier. The event log may be used to reproduce the digest value recorded in RTMR. As such, the verifier can check each individual component described in the event log. The final attestation can be based on the hash of the measurement register
12:02
or the hash of the event log. The TDX architecture provides one MR-ED and four RTMR measurement registers to map the TPM PCR-based measurement.
12:21
MR-TD1 maps the PCR0 as a firmware boot code, which is the TD-SHIM itself. The RTMR0 maps the PCR1 and the PCR7 as a firmware configuration, such as TD-HOB for the VMM or a secure boot policy. RTMR1 maps the PCR2 to PCR6
12:42
as the OS or payload information. The RTMR2 maps the PCR8 to 15 as application information. Different from trans-boots, the secure boot requires one component
13:02
to verify the digital signature of the next-level component before transfer control to it. In order to support such verification, the TD-SHIM needs provision a non-good public key and the minimum secure version number, which is called SVN.
13:22
The payload itself should include the image, digital signature, as well as the SVN value. The secure boot in a TD-SHIM includes two-step verification. In step 1, the TD-SHIM needs to verify its public key matches the public key hash
13:41
in the TD-SHIM image. Then the TD-SHIM needs to verify the digital signature for the payload according to the public key. The digital signature needs to cover both the payload image and the SVN value to prevent the SVN modification. In step 2, the TD-SHIM needs to verify the SVN in the payload
14:02
to ensure it's equal to or bigger than the minimum SVN provisioned in the TD-SHIM image. That is to prevent the payload rollback attack. If the secure boot with SVN is enabled, the payload remote attestation can be used in different verification policy.
14:21
The verification can be based on the SVN, not the image hash. This can be achieved without secure boot because there is no other secure way to allow the payload to pass the SVN information to the TD-SHIM. Without secure boot, the SVN value can be
14:41
tempered by the adversary without being noticed. The measurement with secure boot is almost the same as the one without secure boot. The only difference is that the SVN value of the payload is extended to the RTMR1 as a specific entry.
15:01
As such, the verifier can check the specific SVN entry in the event log. The policy could be I require the TD payload bigger than SVN4. It could be any SVN with SVN5 or SVN6, etc.
15:21
To follow the secure best practice, the TD-SHIM enables the protection such as data execution protection. It marks the code page to be read-only and the data page to be non-executable. It is useful to break the exploitation. Even if the environment is compromised
15:42
such as buffer overflow or stack overflow, the attacker cannot inject the code. We are also trying to enable the control flow guard, CET, such as shadow stack and indirect branch tracking. That is still a work in progress and that work depends on the rest compiler.
16:06
The decision project provides a set of tools. For example, the TE-INFO hash tool allows you to calculate the MRTD-based TE-INFO hash value. As such, you can predict the value in the TD report.
16:20
Payload reference calculator can be used to calculate the TD payload reference value by a big image, a busy image, and the kernel parameter. Metadata checker tool accept the TD-SHIM files as an input and extract the TDX metadata and verify if the metadata is valid,
16:40
then dump the metadata. Finally, we enable the set of tests for the TD-SHIM project. For example, the fuzzing test with AFL fuzz and cargo fuzz, which are two popular ones in the Rust fuzzing. We enable the cargo clipping
17:02
and run the Rudra, Bristol, MR, AI, static analysis tools and fix the reported issues there. Unfortunately, we noticed that some tools cannot work with the latest REST compiler, such as Rudra. cargo-deny is integrated in CI
17:21
to ensure that the great TD-SHIM rely on does not have any known secure vulnerabilities. Beyond that, we also run the unit test and collect the coverage as well to ensure the quality of the project. Based on that, that's all for the TD-SHIM introduction
17:43
and thank you for your attention. Please let me know if there are any questions for that.