SNPGuard: Remote Attestation of SEV-SNP VMs Using Open Source Tools
Luca Wilke

Gianluca Scopelliti

University of Lübeck, Germany
l.wilke@uni-luebeck.de

Ericsson Security Research, Sweden
KU Leuven, Belgium
gianluca.scopelliti@ericsson.com

Abstract—Cloud computing is a ubiquitous solution to handle
today’s complex computing demands. However, it comes withdata privacy concerns, as the cloud service provider has complete access to code and data running on their infrastructure.
VM-based Trusted Execution Environments (TEEs) are apromising solution to solve this issue. They provide strong
isolation guarantees to lock out the cloud service provider,as well as an attestation mechanism to enable the end user toverify their trustworthiness. Attesting the whole boot chainof a VM is a challenging task that requires modifications toseveral software components. While there are open source
solutions for the individual components, the tooling anddocumentation for properly integrating them remains scarce.
In this paper, we try to fill this gap by elaborating on two
common boot workflows and providing open source toolingto perform them with low manual effort. The first workflow
assumes that the VM image does only require integrity
but not confidentiality, allowing for an uninterrupted bootprocess. The second workflow covers booting a VM withan encrypted root filesystem, requiring secure provisioningof the decryption key during early boot. While our toolingtargets AMD Secure Encrypted Virtualization (SEV) VMs,
the concepts also apply to other VM-based TEEs such asIntel Trusted Domain Extensions (TDX).

1. Introduction
Cloud computing revolutionized the way businesses
and individuals utilize computing resources. Instead ofowning and maintaining physical servers or data centers,
users rent them from large cloud service providers ona pay-as-you-go basis, allowing unprecedented flexibility
and scalability. One major concern with shifting computation to the cloud is data privacy. Trusted Execution
Environments (TEEs) aim to solve this challenge, allowing
to execute software on remote machines without the needto trust their operator. To this end, they provide strong(cryptographic) runtime isolation guarantees as well as an
attestation feature to prove their trustworthiness to the end
user. Early designs like Intel Security Guard Extensions(SGX) were process-scoped and required software to be
rewritten, hindering adoption. More recent TEE designs
like AMD Secure Encrypted Virtualization (SEV) andIntel Trust Domain Extensions (TDX) use a different
approach by protecting whole Virtual Machines (VMs)
to achieve a lift and shift solution. These VMs are also
known as Confidential Virtual Machines (CVMs). Similar
to booting a physical machine, booting a CVM includes
several software components and layers. As result, thecorrect attestation of CVMs is quite complex, requiringchanges to several components of the software stack suchas guest firmware and kernel. Nonetheless, without proper(remote) attestation the VM owner cannot verify that their
CVM has not been tampered with. Cloud providers like
Microsoft Azure [18] have solved this challenge, but theirsolution relies on closed-source, proprietary software. As
a result, the VM owner cannot verify these components,
requiring them to again trust the cloud service provider,partially defeating the purpose of TEEs.
In this paper, we introduce an easy-to-use, open source
tool that tackles this challenge for AMD SEV-Secure
Nested Paging (SNP), the latest iteration of SEV. While
there already exist several individual components that areopen source, to the best of our knowledge there is no
unified tool that provides a full workflow from the initial
CVM preparation to its deployment, attestation, and secretprovisioning. As a result, a high manual effort and someexpertise are still required by the VM owner. Our tool
solves this issue by integrating these existing components
and providing templates for common use cases.
In principle, our ideas should generalize to similar
VM-based TEE technologies such as Intel TDX, and in the
future we aim at supporting them as well. Our main goal
is to provide a solid foundation for future research thatwants to either build on top of CVMs or experiment with
tweaking the individual components. We also hope that
our tool will make CVMs more accessible to developers.
While our design is technically similar to Revelio [7], theircode does not seem to be publicly available. Additionally,in contrast to libkrun [17], which tries to minimize VM
size and boot time, we use the feature-rich reference
implementations for the individual components. Finally,
Pontes et al. [20] developed an open source integrationfor SEV-SNP attestation with the SPIFFE framework [23].
SPIFFE aims to standardize secret injection into services.
In contrast to our tool, Pontes et al. do not provide toolingfor configuring and setting up the SEV-SNP VM. In
addition, their dependency on SPIFFE requires a more
complex setup, while our tool is focussed on providing
building blocks that can be easily set up and customized.
The remainder of this paper is organized as follows:
Sect. 2 defines the attacker scenario and gives backgroundon AMD SEV-SNP. In Sect. 3 and Sect. 4 we describe ourtool and give implementation details. In Sect. 5 we discuss
remaining problems and future work, and in Sect. 6 wesummarize our paper.

2. AMD SEV-SNP in a Nutshell
SEV-SNP [2], [3] is a TEE that protects the confidentiality and integrity of whole VMs against an attacker
with root privileges and physical access to the machine,
enabling to run SEV-protected VMs without trusting theinfrastructure provider and virtualization layers such as
the hypervisor.
The root-of-trust of an AMD CPU is the AMD Secure
Processor (SP) (formerly known as PSP), a coprocessor
that hosts the SEV-SNP firmware and performs securitycritical operations like generating and managing memory
encryption keys. Each protected VM is assigned a unique
AES-128 key that is used to encrypt its data before itis written to the RAM. Inside the CPU, an access-rightbased system is used to protect data in the guest VM.
In addition, the Reverse Map Table (RMP) prevents thehypervisor or other tenants from writing to VM memory,ensuring integrity. Moreover, SEV-SNP introduced Virtual
Machine Privilege Levels (VMPLs), an additional set of
hardware enforced privilege levels than can be used by the
VM. This enables use cases like running a virtual TPM(vTPM) inside a secure VM, on a higher privilege layer
than the rest of the software stack.
The AMD SP contains a chip-unique signing key
called Chip Endorsement Key (CEK), derived from secrets stored in chip’s fuses. This key is used to derive
other keys such as the Versioned Chip Endorsement Key(VCEK), used to sign attestation reports. The VCEK
also depends on the version number of the SP firmware
and the CPU microcode. This allows a verifier to attest
that the platform where a secure VM is running has
an up-to-date software stack. A public key infrastructureis used to certify the VCEK from AMD’s root certificates, ensuring the authenticity of attestation reports. Recently, the SP firmware started to support an alternative
to the VCEK called Versioned Loaded Endorsement Key(VLEK), which identifies a specific cloud provider. Whenrequesting an attestation report, the VCEK and VLEK canbe used interchangeably.

3. Design
In this section we describe the high level design of
our tool. Implementation details will be given in Sect. 4.
We designed our tool with two main goals in mind:
1) Integrity of the VM boot chain. It is paramount that
we ensure that the deployed VM is in a good, known
state. This is typically done via remote attestation,although confidential VMs have additional challenges
because their boot process follows multiple stages.
Normally, the launch measurement included in the
SEV-SNP attestation report only covers the guest
firmware, hence there is a need to extend this measurement to later stages such as kernel, initial RAM
disk (initramfs), and eventually the root filesystem.
2) Secret provisioning. A typical confidential workflow
involves injecting some kind of secrets into the deployed TEE instance, e.g., private keys, sensitive datasuch as personal identifiable information, or intellectual property such as AI models. Our tool supports
two modes of secret provisioning, i.e., at runtime andat rest. In the first case, the VM initially does not

Figure 1: Trust chain of the software stack running inside
the VM that shows how to use the SEV measurement
as a trust anchor for software-based measurements. The
control flow is bottom to top.
contain any secrets, which are only injected after bootvia a secure channel established upon remote attestation. In the second case, the VM’s root filesystem
requires confidentiality and is thus encrypted before
transmission to the hypervisor. As a result, we needto enable provisioning the disk encryption key during
early boot.
To achieve the above goals, our tool uses a twostage approach. The first stage covers the first part of
the VM boot process and includes guest firmware, kernel,
initramfs and kernel command line parameters. Here, we
assume that these components do not contain any secrets
and come from known (e.g., open source) code. Thus,
we only need to ensure their integrity (Goal 1). The
second stage consists of the VM’s root filesystem, which
may or may not contain secrets (Goal 2). Here, integrity
is always mandatory, but confidentiality is optional. To
ensure the integrity of the first stage, we use the SEVSNP isolation and attestation features. To achieve integrity
and confidentiality for the second stage, we use the disk
protection techniques supported by the Linux kernel.

3.1. First StageThe very first piece of code that is executed after
starting the SEV-SNP VM is the firmware, which has to be
SEV-SNP-aware in order to correctly set up the VM, e.g.,by allocating memory pages and configuring page bits. To
achieve this, we use the SEV-SNP-enabled version of the
OVMF [1] UEFI implementation.
Normally, the launch measurement in the SEV-SNP
attestation report only includes the memory content of
the OVMF firmware and the initial register state of the
VM’s virtual CPUs. However, there is an SNP-enabled
OVMF firmware version that supports extending the measurement to include the kernel, the initramfs and the kernel
command-line parameters, which are then loaded using
Direct Linux Boot [21]. Fig. 1 shows an overview of themechanism. In short, before loading OVMF into memory,the hypervisor measures those components and adds thecorresponding hashes in a special section of the OVMF
binary. Afterwards, the “hot-patched” version of OVMF
is loaded into memory, making the injected hash values
for the kernel, initramfs and kernel command line partof the SEV-SNP launch measurement. At runtime, before
transferring the execution to the Linux kernel, OVMF
re-computes the measurements of each component andcompares them against the stored reference value, failingto boot if they do not match. As a result, we can use
the remote attestation features of SEV-SNP to prove theintegrity and authenticity of the first stage to the VM
owner.
With SEV-SNP, the code inside the VM is responsible
for requesting the attestation report. The report is signedby the AMD SP whose public key can be verified using
a publicly available certificate chain. Thus, it is safe totransmit the attestation report over an unprotected channel.
To prevent an attacker from replaying an old attestation
report, we make use of the “Guest Data” field, whichallows the VM to include 64 bytes of arbitrary data
into the signed attestation report, to include a nonce sentby the VM owner. By checking that the report contains
the expected nonce, the VM owner can verify that theyreceived a fresh report.

3.2. Second Stage
With the first stage, we can ensure the integrity of theguest VM up to the so-called early userspace, i.e., where
the initial RAM disk is mounted into memory and some
initial configuration of the VM is done before passing
control to the “real” root filesystem. However, as SEVSNP does not provide protection of code and data at rest,
we need other mechanisms to ensure the integrity and(optionally) confidentiality of persistent disks, which canotherwise be easily accessed by the hypervisor.
Depending on whether the root filesystem requires
confidentiality, our tool offers two different approaches tosecret provisioning (Goal 2). If the root filesystem does
not contain any secret data, the VM can boot uninterrupted
and we can later verify that the VM is in a good state via
attestation. Secrets may still be injected after the VM has
fully booted. If the root filesystem should remain secret,
we need to provision it in encrypted form. As a result,
the VM cannot boot past the first stage without having
provisioned the decryption key. Therefore, we necessarilyneed to perform both attestation and secret provisioning
during early boot. Below, we describe the two approaches
in more detail.
Integrity-only Workflow The main idea here is that we
do not want to “pause” the boot process, but insteadallow the VM to boot without any intervention, and only
later, whenever needed, attest it and provision secrets. To
achieve this goal, we leverage the dm-verity utility [14]to ensure the integrity of the root filesystem. In short, thefilesystem is divided into blocks of a predefined size, andeach of them is measured using a hash function (e.g.,
SHA-256). All hashes are then stored in a Merkle tree on
a separate data disk, leaving the original root filesystem
unmodified. The root of the Merkle tree, called root
hash, guarantees the integrity of the whole filesystem andneeds to be stored separately. When the root filesystem isVM

VM Owner
Nonce1) Fetch Attestation Report
2) Generate DH Key Pair
Attestation Report {...
GuestData=Nonce || Server PDHK...}
1) Verify Report
2) Generate DH Key Pair
3) Derive Shared Secret4) Wrap Disk Encryption Key
with Shared Secret
Client PDHK ||Wrapped Disk Encryption Key
1) Derive Shared Secret2) Unwrap Disk Key

Figure 2: Protocol that uses the Guest Data field in theattestation report to securely send a disk encryption key tothe VM. DH stands for Diffie-Hellman and PDHK refers
to the public part of the DH key.

mounted, during early userspace, dm-verity takes as
input the data disk and root hash and verifies the integrity
the filesystem. Besides, integrity is checked at each read,
resulting in a kernel panic if a violation is discovered.
With this approach, the integrity of the root filesystem
can be reduced to the integrity of the root hash, which has
to be provisioned to the guest VM without tampering, butdoes not require confidentiality. We solve this problem
by adding the hash as a kernel parameter. As the firststage already ensures the integrity of the kernel commandline parameters, this approach naturally extends the VM’s
integrity guarantees to the root filesystem. This can beverified, at any moment, by the usual remote attestation
procedure.
One caveat of dm-verity is that the root filesystem
is mounted as read-only, which may not be acceptable
for all applications. Besides, there are partitions in thefilesystem that need to be read-write for the VM to function properly, e.g., /home, /tmp and /var. We solve
this problem by creating one tmpfs filesystem [15] foreach partition that needs to be read-write. These filesystems will only reside in memory, thus their integrity andconfidentiality are preserved at runtime by SEV-SNP. This
process is done in the initramfs where, after opening andverifying the dm-verity filesystem, files are copied tothe tmpfs partitions.
Clearly, secrets such as cryptographic keys should
be deleted from the root filesystem when choosing thisworkflow, as there is no confidentiality at rest. Our tool
helps with this process by automatically deleting all SSH
keys from /etc/ssh when preparing the dm-verity
filesystem. Those keys are then regenerated in earlyuserspace and stored in the tmpfs partitions, such thatthe guest owner can safely connect to the CVM at runtime.
Afterwards, they can retrieve the attestation report toverify its boot chain.
Integrity+Confidentiality Workflow For this workflow,
the VM owner encrypts the root filesystem with
dm-crypt [12] before sending it to the untrusted hypervisor. dm-crypt can also be configured to ensureintegrity protection by leveraging dm-integrity [13]under the hood. To unlock the encrypted disk for thesecond stage, the first stage needs access to the encryption
key. Thus, we need to build an encrypted channel between
the VM owner and the VM to transfer the key. To achievethis, we again leverage the “Guest Data” field to perform a
Diffie-Hellman (DH) key exchange, as depicted in Fig. 2.
The VM owner starts the process by requesting the attestation report, using a nonce to ensure freshness. Next,
the VM generates an ephemeral DH key and includes
the public part in the “Guest Data” field, together with
the nonce. After verifying the attestation report, the VM
owner uses their ephemeral DH key pair to derive ashared secret and uses it to encrypt the disk encryption
key using an authenticated encryption scheme. Finally, theVM owner sends both the encrypted disk encryption key
and the public part of their DH key to the VM. While
the VM authenticates to the guest owner by providing avalid attestation report, the VM owner implicitly proves
their authenticity to the VM by providing the correct disk
encryption key.
The code inside the VM uses the public DH key of theVM owner to derive the shared secret as well, allowing it
to decrypt the disk encryption key. Now, we can unlock
and transfer control to the root filesystem by executing its
init script, bringing up the rich userspace environment of
the VM. After the initialization of the second stage hascompleted, the VM owner can, e.g., use SSH to connect
to the VM. Since the second stage image was encrypted
before it was transferred to the untrusted hypervisor, theVM owner can securely store the private key of the SSH
server as well as the list of public keys that are allowed
to log in inside the image.
Comparison Both workflows have pros and cons. Whilethe integrity-only workflow does not offer confidentiality at rest, the encrypted workflow necessarily requires users to pause the boot process to get theroot filesystem’s decryption key. Besides, dm-verity
might have a better I/O performance compared to
dm-crypt+dm-integrity, but at the same time
mounting some partitions as tmpfs in the integrity-only
workflow would incur some boot latency (for copying
files) and increase memory usage. Users should therefore
choose the workflow that is best suitable for their use
case.

use AMD’s official forks [1] for both. However, mostfeatures are also available in the official upstream versions.
For OVMF, we need to build the AmdSev/AmdSevX64.dsc
target instead of the default OvmfPkgX64.dsc target usedby the build script in the AMD repository. This enables
OMVF’s support for extending the SEV launch measurement to the kernel (cf. Sect. 3).
Building the initramfs. We require modifications to theinitramfs to support integrity and encryption of the root
filesystem. The initramfs is a minimal filesystem that
contains scripts, kernel modules, applications and configuration files that are required to bootstrap the VM andmount the root filesystem.
To build our custom initramfs, we leverage Docker [6]to create a container image with all the required tools.
This approach allows us to easily install components withcomplex dependencies. Afterwards, we export all layersof our container image into a single folder and convert
it to the initramfs format. For the init binary inside theinitramfs we use a small shell script that calls a series ofapplications to orchestrate the boot process and eventuallymounts the filesystem for the second stage. Next, theinit script uses switch root [10] to unmount the current
initramfs filesystem and jump into the root filesystemusing the contained init script as the entry point for the
execution, taking care of starting the services containedin the second stage. One caveat with this approach is thatthe second stage will still use the initially booted Linuxkernel. We discuss implications and potential solutionsin Sect. 5.
If full disk encryption is used, the first stage needs
access to the disk encryption key before it can proceedwith the boot process. To provision the key, we performthe remote attestation protocol described in Sect. 3.2
which we implemented based on the open source sev
library developed by the VirTEE community [25].
Building the second stage image. For preparing the root
filesystem that is mounted in the second stage we startfrom an existing Linux filesystem that can be createdlocally via usual means, such as creating a new VM
from scratch and installing a fresh Linux distribution.
Afterwards, we provide tools and scripts to extract thefilesystem from the VM image, make the necessary adjustments, and generate the corresponding Merkle tree (ifdm-verity is used) or to create an encrypted copy (ifdm-crypt is used).

4. Implementation
5. Limitations and Future Work
This section gives implementation details for the design outlined in Sect. 3. For the hypervisor, we use thepatched Linux kernel and QEMU versions provided by
AMD [1] in order to run SEV-SNP-enabled VMs. For
the VM, we use the SEV-SNP target of OVMF [24] as
the UEFI, and a self-written client and server for theattestation workflow. In addition, we developed scripts tostreamline the whole setup process. Our tool is available
at https://github.com/SNPGuard/snp-guard.
Building the first stage image. Our first stage image
consists of the OVMF UEFI code plus a Linux kernel,
its command-line parameters, and an initramfs. The latter
three can be provided either separately or as a Unified
Kernel Image (UKI). Both OVMF and the Linux kernel
need to be adapted to work with SEV-SNP. Thus, we

Flexible boot. One limitation of our switch root-based approach for transitioning from the first stage to the second
stage is that it does not change the kernel itself. Thus,
we are still executing the publicly known kernel from thefirst stage. Furthermore, any changes that the second stage
VM does to the kernel or initramfs stored on its /bootpartition do not have any effect. One potential solution forthis issue is to use the Linux kernel’s kexec [16] feature,
which enables booting into a new Linux kernel from analready running kernel. However, we were not able to use
this feature as SEV-SNP support for kexec seems to bework in progress [11].
A more principled solution would be to change thefirst stage image to only include a bootloader like Grubor systemd-boot, instead of a full Linux kernel. Thisway, we could properly boot the second stage using its
kernel and initramfs. In addition, this decouples the launchmeasurement from the second stage image as we nolonger need to change the first stage if we want to use
a different kernel version with our second stage. The
main drawback of this approach is that it would resultin a quite restricted programming environment for the
first stage, which conflicts with our goal of enabling aneasy integration of experimental changes. We leave theimplementation of this approach for a future version of
our tool.
Cloud deployments. Currently, our tool can be used to
deploy CVMs on SEV-SNP-enabled hosts where the guest
owner can control the boot process and the parameters
passed to the CVM at launch. However, cloud providers
such as Amazon Web Services (AWS) [4], Microsoft
Azure [18], and Google Cloud Platform (GCP) [8] currently only provide limited customization options in theirconfidential computing offering where, e.g., it is notpossible to run a custom guest firmware. Unfortunately,
this means that our workflows are not fully supported
on public clouds. While we hope that this situation willchange in the future, users might still benefit from ourtool at present by building individual components (e.g.,encrypting the root filesystem).
Virtual TPM. In the future, we are planning to support
a vTPM inside the guest VM. In SEV-SNP, this canbe achieved by leveraging the SEV-SNP specific VMPL
(c.f. Sect. 2) feature to run a module at the highest
VMPL privilege level that exposes vTPM functionalities
to lower-privileged levels such as the guest OS. Besides,
the vTPM can also be used to measure the first stage ofboot without requiring to inject kernel measurements into
OVMF (cf. Sect. 3.1). Moreover, a vTPM can be combined with the Linux Integrity Measurements Architecture(IMA) [22] to provide runtime attestation of userspace
applications, which would enable integrity protection of
the second stage with minimal changes (cf. Sect. 3.2).
The open source community is actively working on vTPM
support as part of the Secure VM Service Module (SVSM)
project [5], and a full design has been proposed by
Narayanan et al. [19].
Intel TDX. The design in Sect. 3 does not only apply
to SEV-SNP but can be generalized to all VM-based
TEEs. In particular, it would be worthwhile to extend ourtool to also support Intel TDX. Here, the only difference
would concern the first stage to build TDX-aware OVMF
and kernel binaries. Besides, we could leverage TDX’s
Runtime Measurement Registers (RTMRs) [9] to perform
integrity measurements similarly to a vTPM (possibly
combined with Linux IMA).

6. Conclusions
Recent advancements in the confidential computing
landscape have highlighted that there is a need to ease thedevelopment of TEE-based solutions in order to increase
adoption, making this technology accessible even to nonskilled developers. While VM-based TEEs are a significant step in the right direction as they do not require any
modifications in user applications, a lot of manual effort
is still required to configure and properly attest CVM

workloads. With our work, we try to further lower the bar
towards TEE adoption by minimizing the manual effort
required to provision and attest CVMs, and we hope that
our tool can accelerate future TEE research or even be
integrated into the supply chain of cloud workloads in the
future.

Acknowledgements
This research is partially funded by the Research FundKU Leuven, by the Cybersecurity Research Program Flanders, by EU H2020 MSCA-ITN action 5GhOSTS under
grant agreement no. 814035 and by the BMBF project
SASVI.

References[1]

AMD, “AMDSEV Github Repository,” https://github.com/
AMDESE/AMDSEV/tree/snp-latest, Accessed on March 23,
2024.

[2]

——, “AMD SEV-SNP: Strengthening VM Isolation with Integrity
Protection and More,” White Paper, January 2020.

[3]——, “SEV Secure Nested Paging Firmware ABI Specification,”
Specification, September 2023, version 1.55.

[4]

AWS, “AMD SEV-SNP,” https://docs.aws.amazon.com/AWSEC2/
latest/UserGuide/sev-snp.html.

[5]

COCONUT, “COCONUT-SVSM Github Repository,” https://github.com/coconut-svsm/svsm, Accessed on March 23, 2024.

[6]

Docker, “Docker,” https://www.docker.com/, Accessed on March
26, 2024.

[7]

A. Galanou, K. Bindlish, L. Preibsch, Y.-A. Pignolet, C. Fetzer,
and R. Kapitza, “Trustworthy confidential virtual machines
for the masses,” in Proceedings of the 24th International
Middleware Conference, ser. Middleware ’23. New York, NY,
USA: Association for Computing Machinery, 2023, p. 316–328.
[Online]. Available: https://doi.org/10.1145/3590140.3629124[8]

Google Cloud, “Confidential Computing,” https://cloud.google.
com/security/products/confidential-computing.

[9]Intel, “Intel Trust Domain Extensions (Intel TDX) Module Base
Architecture Specification,” Specification, November 2023, version
348549-003US.

[10] P. Jones, J. Katz, and Z. Karel, “switch root man page,” https://man7.org/linux/man-pages/man8/switch root.8.html, Accessed on
March 22, 2024.
[11] V. Karasulli, “x86/snp: Add kexec support,” https://lwn.net/
Articles/965773/, Accessed on March 22, 2024.
[12] kernel.org, “dm-crypt,” https://www.kernel.org/doc/html/latest/
admin-guide/device-mapper/dm-crypt.html, Accessed on March
22, 2024.
[13] ——,“dm-integrity,”
https://docs.kernel.org/admin-guide/
device-mapper/dm-integrity.html, Accessed on March 22,2024.
[14] ——,“dm-verity,”
https://docs.kernel.org/admin-guide/
device-mapper/verity.html, Accessed on March 22, 2024.
[15] ——, “Tmpfs file system,” https://www.kernel.org/doc/html/latest/
filesystems/tmpfs.html, Accessed on May 14, 2024.
[16] Linux man pages, “kexec man page,” https://linux.die.net/man/8/
kexec, Accessed on March 22, 2024.
[17] S. López, “libkrun Github Repository,” https://github.com/
containers/libkrun.
[18] Microsoft
Azure,“AboutAzure
confidential
VMs,”
https://learn.microsoft.com/en-us/azure/confidential-computing/confidential-vm-overview.

[19] V. Narayanan, C. Carvalho, A. Ruocco, G. Almasi, J. Bottomley,
M. Ye, T. Feldman-Fitzthum, D. Buono, H. Franke, and A. Burtsev,“Remote attestation of confidential VMs using ephemeral vTPMs,”in Proceedings of the 39th Annual Computer Security Applications
Conference, ser. ACSAC ’23. New York, NY, USA: Association
for Computing Machinery, 2023, p. 732–743. [Online]. Available:
https://doi.org/10.1145/3627106.3627112[20] D. Pontes, F. Silva, E. D. L. Falcão, and A. Brito, “Attesting AMD
SEV-SNP virtual machines with SPIRE,” in 12th Latin-American
Symposium on Dependable and Secure Computing, LADC 2023,
La Paz, Bolivia, October 16-18, 2023. ACM, 2023, pp. 1–10.
[Online]. Available: https://doi.org/10.1145/3615366.3615419[21] QEMU, “Direct Linux Boot,” https://qemu-project.gitlab.io/qemu/
system/linuxboot.html, Accessed on March 26, 2024.
[22] R. Sailer, X. Zhang, T. Jaeger, and L. Van Doorn, “Design andimplementation of a TCG-based integrity measurement architecture.” in USENIX Security symposium, vol. 13, no. 2004, 2004,
pp. 223–238.
[23] SPIFFE, “Secure Production Identity Framework For Everyone(SPIFFE),” https://github.com/spiffe/spiffe, Accessed on May 7th,2024.
[24] tianocore, “Open Virtual Machine Firmware (OVMF),” https://github.com/tianocore/edk2, Accessed on May 7th, 2024.
[25] VirTEE, “VirTEE: A community for building virt-based TEEs,”
https://virtee.io/, Accessed on March 23, 2024.