On 3/21/23 04:29, Jörg Rödel wrote:
Hi,
We are happy to announce that last week our secure VM service module
(SVSM) went public on GitHub for everyone to try it out and participate
in its further development. It is dual-licensed under the MIT and
APACHE-2.0 licenses.
The project is written in Rust and can be cloned from:
https://github.com/coconut-svsm/svsm
There are also repositories in the github project with the Linux host and
guest, EDK2 and QEMU changes needed to run the SVSM and boot up a full
Linux guest.
The SVSM repository contains an installation guide in the INSTALL.md
file and contributor hints in CONTRIBUTING.md.
A blog entry with more details is here:
https://www.suse.com/c/suse-open-sources-secure-vm-service-module-for-confidential-computing/
We also thank AMD for implementing and providing the necessary changes
to Linux and EDK2 to make an SVSM possible.
Have a lot of fun!
I finally found the time to go through coconut-svsm and compare/contrast
it to linux-svsm. Overall, they are very similar once loaded and running.
I also took the time to preview this with a couple of our most prominent
linux-svsm users before I sent it out.
While both SVSM implementations use the Qemu Firmware Configuration
(fw_cfg) interface, the coconut-svsm relies on it a bit more than
linux-svsm. In either case, other interfaces may need to be supported in
order for an SVSM to work with a VMM other than Qemu.
Some of the main differences are (just an accounting, I'm not saying
that one method is any better than the other):
- Both SVSMs end up located in a memory slot outside of memory that is
reported to the guest. Coconut-svsm gets the location and size from
fwcfg, which is customizable via the Qemu command line. Linux-svsm gets
the location and size from the build process and validates that location
and size.
- Coconut-svsm starts in stages. Stage1 starts in 32-bit protected mode
just below the OVMF firmware (just below 4GB), copies stage2 and the
SVSM to 64KB where further initialization is performed and ultimately
with the SVSM being copied to its final location where execution
continues.
The current stage1 location could limit the size of the SVSM based on
the MMIO layout of the guest.
- Linux-svsm is loaded in its final location and starts in 64-bit long
mode. This requires extra setup in Qemu for the VMSA, but no
relocation is needed once it is loaded.
- Coconut-svsm has developed its own IDT and pagetable support instead of
using the x86_64 crate as linux-svsm does:
- IDT:
The main reason for the IDT support was to be able to customize the
entry code, especially when CPL3 support is added. However, that can
be done with the x86_64 crate by not using the "abi_x86_interrupt"
feature.
- Pagetables:
Page table support can be tricky with the x86_64 crate. But in general
I believe it could still be used. Coconut-svsm uses a dynamic offset-
based approach for pagetables based on the final physical address
location. This offset could be utilized in the x86_64 crate
implementation. When CPL3 support comes around, that would require
further investigation.
- The advantage of using the x86_64 crate is getting added testing and
fixes for issues that might not be immediately evident in a from
scratch implementation. While not a issue, investigation could be done
later to see if it is possible to move to those implementations (if
desired).
- Coconut-svsm uses the ACPI MADT table to detect and boot APs. This works
well with Qemu or any VMM that builds the MADT table. The linux-svsm
makes use of the GHCB APIC ID list NAE event.
- Coconut-svsm does not measure the VMPL1 BSP VMSA directly. It uses set
values that are measured as part of SVSM itself. This does prevent
coconut-svsm from being able to launch VMPL1 using a different, measured
BSP initial state. Linux-svsm, after performing some validation, does
use a separately measured VMPL1 firmware BSP VMSA.
- Coconut-svsm copies the original Secrets Page and the "frees" the memory
for it. I couldn't tell if the memory is zeroed out or not, but
something that should be looked at to ensure the VMPCK0 key is not
leaked.
Some questions for coconut-svsm:
- Are there any concerns with using existing code/projects as submodules
within coconut-svsm (e.g. OpenSSL or a software TPM implementation)?
One of our design goals for linux-svsm was desirability to easily
allow downstream users or products to, e.g., use their own crypto
(e.g. company preferred)
- Are you open to having maintainers outside of SUSE? There is some
linux-svsm community concern about project governance and project
priorities and release schedules. This wouldn't have to be AMD even,
but we'd volunteer to help here if desired, but we'd like to foster a
true community model for governance regardless. We'd love to hear
thoughts on this from coconut-svsm folks.
- On the subject of priorities, the number one priority for the
linux-svsm project has been to quickly achieve production quality vTPM
support. The support for this is being actively worked on by
linux-svsm contributors and we'd want to find fastest path towards
getting that redirected into coconut-svsm (possibly starting with CPL0
implementation until CPL3 support is available) and the project
hardened for a release. I imagine there will be some competing
priorities from coconut-svsm project currently, so wanted to get this
out on the table from the beginning.
Since we don't want to split resources or have competing projects, we are
leaning towards moving our development resources over to the coconut-svsm
project. I think we do need to sort out the governance question
(maintainers, prioritization, release/schedule model, ...), but I don't
see hard technical blockers. For others in the linux-svsm developer
community, please ask questions or voice any concerns you may have so that
we can see if they can be addressed.
Thanks,
Tom
