Chapter 8 — Computer architecture
Lesson map
Lesson 08 published. Map, example, EX022.
flowchart TD
N0["Learning outcomes"]
N1["8.1 Execution"]
N2["8.2 Memory and weaknesses"]
N3["8.3 Hardware help"]
N4["8.4 Language choice"]
N5["8.5 Isolation by design"]
N6["Measuring isolation"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX022"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["8.1 Execution"]
N2["8.2 Memory and weaknesses"]
N3["8.3 Hardware help"]
N4["8.4 Language choice"]
N5["8.5 Isolation by design"]
N6["Measuring isolation"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX022"]
[Learning outcomes]
|
v
[8.1 Execution]
|
v
[8.2 Memory and weaknesses]
|
v
[8.3 Hardware help]
|
v
[8.4 Language choice]
|
v
[8.5 Isolation by design]
|
v
[Measuring isolation]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX022]
Learning outcomes
You will (1) explain how processors execute code and isolate processes; (2) relate memory layout to classes of software weaknesses; (3) explain hardware security features that support software; (4) connect architecture to language choice.
8.1 Execution
Processors fetch instructions, decode them and execute them, reading and writing memory. Operating systems use hardware features such as privilege levels and virtual memory to separate programs.
Privilege levels mean ordinary programs cannot touch hardware or other programs' memory directly; they must ask the operating system, which checks permissions first. Virtual memory gives each process its own view of addresses, so a pointer in the image worker cannot name a location inside the web server. When a flaw is exploited, these boundaries decide how far an attacker can move. That is why Coastline treats the process boundary, not the function boundary, as the line that contains damage.
8.2 Memory and weaknesses
In languages without automatic bounds checks, writing past the end of a buffer can corrupt nearby data. The CWE Top 25 includes out-of-bounds write (CWE-787) and use after free (CWE-416), both memory-safety weaknesses. ticket-web's image library imgkit is written in such a language and wrapped for the web app.
An out-of-bounds write lets a malformed input overwrite values the program relies on, such as a length or a return address. Use after free means code keeps using memory that has been handed back and possibly reused for something else. Both can turn a crafted image into code execution. Image decoders are a classic target because they parse complex, attacker-supplied formats at speed.
8.3 Hardware help
Features such as non-executable memory and address randomisation make memory flaws harder to misuse, but do not remove the flaw. Defence in depth combines them with safer code.
Non-executable memory stops injected bytes from being run directly from a data area, and address randomisation makes it hard to guess where useful code sits. Attackers have found ways around each, for example by reusing code already present in the program. The protections raise cost and reduce reliability of attacks; they buy time for patching rather than replacing it. Kwame checks that both are enabled on the image worker's build.
8.4 Language choice
Memory-safe languages prevent many of these weaknesses by design. Coastline writes new services in memory-safe languages and isolates imgkit in a separate process with limited permissions.
Rewriting imgkit would be costly and would introduce new bugs, so Coastline accepts it for now and contains it instead. The choice is made per component: new code gets the safer language, while trusted old code is wrapped. Each wrapped component is listed with its reason and a review date, so the exception is revisited rather than forgotten. Rust and modern managed languages are examples the team considers for replacements.
8.5 Isolation by design
Running risky parsing code in its own process, with no network access and a time limit, limits damage if a flaw is triggered by a malformed image.
The worker receives image bytes, returns a resized image or an error, and has nothing else to reach: no database credentials, no network and a small writable folder. A compromised worker could at worst return a wrong picture. Kwame's measurement test later confirmed the time limit stops runaway processing. Designing the boundary before an advisory arrives is far cheaper than adding it in a hurry afterwards.
Measuring isolation
Kwame tests the image worker's limits by feeding it synthetic oversized but harmless images in a test environment: the worker is stopped by its time limit after two seconds and restarted automatically, while the web server keeps serving tickets. The test shows the isolation works as designed, and it is repeated whenever the worker's configuration changes.
Worked example
When the imgkit advisory (chapter 24) arrives, the isolation means the worst outcome is a crashed image-worker process, not a compromised web server. Kwame records this as evidence that architecture choices reduced the advisory's impact.
Synthetic case. Components and advisories are synthetic.
Errors and limits
Isolation adds complexity and overhead; it must be maintained as code changes.
Exercises
- EX022 — Memory CWEs. Name two memory-safety CWEs. Rubric: 3 = CWE-787, CWE-416; 2 = one; 1 = vague; 0 = none.
- EX023 — Hardware limits. What do hardware features not do? Rubric: 3 = remove the flaw; 2 = partial; 1 = vague; 0 = none.
- EX024 — imgkit isolation. How is imgkit isolated? Rubric: 3 = separate process, limited permissions, no network, time limit; 2 = partial; 1 = vague; 0 = none.
Synthesis
Architecture and language choices shape which weaknesses exist and how far damage spreads.
Continue studying — chapter 08 of 50
← Chapter 07 (draft) · Course chapter index · Chapter 09 (draft) →