obliteration rewrites the PlayStation 4 kernel in Rust and runs it in a hypervisor

A PS4 kernel that is not meant to run on a PS4

Obliteration is a free and open-source PlayStation 4 kernel rewritten in Rust, and the first thing to understand about it is what it is not trying to be.

The stated goal is not to run on the PlayStation 4. It is to run the dumped PlayStation 4 system software on Windows, Linux and macOS, using a custom virtualization stack optimized specifically for Obliteration. The kernel itself is x86_64, and the virtualization layer is what carries the console environment.

The ambition goes further. The project says it wants to become a permissive free and open-source operating system optimized for gaming that can run on a variety of hardware, and that it wants to go beyond a PlayStation 4 emulator because an operating system kernel is already being built. The README lists its reasons for not choosing an existing system: Windows is bloated and Microsoft keeps pushing too much into it, Linux is a nightmare for beginners and its licence makes it a poor fit for proprietary hardware, macOS has a limited set of hardware and costs too much, and FreeBSD and the others were not designed for gaming.

That places the project in the hobby operating system tradition with a console as its starting point. The kernel is written in Rust, the workspace is a Cargo project, and the logo and icon were designed by VocalFan.

For a reader looking for something to run software on, the status section below is the decisive part. For a reader who wants to understand how a console kernel is reconstructed from dumps, this is a rare open example.

The hypervisor is the product: WHPX, KVM and Hypervisor Framework

Because the kernel has to run on three desktop operating systems, the virtualization layer is where most of the engineering sits.

The project uses the Windows Hypervisor Platform, KVM or the macOS Hypervisor Framework directly, with custom made virtual devices for optimized MMIO. Using the platform hypervisor directly rather than a general purpose virtual machine means the virtual hardware is shaped around what the PS4 kernel expects, including the memory mapped I/O behaviour that the console's devices rely on. The README claims near-native performance on that basis.

The other key feature claim is fidelity rather than speed. Kernel behavior is described as near-identical to the PlayStation 4 kernel, and the project says that although no game runs yet, the choices made here are expected to allow very high compatibility later.

The kernel itself is written in Rust and targets x86-64, with aarch64 support visible in the workspace layout, which is consistent with a project that also has to reason about the console's own architecture even while the host is a desktop CPU.

One consequence of this design is the hardware floor. The system requirements are a CPU with SLAT, 16 GB of RAM and a 64-bit operating system. That is a modest list on paper, but it reflects the fact that you are running a guest kernel with its own memory management on top of a host hypervisor.

The July 2026 boot log ends in a panic, and that is the honest status

The README publishes a kernel log from July 12, 2026, and it is the most useful thing in the documentation because it shows exactly how far the project has come and where it stops.

The kernel starts on KVM on an x86_64 host, reports the CPU vendor and identifier, and loads a memory map with two maps covering an initial memory size of 8554659840 bytes, which the log prints as 8.55 GB. It then initialises DMEM in mode 20, described as GL8 release, populates available physical memory, initialises VM statistics with page counts for two partitions, activates a stage 2 heap, and creates the init process. The last lines are the failure:

[I]: Creating init process.
     kernel/src/main.rs:514
[E]: Kernel panic - not yet implemented.
     kernel/src/proc/process.rs:42

The status text says the same thing in prose. The project cannot run any games yet; what exists is a working 64-bit kernel and the VMM to run it, with the GDT, TSS, IDT and syscall instruction successfully set up and the virtual memory system mostly usable. The current work is on launching mini-syscore.elf.

The README explains why it takes this long: the kernel is implemented without stubbing as much as possible, and the hard part is not writing the code but understanding precisely how the PlayStation 4 kernel works. That is a design decision with a cost, and the cost is visible in the log.

Kyty and Uplift: a hard fork that became a rewrite

The lineage of the project explains a lot about its shape.

Obliteration started as a hard fork from Kyty, then the decision was made to rewrite the whole project from scratch, using Kyty and Uplift as references to get going. So the code you read today shares little mechanically with the fork it began as, but the two reference projects remain the reference points for how a console kernel and its emulation environment are put together.

That starting point also shapes the licensing, and the README is unusually explicit about it. All source code is licensed under either the MIT License or the Apache License, Version 2.0, or both, and unless a contribution states otherwise, anything intentionally submitted for inclusion is dual licensed on those terms with no additional conditions.

Then comes the clause that tells you something about the ecosystem this project lives in: the project cannot accept any code from other PlayStation 4 emulators if it is licensed under anything other than MIT or Apache-2.0, unless you are the author of that code.

For an outside contributor this is the rule to read first. It does not ban contributions, but it does constrain where they can come from and under what terms, and the dual MIT and Apache-2.0 grant gives consumers of the kernel the widest possible reuse.

The repository layout supports the picture of an operating system project rather than a single binary: a kernel directory, a gui directory, config, lib with aarch64, bitflag, hv, krt and x86-64 subcrates, macros, docs and scripts, plus a legacy directory, a Cargo.lock and a Cargo.toml at the root.

Building it and getting a daily binary

The build is a standard Rust workspace, and the root Cargo.toml shows the crate layout directly:

[workspace]
resolver = "2"
members = [
    "config",
    "gui",
    "kernel",
    "lib/aarch64",
    "lib/bitflag",
    "lib/hv",
    "lib/krt",
    "lib/x86-64",
    "macros",
]

Two release profiles are configured, dev and release, and both set panic to abort, with link time optimization enabled for release. Panic abort matters for a kernel, since there is no unwinder to run, and the release profile is what the virtualization performance claims would rest on.

Build and development documentation lives on a separate developer site at dev.obliteration.net, and the repository carries mkdocs.yml and a docs directory for the user-facing pages. The GUI uses icons from materialdesignicons, and the repository includes an Info.plist, an entitlements.plist and a bundle.icns for the macOS side of the project.

For people who just want to try it, the README points to daily build binaries produced by the CI workflow. Two conditions are attached. You must sign in to GitHub, otherwise you cannot download the files, and you should remember that no game runs yet, so the binaries are for testing and for helping the project. The maintainers use Linux, so Windows and macOS users may hit unimplemented functions; the README invites pull requests to implement them and offers to help testers who report an issue.

No releases, permissive licences, and what the project is not

Two facts frame any decision to get involved.

The first is that there are no GitHub releases. The only binaries are the daily CI artifacts behind a signed-in GitHub link, which means there is no versioned artefact to pin, no changelog to read and no supported build. The repository is not archived and the last push was on 2026-09-26, so the work is live, but it lives in the default branch and in pull requests rather than in tagged releases.

The second is the licence, which as noted above is MIT or Apache-2.0 or both. That is permissive enough for experimentation, for embedding and for redistribution, with the Apache patent grant and the MIT notice requirement both available to you depending on which applies to a given file.

What the project is not is worth stating as plainly as what it is. It is not an emulator that plays games today, the README says so twice. It is not a PlayStation 4 system software reimplementation, since the console software is used as dumped and only the kernel is being rewritten. It is not a general purpose operating system yet either, since the stated goal is aspirational and the immediate work is booting mini-syscore.elf.

What it is, today, is an open Rust kernel with a custom hypervisor layer, a working descriptor table setup, a usable virtual memory system and a documented panic on the way to the first process. For an operating systems reader that is an unusual and legible artefact, and the log in the README is a better description of the project than any summary would be.

Editorial conclusion

Systems programmers who want to study a console kernel, or who want to contribute to an operating system built from the ground up, should adopt obliteration, because the hypervisor layer, the memory map handling and the descriptor table work are all in the open and the project states plainly what still does not run. It is the wrong tool for playing PS4 games, since the README says no game runs yet, and it is the wrong tool for anyone who needs a stable binary, because the repository publishes no releases and only offers daily CI artifacts that require a signed-in GitHub account. Before joining, read the developer documentation, check that your CPU has SLAT and that you have 16 GB of RAM, and read the licensing note about contributions from other console emulators.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. obhq/obliteration on GitHub
4. Project website
5. README