Skip to content

Conversation

@hgarvison
Copy link

Add tool to VmgsTool to read the IGVMfile from a DLL (passed in as a data file) and write it to VMGS FileId 8 (GUEST_FIRMWARE). To do this pass one of three resource codes (nonconfidential, snp, tdx) into the cmdline tool:

vmgstool.exe copy-igvmfile --filepath --keypath --datapath --resource-code

@hgarvison hgarvison requested a review from a team as a code owner December 15, 2025 20:24
Copilot AI review requested due to automatic review settings December 15, 2025 20:24
@hgarvison hgarvison requested a review from a team as a code owner December 15, 2025 20:24
@github-actions github-actions bot added Guide unsafe Related to unsafe code labels Dec 15, 2025
@github-actions
Copy link

⚠️ Unsafe Code Detected

This PR modifies files containing unsafe Rust code. Extra scrutiny is required during review.

For more on why we check whole files, instead of just diffs, check out the Rustonomicon

Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR adds functionality to vmgstool for reading IGVM firmware files from Windows DLLs and writing them to VMGS file ID 8 (GUEST_FIRMWARE). The implementation uses Windows API calls to extract resources from DLLs and supports multiple resource codes (nonconfidential, snp, snp_no_hcl, tdx, tdx_no_hcl) for different VM configurations.

Key changes:

  • New copy-igvmfile command that extracts IGVM files from DLLs using Windows resource APIs
  • Support for encrypted and unencrypted VMGS files when writing IGVM data
  • Platform-specific implementation for Windows x86_64 only

Reviewed changes

Copilot reviewed 4 out of 5 changed files in this pull request and generated 7 comments.

File Description
vm/vmgs/vmgstool/src/main.rs Implements the copy-igvmfile command with Windows API resource loading, adds error handling, command-line parsing, and test cases
vm/vmgs/vmgstool/build.rs Adds rustc-check-cfg directive for guest_arch configuration
vm/vmgs/vmgstool/Cargo.toml Adds winapi dependency with required Windows API features
Guide/src/dev_guide/dev_tools/vmgstool.md Documents the new copy-igvmfile command usage

@github-actions
Copy link

@github-actions
Copy link

GspUnknown,
#[error("VMGS file is using an unknown encryption algorithm")]
EncryptionUnknown,
#[cfg(all(windows, guest_arch = "x86_64"))]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What makes any of this x86_64 specific?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The file this command is being used to parse (vmfirmwarehcl.dll) doesn't exist in ARM.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the code is capable of running on ARM we should let it, even if it'll never be used. cfgs like this should only be used when the code can't run on a given platform due to actual hardware differences.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sounds good, thanks for the feedback. I'll take out the cfgs and gate the couple of tests that try to access vmfirmwarehcl.dll, so they don't fail in the ARM tests

/// Tries to read the given resource from a resource dll. If the given data
/// buffer is not a valid PE file this function returns Ok(None). If it is a PE
/// file, but the given resource can not be found or loaded this function
/// returns Err(...). On success the return value contains the starting offset
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should probably change the return types to a proper enum with variants like 'NotPeFile, NotFound, Ok(u64, usize)' or something, but that would break most of the ? i think, so feel free to just add a TODO comment instead.

Copy link
Contributor

@smalis-msft smalis-msft left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Non-vmgs portions look good to me, I'll let @tjones60 do the final signoff

if cfg!(feature = "encryption_ossl") || cfg!(feature = "encryption_win") {
println!("cargo:rustc-cfg=with_encryption")
}
build_rs_guest_arch::emit_guest_arch()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is no longer needed now?

Copy link

@SethHollandsworth SethHollandsworth Jan 14, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We still use guest_arch so the ARM tests pass while looking for a Windows & x86 specific file: https://github.com/microsoft/openvmm/pull/2566/changes#diff-5a13f8ed20df6cbedce19fb03d00c9d139cf36b9f16de65e6d6691dfa8dbf5a1R1447

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure how I feel about a test that's relying on a system file like that... @tjones60 thoughts?

/// Copy the IGVM file from a dll into file ID 8 of the VMGS file.
///
/// The proper key file must be specified to write encrypted data.
#[cfg(windows)]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again why cfg? One of the benefits of using object as a parser is that it can do so on any platform.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed, we were using Windows-specific paths but I made it use PathBufs instead. Still learning rust 😅

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Guide unsafe Related to unsafe code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants