Chapter 08 — Computer architecture
Lesson map
Lesson 08 published. Map, example, EX015.
flowchart TD
N0["Learning outcomes and connection"]
N1["8.1 Where state lives"]
N2["8.2 Isolation boundaries"]
N3["8.3 Shared storage and multi-tenancy"]
N4["8.5 Costs"]
N5["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX015"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["8.1 Where state lives"]
N2["8.2 Isolation boundaries"]
N3["8.3 Shared storage and multi-tenancy"]
N4["8.5 Costs"]
N5["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX015"]
[Learning outcomes and connection]
|
v
[8.1 Where state lives]
|
v
[8.2 Isolation boundaries]
|
v
[8.3 Shared storage and multi-tenancy]
|
v
[8.5 Costs]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX015]
Learning outcomes and connection
After this chapter you can (1) locate evidence-bearing state in processors, memory, firmware, storage and virtualisation layers; (2) order collection by volatility and cost; (3) explain how isolation boundaries affect what a responder can see and change; and (4) compare collection options for a virtualised host. It builds on Chapter 3 and prepares Chapters 12, 28 and 34.
8.1 Where state lives
A modern host stores state at many levels: CPU registers and caches (nanoseconds), main memory (lost at power-off), firmware (UEFI, device controllers), local and shared storage, and — for a virtual machine — the hypervisor's view of the guest's memory and disks. Each level differs in volatility, accessibility and trust. RFC 3227 (2002) recommends collecting from most to least volatile; the principle holds, though its examples date from an earlier generation of systems. Memory may contain running processes, network connections and decrypted keys that never reach disk; storage holds history; firmware can persist across reinstallation.
8.2 Isolation boundaries
Privilege rings, memory management units and hypervisors separate software. They also separate observers: a tool running inside a compromised guest relies on that guest's kernel to report truthfully, while a hypervisor-level snapshot observes the guest from outside its trust boundary. Speculative-execution attacks such as Spectre (Kocher et al., 2019) show that boundaries can leak, so architecture must be treated as a set of assumptions to verify, not guarantees. This is why the booking-host table rates the in-guest memory tool as low to medium trust.
8.3 Shared storage and multi-tenancy
When several virtual machines share a storage array, a snapshot of a volume is cheap and fast but captures only what the guest has flushed; a memory snapshot captures volatile state but may be large and briefly pause the guest. In multi-tenant platforms the snapshot must not include another tenant's data — collection scope is an authorisation question as well as a technical one (Chapter 27). On the HVSS cluster that serves council, water-billing and hospital tenants, the scope check must confirm that the snapshotted volume belongs only to the booking host before collection starts.
8.4 Worked example (synthetic): HVSS booking host
A synthetic HVSS virtual machine runs the booking service on a hypervisor cluster with a shared storage array. An endpoint alert suggests a malicious process. Collection options:
| Option | Captures | Cost / risk | Trust |
|---|---|---|---|
| In-guest memory tool | processes, connections, keys | runs on suspect kernel; may alter state; 16 GB to copy | low–medium |
| Hypervisor memory snapshot | full guest RAM | brief pause; needs platform team; 16 GB | higher |
| Storage snapshot | disk blocks as flushed | near-instant; misses unflushed data | high for disk |
| Live triage commands | small, targeted | quick; each command changes state | low |
A defensible order: storage snapshot (cheap, protects disk history), hypervisor memory snapshot with recorded pause time, then targeted live triage only if needed; record hashes and times for each. The evidence-bearing map, not habit, drives the choice.
8.5 Costs
Estimate transfer time: 16 GB over a 1 Gb/s link at ~80% efficiency takes about $16 \times 8 / 0.8 \approx 160$ s; across a congested 100 Mb/s branch link it takes roughly 27 minutes, during which the service is degraded and the data change. Architecture determines whether collection is practical during an incident, so the evidence platform must be designed with collection paths in mind, not added afterwards.
The same arithmetic decides the order in the booking-host example. The storage snapshot is near-instant on the array, while the 16 GB memory snapshot must be copied off the hypervisor before analysis. Collecting it over a branch link would leave the booking service degraded for the whole transfer.
8.6 Errors and limits
- Trusting in-guest tools on a compromised kernel without corroboration.
- Ignoring firmware as a persistence location.
- Taking multi-tenant snapshots without scope checks.
- Forgetting that collection itself changes state; record what it changed.
In the booking-host case, each error has a specific guard. Findings from the in-guest memory tool are corroborated against the hypervisor snapshot before anyone relies on them. The storage snapshot is checked to contain only the booking host's volume on the shared array. The pause time of the memory snapshot and every live triage command are written into the record with their hashes and times.
Exercises — chapter 08
EX015 — Evidence map. Objective: map state to collection. Inputs: a synthetic container host running 12 containers on a VM. Steps: list five evidence-bearing locations across layers, with volatility, a collection method and one trust caveat each. Expected evidence: table. Rubric: 3 = five layers covered with specific caveats; 2 = four; 1 = generic list; 0 = none.
EX016 — Transfer budget. Objective: decide feasibility. Inputs: 64 GB memory image; links of 10 Gb/s and 200 Mb/s at 80% efficiency; incident requires collection within 30 min. Steps: compute both times; recommend. Expected evidence: two times and recommendation. Rubric: 3 = ≈64 s and ≈53 min, with a recommendation such as hypervisor-local snapshot then later transfer or targeted collection; 2 = numbers; 1 = attempt; 0 = none.
Chapter synthesis
Evidence lives at every architectural layer with different volatility and trust. Map it, choose collection by observer position and cost, respect isolation and tenancy boundaries, and design collection paths into the platform before they are needed.
Continue studying — chapter 08 of 50
← Chapter 07 · Course chapter index · Chapter 09 →
Continue to the next authored lesson.