> For the complete documentation index, see [llms.txt](https://docs.enclaive.cloud/confidential-cloud/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.enclaive.cloud/confidential-cloud/technology-in-depth/amd-sev/technology/fundamentals/features/integrity-threats.md). # Integrity Threats In the case of Replay Protection and Data Corruption-based attacks, the exploits exploit the ability of untrusted code to write to the memory of a protected Virtual Machine (VM). To counter this, SEV-SNP implements a measure where only the owner of a memory page (i.e., the SEV-SNP VM to which the page was assigned) can write to that page. This restriction is accomplished by utilizing the Reverse Map Table (RMP) mechanism, further detailed in the subsequent section. Memory Aliasing attacks involve maliciously mapping two different guest pages to the same physical memory page by the hypervisor. Naturally, a guest expects that distinct pages in its guest physical address space correspond to different memory locations, and any aliasing could lead to inadvertent data corruption. Ensuring that each physical memory page can only be mapped to one guest page at any given time is essential to address this threat. Once again, the RMP structure is employed to enforce this crucial property. The final integrity threat, Memory Re-Mapping, arises when the hypervisor maliciously re-maps a single guest page to multiple different physical memory pages. Consequently, the guest may perceive an inconsistent memory view, with only a subset of the data it wrote being present in memory. To tackle this threat, it is imperative to ensure that each guest page is exclusively mapped to one page of physical memory at any given time, and this mapping cannot be altered except by trusted entities, such as the AMD-SP. SEV-SNP utilizes a mechanism known as Page Validation to counter this threat. Page Validation combines the new RMP mechanism with new VM code to effectively manage the injective relationship between guest memory and system memory, thereby enhancing security and thwarting Memory Re-Mapping attempts. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.enclaive.cloud/confidential-cloud/technology-in-depth/amd-sev/technology/fundamentals/features/integrity-threats.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.