Skip to content
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

Infrastructure for running MPS under pKVM #58

Merged
merged 36 commits into from
Jun 7, 2024
Merged

Conversation

spernsteiner
Copy link
Contributor

@spernsteiner spernsteiner commented May 31, 2024

This branch adds support for running and testing MPS under a pKVM guest. This has two parts:

  • A new vm_runner tool that launches QEMU VMs or other commands based on a configuration file. This is used to automate startup of the host VM, guest VM, and MPS itself.
  • Some changes to MPS to allow the test suite to communicate with the MPS binary over a socket.

Documentation for vm_runner can be found in its README. Instructions for running the MPS test suite against an MPS instance running inside a VM can be found in tests/README.md.

Fixes #35

Checklist before requesting a review

  • I have performed a self-review of my code
  • My code matches the coding standards and I have ran the appropriate linters
  • I included documentation updates for my code
  • I extended the test suite and the tests run by the CI to cover my code
  • I assigned a Milestone to this PR
  • I assigned this PR to a Project
  • I assigned this PR appropriate Labels

@spernsteiner spernsteiner added hardware SUT hardware (real/emulated/simulated) SoW TA2.1.1.A Develop the Open SUT primarily using existing components and specifications. labels May 31, 2024
@spernsteiner spernsteiner added this to the MVP 1 milestone May 31, 2024
@spernsteiner
Copy link
Contributor Author

There are some tests for this, but I haven't updated CI.

  • The vm_runner tests and the MPS-in-pKVM test suite both require full VM images, and we don't currently have a story for how to manage those in CI.
  • There's also an MPS aarch64 build script that would be good to run in CI. However, building MPS for aarch64 requires cryptol, a specific version of Verilator, and an aarch64 toolchain. The HARDENS docker image has the first two, but can't easily install the aarch64 toolchain because it's based on an obsolete non-LTS version of Ubuntu for which repos no longer exist.

@spernsteiner
Copy link
Contributor Author

The CN proofs CI failure looks unrelated to me - this PR doesn't modify any MPS code except posix_main.c, which doesn't have CN specs.

Copy link
Collaborator

@podhrmic podhrmic left a comment

Choose a reason for hiding this comment

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

Very cool work! I am happy to approve as is, and then refactor the MPS makefile in a separate PR.

The next step should be figuring out how to cache / build the disk images in the CI, such that we can test this setup with github actions.

EDIT: one thing to change would to be to run sed 's/RTS/MPS/g' on the codebase

@@ -0,0 +1,10 @@
#!/bin/bash
Copy link
Collaborator

Choose a reason for hiding this comment

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

Lets refactor the makefile in lieu of this script, as mentioned in #49

0x1 [[0x33fe, 0x41d3], [0x1842, 0xce9e], [0xa731, 0x6312], [0xbabb, 0xaa2e]] [[0xd683, 0x8077, 0x2d0d], [0x0c50, 0xa354, 0xb23e], [0xc806, 0xa680, 0x25d1], [0x965f, 0xba1f, 0x7f91]] 0x1 0x3
0x3 [[0x8f55, 0xa308], [0x8910, 0xc8f3], [0xed53, 0xa96e], [0x6b72, 0xb094]] [[0x8024, 0x2af2, 0x8a77], [0xd392, 0x6b95, 0xc5e4], [0xd167, 0x78eb, 0xae62], [0xd786, 0x2183, 0xeda3]] 0x3 0x3
0x1 [[0x03a4, 0x7579], [0xfef5, 0x193e], [0x8381, 0xbdd3], [0x649d, 0xae79]] [[0xc42c, 0xd33a, 0x2cc9], [0xa687, 0x657b, 0xbf3b], [0x48d2, 0xc9b1, 0x2b48], [0xb123, 0x8814, 0x497c]] 0x2 0x3
0x1 [[0x753c,
Copy link
Collaborator

Choose a reason for hiding this comment

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

Given these are re-generated every time you build the MPS, maybe we should just add them to .gitignore?

format = "raw"
path = "build_helper.sh"

[process.9p.vm_runner]
Copy link
Collaborator

Choose a reason for hiding this comment

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

What does 9p stand for?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

QEMU's filesystem passthrough uses the Plan 9 remote filesystem protocol, which is named "9P". The name 9p shows up in various places: QEMU uses -device virtio-9p-pci,options... to configure the passthrough, and inside the guest you mount it via mount -t 9p ....

command. In the future, this can be extended to check for a specific
signature before mounting the device.

A typical boot process works like this:
Copy link
Collaborator

Choose a reason for hiding this comment

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

Very cool re-use of vm_runner!

vm_runner/target/"$target"/release/opensut_boot \
/opt/opensut/bin

# TODO: install systemd unit and configure to run on startup
Copy link
Collaborator

Choose a reason for hiding this comment

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

How important is this TODO?

@spernsteiner
Copy link
Contributor Author

one thing to change would to be to run sed 's/RTS/MPS/g' on the codebase

How thorough should that change be? If the goal is to replace literally all mentions of "RTS" including e.g. renaming RTS.cry to MPS.cry, that's going to be quite noisy and will create a lot of conflicts, so IMO it would be better done as a standalone PR in coordination with @peterohanley.

For the current PR, I used the "RTS" name within the MPS code for consistency with existing code that still uses "RTS", and I used "MPS" in the vm_runner test scripts, which are mostly independent of the MPS codebase.

@podhrmic
Copy link
Collaborator

podhrmic commented Jun 5, 2024

IMO it would be better done as a standalone PR

That works for me, lets do that in a new PR

@podhrmic
Copy link
Collaborator

podhrmic commented Jun 5, 2024

@spernsteiner feel free to merge as is

spernsteiner and others added 18 commits June 7, 2024 11:39
Previously, while `runner.py` was waiting for a response from the RTS,
it would send an update-display (`D`) command every second.  In the
nested-VM setup, updating the display is fairly expensive due to the I/O
involved.  If the MPS got behind for any reason, in order to catch up,
it would need to process not only the pending command but all the
update-display commands that were sent while the test runner was
waiting.  Sending an update-display command every second thus severely
exacerbated the slow performance of the nested-VM setup.

This commit changes `runner.py` to send the update-display command every
10 seconds instead of every second.  The test suite now behaves more
reliably in the nested-VM setup.
Builds the VM runner in the CI, some small CI improvements

---------

Co-authored-by: spernsteiner <[email protected]>
@spernsteiner spernsteiner merged commit 155c3a4 into main Jun 7, 2024
5 checks passed
@spernsteiner spernsteiner deleted the 35-mps-in-pkvm branch June 7, 2024 21:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hardware SUT hardware (real/emulated/simulated) SoW TA2.1.1.A Develop the Open SUT primarily using existing components and specifications.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[FEATURE] Instantiate and run MPS in pKVM
2 participants