Skip to content

petri: Disable secure boot by default for HyperV tests and introduce specific secureboot tests #1386

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 10 commits into
base: main
Choose a base branch
from

Conversation

maheeraeron
Copy link

@maheeraeron maheeraeron commented May 20, 2025

This PR focuses on:

  • Disabling secure boot for HyperV VMs by default. This matches the default configuration of OpenVMM tests
  • Introduce a with_secure_boot function that injects a secure boot template per OS flavor
  • Adds a specific multiarch secure_boot test

@maheeraeron maheeraeron changed the title [WIP] petri: OpenVMM tests have secure boot by default [WIP] petri: Enable secure boot by default for OpenVMM tests May 20, 2025
@maheeraeron maheeraeron marked this pull request as ready for review May 22, 2025 20:32
@maheeraeron maheeraeron requested a review from a team as a code owner May 22, 2025 20:32
@smalis-msft
Copy link
Contributor

Think the title and description need updating

@@ -67,6 +67,29 @@ async fn boot(config: Box<dyn PetriVmConfig>) -> anyhow::Result<()> {
Ok(())
}

/// Basic boot test with secure boot enabled.
#[vmm_test(
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we have other tests with secure boot that can be removed/folded into this?

Copy link
Author

Choose a reason for hiding this comment

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

good point, ill have to look around for these

Copy link
Author

Choose a reason for hiding this comment

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

as far as I know, looks like we don't have any other tests with secure boot explicitly?

I did notice guest_test_uefi multiarch test has with_windows_secure_boot_template().

My new with_secure_boot() could be used instead? But I'm not sure if, based on the OsFlavor for guest_test_uefi_x64 or guest_test_uefi_aarch64 what the correct secure boot template would be in this case-- must it be the windows template?

Copy link
Member

Choose a reason for hiding this comment

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

Should we add a test that verifies Linux fails to boot with the Windows secure boot template?

Copy link
Author

Choose a reason for hiding this comment

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

Yes, we should-- I'll add these negative tests next

@maheeraeron
Copy link
Author

Think the title and description need updating

Oh, I kept the title for now since this might still be a work in progress. I made this PR away from draft so that I can test the CI runs

@smalis-msft
Copy link
Contributor

Well it's still a WIP, but the change we're actually making is the opposite of the current title

@maheeraeron maheeraeron changed the title [WIP] petri: Enable secure boot by default for OpenVMM tests petri: Disable secure boot by default for HyperV tests and introduce specific secureboot tests May 22, 2025
@maheeraeron maheeraeron requested a review from tjones60 May 22, 2025 21:13
async fn secure_boot(config: Box<dyn PetriVmConfig>) -> anyhow::Result<()> {
let mut vm = config.with_secure_boot().run_without_agent().await?;
vm.wait_for_successful_boot_event().await?;
assert_eq!(vm.wait_for_teardown().await?, HaltReason::PowerOff);
Copy link
Contributor

Choose a reason for hiding this comment

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

What is telling these vms to shut down? You probably need to add a call to enlightened_shutdown

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants