Skip to main content

Security model

PermawebOS provides measured evidence. It does not turn every hardware target into the same kind of TEE.

LapEE Claim​

LapEE gives verifiers evidence that one PermawebOS node booted through a measured laptop path and that the public node identity is bound to that boot.

The evidence includes:

  • TPM quote and PCR values.
  • AK policy over PCRs 0,1,7,10,11,14,15.
  • PCR 15 replay to the node-message-id.
  • Secure Boot state and UKI identity.
  • Kernel command line, lockdown, IOMMU, CPU, memory-encryption, DMI, and TPM posture.
  • Public node config and loaded-device policy.

This is not same-machine tenant isolation. LapEE runs one node as a single-purpose appliance.

Appliance Boundary​

Production LapEE images are designed to reduce local runtime surfaces:

  • ESP inputs are read once.
  • WiFi credentials are used only for network association.
  • The boot USB is unmounted and detached before PermawebOS starts.
  • Local HID, debug, suspend, hibernation, kexec, and late USB surfaces are disabled where practical in production mode.
  • PermawebOS is the intended remote interface.

The local screen is status output, not an operator console.

What Remains Policy​

Verifier policy decides:

  • which release measurements are accepted;
  • whether Secure Boot must be on;
  • whether TME/SME or the no-TME posture is acceptable;
  • which TPM roots or EK material are accepted;
  • which profile and trusted device signer set are allowed;
  • which warnings are fatal for the use case.

Non-Claims​

LapEE does not prove:

  • firmware is honest;
  • Linux or the PermawebOS kernel is bug-free;
  • commodity hardware resists every physical attack;
  • TME/SME provide full memory-integrity or replay protection;
  • a raw disk hash remains stable after config.json or wifi.conf injection;
  • a passing boot measurement proves every future operation is correct.

The point is explicit, measurable, policy-driven evidence.