Why can stage2 trust the VMM's addresses provided here?

https://github.com/coconut-svsm/svsm/blob/b8042679f07d24dc0a6df53cf73b278eb545a8fd/src/fw_cfg.rs#L123-L132

AFAICT the data read here is not attested or verified and the VMM can respond with anything it wants.

Previously the C-bit position was requested from the hypervisor by executing a SEV Information request via the GHCB MSR protocol. This allows a malicous host to feed us an incorrect value. Instead the C-bit position should be extracted from the CPUID page.

Add a new generic error type, SvsmError. This type can be expanded over time with additional carried information or new variants to represent different error conditions.

In general, internally each subsystem may have its own internal error type (e.g. GhcbError), but must return in its public interface(s) an SvsmError, which may contain this internal (but not private) error type with additional details (e.g. SvsmError::Ghcb).

For guest requests, we define a way to translate these general errors to error codes (SvsmError -> SvsmReqError) via the From trait.

Unfortunately, due to the pervasiveness of error handling and strong typing, this requires a lot of small cascading changes, so making commits self-contained was not an easy task :)

Remove all hardcoded instances of VMPL=1 for the guest, and replace them with a new constant, GUEST_VMPL. Introduce as well a new value in RMPFlags so that users of the structure can easily refer to the guest VMPL.

The best home for the new constant seems to be src/types.rs, but this could be changed.

I have verified that a guest can be booted in VMPL 2 by simply changing the value of the constant.

Fixes #11.

Add error types for GHCB and MSR protocol operations.

These errors are mostly only to be handled from two sites, namely the firmware setup in svsm_main() and the PerCpu handlers. At the first one, we just panic as before, printing a more verbose message. At the second group, we ignore the error types for now to simplify the patches, but handling will be added in a separate PR.

Commenting out this line causes a crash. https://github.com/coconut-svsm/svsm/blob/b8042679f07d24dc0a6df53cf73b278eb545a8fd/src/mm/pagetable.rs#L54

This shouldn't happen because ENCRYPT_MASK is already set to new_encrypt_mask (this is checked in the lines above), so this is essentially a no-op. Yet for some reason removing this line causes a crash. This hints at some kind of UB/memory corruption happening.

Replacing the line for the following code causes the VM to hang even though it should be equivalent:

assert_eq!(new_encrypt_mask, old_encrypt_mask);
unsafe { ENCRYPT_MASK.reinit(&old_encrypt_mask) }; 

If an invalid guest VMPL is specified, the user will get the following error at compile time:

$ make
cargo build  --bin stage2
   Compiling svsm v0.1.0 (/home/user/svsm)
error[E0080]: evaluation of constant value failed
  --> src/types.rs:27:15
   |
27 | const _: () = assert!(GUEST_VMPL > 0 && GUEST_VMPL < VMPL_MAX);
   |               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the evaluated program panicked at 'assertion failed: GUEST_VMPL > 0 && GUEST_VMPL < VMPL_MAX', src/types.rs:27:15
   |
   = note: this error originates in the macro `assert` (in Nightly builds, run with -Z macro-backtrace for more info)

For more information about this error, try `rustc --explain E0080`.
error: could not compile `svsm` due to previous error
make: *** [Makefile:30: stage1/stage2.bin] Error 101

Previously the default representation was used which doesn't guarantee a stable layout. This is problematic because KernelLaunchInfo is passed from the loader to the kernel and any differences in layout would cause a crash. Using the C representation guarantees a stable layout.

Previously a crash could be provoked by setting randomize-layout:

RUSTFLAGS="-Z randomize-layout -Z layout-seed=2" cargo build --bin stage2
RUSTFLAGS="-Z randomize-layout -Z layout-seed=3" cargo build --bin svsm

Currently the guest VMPL is hard-coded to VMPL-1 throughout the code.

Introduce a single global constant which defines the guest VMPL level and use it everywhere in the code. Try to run a guest at VMPL-2 and VMPL-3.

Note that the VMPLCK keys in the secret page need to be cleared for all lower-level VMPLs before the page is passed to the guest.

Fix a subtle bug in allocate_zeroed_page() where inline assembly setting a memory region to zero would get optimized out due to the target address being set as an "in" parameter instead of "inout". This would cause the compiler to assume that the contents of the pointer were not changed, resulting in a crash during boot in release builds release builds. This is similar to the bug fixed in 35b8a31aa2b96e86 ("SVSM/mm/guestmem: Fix GuestPtr::read() operations").

Fix this by using zero_mem_region(), which casts the address to a raw pointer before zeroing out the region, ensuring the operation does not get opimized away.

Implement a lib-crate which can be used to write COCONUT modules in Rust. The crate should contain the runtime for Rust code running in COCONUT on CPL-3: A list of required parts:

• [ ] Application entry point and startup code up to calling main() function
• [ ] Force no-std
• [ ] Linker script
• [ ] SYSCALL wrappers
• [ ] Memory allocator registering itself as the global allocator
• [ ] Re-export parts from the Rust core library

Implement the needed infrastructure to run additional modules in Ring-3 and have it separated from the core COCONUT kernel.

The modules should be in ELF format and provided to the COCONUT kernel via an archive file contained in the final SVSM binary. The kernel will unpack the files and populate a RAM filesystem, from which the kernel launches CPL-3 modules.

This requires (possibly incomplete list):

• [ ] Archive file in SVSM binary
• [ ] RAM file system support
• [ ] Page allocator enhancements for reference counting pages
• [ ] ELF loader (WIP, see #4)
• [ ] Task concept
• [ ] Task switching
• [ ] Task memory management
• [ ] Page fault handling
• [ ] SYSCALL entry/exit
• [ ] SYSCALL interface
• [ ] VC handling (see #14 )
• [ ] Protocol request multiplexer

The project currently requires rust-nightly to be compiled. This makes it impossible to build the project in an automated build environment like the ones used to compile Linux distributions.

Make the necessary modifications step by step to build the project using Rust stable.

Move away from directly making GHCB calls and implement a proper #VC exception handler to handle NAE events.

This is required for CPL-3 support, as some instructions that cause NAEs are allowed in unprivileged code (e.g. CPUID). But the console printing support also benefits from this, as its driver infrastructure can be removed so that it uses IN/OUT instructions directly.

Further, by handling #VC exceptions in stage2 already we can get console support very early in the COCONUT kernel, which makes debugging of the early boot stages much easier.

There is no reason yet to handle MMIO related NAE events, but IOIO is needed, best including INS/OUTS instructions (but these are not needed in the first step).

The SVSM prints all log messages directly to the serial console. In a production environment this could be a security problem as it reveals information about the guest.

Implement a log buffer which stores all log messages in memory. A single 4KiB page is sufficient for now. The log buffer should be set up in stage-2 and passed to the COCONUT kernel when it launches. The COCONUT kernel then migrates the log buffer into its own memory. This way the log-buffer will also contain the stage-2 messages.

For debug builds additionally print the message to the console. For release builds do not print anything to the console by default. Add a flag to set in the code to re-enable console printing also for release builds to make debugging issues easier.

Also start designing a request protocol to allow the guest to read the SVSM log buffer and implement a Linux kernel driver and user-space (in rust) to access the SVSM log from the guest.

• Implement a minimal ELF file reader
• Make the Stage2 to read the SVSM kernel from an ELF (instead of raw binary) and load it according to the layout described therein.
• Let the SVSM kernel determine its own memory layout to transfer over to the runtime page tables from the ELF metadata as well.
• Implement address space randomization in Stage2.

Future plans include

• to load the symbol table from the ELF as well and to e.g. pretty-print stacktraces and
• to use the unwinding records from the ELF for unwinding, alleviating the need for the current framepointer based approach.