Chapter 8 — Computer architecture | Engineering AI and machine-learning security

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Lesson map

Lesson 08 published. Map, example, EX022.

flowchart TD
  N0["Learning outcomes"]
  N1["8.1 Processors and accelerators"]
  N2["8.2 Numeric formats"]
  N3["8.3 Architectural attack surfaces"]
  N4["8.4 Trusted execution and attestation"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX022"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["8.1 Processors and accelerators"]
  N2["8.2 Numeric formats"]
  N3["8.3 Architectural attack surfaces"]
  N4["8.4 Trusted execution and attestation"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX022"]

[Learning outcomes]
    |
    v
[8.1 Processors and accelerators]
    |
    v
[8.2 Numeric formats]
    |
    v
[8.3 Architectural attack surfaces]
    |
    v
[8.4 Trusted execution and attestation]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX022]

Learning outcomes

You will (1) describe CPUs, memory hierarchies, GPUs and accelerators used for machine learning; (2) explain numeric formats and their effect on model behaviour; (3) identify architectural attack surfaces (memory isolation, side channels, firmware); and (4) reason about trusted execution for AI workloads.

8.1 Processors and accelerators

CPUs execute general instructions with deep caches. GPUs and AI accelerators execute thousands of simple operations in parallel, ideal for matrix multiplication. Models move between host memory and device memory; data in device memory may be shared across processes or tenants in cloud settings, so isolation matters.

Copies are the security concern: weights loaded onto a GPU, inputs held in a shared buffer and results waiting to be returned all exist briefly in places another tenant or a careless driver might read. Cloud providers isolate customers, but engineers still ask whether device memory is cleared between jobs and who can see it, and they record the answers in the deployment's threat model.

8.2 Numeric formats

Training often uses 32-bit or 16-bit floating point; inference may use 8-bit integers (quantisation). Lower precision changes outputs slightly and can change decisions near boundaries. Security evaluations must use the deployed precision: an attack or defence measured in 32-bit may behave differently in 8-bit, and vice versa.

Quantisation maps each value to the nearest of a small set of levels, so inputs close to the decision threshold can move to the other side. Gradients computed on a 32-bit copy may not match the 8-bit model's behaviour, which can make attacks look stronger or weaker than they are in service.

8.3 Architectural attack surfaces

Memory-safety bugs in model-serving code can expose weights or inputs. Shared caches and timing can leak information across processes (side channels). Hardware faults — including deliberately induced ones such as rowhammer-style bit flips — can corrupt weights; research has shown that a small number of flipped bits in a network's parameters can sharply degrade or redirect it. Firmware and drivers are part of the trusted computing base.

For an engineer, each item suggests a control: memory-safe languages or careful review for serving code, isolation between tenants, error-correcting memory and integrity checks on loaded weights. Hashing the weight file before loading catches changes on disk, but not bits flipped in memory afterwards, so critical deployments also compare outputs on a fixed check set at intervals.

8.4 Trusted execution and attestation

Trusted execution environments (TEEs) and confidential-computing GPUs aim to protect code and data in use from the host operator, and remote attestation lets a client verify what code is running. They reduce some risks (curious cloud operator) but not others (a vulnerable model server inside the enclave, prompt injection).

Attestation answers a narrow question: is this the expected code on genuine hardware? It says nothing about whether that code is safe. Engineers therefore treat a TEE as one layer that protects against a curious operator, and keep input validation, privilege limits and monitoring in place for attacks that arrive through the model's normal interface.

8.5 Worked example (synthetic NRS case)

TrackEye runs on an edge computer in the inspection train with an 8-bit quantised model. Sam found the robustness tests had been run on the 32-bit model in the lab; rerunning on the deployed 8-bit build changed false negatives at dawn from 9.0% to 9.6%. Sam added "evaluate on the deployed artefact and hardware" as a requirement and noted that the edge computer's maintenance port gives physical access to firmware — a threat-model item.

A rise of 0.6 percentage points is small, but it shows that the lab result did not describe the system actually running on the train. The new requirement means every future robustness figure names the artefact hash and hardware it was measured on.

8.6 Errors and limits

Evaluating a different numeric precision from the one deployed.
Assuming TEEs solve application-level attacks.
Ignoring firmware and physical maintenance ports.

These mistakes share a cause: evaluating an idealised system rather than the deployed one. The precision used in tests is easy to check against the build. TEE claims should be read for what they exclude. Maintenance ports are often left enabled for convenience; Sam's checklist asks for each port whether it is needed in service, who can reach it and whether its use is logged.

Exercises

EX022 — Precision. Why must robustness be tested on the quantised deployed model? Rubric: 3 = quantisation changes outputs near boundaries; results may differ; 2 = partial; 1 = vague; 0 = wrong.
EX023 — TEE limits. Name one threat a TEE mitigates and one it does not for an LLM service. Rubric: 3 = host operator reading data vs prompt injection/server bugs; 2 = one; 1 = vague; 0 = wrong.
EX024 — Bit flips. Explain why weight-integrity checks at load time do not fully address fault attacks. Rubric: 3 = faults can occur in memory after loading; need runtime checks/ECC/redundancy; 2 = partial; 1 = vague; 0 = wrong.

Synthesis

AI runs on real hardware with finite precision, shared resources and firmware. Engineers test the deployed artefact on the deployed platform and include architecture-level threats in the model.

Continue studying — chapter 08 of 50

← Chapter 07 (draft) · Course chapter index · Chapter 09 (draft) →