feat(opentmk): opentmk framework with first testcase #1210
Conversation
feat: opentmk init feat: opentmk init feat: opentmk init feat: opentmk init feat: opentmk init feat: opentmk init feat: init 1 feat: init 2 feat: init 1 feat: opentmk feat: opentmk init 3 feat: opentmk init 4 feat: opentmk init 4
mayank-microsoft
force-pushed
the
target-opentmk
branch
from
c3f74c0 to
056bf7d
Compare
| // Copyright (c) Microsoft Corporation. | ||
| // Licensed under the MIT License. | ||
|
|
||
| #![expect(unsafe_code)] |
There was a problem hiding this comment.
please annotate why we have unsafe in each file we allow it
There was a problem hiding this comment.
I've fixed it as a part of lint fixes. maybe it's an older commit?
smalis-msft
added
the
release-ci-required
| // implement clone for Sender | ||
| impl<T> Clone for Sender<T> { | ||
| fn clone(&self) -> Self { | ||
| self.inner.senders.fetch_add(1, Ordering::SeqCst); |
There was a problem hiding this comment.
Do all these orderings need to be SeqCst? I think we could get away with Relaxed
There was a problem hiding this comment.
Consider adding some unit tests based on the loom crate to test that out (see atomic_ringbuf for examples)
| pub mod hv_memory_protect_write; | ||
| pub mod hv_processor; | ||
| #[cfg(nightly)] | ||
| #[cfg(target_arch = "x86_64")] // xtask-fmt allow-target-arch sys-crate |
There was a problem hiding this comment.
It may be worth adding opentmk as one of the exceptions to the xtask fmt requirement here. If you look at the source of it there's a hardcoded list of exception crates. Then you won't need the comments everywhere.
There was a problem hiding this comment.
I think there's a lot of follow-up work to do here, and a lot of open questions and comments still, but I'd like to get this merged so we can begin working on integrating these tests into CI while we also work on iterating on the still open questions. I think we can continue to use this PR as a place for discussion on this code after it gets merged, and file followup tasks as appropriate.
|
The test failure was intermittent. It passes on rerun. |
|
Yeah, we're working on those. |
|
Some changes for serde in some crates triggered an approval request from microsoft/openvmm-vtl2-settings-approvers. We will need an approval from them as well. |
|
I'll get a bypass. |
smalis-msft
removed
the
release-ci-required
| static COMMON_HANDLER_MUTEX: Mutex<()> = Mutex::new(()); | ||
|
|
||
| #[unsafe(no_mangle)] | ||
| #[no_mangle] |
There was a problem hiding this comment.
isn't no_mangle an unsafe attribute?
There was a problem hiding this comment.
yeah, read up more about it now. with edition 2024, it should be marked unsafe.
6 participants
OpenTMK framework for testing guest-based scenarios with a HCL.
The above diagram illustrates relation between abstract modules.
UEFI Executor Design Decisions:
a. The allocator today switches between UEFI Runtime Allocator and LockedHeapAllocator.
b. The decision to switch between the two allocator is to allow more control over which sections of the memory map is for the heap, this is helpful so that we know we are using a memory section which will not be used by UEFI runtime services after exit boot services. Using the UEFI allocator is important so that we can allocate any object before we call main. If a panic occurs before main, we need to allocate strings in the Panic handler. UEFI allocator can’t be used after exit boot services.
a. The panic handler today logs the panic info as string using the logger module and then loops. The test driver is informed of the panic and the test driver terminates the VM.
b. Improvement planned to shutdown the VM.
c. Today we use our own interrupt handler, using ud2 causes an fainterrupt but that does not cause a triple fault.
a. In scope for a task being tracked
Platform Design Decisions
ARM64 implementation is a placeholder and out of scope, the work is tacked by . The work is mostly around implementing Interrupt handling, VP bring up (just the implementation for default context), TPM specific changes and end-to-end testing.
a. Platform/hyperv/arch houses all the modules which require a platform specific implementation.
b. VTL calls/return need to be handled carefully, as many of the general-purpose register values are not preserved across VTL switch. The requires us to push all the values to stack before a switch and restore back when we return. We also need to handle this carefully when VTL switch happens because of secure intercepts.
c. Tests which require for secure intercepts to happen must use macro: create_function_with_restore to isolate the violating function.
a. Today we hardcode the value for how many VPs are present. Earlier I had tried constructing the heuristics to read the CPU topology from CPU-ID but they returned differently for Intel and AMD. I intend to use ACPI table to construct this information/take the values as input in test configuration in the next set of improvements.
b. The AP bring up in start_on_vp takes care of everything related to enabling the VTLs and scheduling the VpExecutor object. Working on changing the name as suggested in the PR. This change is mostly for simplicity, for complex tests where the heuristic has to be tested for boundary testing I recommend authoring a test with direct dependency on platform and calling the hypercall interface (HvCall is a pub field in HvTestCtx) without using the generic interface of the platform traits.
a. We depend on the x86_64 crate to provide structure and helpers, along with x86-interrupt ABI.
b. Since custom ABI is a nightly feature, we keep the feature behind the nightly feature flag.
c. We are tracking a task to move to naked functions as a part of the improvements.
a. We currently use a duplicated module of protocol module from tpm crate, we can’t depend on tpm crate since it links to openssl which we want to avoid, apart from that we we can’t readily move the protocol because of some coupling between the protocol module and the errors struct from tpm ref crate. I’ll work on decoupling the modules once we are ok with other changes in this PR. I feel it may be better to take the decoupling in a follow up PR, since there are a lot of changes in this PR, isolating the PR to not touch TPM implementation will help reduce risk of breaking anything in the TPM crate.
a. We have a separate implementation which is building on top of minimal_rt, the major reasons are to facilitate multiple process writing logs at the same time (by implementing locks) and to write to COM1/COM2 instead of the default COM3.