amdese / linux-svsm

Linux SVSM (Secure VM Service Module) for secure x86 virtualization in Rust

Linux SVSM (Secure VM Service Module)

** The Linux SVSM project is no longer being actively developed. Users of Linux SVSM should switch over to the COCONUT SVSM project. **

Table of contents

1. What is this magic?
2. Preparing the host
3. Installation
4. Running Linux SVSM
5. Contribution
6. Linux SVSM userspace
7. Authors and License

What is this magic?

Linux SVSM (Secure VM Service Module) implements a guest communication interface so that VM guests can offload sensitive operations (for example, updating access permissions on protected pages) onto a privileged* guest acting as service module. Linux SVSM relies on AMD's Secure Nested Paging (SNP) and prior Secure Encrypted Virtualization technologies (See SEV documentation).

The idea is that Linux SVSM will not only offload security operations, but will also be able to provide other services such as live VM migration; the privilege separation model of SVSM permits the existence of a virtual Trusted Platform Module (virtual TPM).

* AMD SNP introduces the Virtual Machine Privilege Level (VMPLs) for enhanced security control. VMPL0 is the highest level of privilege. Linux SVSM runs at VMPL 0, as opposed to other guests running under VMPL >=1. Certain operations become architecturally impossible to guests running at lower privilege levels (e.g. use of the PVALIDATE instruction and certain forms of RMPADJUST).

Generate and read source code documentation with:

# make doc

which will also install necessary prerequisites.

Preparing the host

Linux SVSM assumes a host with support for AMD's SEV-SNP, as well as compatible guest, Qemu and OVMF BIOS. We provide bash scripts to automate the installation process of these prerequisites. The remainder of these instructions were tested on Ubuntu 22.04 server, installed with kernel 5.15.0-46-generic.

Start by verifying that the following BIOS settings are enabled. The settings may vary depending on the vendor BIOS. The menu options below are from AMD's BIOS.

  CBS -> CPU Common ->
                SEV-ES ASID space Limit Control -> Manual
                SEV-ES ASID space limit -> 100
                SNP Memory Coverage -> Enabled
                SMEE -> Enabled
      -> NBIO common ->
                SEV-SNP -> Enabled

We now need to build the host and guest kernels, Qemu and OVMF BIOS used for launching the SEV-SNP guest.

$ cd scripts/
$ ./build.sh --package

If build fails, read subsection Build troubleshooting. On successful build, the binaries will be available in snp-release-<DATE>.

Now we need to install the Linux kernel on the host machine:

$ cd snp-release-<date>
$ sudo ./install.sh

Reboot the machine and choose SNP Host kernel from the grub menu. You can check you have a kernel with the proper SNP support with:

$ sudo dmesg | grep SEV
[    7.393321] SEV-SNP: RMP table physical address 0x0000000088a00000 - 0x00000000a8ffffff
[   18.958687] ccp 0000:22:00.1: SEV firmware update successful
[   21.081484] ccp 0000:22:00.1: SEV-SNP API:1.51 build:3
[   21.286378] SEV supported: 255 ASIDs
[   21.290367] SEV-ES and SEV-SNP supported: 254 ASIDs

Build troubleshooting

The most likely source of build errors is missing a tool. Try installing the following:

$ sudo apt install make ninja-build libglib2.0-dev libpixman-1-dev python3
$ sudo apt install nasm iasl flex bison libelf-dev libssl-dev

If your error is during OVMF's compilation, you can try getting a verbose form of the error, running manually with -v. In our case:

$ cd ovmf
$ source edksetup.sh
$ nice build -v -q --cmd-len=64436 -DDEBUG_ON_SERIAL_PORT -n 32 -t GCC5 -a X64 -p OvmfPkg/OvmfPkgX64.dsc

If your error involves still not finding Python, you may try to replace python with python3 in the file BaseTools/Tests/GNUmakefile of the ovmf folder that you have just cloned.

Installation

Linux SVSM requires the Rust nightly tool-chain, as well as components that can be downloaded from rustup. The process can be automated with:

# make prereq

You can select default installation for rustup. After that, make sure rust-lld can be found in your PATH. You can edit your ~/.bashrc with:

export PATH="/(YOUR PATH)/rustlib/x86_64-unknown-linux-gnu/bin/:$PATH"

To build:

# make

To build with serial output progress information, for debugging:

# make FEATURES=verbose

You should NEVER have to specify the cargo target, as we have .cargo/config.toml. The Makefile includes a basic clean target. To force prerequisites re-installation on the next execution of make do:

# make superclean

To run the unit tests:

# make test

Running Linux SVSM

The building process will generate svsm.bin that can be passed to Qemu (svsm parameter). Inside directory scripts/ we provide launch-qemu.sh to ease the execution of the Qemu virtual machine. First, we need an empty virtual disk image and distribution (in our example, Ubuntu):

# qemu-img create -f qcow2 guest.qcow2 30G
# wget <link-to-iso> ubuntu.iso

Once we have an image prepared, we can boot with the command below. In the Grub option of installation, you can edit the linux kernel command adding 'console=tty0 console=ttyS0,115200n8' and then Ctr+X.

# ./launch-qemu.sh -hda guest.qcow2 -cdrom ubuntu.iso

after that, we can simply boot and install the kernel *.debs/*.rpms from within the guest VM.

[host@snp-host ~]#  ./launch-qemu.sh -hda guest.qcow2
[guest@snp-guest ~]# scp host@ip:/<dir>/scripts/linux/<version>*guest*.deb .
[guest@snp-guest ~]# chmod +x *.deb && dpkg -i *.deb
[guest@snp-guest ~]# reboot

Finally, we will have to execute the script again, this time providing the SVSM binary. Once the SVSM guest is up, you can check it is running on VMPL1 (lower privilege level) with:

[host@snp-host ~]#  ./launch-qemu.sh -hda guest.qcow2 -sev-snp -svsm svsm.bin
[guest@snp-guest ~]# dmesg | grep VMPL
[    1.264552] SEV: SNP running at VMPL1.

Note: The launch-qemu.sh script was updated to support the newer UPM-based SEV-SNP support. If you are running on an older SEV-SNP host kernel that doesn't support UPM, please add the -noupm parameter to the launch command:

[host@snp-host ~]#  ./launch-qemu.sh -hda guest.qcow2 -sev-snp -svsm svsm.bin -noupm

By default, SVSM lives at 512 GB (SVSM_GPA), and has 256 MB of memory (SVSM_MEM). This can be changed at compilation. For example:

# make SVSM_GPA=0x90000000 SVSM_MEM=0x20000000

The SVSM page table applies an offset to its virtual addresses.

Linux SVSM userspace

Linux SVSM's main branch does not contain support for userspace (CPL3). If interested, checkout branch cpl-support.

Contribution

Please read CONTRIBUTING.md for instructions on contribution and style.

Authors and License

The original authors and maintainers of this software are:

• Thomas Lendacky
• Carlos Bilbao

and they will act as reviewers for future contributions.

Other developers have made substantial contributions to this project, to obtain the full list, please refer to the Contributors page or review the authorship information in the project's source code headers.

Linux SVSM is distributed under the MIT license. For more information, read file LICENSE. To obtain information about the crates that Linux SVSM depends on, you can run:

$./scripts/crates.sh

linux-svsm's Issues

Study a better way to unwrap errors

Something we can have like unwrap, that instead of panic will call vc_terminate_xxxx. Consider this code:

    let init_frame: PhysFrame = match mem_allocate_frames(init_count) {
        Some(f) => f,
        None => vc_terminate_svsm_enomem(),
    };

from something generic resembling:

pub trait CustomUnwrap<T> {
    fn unwrap_svsm_enomem(self) -> T;
}

impl CustomUnwrap<T> for Option<T> {
    fn unwrap_svsm_enomem(self) -> T {
        match self {
            Some(value) => value,
            None => vc_terminate_svsm_enomem(),
        }
    }
}

Como ejecutar en Windows 10?

¿Me podrían proveer instrucciones de ejecución desde Windows 10 OS? Mil gracias.

vcpu0, guest rIP: 0x0 vmgexit: GHCB GPA [0x4e14000] is not registered.

this worked last week on the same machine, but for some reason an identical setup no longer works.

when using ./launch-qemu.sh with -sev-snp

host:

[ 6748.446657] kvm [1507554]: vcpu0, guest rIP: 0x0 vmgexit: GHCB GPA [0x4e14000] is not registered.

guest:

error: kvm run failed Invalid argument
EAX=0000001a EBX=00000073 ECX=00000000 EDX=00000000
ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000
EIP=00000000 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0000 00000000 00000000 00000000
CS =0000 00000000 00000000 00000000
SS =0000 00000000 00000000 00000000
DS =0000 00000000 00000000 00000000
FS =0000 00000000 00000000 00000000
GS =0000 00000000 00000000 00000000
LDT=0000 00000000 00000000 00000000
TR =0000 00000000 00000000 00000000
GDT=     00000000 00000000
IDT=     00000000 00000000
CR0=80000001 CR2=00000000 CR3=00000000 CR4=00000020
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 
DR6=00000000ffff0ff0 DR7=0000000000000400
EFER=0000000000000900
Code=<??> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??

How to get the output of SVSM?

Sorry for help. I'm trying to add code for SVSM, however, I cannot get the output from the terminal or QEMU cmdline generated by the RUST code, like:

prints!("Hello, new SVSM calls");

How can I get the output, or are there other debugging methods recommanded?

Running on Fedora 36

I ran into some issues then trying to use SVSM on Fedora 36.
I know the main focus is Ubuntu 22.04 right now, but I'll leave this info here just in case.

OVMF crashes

The OVMF crashes right after the start when built on Fedora 36 (gcc 12).

Both of these workarounds to the trick:

1. Disable LTO. See this patch by Alexey Kardashevskiy.
2. Add -fno-omit-frame-pointer to CC_FLAGS , see https://edk2.groups.io/g/devel/message/90443

Building the Linux kernels

When building the Linux kernels for host and guest I found that I needed to apply these two commits to fix some build issues:

commit 879e518ad704859f7288f6732902dd115e45294a
Author: Kees Cook <[email protected]>
Date:   Sun Feb 13 10:24:43 2022 -0800

    libsubcmd: Fix use-after-free for realloc(..., 0)

commit 39372df4875060a5931b4bd09362e7689c3cfb96
Author: Josh Poimboeuf <[email protected]>
Date:   Mon Apr 18 09:50:21 2022 -0700

    libsubcmd: Fix OPTION_GROUP sorting

ccp 0000:46:00.1: SEV-SNP support requires firmware version >= 1:51

i cant launch sev guests on this host kernel.

qemu-system-x86_64: sev_kvm_init: cbitpos check failed, host '51' requested '0'
qemu-system-x86_64: failed to initialize kvm: Operation not permitted

this is possibly related

root@yca7h:~/linux-svsm/scripts# dmesg | grep -i sev
[    0.541244] SEV-SNP: RMP table physical address 0x0000000035600000 - 0x0000000075bfffff
[   53.723301] ccp 0000:46:00.1: sev enabled
[   53.739626] ccp 0000:46:00.1: SEV-SNP support requires firmware version >= 1:51
[   53.752157] ccp 0000:46:00.1: SEV: failed to INIT error 0x1
[   53.752162] ccp 0000:46:00.1: SEV API:1.15 build:15
[   54.166212] SEV supported: 410 ASIDs
[   54.166212] SEV-ES and SEV-SNP supported: 99 ASIDs

firmware doesnt appear to be loaded at all. on another host with an upstream kernel i'm getting this dmesg

root@sev-playground ~ # dmesg | grep firmware
[    0.158501] Spectre V2 : Enabling Speculation Barrier for firmware calls
[    0.611350] GHES: APEI firmware first mode is enabled by APEI bit.
[    4.723458] ccp 0000:44:00.1: firmware: failed to load amd/amd_sev_fam17h_model31h.sbin (-2)
[    4.723615] firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware
[    4.723805] ccp 0000:44:00.1: firmware: failed to load amd/amd_sev_fam17h_model31h.sbin (-2)
[    4.724521] ccp 0000:44:00.1: firmware: direct-loading firmware amd/amd_sev_fam17h_model3xh.sbin

but this kernel has no such messages

root@yca7h:/lib/firmware/amd# ls -l
-rw-r--r-- 1 root root  82688 Sep  8 11:33  amd_sev_fam19h_model0xh_1.51.03.esbin
-rw-r--r-- 1 root root  82688 Sep  8 11:33  amd_sev_fam19h_model0xh_1.51.03.sbin
-rw-r--r-- 1 root root 142857 Sep  8 18:59  amd_sev_fam19h_model0xh_1.51.03.zip
-rw-r--r-- 1 root root  14873 Sep  8 11:50 'Milan Release Notes.txt'

this is a 7443P

maybe this is related?

can a guest-owner verify svsm?

there's a fundamental thing i still don't understand about SNP, and i was assuming SVSM solves that, but i cant figure out how.

in a cloud environment, a guest owner can typically not supply their own firmware (OVMF, vTPM)
and the common solution appears to be that the identityblock is signed by the CSP,
and the guest owner verifies that that signature came from a known good CSP key.

i was assuming with the svsm stack, it's actually svsm that gets attested, but it looks like its still the entire firmware.
even tho svsm has higher privilege than the next firmware, the guest owner can't really verify that a specific expected version of svsm was loaded.

did i fundamentally misunderstand what problem svsm actually solves?

Failed to boot guest-os with svsm after adding a new hard disk in the machine.

Hello, everyone. Here comes a problem!

Recently we brought a new hard disk, and plugged into the machine. Every thing remains unchanged except the /home partition moved to the new disk. The linux-svsm worked very well before this operation. The binaries remain unchanged. However, we failed to boot the guest-os with linux-svsm, details are as following:

$ dmesg | egrep "ccp|sev|SEV|SNP"
[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-5.19.0-rc6-snp-host root=UUID=f0d15ade-1929-442a-b1f8-befb36389d13 ro mem_encrypt=on kvm_amd.sev=1 kvm_amd.dump_invalid_vmcb=1 quiet splash vt.handoff=7
[    0.118670] Kernel command line: BOOT_IMAGE=/vmlinuz-5.19.0-rc6-snp-host root=UUID=f0d15ade-1929-442a-b1f8-befb36389d13 ro mem_encrypt=on kvm_amd.sev=1 kvm_amd.dump_invalid_vmcb=1 quiet splash vt.handoff=7
[    1.053091] AMD-Vi: SNP enabled
[    1.053093] SEV-SNP: RMP table physical address 0x0000000098400000 - 0x00000000a89fffff
[    1.194943] AMD-Vi: Extended features (0x841f77e022094ace, 0x0): PPR X2APIC NX IA GA PC SNP
[    1.194951] AMD-Vi: Extended features (0x841f77e022094ace, 0x0): PPR X2APIC NX IA GA PC SNP
[    1.194955] AMD-Vi: Extended features (0x841f77e022094ace, 0x0): PPR X2APIC NX IA GA PC SNP
[    1.194959] AMD-Vi: Extended features (0x841f77e022094ace, 0x0): PPR X2APIC NX IA GA PC SNP
[    1.194962] AMD-Vi: Extended features (0x841f77e022094ace, 0x0): PPR X2APIC NX IA GA PC SNP
[    1.194965] AMD-Vi: Extended features (0x841f77e022094ace, 0x0): PPR X2APIC NX IA GA PC SNP
[    1.194969] AMD-Vi: Extended features (0x841f77e022094ace, 0x0): PPR X2APIC NX IA GA PC SNP
[    1.194972] AMD-Vi: Extended features (0x841f77e022094ace, 0x0): PPR X2APIC NX IA GA PC SNP
[    6.078612] ccp 0000:22:00.1: enabling device (0000 -> 0002)
[    6.078732] ccp 0000:22:00.1: no command queues available
[    6.079038] ccp 0000:22:00.1: sev enabled
[    6.079040] ccp 0000:22:00.1: psp enabled
[    6.079364] ccp 0000:a2:00.1: enabling device (0000 -> 0002)
[    6.081575] ccp 0000:a2:00.1: no command queues available
[    6.081603] ccp 0000:a2:00.1: psp enabled
[    6.150077] ccp 0000:22:00.1: SEV firmware update successful
[    7.209261] ccp 0000:22:00.1: SEV API:1.51 build:3
[    7.209273] ccp 0000:22:00.1: SEV-SNP API:1.51 build:3
[    7.279794] SEV supported: 410 ASIDs
[    7.279795] SEV-ES and SEV-SNP supported: 99 ASIDs

$ sudo ./launch-qemu.sh -hda guest.raw -sev-snp -svsm svsm.bin
trap: SIGINT: bad trap
./usr/local/bin/qemu-system-x86_64 -enable-kvm -cpu EPYC-v4,host-phys-bits=true -smp 4 -m 4G -machine type=q35,memory-encryption=sev0,vmport=off,svsm=svsm.bin -object sev-snp-guest,id=sev0,policy=0x30000,cbitpos=51,reduced-phys-bits=1,init-flags=0x4,host-data=b2l3bmNvd3FuY21wbXA -drive if=pflash,format=raw,unit=0,file=/media/benshan/linux-svsm/scripts/snp-release-2022-10-13/usr/local/share/qemu/OVMF_CODE.fd,readonly=on -drive if=pflash,format=raw,unit=1,file=./guest.fd -drive file=guest.raw,if=none,id=disk0,format=raw -device virtio-scsi-pci,id=scsi0,disable-legacy=on,iommu_platform=true -device scsi-hd,drive=disk0 -nographic -monitor pty -monitor unix:monitor,server,nowait -netdev user,id=vmnic,hostfwd=tcp::20000-:22,hostfwd=tcp::9600-:9600 -device e1000,netdev=vmnic,romfile= 
Mapping CTRL-C to CTRL-]
Launching VM ...
  /tmp/cmdline.70179
char device redirected to /dev/pts/3 (label compat_monitor0)
qemu-system-x86_64: sev_kvm_init: failed to initialize ret=-95 fw_error=0 ''
qemu-system-x86_64: failed to initialize kvm: Operation not permitted

However, we can boot the guest-os without linux-svsm. The command line is just like this:

$ sudo ./launch-qemu.sh -hda guest.raw -sev-snp

Even if we try out the latest version of linux-svsm on the mainline without our changes, error still appeared.

$ sudo ./launch-qemu.sh -hda guest.raw -sev-snp -svsm svsm-official.bin
trap: SIGINT: bad trap
./usr/local/bin/qemu-system-x86_64 -enable-kvm -cpu EPYC-v4,host-phys-bits=true -smp 4 -m 4G -machine type=q35,memory-encryption=sev0,vmport=off,svsm=svsm-official.bin -object sev-snp-guest,id=sev0,policy=0x30000,cbitpos=51,reduced-phys-bits=1,init-flags=0x4,host-data=b2l3bmNvd3FuY21wbXA -drive if=pflash,format=raw,unit=0,file=/media/benshan/linux-svsm/scripts/snp-release-2022-10-13/usr/local/share/qemu/OVMF_CODE.fd,readonly=on -drive if=pflash,format=raw,unit=1,file=./guest.fd -drive file=guest.raw,if=none,id=disk0,format=raw -device virtio-scsi-pci,id=scsi0,disable-legacy=on,iommu_platform=true -device scsi-hd,drive=disk0 -nographic -monitor pty -monitor unix:monitor,server,nowait -netdev user,id=vmnic,hostfwd=tcp::20000-:22,hostfwd=tcp::9600-:9600 -device e1000,netdev=vmnic,romfile= 
Mapping CTRL-C to CTRL-]
Launching VM ...
  /tmp/cmdline.343381
char device redirected to /dev/pts/11 (label compat_monitor0)
qemu-system-x86_64: sev_kvm_init: failed to initialize ret=-95 fw_error=0 ''
qemu-system-x86_64: failed to initialize kvm: Operation not permitted

I guess the problem is due to the hardware changes. But how to solve the problem remains unknown to us. Since we didn't meet this problem before. Maybe we should create a new virtual-machine image, which seems to be tedious. Since we made no changes to the virtual machine image.

Now I found the error message comes from the following function in QEME. the error code comes from a ioctl request.

static void
sev_ram_block_added(RAMBlockNotifier *n, void *host, size_t size,
                    size_t max_size)
{
    int r;
    struct kvm_enc_region range;
    ram_addr_t offset;
    MemoryRegion *mr;

    /*
     * The RAM device presents a memory region that should be treated
     * as IO region and should not be pinned.
     */
    mr = memory_region_from_host(host, &offset);
    if (mr && memory_region_is_ram_device(mr)) {
        return;
    }

    range.addr = (__u64)(unsigned long)host;
    range.size = max_size;

    trace_kvm_memcrypt_register_region(host, max_size);
    r = kvm_vm_ioctl(kvm_state, KVM_MEMORY_ENCRYPT_REG_REGION, &range);
    if (r) {
        error_report("%s: failed to register region (%p+%#zx) error '%s'",
                     __func__, host, max_size, strerror(errno));
        exit(1);
    }
}

The corresponding function in the host kernel is as following,

        case KVM_MEMORY_ENCRYPT_REG_REGION: {
                struct kvm_enc_region region;

                r = -EFAULT;
                if (copy_from_user(&region, argp, sizeof(region)))
                        goto out;

                r = -ENOTTY;
                if (kvm_x86_ops.mem_enc_reg_region)
                        r = static_call(kvm_x86_mem_enc_reg_region)(kvm, &region);
                break;
        }

which may provide additional information about the problem.

Any help would be appreciated here!

---

Oh, the default kernel version is changed... This reason of this problem has been found!

make doc fails. First error: error[E0463]: can't find crate for `core`

Full log attached. Ubuntu 22.04.1 LTS.
log.txt

Getting attestation report from VMPL0

We are trying to get an attestation report from within the SVSM (basically to attest the vTPM).

Software

Host kernel - 5.14.0-rc2-snp-host-e69def60bfa5
linux-svsm - latest main (454f26edd) + some additions for bringing in libcrypto.

Here is what I am trying to do (more details on the gist)

Create Headers

• Create a report req (struct snp_report_req)
  • Tried with different req.vmpl values (0, 1, 2)
• Populate message headers (struct snp_guest_msg)
  • https://www.amd.com/system/files/TechDocs/56860.pdf#page=113 - Table. 97

Encryption with AAD

• Use vmpck0 from svsm_secrets page as the key
• Use a monotonic sequence number as the IV
• Use offset 0x30..0x5F of the header as AAD
• Use the snp_report_req as payload (plaintext)
• Encrypt with AesGcm (get back the auth_tag)

For GHCB request

• Mark request and response buffers as shared
• Perform a guest request (0x80000011)
• Check sw_exit_info_2 value for errors.

I am getting back an INVALID_PARAM (0x16) for this request. Table 100 here says MBZ fields are not zero. for this particular error. I have verified that my request has all the reserved fields set to zero.

Am I missing anything obvious? Is there a PoC code on how to get attestation reports from SVSM?
Do you have any pointers on how to debug this issue?

BTW, the manual says that The authentication tag authenticates the bytes from 20h to the end of the encrypted payload, but the implementation passes bytes 0x30 to 0x5F. This seem to be a discrepancy. Can you pass it on to the documentation folks if you think this needs to be fixed?

Qemu got stuck because of RMP fault when I enable svsm.bin. Could you take a look?

Hello!
I was going through the whole process for installing linux-svsm recently on a server with AMD's SEV-SNP enabled. It builds well and I successfully get the directory named "snp-release-2023-08-12" and the corresponding 'tar.gz' file. I ran the following command and the qemu can launch the Guest VM successfully.

[host machine]: $ uname -a
Linux super-server 6.1.0-rc4-snp-host-4c33a31c6e15 #1 SMP PREEMPT_DYNAMIC Sat Aug 12 20:27:41 CST 2023 x86_64 x86_64 x86_64 GNU/Linux
[host machine]: $ ./launch-qemu.sh -hda guest.qcow2
[guest machine]: $ uname -a
Linux link-server 6.2.0-snp-guest-20e69de4dd39 #2 SMP PREEMPT_DYNAMIC Sat Aug 12 20:07:46 CST 2023 x86_64 x86_64 x86_64 GNU/Linux

However, as I wanted to launch with svsm.bin, the qemu simply got stuck.......

link@super-server:~/linux-svsm/scripts$ sudo ./launch-qemu.sh -hda guest.qcow2 -sev-snp -svsm ../svsm.bin
./usr/local/bin/qemu-system-x86_64 -enable-kvm -cpu EPYC-v4,host-phys-bits=true -smp 4 -machine type=q35,confidential-guest-support=sev0,memory-backend=ram1,kvm-type=protected,vmport=off,svsm=../svsm.bin -object memory-backend-memfd-private,id=ram1,size=4G,share=true -object sev-snp-guest,id=sev0,policy=0x30000,cbitpos=51,reduced-phys-bits=1,init-flags=0x4,host-data=b2l3bmNvd3FuY21wbXA -drive if=pflash,format=raw,unit=0,file=/home/link/linux-svsm/scripts/usr/local/share/qemu/OVMF_CODE.fd,readonly=on -drive if=pflash,format=raw,unit=1,file=./guest.fd -drive file=guest.qcow2,if=none,id=disk0,format=qcow2 -device virtio-scsi-pci,id=scsi0,disable-legacy=on,iommu_platform=true -device scsi-hd,drive=disk0 -nographic -monitor pty -monitor unix:monitor,server,nowait -netdev user,id=vmnic -device e1000,netdev=vmnic,romfile=
Mapping CTRL-C to CTRL-]
Launching VM ...
  /tmp/cmdline.69063
char device redirected to /dev/pts/2 (label compat_monitor0)
qemu-system-x86_64: warning: Setting vm_type: protected
qemu-system-x86_64: warning: Setting vm_type: protected
qemu-system-x86_64: warning: UPM mode enabled, discard=(null)
qemu-system-x86_64: warning: creating ROM device with private memory.
qemu-system-x86_64: warning: creating ROM device with private memory.

It stuck like this, nothing else happened. I know the message shown here is not helpful but qemu just simply stuck like this.

As I delete "-svsm ../svsm.bin", only with -sev-snp enabled, which means I ran the following command:

 ./launch-qemu.sh -hda guest.qcow2 -sev-snp

It also got stuck like above.

And here is the system log in /var/log/syslog as Qemu got stuck.

Aug 13 22:44:35 super-server x11vnc[5584]:  --- x11vnc loop: sleeping 2000 ms ---
Aug 13 22:44:37 super-server kernel: [ 9829.028170] kvm_amd: Unexpected RMP fault for GPA 0x800013c000, error_code 0x680000007
Aug 13 22:44:37 super-server kernel: [ 9834.031966] handle_rmp_page_fault: 2884137 callbacks suppressed
Aug 13 22:44:37 super-server kernel: [ 9834.031971] kvm_amd: Unexpected RMP fault for GPA 0x800013c000, error_code 0x680000007
Aug 13 22:44:37 super-server kernel: [ 9834.031977] kvm_amd: Unexpected RMP fault for GPA 0x800013c000, error_code 0x680000007
Aug 13 22:44:37 super-server kernel: [ 9834.031979] kvm_amd: Unexpected RMP fault for GPA 0x800013c000, error_code 0x680000007
Aug 13 22:44:37 super-server kernel: [ 9834.031982] kvm_amd: Unexpected RMP fault for GPA 0x800013c000, error_code 0x680000007
Aug 13 22:44:37 super-server kernel: [ 9834.031985] kvm_amd: Unexpected RMP fault for GPA 0x800013c000, error_code 0x680000007
Aug 13 22:44:37 super-server kernel: [ 9834.031987] kvm_amd: Unexpected RMP fault for GPA 0x800013c000, error_code 0x680000007
Aug 13 22:44:37 super-server kernel: [ 9834.031990] kvm_amd: Unexpected RMP fault for GPA 0x800013c000, error_code 0x680000007
Aug 13 22:44:37 super-server kernel: [ 9834.031993] kvm_amd: Unexpected RMP fault for GPA 0x800013c000, error_code 0x680000007
Aug 13 22:44:37 super-server kernel: [ 9834.031995] kvm_amd: Unexpected RMP fault for GPA 0x800013c000, error_code 0x680000007

I suspect that the error may have been caused by my previous actions of running

`sudo apt-get update` and `sudo apt-get upgrade`

on the server. But According to the syslog, it is too strange to blame on update && upgrade. In fact I tried to roll back to former version of my software, but it doesn't help.

Besides, as I finished ./install.sh and reboot, my host OS can't make simple kernel module like helloworld, it says:

ERROR: Kernel configuration is invalid etc...

I wonder if you have any suggestions on how to resolve this issue....Or maybe it's time to repair our server...?..

Earlier this year, approximately on March 16, 2023, my colleague was able to successfully launch virtual machines on the same server, running the same version of QEMU and the operating system, with -svsm enabled.

PS: after my 'update & upgrade', my colleague can't launch his project with svsm.bin either...
PS: I've tested the Qemu version of cocosvsm, our server can build the Host OS & OVMF & Qemu & Guest OS of cocosvsm successfully, but the qemu also got stuck when I input svsm.bin of linux-svsm project.....

Looking forward to your reply And great thanks for this project.

SVSM Boot Args Support

Just like the linux kernel, we can propagate the cmdline to the kernel with QEMU. A seperate cmdline support for SVSM may be useful!

A problem occurred when running with SVSM

Hello, everyone! Here comes a problem with commit-id: 6c164e3!

commit 6c164e3a4d9adddda7e0c4f952dbe631db68d720 (main)
Author: Carlos Bilbao <[email protected]>
Date:   Fri Sep 30 16:42:02 2022 -0500

    SVSM: cpu: smp: Make types of variables explicit
    
    Make variable definitions explicit on type as to contribution guidelines.
    
    Signed-off-by: Carlos Bilbao <[email protected]>

After following the instructions in README.md, I can successfully run the built host-kernel and guest-kernel on my machine without -svsm svsm.bin. Here provides some basic information. It indicates no problem with AMD SEV-SNP hardware and firmware configuration.

public@super-server:~$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 22.04.1 LTS
Release:	22.04
Codename:	jammy
public@super-server:~$ uname -msr
Linux 5.14.0-rc2-snp-host-e5db36696347 x86_64
public@super-server:~$ dmesg | grep -E 'sev|SEV'
[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-5.14.0-rc2-snp-host-e5db36696347 root=UUID=f0d15ade-1929-442a-b1f8-befb36389d13 ro mem_encrypt=on kvm_amd.sev=1 quiet splash vt.handoff=7
[    0.119153] Kernel command line: BOOT_IMAGE=/vmlinuz-5.14.0-rc2-snp-host-e5db36696347 root=UUID=f0d15ade-1929-442a-b1f8-befb36389d13 ro mem_encrypt=on kvm_amd.sev=1 quiet splash vt.handoff=7
[    0.985389] SEV-SNP: RMP table physical address 0x0000000098400000 - 0x00000000a89fffff
[    5.695363] ccp 0000:22:00.1: sev enabled
[    5.757488] ccp 0000:22:00.1: SEV firmware update successful
[    6.801389] ccp 0000:22:00.1: SEV-SNP API:1.51 build:3
[    6.844191] SEV supported: 410 ASIDs
[    6.844192] SEV-ES and SEV-SNP supported: 99 ASIDs
[ 3239.669457] SEV-ES guest requested termination: 0xf:0x1

After running the following command line either with or without -sev-snp, I can select the grub menu and log into Ubuntu.

$ sudo ./launch-qemu.sh -hda guest.raw -append 'console=tty0 console=ttyS0,115200n8' -vnc 1
$ sudo ./launch-qemu.sh -hda guest.raw -append 'console=tty0 console=ttyS0,115200n8' -vnc 1 -sev-snp

Here is basic information about the guest-os running with -sev-snp, also the guest os-release is Ubuntu 22.04.1 LTS.

public@sev-snp-guest:~/Desktop$ uname -msr
Linux 5.17.0-rc6-snp-guest-3f7b2e900f58 x86_64
public@sev-snp-guest:~/Desktop$ dmesg | grep -E 'sev|SEV|VMPL'
[    2.827500] AMD Memory Encryption Features active: SEV SEV-ES SEV-SNP
[    3.071393] SEV: SNP running at VMPL0.
[    3.071395] SEV: Using SNP CPUID table, 31 entries present.
[    3.213723] SEV: SNP guest platform device initialized.
[    4.538742] systemd[1]: Hostname set to <sev-snp-guest>.
public@sev-snp-guest:~/Desktop$ 

It indicates that the configuration of the guest-os has no problem with -sev-snp, and the kernel of guest-os is running under VMPL0. Then, I run make all under linux-svsm folder, the svsm.bin is produced without errors. However, I cannot start the guest-os with -svsm svsm.bin, as shown below

sudo ./launch-qemu.sh -hda guest.raw -append 'console=tty0 console=ttyS0,115200n8' -vnc 1 -sev-snp -svsm svsm.bin

Here is the error log, it ends with a series of ?? ??

public@super-server:/media/public/linux-svsm/scripts/snp-release-2022-10-10$ sudo ./launch-qemu.sh -hda guest.raw -append 'console=tty0 console=ttyS0,115200n8' -vnc 1 -sev-snp -svsm svsm.bin 
trap: SIGINT: bad trap
./launch-qemu.sh: 264: [: 16G: unexpected operator
./launch-qemu.sh: 338: [[: not found
Starting VNC on port 1
./usr/local/bin/qemu-system-x86_64 -enable-kvm -cpu EPYC-v4,host-phys-bits=true -smp 64 -m 16G -machine type=q35,memory-encryption=sev0,vmport=off,svsm=svsm.bin -object sev-snp-guest,id=sev0,policy=0x30000,cbitpos=51,reduced-phys-bits=1,init-flags=0x4,host-data=b2l3bmNvd3FuY21wbXA -drive if=pflash,format=raw,unit=0,file=/media/public/linux-svsm/scripts/snp-release-2022-10-10/usr/local/share/qemu/OVMF_CODE.fd,readonly=on -drive if=pflash,format=raw,unit=1,file=./guest.fd -drive file=guest.raw,if=none,id=disk0,format=raw -device virtio-scsi-pci,id=scsi0,disable-legacy=on,iommu_platform=true -device scsi-hd,drive=disk0 -nographic -vnc :1 -monitor pty -monitor unix:monitor,server,nowait -netdev user,id=vmnic -device e1000,netdev=vmnic,romfile= 
Mapping CTRL-C to CTRL-]
Launching VM ...
  /tmp/cmdline.7778
char device redirected to /dev/pts/4 (label compat_monitor0)
error: kvm run failed Invalid argument
EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000000
ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000
EIP=00000000 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0000 00000000 00000000 00000000
CS =0000 00000000 00000000 00000000
SS =0000 00000000 00000000 00000000
DS =0000 00000000 00000000 00000000
FS =0000 00000000 00000000 00000000
GS =0000 00000000 00000000 00000000
LDT=0000 00000000 00000000 00000000
TR =0000 00000000 00000000 00000000
GDT=     0000000000000000 00000000
IDT=     0000000000000000 00000000
CR0=80010033 CR2=0000000000000000 CR3=0000000000000000 CR4=00000668
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 
DR6=00000000ffff0ff0 DR7=0000000000000400
EFER=0000000000001d00
Code=<??> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??

For simplicity, the command line to run QEMU is shown below:

./usr/local/bin/qemu-system-x86_64 \
               -enable-kvm -cpu EPYC-v4,host-phys-bits=true \
               -smp 64 -m 16G \
               -machine type=q35,memory-encryption=sev0,vmport=off,svsm=svsm.bin \
               -object sev-snp-guest,id=sev0,policy=0x30000,cbitpos=51,reduced-phys-bits=1,init-flags=0x4,host-data=b2l3bmNvd3FuY21wbXA \
               -drive if=pflash,format=raw,unit=0,file=/media/public/linux-svsm/scripts/snp-release-2022-10-10/usr/local/share/qemu/OVMF_CODE.fd,readonly=on \
               -drive if=pflash,format=raw,unit=1,file=./guest.fd \
               -drive file=guest.raw,if=none,id=disk0,format=raw \
               -device virtio-scsi-pci,id=scsi0,disable-legacy=on,iommu_platform=true \
               -device scsi-hd,drive=disk0 \
               -nographic \
               -vnc :1 \
               -monitor pty \
               -monitor unix:monitor,server,nowait \
               -netdev user,id=vmnic \
               -device e1000,netdev=vmnic,romfile= 

However, after pulling the following commit and rebuilding the vmsa.bin with make all,

commit 8dd35c702837d393c3aa98d7178257f3e88237d0 (origin/main, origin/HEAD)
Merge: 962ca6f cc370ea
Author: Carlos Bilbao <[email protected]>
Date:   Tue Oct 11 15:13:38 2022 -0500

    Merge pull request #12 from Zildj1an/main
    
    Ensure VMPLs executed with required and supported SEV features.
    Signed-off-by: Carlos Bilbao <[email protected]>

and running launch-qemu.sh with -svsm -svsm.bin, here comes similar errors:

public@super-server:/media/public/linux-svsm/scripts/snp-release-2022-10-10$ sudo ./launch-qemu.sh -hda guest.raw -append 'console=tty0 console=ttyS0,115200n8' -vnc 1 -sev-snp -svsm svsm.bin 
[sudo] password for public: 
trap: SIGINT: bad trap
./launch-qemu.sh: 264: [: 16G: unexpected operator
./launch-qemu.sh: 338: [[: not found
Starting VNC on port 1
./usr/local/bin/qemu-system-x86_64 -enable-kvm -cpu EPYC-v4,host-phys-bits=true -smp 64 -m 16G -machine type=q35,memory-encryption=sev0,vmport=off,svsm=svsm.bin -object sev-snp-guest,id=sev0,policy=0x30000,cbitpos=51,reduced-phys-bits=1,init-flags=0x4,host-data=b2l3bmNvd3FuY21wbXA -drive if=pflash,format=raw,unit=0,file=/media/public/linux-svsm/scripts/snp-release-2022-10-10/usr/local/share/qemu/OVMF_CODE.fd,readonly=on -drive if=pflash,format=raw,unit=1,file=./guest.fd -drive file=guest.raw,if=none,id=disk0,format=raw -device virtio-scsi-pci,id=scsi0,disable-legacy=on,iommu_platform=true -device scsi-hd,drive=disk0 -nographic -vnc :1 -monitor pty -monitor unix:monitor,server,nowait -netdev user,id=vmnic -device e1000,netdev=vmnic,romfile= 
Mapping CTRL-C to CTRL-]
Launching VM ...
  /tmp/cmdline.5419
char device redirected to /dev/pts/3 (label compat_monitor0)
error: kvm run failed Invalid argument
EAX=00000000 EBX=00000000 ECX=00000000 EDX=00800f12
ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000
EIP=00000000 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0000 00000000 00000000 00000000
CS =0000 00000000 00000000 00000000
SS =0000 00000000 00000000 00000000
DS =0000 00000000 00000000 00000000
FS =0000 00000000 00000000 00000000
GS =0000 00000000 00000000 00000000
LDT=0000 00000000 00000000 00000000
TR =0000 00000000 00000000 00000000
GDT=     0000000000000000 00000000
IDT=     0000000000000000 00000000
CR0=80010033 CR2=0000000000000000 CR3=0000000000000000 CR4=00000668
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 
DR6=00000000ffff0ff0 DR7=0000000000000400
EFER=0000000000001d00
Code=?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? <??> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??

Any help will be appreciated!

vTPM support

Hello,
does linux-svsm already implements vTPM support and are there some examples that show how to use this to achieve vTPM in the Guest OS?

`address_valid` can be bypassed

The address_valid is used to check whether VMPL1 is allowed to access a given address. It does this by comparing the address with the SVSM's memory and the list of VMSAs.
These checks can be bypassed by setting the C-bit in the address because address_valid only compares with addresses without the C-bit.
AFAICT this isn't exploitable because it always eventually triggers an overflow check in pgtable_pa_to_va, however if the SVSM were to be compiled in release mode, overflow checks would be disabled and this would be exploitable.

OVMF fails to build on nasm versions < `2.15.01`

Intel CET support was introduced on nasm from v2.15.01. On older nasm versions, OVMF fails to build with

"nasm" -I/local/devel/linux-svsm/scripts/ovmf/MdePkg/Library/BaseLib/X64/ -I/local/devel/linux-svsm/scripts/ovmf/MdePkg/Library/BaseLib/X64/ -I/local/devel/linux-svsm/scripts/ovmf/MdePkg/Library/BaseLib/ -I/local/devel/linux-svsm/scripts/ovmf/Build/Ov
mfX64/DEBUG_GCC5/X64/MdePkg/Library/BaseLib/BaseLib/DEBUG/ -I/local/devel/linux-svsm/scripts/ovmf/MdePkg/ -I/local/devel/linux-svsm/scripts/ovmf/MdePkg/Include/ -I/local/devel/linux-svsm/scripts/ovmf/MdePkg/Test/UnitTest/Include/ -I/local/devel/linux-
svsm/scripts/ovmf/MdePkg/Include/X64/ -f elf64 -o /local/devel/linux-svsm/scripts/ovmf/Build/OvmfX64/DEBUG_GCC5/X64/MdePkg/Library/BaseLib/BaseLib/OUTPUT/X64/LongJump.obj /local/devel/linux-svsm/scripts/ovmf/Build/OvmfX64/DEBUG_GCC5/X64/MdePkg/Library
/BaseLib/BaseLib/OUTPUT/X64/LongJump.iii
/local/devel/linux-svsm/scripts/ovmf/Build/OvmfX64/DEBUG_GCC5/X64/MdePkg/Library/BaseLib/BaseLib/OUTPUT/X64/LongJump.iii:44: error: parser: instruction expected
/local/devel/linux-svsm/scripts/ovmf/Build/OvmfX64/DEBUG_GCC5/X64/MdePkg/Library/BaseLib/BaseLib/OUTPUT/X64/LongJump.iii:49: error: parser: instruction expected
make: *** [GNUmakefile:791: /local/devel/linux-svsm/scripts/ovmf/Build/OvmfX64/DEBUG_GCC5/X64/MdePkg/Library/BaseLib/BaseLib/OUTPUT/X64/LongJump.obj] Error 1


build.py...
 : error 7000: Failed to execute command
        make tbuild [/local/devel/linux-svsm/scripts/ovmf/Build/OvmfX64/DEBUG_GCC5/X64/MdePkg/Library/BaseLib/BaseLib]


build.py...
 : error F002: Failed to build module
        /local/devel/linux-svsm/scripts/ovmf/MdePkg/Library/BaseLib/BaseLib.inf [X64, GCC5, DEBUG]

on File LongJump.iii

    41      push rdx ; save rdx
    42
    43      mov rdx, [rcx + 0xF8] ; rdx = target SSP
 -> 44      rdsspq rax
    45      sub rdx, rax ; rdx = delta
    46      mov rax, rdx ; rax = delta
    47
    48      shr rax, 3 ; rax = delta/sizeof(UINT64)
 -> 49      incsspq rax
    50

You need to upgrade nasm to v2.15.01 or later to successfully compile. The README.md states that the entire setup is tested on Ubuntu 22.04 which has nasm v2.15.05-1. So, this is not an issue.

Just leaving it here, in case if anyone encounters it.

where does certs_table go?

it looks like most guest tools expect the cert chain to be returned in the "extended report",
in my case its empty.

but going through the steps in this repo, they are never passed to qemu anywhere, and i don't see where that would even be done.

https://developer.amd.com/wp-content/resources/56421.pdf says they go in DATA_GPA

but there's no mention of that in the svsm source code

Bugs with rust 1.71.0-nightly

I updated my Rust toolchain:

$ cargo --version
cargo 1.71.0-nightly (de80432f0 2023-04-21)

Now I'm running into two problems (so far):

1. Feature alloc_handler_error no longer exists:

   Compiling linux_svsm v0.1.0 (/home/dov/linux-svsm)
error[E0557]: feature has been removed
  --> src/lib.rs:11:12
   |
11 | #![feature(alloc_error_handler)]
   |            ^^^^^^^^^^^^^^^^^^^ feature has been removed
   |
   = note: now handled by panic handler

error: cannot find attribute `alloc_error_handler` in this scope
    --> src/mem/alloc.rs:1145:3
     |
1145 | #[alloc_error_handler]
     |   ^^^^^^^^^^^^^^^^^^^
     |
     = note: `alloc_error_handler` is in scope, but it is a function, not an attribute

For more information about this error, try `rustc --explain E0557`.
error: could not compile `linux_svsm` (lib) due to 2 previous errors

It seems that the default implemenation of the alloc error is to panic, which is good for us (it'll call our custom panic handler). If I delete all mentions of alloc_error_handler, I can successfully build linux-svsm.

2. When I run linux-svsm, I get this:

Launching VM ...
  /tmp/cmdline.74246
char device redirected to /dev/pts/10 (label compat_monitor0)
> All 18 firmware config files read.
> Starting SMP for 7 APs:
-- AP 1/7 initialized.
-- AP 2/7 initialized.
-- AP 3/7 initialized.
-- AP 4/7 initialized.
-- AP 5/7 initialized.
-- AP 6/7 initialized.
-- AP 7/7 initialized.
PANIC!
panicked at 'misaligned pointer dereference: address must be a multiple of 0x4 but is 0xffff8000ffffff6e', src/bios.rs:203:23
PANIC!

I haven't yet started debugging this (or tried to understand why this behaviour has changed).

Maybe it's time to update Documentation about GHCB standardlizations?

Thank you for this awesome project! I've learnt a lot about AMD SEV-SNP when reading the source code in this project.

I wonder will the Documentation about GHCB standardlizations be updated soon? As I read the source code, I came across some Parameters like GHCB_NAE_GET_APIC_IDS, GHCB_NAE_RUN_VMPL. In the SVSM draft file, it mentioned that new protocols parameters like this will be added and explained further in GHCB standlization file.

This request is made in one of two ways, either by using
the GHCB MSR protocol with a value of 0x16 or by setting GHCB fields
SW_EXITCODE=0x8000_0017 and SW_EXITINFO1=0. (See the GHCB Specification for further
details.)

However, the above Parameters seemed not documented in the GHCB standardlizations file yet, so will this standardlization file be updated soon?

Looking forward to your reply and many thanks to your efforts!😊

Unit tests broke after inclusion of Rust wrappers

The commit that adds Rust wrappers required by external dependencies (this one) broke make test, that runs for ever. This issue seems to be related with the inclusion of pub mod wrapper since we can run the tests by editing lib.rs:

#[cfg(not(test)]
pub mod wrapper;

However, this is not a real solution since we want to be able to run tests of OpenSSL too.

Use the `x86_64-unknown-none` built-in target to make distro packaging easier

@cuviper and @berrange mentioned in the discussion below that it is highly desirable to avoid application specific build targets. From a distro packaging perspective, it would be better to get rid of the current target json file (svsm-target.json) and use the x86_64-unknown-none built-in target.

#35 (comment)

apic_id_for() returning `cpu_id`

linux-svsm/src/cpu/percpu.rs

Line 145 in f68a6c7

apic_id = (*p).cpu_id;

shouldn't this be

            apic_id = (*p).apic_id;

?

Moving from rustup/nightlies to standard rust

The SVSM cannot be packaged by any distribution until it can be built by a standard and released version of rust. How far away from this are we? The main reason I thought we needed nightlies was asm() which went into 1.59, and has been picked up by the distributions. Can we now try moving away from rust nightlies and see if it can be made to work?

ubuntu 22 does not work with -nographic

the readme says it's been tested with ubuntu 22, but the 22 installer doesnt actually work in qemu -nographic.
it'll just hang here (output likely unrelated)

ConvertPages: range 1000000 - 462DFFF covers multiple entries
ConvertPages: range 1000000 - 462DFFF covers multiple entries
CpuDxe: 5-Level Paging = 0
MpInitChangeApLoopCallback() done!
SetUefiImageMemoryAttributes - 0x000000007FAE6000 - 0x0000000000009000 (0x0000000000000008)
SetUefiImageMemoryAttributes - 0x000000007FADF000 - 0x0000000000007000 (0x0000000000000008)
SetUefiImageMemoryAttributes - 0x000000007FAD9000 - 0x0000000000006000 (0x0000000000000008)
SetUefiImageMemoryAttributes - 0x000000007FAD2000 - 0x0000000000007000 (0x0000000000000008)
SetUefiImageMemoryAttributes - 0x000000007FAC2000 - 0x0000000000010000 (0x0000000000000008)
SetUefiImageMemoryAttributes - 0x000000007FABD000 - 0x0000000000005000 (0x0000000000000008)
SetUefiImageMemoryAttributes - 0x000000007FAB6000 - 0x0000000000007000 (0x0000000000000008)
SetUefiImageMemoryAttributes - 0x000000007FAB2000 - 0x0000000000004000 (0x0000000000000008)
SetUefiImageMemoryAttributes - 0x000000007FAAD000 - 0x0000000000005000 (0x0000000000000008)

How to capture the outputs of serial_out in the terminal?

Hello, everyone. Here comes a problem!

I noticed that the prints macro can be used to write a string to the serial output. However, after running guest-os with linux-svsm support successfully, I can not find the outputs of prints macro in the complete booting logs on the screen. The command line to boot the guest-os is as following.

sudo ./launch-qemu.sh -hda guest.raw -sev-snp -svsm svsm.bin

So how can I enable the serial output of the Qemu, such that I can capture the prints from svsm in the terminal. Any help would be appreciated.