Editing Hypervisor

Jump to navigation Jump to search
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.

Latest revision Your text
Line 1: Line 1:
The PS5 utilizes a presumably custom hypervisor (HV) to protect the non-secure kernel. The hypervisor is a virtual machine monitor (VMM), where kernel and usermode applications such as games run in a guest OS. Hardware, as well as the x86 kernel, talks to the Hypervisor through "hypercalls" and [https://en.wikipedia.org/wiki/Memory-mapped_I/O memory-mapped I/O (MMIO)]. It can be considered the highest privilege level for x86 on the system.
The more conventional use of a hypervisor is to run separate virtual machines on a host machine that are isolated from each other and can run their own guest operating systems. In the PS5 case, it is used primarily for Virtualization Based Security (VBS) to protect the kernel integrity.
The PS5 Hypervisor protects the integrity of the [https://en.wikipedia.org/wiki/Control_register Control Registers (CRs)], which by extension includes Write Protection (WP) and other protections such as [https://en.wikipedia.org/wiki/Supervisor_Mode_Access_Prevention Supervisor Mode Access/Execution Prevention (SMAP/SMEP)]. It also protects the kernel page table entries through the use of nested paging via [http://developer.amd.com/wordpress/media/2012/10/NPT-WP-1%201-final-TM.pdf Second Level Address Translation (SLAT)]. By looking at the hypercalls, it seems Sony has also moved the I/O memory management unit (IOMMU) to the Hypervisor from the kernel.
== Hypercalls ==
The PS5 Hypervisor has very few hypercalls compared to the PS3's. Little information is known about them as of yet beyond the call names.
{| class="wikitable"
{| class="wikitable"
|+ vmmcalls (VMMCALL_HV_*)
|+ vmmcalls (VMMCALL_HV_*)
Line 47: Line 37:
|}
|}


== In-Kernel Hypervisor (<= 2.70) ==
On PS5 System Software 2.70 and lower, the Hypervisor is integrated as part of the kernel binary. Later versions have the Hypervisor as a separately loaded component.
The hypervisor's main goals are to protect kernel code integrity and enforce <code>xotext</code> (aka. eXecute Only Memory or "XOM") on the kernel. To accomplish this, Sony takes advantage of various features provided by AMD Secure Virtual Machine (SVM), such as; Nested Page Tables (NPT), Guest Mode Execute Trap (GMET), and intercepting reads/writes to Control Registers (CRs) as well as Machine State Registers (MSRs). Furthermore, xotext seems to be hardware-backed as a collaboration with AMD, named "nda feature". The hypervisor also manages the I/O Memory Management Unit (IOMMU), as hinted by the fact that it exposes various hypercalls for configuring it.
It is worth noting the hypervisor is very small, especially when compared to that of the PS3. It only supports a handful of hypercalls and mainly exists to protect the kernel. It does not run multiple VMs or use nested virtualization. It only virtualizes the kernel/usermode, which Sony calls "GameOS".
=== Page Tables ===
==== Hypervisor Page Tables ====
On boot, the hypervisor sets up two page tables. It first sets up its own tables, which essentially involves copying the kernel page tables constructed by FreeBSD and re-mapping kernel pages as read/write. Kernel text pages are also not mapped with the <code>xotext</code> bit set, as the hypervisor needs to be able to read kernel .text pages in specific intercept handlers.
==== Nested Page Tables ====
The other set of page tables that are built are the nested page tables for the guest kernel. This is also known as Second-Level Address Translation (SLAT). How it works is that the physical addresses that the kernel "sees" are then translated again through the NPT, which makes the hypervisor the ultimate authority on how physical memory is mapped and what the page permissions are.
Of course, the NPT are stored in a data segment accessible only to the hypervisor, so the guest kernel cannot edit nested Page Table Entries (PTEs). As opposed to the hypervisor's own page tables, kernel text pages have the <code>xotext</code> bit (bit 58) set in most cases for NPT PTEs.
Also noteworthy is the fact that the hypervisor enables the GMET feature. At its core, this feature prevents the CPU from executing code from lower-privileged pages in a higher-privileged context. In other words, if you try to execute a user-mapped code page as kernel (CPL0), a Nested Page Fault or <code>#NPF</code> is thrown and the system will crash.
=== Control Register Protection ===
One of the most important tasks of the hypervisor is protecting the integrity of sensitive control register bits, especially CR0 and CR4. Bits such as the Write Protect (WP) bit, Protection Enabled (PE) bit, and Supervisor Mode Access/Execution Prevention (SMAP/SMEP) bits are very useful for attacking the kernel, and so writes to these registers are intercepted and checked.
Attempting to write to the following CR0 bits gets filtered out and will result in a <code>#GP</code> fault injected into the guest:
{| class="wikitable"
|+ Filtered CR0 Bits
|-
! Bit !! Mnemonic !! Description
|-
| 31 || PG || Paging
|-
| 16 || WP || Write Protect
|-
| 5 || NE || Numeric Error
|-
| 0 || PE || Protection Enable
|}
Similarly, the following CR4 bits are filtered:
{| class="wikitable"
|+ Filtered CR4 Bits
|-
! Bit !! Mnemonic !! Description
|-
| 21 || SMAP || Supervisor Mode Access Protection
|-
| 20 || SMEP || Supervisor Mode Execution Prevention
|-
| 0 || VME || Virtual 8086 Mode Extensions
|}
=== Machine State Register Protection ===
MSRs are another vector that the hypervisor mitigates. This is done by constructing an MSR Protection Map (MSRPM), which is essentially a bitmap of all MSRs that indicate if they're protected from read and/or write. A listing of protected MSRs dumped from a script is provided in a paste link below.
For most MSRs that are protected, violating this protection will result in a <code>#GP</code> fault injected into the guest. One exception to this rule is the Extended Features (EFER) register, which allows some writes which are masked. Attempting to change the following EFER bits will simply be dropped and not take effect:
{| class="wikitable"
|+ Masked EFER Bits
|-
! Bit !! Mnemonic !! Description
|-
| 16 || nda || xotext (XOM)
|-
| 12 || SVME || Secure Virtual Machine Enable
|-
| 11 || NXE || No-Execute Enable
|}
The parsed MSR protection map can be found [https://gist.github.com/Cryptogenic/83235b4cf4315500cb3146ed6d978ad0 here], and the script that parsed it [https://gist.github.com/Cryptogenic/aab893a2c608f2aeb117983fd97822d8 here].
=== Other intercepts ===
Beyond CR accesses, MSR accesses, and hypercalls, the hypervisor also handles intercepts and various other exit codes. They are listed below:


* <code>VMEXIT_CPUID</code> (presumably for PS4 emulation)
* 0-3 and E:  Disabled on 4.50
* <code>VMEXIT_RDPRU</code> (always injects a <code>#GP</code> exception into guest)
Please note that all contributions to PS5 Developer wiki are considered to be released under the GNU Free Documentation License 1.2 (see PS5 Developer wiki:Copyrights for details). If you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource. Do not submit copyrighted work without permission!

To protect the wiki against automated edit spam, we kindly ask you to solve the following hCaptcha:

Cancel Editing help (opens in new window)
Retrieved from "http://www.psdevwiki.com/ps5/Hypervisor"