Pith. sign in

REVIEW 4 major objections 4 minor 37 references

Insecure Until Proven Updated: Analyzing AMD SEV's Remote Attestation

T0 review · 4 major / 4 minor · reviewed 2026-08-14 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read AMD SEV's remote attestation can be fully bypassed on Epyc Naples because the Chip Endorsement Key private key can be extracted and old vulnerable firmware can be reinstalled.

desk verdict First real break of SEV remote attestation with a CEK extraction proven against AMD's certificate chain; the universal rollback-resistance claim is the load-bearing soft spot. read the letter →

arxiv 1908.11680 v2 pith:7FQLYHP2 submitted 2019-08-30 cs.CR

Robert Buhren , Christian Werling , Jean-Pierre Seifert This is my paper · ORCID
classification cs.CR
keywords SEVremoteattestationPlatformSecurityProcessorChipEndorsementKeyfirmwarerollbackmemoryencryptioncloudEpycNaples
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper aims to establish that AMD's Secure Encrypted Virtualization (SEV) on the Epyc Naples processor line cannot protect guests from a malicious cloud provider. The load-bearing result is that the private key anchoring remote attestation, the Chip Endorsement Key (CEK), can be physically extracted from the CPU's Platform Security Processor. A signature-verification flaw in the PSP operating system, combined with the complete absence of rollback prevention, lets an attacker install an older signed vulnerable firmware even on machines that have been patched. With any extracted CEK, the paper argues, a cloud provider can fake the presence of SEV, decrypt a guest's disk key, or decrypt memory exported during migration. If this is correct, SEV on Naples gives no confidentiality or authenticity guarantee against an untrusted cloud provider, and no purely software-based fix can restore it.

What carries the argument

The load-bearing object is the Chip Endorsement Key (CEK), the CPU-unique ECDSA private key derived through a key derivation function from a 32-byte one-time-programmable fuse value, and signed by the AMD SEV Signing Key. It anchors the certificate chain in which the Platform Diffie-Hellman key is signed by the Platform Endorsement Key, which is in turn signed by the CEK, then by the AMD SEV Signing Key, then by the AMD Root Key. The enabling mechanism is the PSP secure-boot path: the on-chip ROM bootloader verifies the ARK public key and the PSP OS, the PSP OS loads and verifies the SEV firmware, and the SEV firmware obtains the fuse-derived secret through a syscall. Because the PSP OS signature verification has a flaw that allows custom signed components to run, and because the bootloader has no rollback prevention and cannot be updated, an attacker can always install an older signed PSP OS and a patched SEV firmware to read PSP memory and extract the CEK. The CEK's validity across all firmware versions is what turns that one-time extraction into a permanent credential.

What would settle it

Install the latest vendor firmware on an Epyc Naples system, then flash an older signed PSP OS that contains the reported signature-verification flaw; if the machine rejects the older image or refuses to boot rather than executing it, the rollback premise that makes CEK extraction possible is false.

Watch

Extended reading notes

Core claim

The central discovery is that the Chip Endorsement Key, the ECDSA key derived from chip-unique one-time-programmable fuses that roots the SEV certificate chain, is not protected against a compromised PSP. Using a patched SEV firmware installed through the PSP OS signature-verification vulnerability, the authors read the CEK private key from three Epyc Naples CPUs and verified the extracted keys against certificates obtained from the manufacturer's key server. Because the PSP's on-chip bootloader cannot be updated and enforces no rollback prevention, even CPUs running patched firmware can be reverted to a vulnerable signed PSP OS. The extracted CEK, whose lifetime is the lifetime of the CPU, then enables three attacks: faking SEV presence and decrypting the guest's disk key; impersonating a legitimate migration target so that any extracted CEK, not just the target's, decrypts exported VM memory; and patching the SEV firmware to override the guest policy's debug setting and read guest memory in plaintext. The paper concludes that on Naples, SEV cannot deliver its promised security when the cloud provider is untrusted.

Load-bearing premise

The attacks depend on the premise that the PSP's on-chip bootloader cannot be updated and enforces no rollback prevention, so an attacker can always install an older signed PSP OS containing the signature-verification bug even after the vendor patches the firmware.

Editorial extensions

If this is right

  • A malicious cloud provider can run guests without SEV memory encryption and still pass remote attestation, then decrypt the disk key the guest owner sends over the supposedly secure channel.
  • Any extracted CEK, not just the target platform's, is enough to decrypt a VM's exported memory during migration because the attacker can impersonate the migration endpoint.
  • Software-only fixes cannot restore security on Naples: the CEK remains valid for the CPU's lifetime and old signed PSP OS images can always be reinstalled.
  • The debug interface attack reads and writes guest memory in plaintext regardless of the guest policy, and it requires no helper software inside the guest.
  • If the manufacturer adopts the paper's proposed version-dependent CEK derivation, guest owners could refuse platforms with known-vulnerable firmware versions, which would close the attacks described here.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The migration attack effectively makes the CEK a product-line master key: because attestation does not bind a target's identity to a specific CPU, one extracted CEK jeopardizes every Naples VM whose guest policy allows migration.
  • The rollback gap is a general design lesson beyond this product: any security processor with an unupdatable boot ROM and no version counter can be returned to a signed-but-buggy firmware state, so a monotonic fuse or version check at the root of trust is the natural class of fix.
  • A direct test of the paper's proposed redesign would be to show that a CEK extracted under an old firmware no longer matches the certificate served for a newer firmware version; the paper does not implement this, so that part remains a design proposal rather than a demonstrated result.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 4 minor

Summary. This paper analyzes the firmware that implements AMD SEV remote attestation on the first-generation Epyc (Naples) processors. The authors reverse the Platform Security Processor (PSP) boot chain, identify a signature-verification flaw in the PSP OS, use it to install a patched SEV firmware with arbitrary PSP memory access, and extract the Chip Endorsement Key (CEK) private keys of three CPUs. They provide external evidence for the extraction: a signature over the paper title made with an extracted key and verifiable against AMD's certificate chain. Building on the extracted key, they present three attacks: Fake SEV (a malicious provider simulates SEV using any extracted CEK), a Migration attack (an attacker posing as a migration target decrypts exported VM memory), and a Debug Override attack (a patched SEV firmware ignores the guest's debug policy). They further argue that missing rollback protection on Naples means patched firmware does not restore security, and they propose design changes that tie the CEK to PSP OS and SEV firmware versions. The paper withholds the precise exploit details for responsible-disclosure reasons.

Significance. If the central claims hold, this is a significant result: it breaks the trust model of AMD SEV on the entire Naples product line, showing that a malicious cloud provider with reasonable hardware/software access can circumvent both the authenticity and the confidentiality guarantees of SEV. The externally verifiable signature is a strong artifact, and the accompanying PSPTool release is useful for follow-up research. The paper's strength is that the CEK extraction is not merely hypothesized but evidenced against AMD's own certificate infrastructure, and the attack logic for Fake SEV and Migration is coherent. The main uncertainty is the evidence for the universal 'no rollback prevention' claim and the corresponding scope of the conclusion that even patched Naples systems are unconditionally vulnerable.

major comments (4)
  1. [Section 3.2] The assertion that the PSP 'does not employ any rollback prevention mechanism' is load-bearing for the paper's headline claim that even patched Naples systems remain exploitable and for the Debug Override attack's statement that the attack works even after the firmware vulnerabilities are fixed (§5.3). The support provided is indirect: an unspecified set of logic-analyzer experiments and the observation that ten UEFI images from five vendors share the same ARK. These observations do not rule out a monotonic replay counter, a fuse-based version floor, or an OEM-specific boot path that rejects older PSP OS versions even when the signing key is unchanged. Please provide the full experimental protocol, the exact set of boards and firmware versions tested, and any attempts to trigger a rollback rejection; alternatively, explicitly narrow the universal claim to systems for which the absence of rollback protection was actually verified.
  2. [Section 3.3] The exact CEK extraction mechanism is omitted, so an independent reviewer cannot assess whether the method generalizes to all Naples systems or only to the particular firmware images the authors tested. I agree with not publishing full exploit details, and the verifiable signature is strong evidence that at least one CEK was extracted. However, the paper should state the conditions under which extraction is possible (e.g., which PSP OS versions, which motherboard firmware, which SPI-flash access assumptions), and should qualify the scope of the conclusion accordingly. As written, the central claim that the entire Naples series is 'useless' is broader than what the evidence in the paper directly supports.
  3. [Section 6.2] The proposed design requires the AMD Key Server to calculate version-dependent CEKs from the chip-unique SOTP value, but Sections 2.3 and 3.1 describe SOTP as an OTP fuse value that is only available inside the CPU/SEV firmware. The paper does not explain how AMD would obtain, store, or protect per-chip SOTP values, nor how the Key Server could compute SCEK without introducing a new single point of compromise. This is a feasibility gap in the proposed mitigation and should be addressed explicitly, at least by stating the provisioning assumption (e.g., SOTP escrowed at manufacturing).
  4. [Sections 5.1 and 5.2] The attack models for Fake SEV and Migration correctly note that the attacker needs only one extracted CEK from any SEV-enabled system. The paper should be careful to distinguish these attacks, which do not require the victim's platform itself to be rollback-vulnerable, from the Debug Override attack, which does require installing a patched SEV firmware on the victim's host. The current text is largely clear on this point, but the abstract and conclusion phrase the result in a way that can be read as claiming that every individual Naples system can be directly compromised; the distinct preconditions should be restated prominently.
minor comments (4)
  1. [Entire manuscript] The text supplied to me contains pervasive OCR-like artifacts (e.g., '/T_', '/f_', 'a/t_tacker') that obscure the technical content. These should be cleaned before a final version is produced.
  2. [Section 4.2] The KSM-based economic motivation is plausible but would be stronger with a quantitative reference for the memory overhead that SEV introduces and for the prevalence of KSM in IaaS deployments.
  3. [Abstract and Conclusion] The phrase 'no purely software-based mitigations are possible' should be qualified: it is true for existing Naples hardware under the no-rollback premise, but the paper's own contribution is a firmware/hardware design change for future CPUs, so the statement could be misread as ruling out all firmware-based fixes.
  4. [Section 6.2] In the proposed design, the on-chip bootloader must parse the PSP OS version from the signed header and perform a KDF before provisioning the CCP. Since the on-chip bootloader is not updatable, the paper should state explicitly that these changes apply only to future CPU generations and should estimate the added ROM complexity.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the CEK extraction is externally validated against AMD's certificates and the proposed attacks are independent of any self-referential derivation.

full rationale

The paper's central claims are empirical and externally anchored rather than derived from their own assumptions. The CEK extraction claim is validated against an external benchmark: the authors state they 'obtained the corresponding signed CEK certificates from the AMD key server... and verified the extracted private keys by creating signatures that can be validated using the signed CEK certificate,' with a public proof-of-concept signature. The firmware analysis is based on hardware observations (logic-analyzer recordings of SPI flash accesses) and publicly documented UEFI/PSP structures, not on a fitted parameter or a self-citation. The attacks—Fake SEV, Migration, and Debug Override—are constructed directly from the extracted key or from the patched SEV firmware, and each attack's mechanism is spelled out in terms of the SEV protocol's own certificate chains and key-wrapping steps. The self-cited runtime attacks [15] and related work [13, 21] are background or independent prior findings, not load-bearing premises for the attestation analysis. The weakest premise, the absence of PSP rollback prevention, is supported by the authors' own experiments and by analysis of ten UEFI images from five vendors; even if this premise were under-evidenced, that would be a correctness or verification concern, not circularity, since the claim is not defined in terms of the conclusion and is falsifiable. No equation, fitted value, or self-citation chain reduces the paper's predictions to its inputs, so the appropriate circularity score is 0.

Assumptions & free parameters 0 free parameters · 5 assumptions · 0 invented entities

The central claim introduces no fitted numeric parameters and no new physical entities. It rests on a chain of empirical and domain assumptions about the PSP boot flow, the immutability of the on-chip bootloader, the AMD key server, and the documented SEV API. All of these are stated in Sections 2 and 3.

assumptions (5)
  • domain assumption The PSP OS signature verification can be bypassed on signed firmware versions, and older signed firmware can be reinstalled because the PSP has no rollback prevention.
    Reported from experiments in Section 3.2; exact vulnerability details are withheld, so this is a load-bearing empirical premise for all three attacks.
  • domain assumption The PSP on-chip bootloader is stored in ROM and cannot be updated through UEFI firmware updates.
    Stated in Section 3.2 and 6.1 based on AMD correspondence; without this, rollback could be patched in software.
  • domain assumption AMD's key server returns CEK certificates for a given platform ID, and clients verify the chain PDH to PEK to CEK to ASK to ARK as specified in the SEV API.
    The Fake SEV and Migration attacks depend on this external public-key infrastructure and on certificates remaining available for compromised CEKs (Sections 2.4 and 5.1).
  • domain assumption The SEV API commands for launch, migration, and debug behave as documented in AMD SEV API version 0.17.
    Attack descriptions in Section 5 are constructed directly against the documented API; divergence would change the attack steps.
  • domain assumption The CEK is derived from chip-unique OTP fuses using a key derivation function, as specified in AMD's SEV API.
    This grounds the claim that CEK lifetime equals CPU lifetime, which makes leaked keys permanently valid (Sections 2.3 and 6.1).

how reviews work

0 comments
Cite this review

Pith. "Pith review of Insecure Until Proven Updated: Analyzing AMD SEV's Remote Attestation." pith.science (2026). https://pith.science/paper/7FQLYHP2

@misc{pith2026190811680,
  author       = {Pith},
  title        = {Pith review of: Insecure Until Proven Updated: Analyzing AMD SEV's Remote Attestation},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/7FQLYHP2}},
  note         = {Machine review of arXiv:1908.11680}
}
read the original abstract

Customers of cloud services have to trust the cloud providers, as they control the building blocks that form the cloud. This includes the hypervisor enabling the sharing of a single hardware platform among multiple tenants. AMD Secure Encrypted Virtualization (SEV) claims a new level of protection in cloud scenarios. AMD SEV encrypts the main memory of virtual machines with VM-specific keys, thereby denying the higher-privileged hypervisor access to a guest's memory. To enable the cloud customer to verify the correct deployment of his virtual machine, SEV additionally introduces a remote attestation protocol.This paper analyzes the firmware components that implement the SEV remote attestation protocol on the current AMD Epyc Naples CPU series. We demonstrate that it is possible to extract critical CPU-specific keys that are fundamental for the security of the remote attestation protocol.Building on the extracted keys, we propose attacks that allow a malicious cloud provider a complete circumvention of the SEV protection mechanisms. Although the underlying firmware issues were already fixed by AMD, we show that the current series of AMD Epyc CPUs, i.e., the Naples series, does not prevent the installation of previous firmware versions. We show that the severity of our proposed attacks is very high as no purely software-based mitigations are possible. This effectively renders the SEV technology on current AMD Epyc CPUs useless when confronted with an untrusted cloud provider. To overcome these issues, we also propose robust changes to the SEV design that allow future generations of the SEV technology to mitigate the proposed attacks.

Figures

Figures reproduced from arXiv: 1908.11680 by the authors.

Figure 1
Figure 1. Cryptographic keys in SEV. A shield denotes the [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. SEV Secure Channel. Protocol initiated by the [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Initial deployment of a guest virtual machine in [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (4 more)
Figure 4
Figure 4. Figure 4: Boot procedure on an SEV-enabled system. A lock [PITH_FULL_IMAGE:figures/full_fig_p006_4.png]
Figure 2
Figure 2. Figure 2: Œe memory of the VM is encrypted using the generated [PITH_FULL_IMAGE:figures/full_fig_p008_2.png]
Figure 4
Figure 4. Figure 4: In our proposed design, the on-chip bootloader provisions [PITH_FULL_IMAGE:figures/full_fig_p010_4.png]
Figure 5
Figure 5. Figure 5: ‡e current SEV design as opposed to our proposed [PITH_FULL_IMAGE:figures/full_fig_p010_5.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

37 extracted references · 32 canonical work pages

  1. [1]

    AMD. 2005. Secure Virtual Machine Architecture Reference Manual. Whitepaper

    work page 2005

  2. [2]

    AMD. 2013. AMD Security and Server innovation. h/t_tps: //members.ue/f_i.org/learningcenter/UEFI PlugFest AMD Security and Server innovation AMD March 2013.pdf Accessed: 2019-04-29

    work page 2013

  3. [3]

    AMD. 2018. AMD Secure Encrypted Virtualization API Version 0.17. h/t_tps: //developer.amd.com/wp-content/resources/55766.PDF Accessed: 2019-08-05

    work page 2018

  4. [4]

    AMD. 2019. AMD CEK Certi/f_icate Server. h/t_tps://kdsintf.amd.com/cek/ Accessed: 2019-04-16

    work page 2019

  5. [5]

    AMD. 2019. SEV /f_irmware for Naples. h/t_tps://developer.amd.com/wp-content/ resources/amd sev fam17h model0xh 0.17b11.zip Accessed: 2019-04-16

    work page 2019

  6. [6]

    Kaplan AMD and Others. 2016. AMD Memory Encryption. h/t_tps: //developer.amd.com/wordpress/media/2013/12/AMD Memory Encryption Whitepaper v7-Public.pdf Accessed: 2019-08-05

    work page 2016

  7. [7]

    Andrea Arcangeli, Izik Eidus, and Chris Wright. 2009. Increasing memory density by using KSM. In Proceedings of the linux symposium . Citeseer, 19–28

    work page 2009

  8. [8]

    Russell Brandom and Colin Lecher. 2018. House passes controversial legislation giving the US more access to overseas data. (2018). h/t_tps://www.theverge. com/2018/3/22/17131004/cloud-act-congress-omnibus-passed-mlat Accessed: 2019-05-14

    work page 2018

Show all 37 references
  1. [9]

    Robert Buhren. 2019. Repository containing supplemental data and results. (2019). h/t_tps://github.com/RobertBuhren/ Insecure-Until-Proven-Updated-Analyzing-AMD-SEV-s-Remote-A/t_testation Accessed: 2019-08-01

    2019

  2. [10]

    CodeRush. 2013. Flashing modi/f_ied AMI Aptio UEFI using AFU. h/t_tps://www.win-raid.com/ t286f16-Guide-Deprecated-Flashing-modi/f_ied-AMI-Aptio-UEFI-using-AFU. html Accessed: 2019-04-18

    2013

  3. [11]

    Zhao-Hui Du, Zhiwei Ying, Zhenke Ma, Yufei Mai, Phoebe Wang, Jesse Liu, and Jesse Fang. 2017. Secure Encrypted Virtualization is Unsecure. arXiv:1712.05090

    2017 arXiv

  4. [12]

    Uni/f_ied EFI. 2017. Platform Initialization (PI) Speci/f_ication. h/t_tps://ue/f_i.org/ sites/default//f_iles/resources/PISpec 1 6.pdf Accessed: 2019-05-02

    2017

  5. [13]

    Uri Farkas and CTS-Labs Ido Li On. 2019. AMDFlaws /f_i/question_exclam A Technical Deep Dive. h/t_tps://msrnd-cdn-stor.azureedge.net/bluehat/bluehatil/2019/assets/doc/ /T_he%20AMDFlaws%20Story%20Technical%20Deep%20Dive.pdf Accessed: 2019- 05-06

    2019

  6. [14]

    Rosado, Eduardo Fern´andez-Medina, and Eduardo B

    Keiko Hashizume, David G. Rosado, Eduardo Fern´andez-Medina, and Eduardo B. Fernandez. 2013. An analysis of security issues for cloud computing. Journal of Internet Services and Applications 4, 1 (27 Feb 2013), 5. h/t_tps://doi.org/10.1186/ 1869-0238-4-5

    2013

  7. [15]

    Felicitas Hetzelt and Robert Buhren. 2017. Security Analysis of Encrypted Virtual Machines. In Proceedings of the 13th ACM SIGPLAN/SIGOPS International Conference on Virtual Execution Environments (VEE ’17) . ACM, New York, NY, USA, 129–142. h/t_tps://doi.org/10.1145/3050748.3050763

    2017

  8. [16]

    Intel Security Center. 2019. Intel CSME, Server Platform Services, Trusted Execution Engine and Intel Active Management Technology 2018.4 QSR Ad- visory. h/t_tps://www.intel.com/content/www/us/en/security-center/advisory/ intel-sa-00185.html. Accessed: 2019-05-06

    2019

  9. [17]

    Intel Security Center. 2019. Intel Firmware 2018.4 QSR Advisory. h/t_tps://www. intel.com/content/www/us/en/security-center/advisory/intel-sa-00191.html. Accessed: 2019-05-06

    2019

  10. [18]

    S. Jin, J. Ahn, S. Cha, and J. Huh. 2011. Architectural support for secure virtualiza- tion under a vulnerable hypervisor. In 2011 44th Annual IEEE/ACM International Symposium on Microarchitecture (MICRO) . 272–283

    2011

  11. [19]

    Miltiadis Kandias, Nikos Virvilis, and Dimitris Gritzalis. 2013. /T_he Insider /T_hreat in Cloud Computing. InCritical Information Infrastructure Security , San- dro Bologna, Bernhard H¨ammerli, Dimitris Gritzalis, and Stephen Wolthusen (Eds.). Springer Berlin Heidelberg, Berl...

    2013

  12. [20]

    David Kaplan. 2017. Protecting VM Register State with SEV-ES. h/t_tps://www.amd.com/system//f_iles/TechDocs/Protecting%20VM%20Register% 20State%20with%20SEV-ES.pdf Accessed: 2019-05-06

    2017

  13. [21]

    CTS Labs. 2018. Severe Security Advisory on AMD Processors. h/t_tps: //safe/f_irmware.com/amd/f_lawswhitepaper.pdf Accessed: 2019-05-06

    2018

  14. [22]

    /T_homas Lendacky and Gary Hook. 2016. ccp-dev.h. h/t_tps: //git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/crypto/ ccp/ccp-dev.h?h=v5.0.12#n402 Accessed: 2019-05-04

    2016

  15. [23]

    McCune, Bryan Parno, Adrian Perrig, Michael Reiter, and Hi- roshi Isozaki

    Jonathan M. McCune, Bryan Parno, Adrian Perrig, Michael Reiter, and Hi- roshi Isozaki. 2008. Flicker: an execution infrastructure for TCB minimiza- tion. EuroSys’08 - Proceedings of the EuroSys 2008 Conference 42, 315–328. h/t_tps://doi.org/10.1145/1352592.1352625

    2008

  16. [24]

    Mark Papermaste. 2018. Initial AMD Technical Assessment of CTS Labs Re- search. h/t_tps://community.amd.com/community/amd-corporate/blog/2018/03/ 21/initial-amd-technical-assessment-of-cts-labs-research. Accessed: 2019-05- 10

    2018

  17. [25]

    Mathias Morbitzer, Manuel Huber, Julian Horsch, and Sascha Wessel. 2018. SEVered: Subverting AMD’s Virtual Machine Encryption. InProceedings of the 11th European Workshop on Systems Security (EuroSec’18). ACM, New York, NY, USA, Article 1, 6 pages. h/t_tps://doi.org/10.1145/31...

    2018

  18. [26]

    Coreboot Project. 2014. PspDirectory.h. h/t_tps://github.com/coreboot/ coreboot/blob/master/src/vendorcode/amd/pi/00660F01/Proc/Psp/PspBaseLib/ PspDirectory.h Accessed: 2019-04-03

    2014

  19. [27]

    Kaveh Razavi, Ben Gras, Erik Bosman, Bart Preneel, Cristiano Giuffrida, and Herbert Bos. 2016. Flip feng shui: Hammering a needle in the so/f_tware stack. In 25th {USENIX} Security Symposium ( {USENIX} Security 16). 1–18

    2016

  20. [28]

    Supermicro. [n. d.]. Supermicro Update Manager. h/t_tps://www.supermicro. com/solutions/SMS SUM.cfm Accessed: 2019-04-26

    2019

  21. [29]

    Jakub Szefer and Ruby B. Lee. 2012. Architectural Support for Hypervisor-secure Virtualization. SIGPLAN Not. 47, 4 (March 2012), 437–450. h/t_tps://doi.org/10. 1145/2248487.2151022

    2012

  22. [30]

    Rich Uhlig, Gil Neiger, Dion Rodgers, Amy L Santoni, Fernando Martins, An- drew V Anderson, Steven M Benne/t_t, Alain K¨agi, Felix H Leung, and Larry Smith

  23. [31]

    Stefan Weil. 2019. QEMU version 4.0.93 User Documentation. (2019). h/t_tps: //qemu.weilnetz.de/doc/qemu-doc.html#Commands Accessed: 2019-08-01

    2019

  24. [32]

    Christian Werling and Robert Buhren. 2019. PSPTool: Display, extract, and manipulate PSP /f_irmware inside UEFI images. (2019). h/t_tps://github.com/ cwerling/psptool Accessed: 2019-08-01

    2019

  25. [33]

    Y. Wu, Y. Liu, R. Liu, H. Chen, B. Zang, and H. Guan. 2018. Comprehensive VM Protection Against Untrusted Hypervisor /T_hrough Retro/f_i/t_ted AMD Memory Encryption. In 2018 IEEE International Symposium on High Performance Computer Architecture (HPCA). 441–453. h/t_tps://doi.o...

    2018

  26. [34]

    Y. Xia, Y. Liu, and H. Chen. 2013. Architecture support for guest-transparent VM protection from untrusted hypervisor and physical a/t_tacks. In2013 IEEE 19th International Symposium on High Performance Computer Architecture (HPCA) . 246–257. h/t_tps://doi.org/10.1109/HPCA.201...

    2013

  27. [35]

    Yuval Yarom and Katrina Falkner. 2014. FLUSH+ RELOAD: a high resolution, low noise, L3 cache side-channel a/t_tack. In23rd {USENIX} Security Symposium ({USENIX} Security 14). 719–732

    2014

  28. [36]

    Fengzhe Zhang, Jin Chen, Haibo Chen, and Binyu Zang. 2011. CloudVisor: Retro/f_i/t_ting protection of virtual machines in multi-tenant cloud with nested virtualization. SOSP’11 - Proceedings of the 23rd ACM Symposium on Operating Systems Principles, 203–216. h/t_tps://doi.org/...

    2011

  29. [2005]

    Computer 38, 5 (2005), 48–56

    Intel virtualization technology. Computer 38, 5 (2005), 48–56

    2005

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.