(&self, machine: &Machine)
| 297 | } |
| 298 | |
| 299 | pub fn rtmr0_log(&self, machine: &Machine) -> Result<(RtmrLog, Tables)> { |
| 300 | let td_hob_hash = self.measure_td_hob(machine.memory_size)?; |
| 301 | let cfv_image_hash = hex!("344BC51C980BA621AAA00DA3ED7436F7D6E549197DFE699515DFA2C6583D95E6412AF21C097D473155875FFD561D6790"); |
| 302 | |
| 303 | let tables = machine.build_tables()?; |
| 304 | let acpi_tables_hash = measure_sha384(&tables.tables); |
| 305 | let acpi_rsdp_hash = measure_sha384(&tables.rsdp); |
| 306 | let acpi_loader_hash = measure_sha384(&tables.loader); |
| 307 | |
| 308 | let secureboot_hash = |
| 309 | measure_tdx_efi_variable("8BE4DF61-93CA-11D2-AA0D-00E098032B8C", "SecureBoot")?; |
| 310 | let pk_hash = measure_tdx_efi_variable("8BE4DF61-93CA-11D2-AA0D-00E098032B8C", "PK")?; |
| 311 | let kek_hash = measure_tdx_efi_variable("8BE4DF61-93CA-11D2-AA0D-00E098032B8C", "KEK")?; |
| 312 | let db_hash = measure_tdx_efi_variable("D719B2CB-3D3A-4596-A3BC-DAD00E67656F", "db")?; |
| 313 | let dbx_hash = measure_tdx_efi_variable("D719B2CB-3D3A-4596-A3BC-DAD00E67656F", "dbx")?; |
| 314 | let separator_hash = measure_sha384(&[0x00, 0x00, 0x00, 0x00]); |
| 315 | |
| 316 | let log = match machine.ovmf_variant { |
| 317 | OvmfVariant::Pre202505 => { |
| 318 | // Boot0000 = OVMF UiApp (fixed digest for pre-202505 firmware). |
| 319 | let boot000_hash = hex!("23ADA07F5261F12F34A0BD8E46760962D6B4D576A416F1FEA1C64BC656B1D28EACF7047AE6E967C58FD2A98BFA74C298"); |
| 320 | vec![ |
| 321 | td_hob_hash, |
| 322 | cfv_image_hash.to_vec(), |
| 323 | secureboot_hash, |
| 324 | pk_hash, |
| 325 | kek_hash, |
| 326 | db_hash, |
| 327 | dbx_hash, |
| 328 | separator_hash, |
| 329 | acpi_loader_hash, |
| 330 | acpi_rsdp_hash, |
| 331 | acpi_tables_hash, |
| 332 | measure_sha384(&[0x00, 0x00]), // BootOrder (raw 2 bytes in legacy OVMF) |
| 333 | boot000_hash.to_vec(), |
| 334 | ] |
| 335 | } |
| 336 | OvmfVariant::Stable202505 => { |
| 337 | // edk2-stable202505 emits 17 RTMR[0] events instead of 13. The |
| 338 | // boot-option set is fully derivable from OVMF-internal |
| 339 | // constants (FV and file GUIDs, descriptions, attributes); the |
| 340 | // remaining two — the bootorder fw_cfg measurement and |
| 341 | // EV_EFI_VARIABLE_AUTHORITY — stay as captured digests because |
| 342 | // their content depends on QEMU's emitted device list and on |
| 343 | // OVMF-internal logic that's not worth shadowing here. |
| 344 | |
| 345 | // fw_cfg `BootMenu` is a u16; dstack doesn't pass `-boot |
| 346 | // menu=on`, so it defaults to 0x0000. |
| 347 | let bootmenu_fwcfg_hash = measure_sha384(&[0x00, 0x00]); |
| 348 | |
| 349 | // fw_cfg `bootorder` is the NUL-separated list of QEMU device |
| 350 | // paths whose backing devices have `bootindex` set. For |
| 351 | // `-kernel` boot, QEMU (hw/i386/x86.c::x86_load_linux) injects |
| 352 | // a single option ROM with `bootindex = 0`: |
| 353 | // * `linuxboot_dma.bin` if fw_cfg DMA is enabled (q35 default) |
| 354 | // * `linuxboot.bin` otherwise |
| 355 | // dstack-vmm always uses q35 → DMA is on → the bootorder file |
| 356 | // contains just the single path below (31 bytes, trailing |
no test coverage detected