v0.0.5

Release v0.0.5

Builds on v0.0.4. This release is a security-and-fidelity pass: it tightens
the kernel's most sensitive edges and fills in the system-call behaviors
real-world software relies on — far enough that a standard container runtime
now starts a container end to end and the kernel boots an unmodified
distribution to an interactive shell.

• Hardened security-sensitive edges. Returning from a signal can no longer be
  used to hand a program elevated processor flags, and the two signals that
  must never be caught or ignored now always take effect. Memory-management
  arithmetic is bounds-checked and overflow-checked even in release builds, a
  reference-count lifetime hazard is closed, and a program's privileges are
  recomputed correctly when it replaces its own image. Socket address lengths
  are clamped to what the caller passed, a shared-memory attach race is closed,
  and the priority-inheritance and debugger paths now go through the engine's
  own entry points.

• Real in-memory file sealing. A program can seal an anonymous in-memory file
  against growth, shrinking, or further writes, and those seals are enforced —
  including against a later attempt to regain write access through a mapping.

• Faithful memory remapping. Remapping a mapped file or shared region now moves
  and resizes it correctly, including a fixed-address move and a partial
  sub-range of a shared segment.

• Real mount semantics. Read-only, no-setuid, no-device, and no-exec are
  enforced per mount and can be changed by remounting; remounting a bind mount
  applies the new flags to the right mount; and the filesystem-statistics call
  reports a mount's flags, so software that checks whether it sits on a
  read-only mount reads the truth. Each mount namespace carries its own mount
  flags, so a change in one namespace cannot alter another's.

• Correct rename and open semantics. Rename honors its no-replace, exchange,
  and directory-cycle rules; renaming across filesystems reports the right
  error; overwriting rename — on disk and across directories — is correct and
  atomic; opening a non-directory as a directory, or a directory for writing,
  fails the way callers expect; and truncate-on-open only truncates regular
  files, so redirecting output into a device works.

• Faithful executable identity. A process's own executable stays openable
  through the process filesystem even after it re-executes itself from an
  open file descriptor with no backing path, while still reporting that path
  when asked — the startup pattern security-conscious runtimes use to protect
  themselves from tampering.

• Runs real container workloads. With the above in place, a standard container
  runtime sets up and runs a container to completion, and the kernel boots an
  unmodified distribution through its init system to an interactive shell. The
  conformance suite — real applications booted under the kernel — passes in
  full.

See README.md for what runs today, and docs/ for the architecture, the
verification recipe, and the clean-room policy.