build(deps): bump the actions-updates group across 1 directory with 3 updates

Bumps the actions-updates group with 3 updates in the / directory: [step-security/harden-runner](https://github.com/step-security/harden-runner), [actions/create-github-app-token](https://github.com/actions/create-github-app-token) and [MarcoIeni/release-plz-action](https://github.com/marcoieni/release-plz-action).


Updates `step-security/harden-runner` from 2.11.0 to 2.11.1
- [Release notes](https://github.com/step-security/harden-runner/releases)
- [Commits](4d991eb9b9...c6295a65d1)

Updates `actions/create-github-app-token` from 1.11.6 to 1.12.0
- [Release notes](https://github.com/actions/create-github-app-token/releases)
- [Commits](21cfef2b49...d72941d797)

Updates `MarcoIeni/release-plz-action` from 0.5.99 to 0.5.101
- [Release notes](https://github.com/marcoieni/release-plz-action/releases)
- [Commits](476794ede1...8e91c71a60)

---
updated-dependencies:
- dependency-name: step-security/harden-runner
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: actions-updates
- dependency-name: actions/create-github-app-token
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: actions-updates
- dependency-name: MarcoIeni/release-plz-action
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: actions-updates
...

Signed-off-by: dependabot[bot] <support@github.com>

.github/workflows/check.yml

@@ -6,16 +6,13 @@ on:
   merge_group:
     branches:
     - main
-permissions:
-  contents: read
-
 jobs:
   rustfmt:
     name: rustfmt
     runs-on: ubuntu-latest
     steps:
     - name: harden runner
-      uses: step-security/harden-runner@4d991eb9b905ef189e4c376166672c3f2f230481 # v2.11.0
+      uses: step-security/harden-runner@c6295a65d1254861815972266d5933fd6e532bdf # v2.11.1
       with:
         egress-policy: audit
     - name: checkout repository
@@ -36,7 +33,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
     - name: harden runner
-      uses: step-security/harden-runner@4d991eb9b905ef189e4c376166672c3f2f230481 # v2.11.0
+      uses: step-security/harden-runner@c6295a65d1254861815972266d5933fd6e532bdf # v2.11.1
       with:
         egress-policy: audit
     - name: checkout repository
@@ -58,7 +55,7 @@ jobs:
     name: full build linux-${{ matrix.arch }}
     steps:
     - name: harden runner
-      uses: step-security/harden-runner@4d991eb9b905ef189e4c376166672c3f2f230481 # v2.11.0
+      uses: step-security/harden-runner@c6295a65d1254861815972266d5933fd6e532bdf # v2.11.1
       with:
         egress-policy: audit
     - name: checkout repository
@@ -86,7 +83,7 @@ jobs:
     name: full test linux-${{ matrix.arch }}
     steps:
     - name: harden runner
-      uses: step-security/harden-runner@4d991eb9b905ef189e4c376166672c3f2f230481 # v2.11.0
+      uses: step-security/harden-runner@c6295a65d1254861815972266d5933fd6e532bdf # v2.11.1
       with:
         egress-policy: audit
     - name: checkout repository
@@ -113,7 +110,7 @@ jobs:
     name: full clippy linux-${{ matrix.arch }}
     steps:
     - name: harden runner
-      uses: step-security/harden-runner@4d991eb9b905ef189e4c376166672c3f2f230481 # v2.11.0
+      uses: step-security/harden-runner@c6295a65d1254861815972266d5933fd6e532bdf # v2.11.1
       with:
         egress-policy: audit
     - name: checkout repository

.github/workflows/release-plz.yml

@@ -6,9 +6,6 @@ on:
 concurrency:
   group: "${{ github.workflow }}"
   cancel-in-progress: true
-permissions:
-  contents: read
-
 jobs:
   release-plz:
     name: release-plz
@@ -18,11 +15,11 @@ jobs:
       contents: write
     steps:
     - name: harden runner
-      uses: step-security/harden-runner@4d991eb9b905ef189e4c376166672c3f2f230481 # v2.11.0
+      uses: step-security/harden-runner@c6295a65d1254861815972266d5933fd6e532bdf # v2.11.1
       with:
         egress-policy: audit
     - name: generate cultivator token
-      uses: actions/create-github-app-token@21cfef2b496dd8ef5b904c159339626a10ad380e # v1.11.6
+      uses: actions/create-github-app-token@d72941d797fd3113feb6b93fd0dec494b13a2547 # v1.12.0
       id: generate-token
       with:
         app-id: "${{ secrets.EDERA_CULTIVATION_APP_ID }}"
@@ -40,7 +37,7 @@ jobs:
     - name: install linux dependencies
       run: ./hack/ci/install-linux-deps.sh
     - name: release-plz
-      uses: MarcoIeni/release-plz-action@476794ede164c5137bfc3a1dc6ed3675275690f9 # v0.5.99
+      uses: MarcoIeni/release-plz-action@8e91c71a60327f76b30233d17e3cabb316522e8f # v0.5.101
       env:
         GITHUB_TOKEN: "${{ steps.generate-token.outputs.token }}"
         CARGO_REGISTRY_TOKEN: "${{ secrets.KRATA_RELEASE_CARGO_TOKEN }}"

README.md

@@ -11,7 +11,6 @@ krata is an implementation of a Xen control-plane in Rust.
 - [Frequently Asked Questions](FAQ.md)
 - [Code of Conduct](CODE_OF_CONDUCT.md)
 - [Security Policy](SECURITY.md)
-- [Edera Technical Overview](technical-overview.md)
 
 ## Introduction
 
@@ -24,4 +23,3 @@ It provides the base layer upon which Edera Protect zones are built on: a secure
 |--------------|------------------|-------------------------|
 | x86_64       | 100% Completed   | None, Intel VT-x, AMD-V |
 | aarch64      | 10% Completed    | AArch64 virtualization  |
-

technical-overview.md

@@ -1,86 +0,0 @@
-# Edera Technical Overview
-
-## What is Edera?
-
-Edera is a secure-by-default, cloud-native platform built on a reimagined, memory-safe type-1 hypervisor. It unlocks hard multitenancy and strong container isolation—without the performance hit.
-
-Unlike traditional container runtimes that share a single Linux kernel across containers, Edera runs each container in a lightweight virtual machine (called a **zone**), with its own dedicated Linux kernel. This eliminates the kernel as a shared attack surface.
-
-And because Edera doesn’t rely on nested virtualization, it runs wherever containers do—across public clouds, on-prem, and edge environments.
-
-## How Edera Works
-
-At its core, Edera uses a custom hypervisor based on Xen, with key components rewritten in Rust for safety, performance, and maintainability. Edera introduces the concept of **zones**—independent, fast-booting virtual machines that serve as security boundaries for container workloads.
-
-Each zone runs its own Linux kernel and minimal init system. The kernel and other system components are delivered via OCI images, keeping things composable, cacheable, and consistent.
-
-Zones are paravirtualized using the Xen PV protocol. This keeps them lightweight and fast—no hardware virtualization required. But when hardware support is available (e.g., on x86 with VT-x), Edera uses it to get near bare-metal performance.
-
-## How Edera Runs & Secures Containers
-
-Edera allows you to compose your infrastructure the same way you compose workloads: using OCI images.
-
-Each zone consumes a small number of OCI images:
-- A **kernel image** that provides the zone kernel.
-- One or more **system extension images** that provide init systems, utilities, and kernel modules.
-- Optionally, **driver zones**—zones that provide shared services (like networking) to other zones.
-
-Inside each zone, container workloads run via a minimal OCI runtime called **Styrolite**, written in Rust. Unlike traditional setups (like Kata Containers, which layer containerd and runc as external processes), Styrolite is embedded inside the zone itself.
-
-### Key Benefits of This Design
-- No external container runtime processes  
-- Zone init system directly manages containers  
-- Minimal attack surface, optimized for secure execution
-
-This tightly integrated design avoids the complexity, latency, and exposure introduced by conventional container runtimes. It keeps the execution path short, verifiable, and secure-by-design.
-
-## Zones as Security Boundaries
-
-In Kubernetes, Edera runs pods inside **zones**—isolated virtual machines that eliminate risks like container escape, privilege escalation, and lateral movement.
-
-Each zone boots its own kernel, pulled via OCI, and runs a single pod by default. You can also configure zones to run a replica set, a namespace, or a set of trusted workloads together.
-
-To use Edera, apply the `RuntimeClass`:
-
-```yaml
-apiVersion: node.k8s.io/v1
-kind: RuntimeClass
-metadata:
-  name: edera
-handler: edera
-```
-
-Then annotate your pod:
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
-  name: edera-protect-pod
-spec:
-  runtimeClassName: edera
-```
-
-This causes the pod to be scheduled to a node running Edera’s hypervisor. The pod is transparently launched inside its own VM zone—no image changes, no config rewrites, and no extra work from developers.
-
-## What Exactly Is an Edera Zone?
-
-An Edera zone is a minimal VM built from OCI-delivered components. At launch time, the Edera daemon unpacks:
-
-### Kernel Image
-Located under `/kernel` in the OCI image:
-- `image`: the Linux kernel (vmlinuz)
-- `metadata`: key-value pairs for boot parameters
-- `addons.squashfs`: includes kernel modules in `/modules`
-- `config.gz`: the kernel configuration file
-
-### Initramfs Contents
-Packaged in a CPIO archive, typically mounted from:
-`usr/lib/edera/protect/zone/initrd`
-
-The initramfs includes:
-- `/init`: static Rust binary that initializes the zone
-- `/bin/styrolite`: embedded container runtime
-- `/bin/zone`: control plane for managing containers and services via IDM (inter-domain messaging)
-
-This structure lets Edera launch zones rapidly, with well-defined boundaries and no dependency on the host OS kernel. Everything the workload touches is defined, versioned, and validated.