Learn From Hardware and Firmware Failures

What you will learn

This lesson covers:

Microarchitectural attacks
Speculative execution
Fault injection
Firmware compromise
Microcode risk
Platform patching
TCB recovery
Security advisories

Hardware is trusted, not infallible

A TEE depends on processor hardware and firmware.

That dependency creates strong isolation, but it also creates a serious failure mode.

When hardware assumptions break, many workloads may be affected at once.

TEE developers need to understand attack classes, not only product features.

TEE attack-layer stack showing that vulnerabilities can arise across application, runtime, OS interfaces, microarchitecture, firmware, microcode, processor, and physical hardware.

Transient and speculative execution attacks

Modern processors execute instructions speculatively to improve performance.

A processor may begin work before it knows whether that work should be committed.

The architectural result may be discarded, while microarchitectural effects remain visible through a side channel.

Foreshadow demonstrated that transient execution could leak SGX enclave secrets and, in the studied systems, undermine attestation-related keys and trust assumptions.

The main lesson is:

> Architectural access control does not automatically control every microarchitectural effect.

Fault injection

Fault injection causes the processor to execute incorrectly.

Possible fault sources include:

Voltage manipulation
Clock manipulation
Power interruption
Laser or electromagnetic injection
Cache-state manipulation
Rowhammer-style effects
Firmware abuse
Malicious microcode

Plundervolt showed that privileged software could use voltage-control interfaces to corrupt Intel SGX computations. The attack targeted integrity inside the processor rather than modifying protected external memory.

CacheWarp

CacheWarp demonstrated a software-controlled fault attack against AMD SEV-ES and SEV-SNP.

The attack used cache invalidation behaviour to make a guest continue from stale architectural state. Demonstrations included cryptographic-key recovery, authentication bypass, and privilege escalation.

The lesson is not that memory integrity is useless.

The lesson is that the guarantee depends on the complete interaction between:

Caches
Memory
Instructions
Hypervisor control
Firmware
Microcode

System Management Mode risk

System Management Mode is a highly privileged x86 execution environment used for firmware-level system functions.

AMD's advisory for CVE-2023-31315 describes a condition in which an attacker with ring-0 privileges could modify SMM configuration despite SMM Lock, potentially leading to arbitrary code execution.

TEE threat models should state whether compromise of highly privileged firmware modes is considered.

Microcode risk

Processors use microcode to implement and update some instruction behaviour.

Microcode updates may:

Fix vulnerabilities
Change performance
Change attestation status
Add mitigations
Disable unsafe features

Microcode verification itself is part of the trust chain.

AMD disclosed a microcode signature-verification vulnerability that could allow a privileged attacker to load malicious microcode on affected systems.

This shows why the TCB includes more than the visible application and guest operating system.

TCB recovery

When a hardware vulnerability is disclosed, the platform may require:

Microcode update
Firmware update
BIOS update
Kernel update
Compiler mitigation
Application rebuild
New measurement
Updated attestation policy
Revocation of old platforms
Key rotation

A patched system may produce a different TCB status or security version.

The verifier must understand that status.

Security-version policy

A policy should not only accept a workload measurement.

It should also enforce a minimum platform security level when the evidence supports it.

Example:

`` Accept: workload_measurement = approved firmware_security_version >= 12 microcode_security_version >= 9 debug = false ``

When a vulnerability is disclosed, the policy can increase the minimum value.

Patch versus availability

Immediate revocation may protect confidentiality but stop the service.

Delayed revocation may preserve availability while exposing secrets.

A response plan should define:

Vulnerability severity threshold
Emergency maintenance window
Required patch time
Secret-rotation rule
Customer notification
Workload shutdown criteria
Fallback architecture
Evidence-policy update

Hardware diversity

A system may distribute trust across different hardware families.

For example:

One key share in AMD SEV-SNP
One share in Intel TDX
One share in a separate HSM

A threshold operation requires multiple shares.

This may reduce dependence on one platform family.

It increases:

Operational complexity
Attestation complexity
Network communication
Failure handling
Policy management

💡

Hardware diversity is not automatically safer. It is a trade-off between reduced single-vendor risk and increased operational complexity.

New research continues

TEE attack research remains active.

Current research includes attacks and mitigations involving:

Controlled channels
Cache and timing leakage
Interrupt-driven single stepping
VM integrity
Firmware
CPU performance counters
Composite CPU and device attestation

A TEE curriculum and production system both need an update process.

Advisory workflow

A security team should monitor:

Hardware vendor advisories
Cloud-provider notices
Firmware updates
Linux kernel security lists
NVD records
Academic security conferences
TEE runtime releases
Attestation-collateral changes

When an advisory appears:

1. Identify affected hardware. 2. Identify affected workload versions. 3. Determine attacker requirements. 4. Determine affected property. 5. Find vendor mitigation. 6. Check performance impact. 7. Update policy. 8. Patch and attest. 9. Rotate secrets if required. 10. Record remaining risk.

TEE vulnerability-response flow from security advisory and impact analysis through patching, attestation-policy update, optional key rotation, and service recovery.

Developer exercise

Choose one attack:

Foreshadow
Plundervolt
CacheWarp
SinkClose

Write:

1. Affected platform 2. Attacker capability 3. Failed assumption 4. Security property affected 5. Mitigation 6. Remaining risk 7. Required verifier-policy change

Common mistakes

⚠

**Saying hardware attacks are impossible without physical access** — Foreshadow and Plundervolt both showed software-only paths to hardware-level compromise. **Patching the host but not updating attestation policy** — A patched system may have a new security version; the verifier must require it. **Ignoring microcode and firmware** — These are part of the TCB and need patching too. **Treating a vendor mitigation as proof that all related risk is removed** — New research may find bypass techniques. **Failing to rotate secrets after possible exposure** — Secrets provisioned before a vulnerability may have been accessible to an attacker. **Keeping vulnerable systems accepted for compatibility** — Minimum security-version policies must be enforced.

Key takeaways

Hardware trust is an assumption.
Microarchitectural and fault attacks can bypass expected boundaries.
Firmware and microcode are part of the TCB.
Patching may change attestation status.
Vulnerability response must connect patches, policy, measurements, and keys.
TEE security requires continuous maintenance.

Check your understanding

1. How does transient execution differ from normal architectural execution? 2. What property did Plundervolt attack? 3. Why is microcode part of the TCB? 4. Why must verifier policy change after some patches? 5. What costs come with hardware diversity?