Chapter 8 — Computer architecture

Chapter 8 — Computer architecture

Lesson map

Lesson 08 published. Map, example, EX022.

flowchart TD
  N0["Learning outcomes"]
  N1["8.1 Privilege levels"]
  N2["8.2 Trusted boot"]
  N3["8.3 Firmware"]
  N4["8.4 Hardware security modules"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX022"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["8.1 Privilege levels"]
  N2["8.2 Trusted boot"]
  N3["8.3 Firmware"]
  N4["8.4 Hardware security modules"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX022"]

[Learning outcomes]
    |
    v
[8.1 Privilege levels]
    |
    v
[8.2 Trusted boot]
    |
    v
[8.3 Firmware]
    |
    v
[8.4 Hardware security modules]
    |
    v
[Worked example] --> [Exercise EX022]

Learning outcomes

You will (1) explain how hardware enforces isolation; (2) describe trusted boot; (3) relate firmware to security risk.

8.1 Privilege levels

Processors run code at different privilege levels. The operating system kernel runs with full control, while applications run restricted and must ask the kernel to access hardware. Lindiwe learns that this separation stops a compromised application from directly reading another program's memory. Memory management units enforce boundaries between processes. Prof. Hale explains that much of software security depends on these hardware features working correctly, which is why processor flaws affect everyone at once. Lindiwe reads about processor flaws that let programs infer memory contents across this boundary.

8.2 Trusted boot

When a laptop starts, firmware loads a bootloader, which loads the operating system. If an attacker alters any stage, later security checks can be bypassed. Secure boot verifies a digital signature at each stage, refusing to run unsigned code. Lindiwe checks a synthetic inventory of Saltmarsh laptops and finds a small group with secure boot disabled for an old driver. She recommends replacing the driver so the feature can be enabled across the fleet. The desktop team schedules the driver replacement for the next quarter.

8.3 Firmware

Firmware in network cards, disks and management controllers runs below the operating system and is rarely updated. Lindiwe learns that server management controllers often have their own network interface and passwords. At Saltmarsh, several controllers still use factory credentials on the server network. She recommends moving them to a separate management network and changing credentials. Prof. Hale notes that attackers favour layers defenders forget to monitor. Lindiwe also lists firmware versions from the synthetic inventory and finds that most management controllers have not been updated since installation, which she adds to the patching backlog.

8.4 Hardware security modules

Some keys need stronger protection than software provides. A hardware security module stores keys inside tamper-resistant hardware and performs cryptographic operations without revealing them. Lindiwe learns that Saltmarsh's payment provider uses such modules, while Saltmarsh's own code-signing key sits in a file on a build server. She recommends moving it to a hardware token or managed key service, so stealing the build server does not give an attacker the ability to sign malicious updates. The development lead agrees to cost the change before the next release.

Worked example

Lindiwe connects privilege levels, secure boot, management controller credentials and hardware key protection to concrete improvements at Saltmarsh.

Synthetic case. Inventories are synthetic.

Errors and limits

Firmware and management controllers are often left with factory credentials.

Exercises

• EX022 — Kernel separation. What does kernel and application separation prevent? Rubric: 3 = one application reading another's memory;; 2 = partly correct;; 1 = vague;; 0 = none.
• EX023 — Secure boot gap. Why was secure boot disabled on some laptops? Rubric: 3 = an old driver;; 2 = partly correct;; 1 = other;; 0 = none.
• EX024 — Signing key. Where should the code-signing key move? Rubric: 3 = a hardware token or managed key service;; 2 = partly correct;; 1 = vague;; 0 = none.

Continue studying — lesson 08 (chapter 08 of 50)

← Chapter 07 · Course chapter index · Chapter 09 →

Continue to the next authored lesson.