Chapter 8 — Computer architecture
Lesson map
Lesson 08 published. Map, example, EX015.
flowchart TD
N0["Learning outcomes and connection"]
N1["8.1 The machine model"]
N2["8.2 PLCs, RTUs and embedded controllers"]
N3["8.3 Hardware support for security"]
N4["8.4 When speed creates leakage"]
N5["8.6 Practical activity"]
N6["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX015"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["8.1 The machine model"]
N2["8.2 PLCs, RTUs and embedded controllers"]
N3["8.3 Hardware support for security"]
N4["8.4 When speed creates leakage"]
N5["8.6 Practical activity"]
N6["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX015"]
[Learning outcomes and connection]
|
v
[8.1 The machine model]
|
v
[8.2 PLCs, RTUs and embedded controllers]
|
v
[8.3 Hardware support for security]
|
v
[8.4 When speed creates leakage]
|
v
[8.6 Practical activity]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX015]
Learning outcomes and connection
After this chapter you can (1) describe how a processor, memory hierarchy and I/O interact, and why this matters for real-time control; (2) explain the architecture of programmable logic controllers (PLCs), RTUs and embedded controllers; (3) relate hardware features — privilege levels, memory protection, secure boot, hardware roots of trust — to security guarantees; and (4) explain how performance optimisations such as caching and speculation create vulnerabilities. It builds on Chapter 3 and prepares Chapter 12 (operating systems).
8.1 The machine model
A processor fetches instructions from memory, decodes and executes them, and reads and writes data in registers and memory. Memory is a hierarchy — registers, caches, main memory, storage — each level larger and slower. I/O devices connect through buses and interrupts; an interrupt suspends normal execution so the processor can service a device. Determinism — knowing the worst-case time an operation takes — matters more in control than average speed: a pump-protection routine that usually takes 1 ms but occasionally 50 ms because of a cache miss storm or garbage collection may miss its deadline.
8.2 PLCs, RTUs and embedded controllers
A PLC executes a scan cycle: read inputs, execute the user program, write outputs, perform communications and diagnostics, repeat — often every 10–100 ms. Its program is written in languages standardised in IEC 61131-3 (ladder logic, function block diagrams, structured text). An RTU is designed for remote sites: it gathers measurements, applies simple logic and communicates over long-distance links, tolerating intermittent connectivity. Both are long-lived: equipment installed today may run for fifteen to twenty-five years, so the security features you choose now must still be acceptable in the 2040s. Many legacy controllers accept program changes from anyone who can reach them on the network; Stuxnet exploited the path from an engineering workstation to PLC logic, as analysed by Langner (2011).
8.3 Hardware support for security
- Privilege levels separate kernel from user code; a fault in user code cannot directly overwrite the kernel.
- Memory protection units (MPU) and memory management units (MMU) enforce which code may access which memory; an MPU is common in microcontrollers that lack a full MMU.
- Execute-never marking prevents data regions from being executed.
- Secure boot verifies a cryptographic signature on each stage of firmware before running it, anchored in an immutable root of trust (ROM code or fused keys). It protects against persistent firmware modification, not against a correctly signed but vulnerable image.
- Trusted platform modules and secure elements store keys so that software cannot read them out.
8.4 When speed creates leakage
Caches and speculative execution make processors fast by guessing and keeping state, and that state can leak. Kocher et al. (2019) showed that speculative execution can be steered to read memory across protection boundaries (Spectre). Kim et al. (2014) showed that repeated DRAM access can flip bits in adjacent rows (Rowhammer). These matter most where untrusted code shares hardware with trusted code — virtualised control-centre servers, shared cloud — and less in a single-purpose PLC. The engineering lesson: hardware is part of the attack surface, and isolation that relies on shared hardware must be justified.
8.5 Worked example: choosing an RTU platform (synthetic)
TMRP compares two candidate RTUs. RTU-A: mature, deterministic, no secure boot, firmware updates unsigned, program changes authenticated only by a shared password. RTU-B: secure boot with vendor-signed firmware, role-based authentication for program changes, hardware key storage, but a 200 ms longer worst-case response to communication requests and a new product with limited field history. The team scores both against requirements: R1 (authenticated telemetry) needs key storage — favouring B; R7 (alarm within 60 s) is met by both, as 200 ms is negligible; maintainability over 20 years favours a vendor with a published secure-development lifecycle. The decision record selects B for new sites and a gateway for legacy RTU-A sites, with a pilot to collect field reliability data before fleet roll-out.
8.6 Practical activity
For a microcontroller or PLC family of your choice, read the vendor's public security manual (or a datasheet) and complete a table: privilege separation, memory protection, secure boot, signed updates, key storage, authenticated programming. Mark each "yes / no / configurable / unknown" with a source citation. Use public documents only.
Record the document title, version and date for each entry, because security features change between firmware releases. Where the manual is silent, mark the feature unknown rather than guessing, and list the question you would ask the vendor. The table is the same comparison the TMRP team made between RTU-A and RTU-B, and it shows quickly whether a product can support authenticated telemetry and key storage without a gateway.
8.7 Common errors and limits
- Equating "fast" with "deterministic".
- Assuming secure boot prevents exploitation of signed firmware.
- Ignoring the 20-year lifetime when choosing cryptographic and update features.
- Treating hardware isolation on shared servers as absolute.
- Treating vendor marketing as evidence; ask for documentation and test.
The RTU comparison shows these errors in practice. RTU-A is deterministic but cannot protect keys, so speed alone does not make it suitable. RTU-B's secure boot does not stop a malicious but legitimately signed logic change, which is why role-based programming access is listed beside it. Both must still be supportable in the 2040s, and the pilot exists because vendor claims are not field evidence.
Exercises — chapter 8
EX015 — Scan-cycle budget. Objective: reason about determinism. Inputs: PLC scan of 20 ms nominal, 45 ms worst case; a pump-protection requirement to trip within 100 ms of a low-suction signal, which is debounced over two consecutive scans. Steps: compute the worst-case trip latency (input sampling just after a read, two scans to confirm, output write). Expected evidence: calculation and conclusion. Rubric: 3 = correct worst case including sampling delay and judgement against 100 ms; 2 = sampling delay omitted; 1 = nominal scan only; 0 = none.
EX016 — What secure boot buys. Objective: scope a control precisely. Inputs: RTU-B in §8.5. Steps: list two attacks secure boot prevents, two it does not, and the complementary control for each of the latter. Expected evidence: table. Rubric: 3 = accurate scope (prevents unsigned persistent firmware; not runtime exploits or malicious logic changes via legitimate programming), matched controls; 2 = one error; 1 = generic; 0 = none.
Chapter synthesis
Architecture determines both timing and trust. Control needs worst-case, not average, performance. PLCs and RTUs are long-lived, scan-based machines whose security features must still be adequate decades from now. Hardware mechanisms — privilege, memory protection, secure boot, key storage — give specific, limited guarantees; performance features can leak across boundaries. State exactly what each mechanism protects against.
Continue studying — chapter 08 of 50
← Chapter 07 · Course chapter index · Chapter 09 →
Continue to the next authored lesson.