How Game Consoles Are Built

Keyboard shortcuts

×

?

Open this guide

Alt + B

Show or hide the lesson list

Alt + O

Show or fold the lesson outline

Alt + N

Open or close notes

Alt + H

Toggle semantic colours

Alt + D

Toggle page brightness

Alt + C

Toggle code brightness

← →

Move through a focused code trace

Home End

First or final step in a focused trace

Escape

Close this guide or an open panel

Reader shortcuts pause while you type in a text field.

Cheatsheet for Lesson 13.6Key ideas, reference and questions

A one-page summary of “How Game Consoles Are Built” you can keep beside your notes. Plain Markdown.

Lesson 13.6 — How Game Consoles Are Built: cheatsheet

• Remember: A genuine signature does not establish freshness; accepting an older approved image is a separate decision.
• Also useful: Think of boot as a relay of checked handoffs: each trusted stage verifies the next before letting that stage run.

Key terms

• system on a chip: A chip that holds most of a computer's parts is called a system on a chip, or SoC.
• unified memory: This design is called unified memory.
• boot ROM: The first link is the boot ROM, a small program written into the chip when it is manufactured, which no software, update, or owner can change.
• root of trust: It is the root of trust: every later stage is trusted only because an earlier stage checked it, and the chain ends at the one piece of code that needs no check because nobody can alter it.
• measurements: Those hashes, called measurements, describe exactly what booted.
• Homebrew: Homebrew is software written by hobbyists for a platform without the platform holder's licence: games, tools, media players, and emulators.

Review

• Q: Why can an online service not simply ask a console whether its software has been modified? A: Modified software could answer "no", so the service needs a signed report from the security processor
• Q: A flaw is found in one stage of a console's boot chain. Which stage's flaw cannot be fixed by a system update on consoles that are already sold? A: The boot ROM, which is written into the chip when it is manufactured

Download cheatsheet (.md)

Download cheatsheet (.md)

Open a current game console and you find parts a PC builder would recognise: a processor, a graphics processor, memory, an SSD, and a network adapter. The PlayStation 5 and the Xbox Series X even run the same x86-64 instruction set as most PCs. Yet a PC runs whatever its owner installs, while a console runs only what its maker has approved. Both facts come from design choices, and this lesson follows them from the chip up.

Firmware and Bare-Metal Rust established how device code starts and uses its memory. A console adds a larger software stack and checks which images are allowed to run at each stage.

A fixed computer on one chip

Three well-known consoles:

Console	Released	CPU	GPU	Memory
PlayStation 5	2020	8 AMD Zen 2 cores, x86-64	AMD RDNA 2, 36 compute units	16 GB GDDR6, shared
Xbox Series X	2020	8 AMD Zen 2 cores, x86-64	AMD RDNA 2, 52 compute units	16 GB GDDR6, shared
Nintendo Switch	2017	Arm Cortex-A57 cores	Nvidia Maxwell-based	4 GB LPDDR4, shared

Two things in that table differ from a typical gaming PC.

First, the CPU cores and the GPU sit on the same piece of silicon. A chip that holds most of a computer’s parts is called a system on a chip, or SoC.

Second, the word “shared” in the memory column. A gaming PC gives the CPU system RAM on the motherboard and gives the graphics card its own video RAM, so anything the GPU needs, such as the textures and vertex buffers of Chapter 7, is copied across the PCI Express bus. In a console, the CPU and the GPU use one pool of memory: the CPU writes a buffer, and the GPU reads the very same bytes. This design is called unified memory.

PC: system RAM, a copy, then video RAMThe CPU and the GPU have separate memories, so data has to be copied from one to the other.

1. 1 The CPU fills a buffer in system RAM

   CPU side, then GPU side

   buffersystem RAM

   emptyvideo RAM

   The data starts on the CPU’s side.

2. 2 It is copied to video RAM; the GPU reads that copy

   ↓ copy

   CPU side, then GPU side

   buffersystem RAM

   copy of the buffervideo RAM · GPU reads here

   The copy costs time, and changes the CPU makes afterwards are not seen until the next copy.

The CPU and the GPU have separate memories, so data has to be copied from one to the other.

Console: CPU and GPU share one memoryOn one SoC both processors use the same memory, so one buffer serves both.

1. 1 The CPU writes the shared buffer

   One SoC

   CPUwrites

   GPU

   shared bufferone memory

   There is one buffer, in memory both processors can reach.

2. 2 The GPU reads the same buffer

   One SoC

   CPU

   GPUreads

   shared bufferno copy

   No copy is needed, because both use the same bytes.

On one SoC both processors use the same memory, so one buffer serves both.

The shared pool has to satisfy its hungriest reader, the GPU, so consoles build it from graphics memory. The PlayStation 5’s memory bus is 256 bits wide, one wire per bit, and each wire carries 14 billion bits per second. That is 256 × 14 = 3,584 billion bits per second, and dividing by 8 bits per byte gives 448 GB every second, for the CPU and GPU alike.

The third difference is not in the table because it is the table: every PlayStation 5 has the same chip, the same memory, and the same clock speeds. A PC game has to run on thousands of combinations of parts; a console game is tuned for exactly one. At 60 frames per second, each frame gets 1,000 ms ÷ 60 ≈ 16.7 ms for all of its work, from game logic and physics to rendering (Lesson 4.1). A measurement on one console holds for every console, so developers can spend that budget almost to the last millisecond. They can even compile their shaders ahead of time for the one GPU and ship the results on the disc, a luxury that emulators lack, as Lesson 13.9 shows.

Sharing the PC’s instruction set does not make a console game a PC game, though. Its machine code calls the console’s own operating system and graphics interfaces, such as a console version of Direct3D 12 on Xbox and Sony’s own interfaces on PlayStation, which is why moving a console game to PC is still porting work.

The software stack: a hypervisor and two partitions

When Microsoft introduced the Xbox One in 2013, it described the console as running three operating systems at once: a hypervisor that owns the hardware, a game partition that runs the current game, and a Windows-based partition for the home screen and apps. Other consoles differ in the details, but the same shape keeps appearing:

A partition here is a virtual machine in the sense of Lesson 13.3: an operating system that sees only the cores, memory, and devices the hypervisor gives it. The split pays for itself three ways:

• Predictable timing. The game partition has CPU cores and memory reserved for it, so a background download cannot steal time from a frame. With 16.7 ms per frame, a background task that takes 2 ms at the wrong moment is a visible stutter.
• Containment. A bug in a game, such as a crash caused by a malformed save file, stays inside the game partition. The system partition’s memory, where account tokens and purchase records live, is not even mapped into the game’s address space.
• Independent updates. The system software can change without touching the game partition that thousands of shipped games depend on.

Most console chips also contain a small, separate security processor. It starts before the main cores, holds the console’s keys, and performs the checks described next. The main cores never see those keys.

Secure boot: a chain of trust

When a console powers on, which code runs first, and why should anyone trust it? Secure boot answers with a chain of trust: each stage checks the digital signature (Lesson 10.8) of the next stage before running it, and refuses if the check fails.

Alternative: Think of boot as a relay of checked handoffs: each trusted stage verifies the next before letting that stage run.

An authentic image can still be too old. This step-by-step trace needs JavaScript. Here is the code and where the run ends.

read the selected inputs
evaluate each stated condition
combine the required conditions
perform the effect only when accepted
otherwise retain the old state
report the result and its limits

Result: this image passes both illustrated boot checks.

Final values: minimum = 3; signature = yes; image_version = 3; version_allowed = true; signature_valid = true; accepted = true; entered_bootloader = true.

Read every step of the lesson’s example

1. Step 1, line 1. Start with the selected inputs and follow how the next operation changes the state.

   minimum = 3; signature = yes.

2. Step 2, line 2. The image is version three. Authenticity and rollback resistance answer different questions.

   minimum = 3; signature = yes; image_version = 3; version_allowed = true; signature_valid = true.

3. Step 3, line 3. Accept only when the required conditions all hold.

   minimum = 3; signature = yes; image_version = 3; version_allowed = true; signature_valid = true; accepted = true.

4. Step 4, line 4. The model performs the accepted effect.

   minimum = 3; signature = yes; image_version = 3; version_allowed = true; signature_valid = true; accepted = true; entered_bootloader = true.

5. Step 5, line 6. Result: this image passes both illustrated boot checks.

   minimum = 3; signature = yes; image_version = 3; version_allowed = true; signature_valid = true; accepted = true; entered_bootloader = true.

Watch it happenVerify each image before transferring execution

Factory boot ROM checks an image key against fused trust, verifies the signed header and code, and accepts security version 3 against minimum 3. Code enters the bootloader only after those checks. The loader checks privileged code, kernels check system components, and system services check a game signature and licence before decrypting and starting the game.

Read the steps

1. Power on begins in factory-written boot ROM. The bootloader image is stored but not executing. Its example key and signature each occupy 2,048 divided by 8, or 256 bytes.
2. Hash the public key supplied with the image. Compare that result with the unchangeable fused key hash. A different key would stop the boot; a matching hash allows signature verification to continue.
3. Hash the signed header and code, then check the signature with the trusted key. Check security version 3 against the three set fuses: 3 is at least the minimum 3. Both checks must pass before any jump.
4. Only now does the ROM enter the verified bootloader. The loader reads the next privileged image, hashes its signed contents, and verifies its signature before starting the hypervisor and kernels.
5. Enter the verified privileged code. The hypervisor and kernels check the system components they load. The next code image remains data until its check succeeds.
6. The verified system services begin. Before starting the game, they check the package signature and licence, then decrypt the accepted package. A valid signature alone does not supply a licence.
7. The accepted game code enters the execution path. Every later stage ran only after an earlier trusted stage checked it. A failed check would have taken the refusal route instead.

The image sizes and fuse values are the lesson’s example. Code blocks move into the execution path only after their checks pass.

The first link is the boot ROM, a small program written into the chip when it is manufactured, which no software, update, or owner can change. It is the root of trust: every later stage is trusted only because an earlier stage checked it, and the chain ends at the one piece of code that needs no check because nobody can alter it.

Each check is a digital signature, the same mechanism Windows uses on programs: the console maker signs every stage with a private key kept in its own buildings, and the console checks each signature with the matching public key, which can check signatures but cannot make them (Lesson 10.8 walks through how). The boot ROM needs that public key to check the first signature, and the key must be as unchangeable as the ROM. Chips can keep such values in eFuses: physical bits set once during manufacturing and then locked against ordinary software writes. Lesson 13.7 returns to how those bits can also lock a hardware debug port. A 2,048-bit RSA public key would need 2,048 of them. Chips store a SHA-256 hash of the key instead, which is 256 bits and so 256 fuses, and the key itself travels in flash storage alongside the bootloader:

security version3

code length65,536

public key256 bytes

code65,536 bytes

signature256 bytes

header

its hash must match the fuses

the next stage

signs the header and code

A boot image in flash. With RSA-2048, the key and the signature are each 2,048 bits, which is 2,048 ÷ 8 = 256 bytes.

Before it runs a single instruction of the bootloader, the boot ROM:

1. hashes the public key that came with the image and compares the result with the fused hash, since a mismatch means someone supplied their own key;
2. hashes the header and the code;
3. checks the signature against that hash using the now-trusted key;
4. checks the security version, described in the next section;
5. only then jumps to the code.

Each later stage repeats the pattern for the stage after it, with keys that the earlier, already-checked stage vouches for. A bug in any later stage can therefore be fixed by an update, because the stage before it checks the replacement’s signature like any other. A bug in the boot ROM cannot be fixed on consoles already sold: nothing checks the ROM and nothing can rewrite it, so only a new revision of the chip fixes it. This has happened to at least one console family, whose early units remain modifiable for that reason alone.

Anti-rollback: old versions stay dead

A signature proves who made the code, not that it is the latest version. If version 4 of the bootloader fixes a security hole in version 3, version 3 is still genuinely signed, and without another check anyone could reinstall it and use its hole.

TL;DR: A genuine signature does not establish freshness; accepting an older approved image is a separate decision.

Consoles stop this with anti-rollback, a security version counter kept in fuses. Each boot image carries a security version, and the boot code refuses any image whose version is below the number of blown fuses:

fuse 01

fuse 11

fuse 21

fuse 30

fuse 40

fuse 50

fuse 60

fuse 70

A bank of eight anti-rollback fuses. Three are blown, 1 + 1 + 1 = 3, so the minimum accepted security version is 3.

When an update fixes a security hole, it raises the security version to 4 and blows fuse 3, and from then on a version-3 image is refused. A fuse cannot be unblown, so the minimum only ever rises. And because a bank of eight fuses can count only to 8, makers raise the security version only for updates that fix a security flaw, not for every update: each increase spends a fuse forever.

Code signing and encrypted game packages

The chain does not stop at boot. Everything a console runs, including system updates, apps, and every game, must carry the platform holder’s signature, which the system software checks before launching it. Unsigned code simply does not run. On Windows, by contrast, an Authenticode signature (Lesson 10.8) is optional for ordinary programs, and an unsigned program runs after a warning, because the owner decides.

Game packages are also encrypted, and the two protections do different jobs (Lesson 10.10). The signature proves that the package came, unchanged, from the platform holder. The encryption hides the contents, so the code cannot be read, or copied to run elsewhere, outside a console holding the right keys. Those keys stay inside the security processor, which decrypts content for the game without ever handing the keys to the game or to the system software. Digital purchases add a licence check before anything is decrypted.

Signing everything has a consequence for memory. Code that a program writes for itself at run time was never signed, so consoles generally do not let ordinary games mark memory as both writable and executable, the combination that Lesson 6.5 treats as a place where data can become code. That rule returns in Lesson 13.9, because an emulator’s fastest technique needs exactly that combination.

Why a console is harder to modify than a PC

Question	Typical PC	Typical console
Who decides which code may run?	the owner, as administrator	the platform holder, through signatures
Where does trust start?	firmware whose Secure Boot keys the owner can change or switch off	a boot ROM and a fused key hash that nobody can change
Can the owner debug a running game?	yes, as Chapters 2 and 5 do	no; that needs a development kit
Who holds the storage keys?	the owner, if the disk is encrypted at all	the security processor, never software
Can old system software be reinstalled?	usually	no; anti-rollback fuses refuse it

The deeper difference is whose interests the protections serve. A PC’s security defends its owner against other people: malware, other users, network attackers. The owner is the administrator and may switch any of it off. A console’s security also defends the platform holder and game publishers against the owner: against copying games, against cheating in online play, and against running unapproved software. So a console is built so that its owner cannot switch the protections off, down to debug ports locked with fuses (Lesson 13.7).

Game developers still need to debug. Licensed studios receive development kits: consoles with debugging enabled and different keys, which run unsigned test builds. A retail console lacks those permissions by design.

Narration: A development kit’s debug permissions explain why a studio can inspect its test build while the equivalent retail device refuses the same operation.

Why online services ban modified consoles

An online service decides whether to let a console into matchmaking, the store, and cloud saves. It cannot look inside the console, so it needs the console to prove what software it booted. That proof is called remote attestation:

As each boot stage runs, it records a hash of the next stage before starting it. Those hashes, called measurements, describe exactly what booted. The security processor signs the service’s nonce together with the measurements, using a key unique to that console, fused at the factory, that no software can read. The service checks the signature and compares the measurements with the values genuine software produces. Console makers do not publish their exact protocols, but PCs with a TPM security chip use the same idea, called measured boot.

A console running modified software cannot produce a valid report. The modified software cannot reach the key, and it cannot make the measurements match software it is not. Such a console can run cheats in matches with other people, run pirated games, and send messages that genuine software never would, so the service trusts nothing it says and may ban it. Attestation is still only one layer: no check on a client is perfect, so the server goes on checking every action. Lesson 15.5 follows the ban as one enforcement decision among the other layers.

Homebrew and the law

Homebrew is software written by hobbyists for a platform without the platform holder’s licence: games, tools, media players, and emulators. Because a console runs only signed code, unofficial homebrew depends on a flaw somewhere in the chain of trust, and its legal position is contested. Running pirated games is copyright infringement however the console was modified. This book stays out of that territory: none of its labs modify a console. Lesson 13.9 studies console software from the other side, with an emulator running on your own PC and programs you are allowed to run.

Optional reference: official homebrew, circumvention law, and the arguments on each side

Homebrew’s legal position is worth describing precisely rather than taking a side.

Platform holders have sometimes opened official doors. In the late 1990s Sony sold the Net Yaroze, a black PlayStation that hobbyists could program. The PlayStation 3’s “Other OS” feature let owners install Linux until a 2010 system update removed it. Microsoft’s Developer Mode turns a retail Xbox into a limited development kit for apps, for anyone with a developer account.

Platform holders treat exploiting a flaw in the chain of trust as circumvention. They patch it, ban consoles detected online running modified software, and have sued, and in some cases seen prosecuted, people who sold modification devices commercially. Many countries have anti-circumvention laws, such as section 1201 of the US Digital Millennium Copyright Act and Article 6 of the EU’s 2001 Copyright Directive. These make it unlawful to break technical measures that protect copyrighted works, with exemptions that vary by country and by kind of device.

On the other side, homebrew developers and some researchers argue that owners should be able to run their own code on hardware they bought, and that preserving old software depends on it. Where the line falls depends on the country, the device, and exactly what is done, and this lesson is not legal advice.

🧩

Knowledge check

Why not just ask?

Why can an online service not simply ask a console whether its software has been modified?

1Modified software could answer "no", so the service needs a signed report from the security processor2Consoles cannot send any message at all before the owner has signed in to an account3The honest answer would be too large to send, so the console sends a short random number4Online services may not ask consoles about their software, so they ban unlisted consoles instead

Check answer

Finished Lesson 13.6?

Mark it done and the lesson list shows a ✓ beside it. A chapter whose lessons are all done is marked done too. Progress is saved in this browser only.

Mark lesson doneLesson done. Mark it not done

Chapter 13: 10 lessons

📝 Notes