Core Components Deep Dive

Edera’s stack consists of several key open-source projects, each playing a critical role. Let’s explore each one.

Protect: The Xen Control Plane

Protect is the heart of Edera’s VM management. It’s responsible for creating, managing, and destroying Zones via Xen.

What Protect Does

• VM Lifecycle Management: Create, start, stop, destroy VMs
• Resource Allocation: CPU, memory, disk assignment
• Device Management: Network, storage, GPU attachment
• Event Monitoring: Track VM state changes
• API Server: Provides gRPC API for VM operations

Architecture

┌──────────────────────────────────┐
│          Protect Daemon          │
│                                  │
│  ┌────────────┐  ┌────────────┐  │
│  │ VM Manager │  │  Resource  │  │
│  │            │  │  Allocator │  │
│  └────────────┘  └────────────┘  │
│                                  │
│  ┌────────────────────────────┐  │
│  │      Xen Toolstack         │  │
│  │      (libxl interface)     │  │
│  └────────────────────────────┘  │
└────────────┬─────────────────────┘
             │
             ▼
      Xen Hypervisor

Key Features

Declarative Configuration:

Fast Boot Times:

• Optimized kernel and initrd
• Paravirtualized drivers
• Minimal userspace in Zone

Resource Management:

• CPU pinning support
• Memory ballooning
• Disk I/O throttling
• Network bandwidth control

Why It Matters

Protect abstracts away Xen’s complexity, providing a modern, declarative API for VM management. It’s what makes Edera feel like containers, not traditional VMs.

Styrolite: The Container Runtime

Repository: github.com/edera-dev/styrolite

Styrolite is Edera’s CRI-compatible container runtime. It makes Edera work seamlessly with Kubernetes.

What Styrolite Does

• CRI Implementation: Full Container Runtime Interface support
• Image Management: Pull, cache, and extract OCI images
• Translation Layer: Convert container specs to VM specs
• Integration: Bridge between Kubernetes and Protect
• Status Reporting: Report pod/container status to kubelet

CRI Operations

Styrolite implements all standard CRI operations:

// Key CRI APIs Styrolite implements
RunPodSandbox(config *PodSandboxConfig) (string, error)
StopPodSandbox(podSandboxId string) error
RemovePodSandbox(podSandboxId string) error
PodSandboxStatus(podSandboxId string) (*PodSandboxStatus, error)

CreateContainer(podSandboxId, config *ContainerConfig) (string, error)
StartContainer(containerId string) error
StopContainer(containerId string, timeout int64) error
RemoveContainer(containerId string) error
ContainerStatus(containerId string) (*ContainerStatus, error)
ListContainers(filter *ContainerFilter) ([]*Container, error)

ExecSync(containerId string, cmd []string) (stdout, stderr, error)
Exec(containerId string, cmd []string) (io.ReadWriteCloser, error)

How It Works

1. Receive Request: kubelet calls CRI API (e.g., RunPodSandbox)
2. Image Handling: Pull and extract OCI image if needed
3. Translation: Convert container config to Protect VM spec
4. Delegation: Call Protect to create Zone
5. Monitoring: Watch VM status and report back
6. Response: Return success/failure to kubelet

Integration with Kubernetes

┌─────────────────────────────────┐
│         Kubernetes              │
│      (kubelet component)        │
└────────────┬────────────────────┘
             │ CRI gRPC
             ▼
┌─────────────────────────────────┐
│         Styrolite               │
│                                 │
│  ┌──────────┐  ┌─────────────┐  │
│  │  Image   │  │     CRI     │  │
│  │  Manager │  │   Service   │  │
│  └──────────┘  └─────────────┘  │
└────────────┬────────────────────┘
             │ Protect API
             ▼
┌─────────────────────────────────┐
│            Protect              │
└─────────────────────────────────┘

Why It Matters

Styrolite makes Edera completely transparent to Kubernetes. Developers and operators don’t need to change anything—it just works.

OpenPaX: Kernel Hardening

Repository: github.com/edera-dev/openpax

OpenPaX is Edera’s kernel security patch set, providing additional hardening for guest kernels.

What OpenPaX Does

• Memory Protection: Additional ASLR, stack protection
• Exploit Mitigation: Prevent common exploit techniques
• Hardened Kernel: Reduce attack surface within guest VM
• Defense in Depth: Extra layer even if VM compromised

Security Features

Address Space Layout Randomization (ASLR):

• Randomize memory layouts
• Make exploits harder to develop
• Prevent return-oriented programming (ROP)

Stack Protections:

• Stack canaries
• Non-executable stack
• Stack clash prevention

Memory Restrictions:

• Restrict mprotect()
• Prevent writable+executable pages
• Limit kernel pointer leaks

Why It Matters

Even though Zones are isolated, defense in depth matters. OpenPaX makes it harder to exploit vulnerabilities within a Zone, adding another security layer.

am-i-isolated: Runtime Scanner

Repository: github.com/edera-dev/am-i-isolated

am-i-isolated is a utility that checks your runtime isolation from inside a container.

What am-i-isolated Does

• Detection: Identify what isolation you’re running in
• Verification: Confirm Edera isolation is active
• Reporting: Detailed isolation characteristics
• Testing: Validate security posture

Usage

Run it in any container:

kubectl run isolation-check --image=ghcr.io/edera-dev/am-i-isolated:latest --rm -it

Detection Methods

am-i-isolated checks for:

• Hypervisor presence (CPUID, /sys/hypervisor)
• Xen-specific files and interfaces
• Kernel command line parameters
• Paravirtualized device drivers
• Memory characteristics

Why It Matters

Visibility into isolation is crucial for compliance and verification. am-i-isolated provides proof that Edera isolation is working as expected.

Xen: The Hypervisor Foundation

Website: xenproject.org

While not developed by Edera, Xen is the foundation everything else builds on.

Xen Architecture

┌───────────────────────────────────────┐
│          Dom0 (Control Domain)        │
│   ┌───────────────────────────────┐   │
│   │ Protect + Styrolite           │   │
│   └───────────────────────────────┘   │
└─────────────┬─────────────────────────┘
              │
┌─────────────┴─────────────────────────┐
│         Xen Hypervisor                │
│  ┌─────────────────────────────────┐  │
│  │  Scheduler | Memory Manager     │  │
│  │  Event Channels | Grant Tables  │  │
│  │  IOMMU | Virtual CPUs           │  │
│  └─────────────────────────────────┘  │
└──────────────┬────────────────────────┘
               │
┌──────────────┴────────────────────────┐
│          DomU (Guest Domains)         │
│  ┌────────┐  ┌────────┐  ┌────────┐   │
│  │   Zone1│  │   Zone2│  │   Zone3│   │
│  └────────┘  └────────┘  └────────┘   │
└───────────────────────────────────────┘

Key Xen Concepts

Dom0 (Domain 0):

• Privileged control domain
• Runs Edera control plane
• Has hardware access
• Manages guest VMs

DomU (Domain Unprivileged):

• Guest domains (Zones)
• Your containers run here
• Isolated from each other
• Cannot access hardware directly

Paravirtualization:

• Guests use hypercalls instead of privileged instructions
• Higher performance than full virtualization
• Enables nested deployment (works in cloud VMs)

Xen Security Features

• Memory Isolation: Each DomU has separate memory pages
• CPU Scheduling: Fair scheduling with isolation
• IOMMU: Direct device assignment with DMA protection
• Event Channels: Secure inter-VM communication
• Grant Tables: Controlled memory sharing

How Components Work Together

Let’s trace a complete workflow:

Deploying a Pod

1. kubectl apply → Kubernetes API

2. Scheduler → Selects Edera node

3. kubelet → Calls Styrolite (CRI)
   "RunPodSandbox" + "CreateContainer"

4. Styrolite → Pulls OCI image
   Extracts layers to local storage

5. Styrolite → Translates to VM spec
   {vcpus: 2, memory: 4Gi, rootfs: ...}

6. Styrolite → Calls Protect API
   "CreateVM" with spec

7. Protect → Allocates resources
   CPU, memory, network, disk

8. Protect → Calls Xen (libxl)
   Creates DomU configuration

9. Xen → Boots Zone
   Loads kernel, starts init

10. Guest kernel → Starts container runtime
    Launches container process

11. Container → Application runs
    Isolated in Zone

12. Protect → Reports status to Styrolite

13. Styrolite → Reports to kubelet

14. kubelet → Updates Kubernetes API
    Pod status: Running

Total time: ~1-2 seconds

Networking Flow

Container → veth → Zone bridge → Dom0 → CNI plugin → Network

Each Zone has paravirtualized network devices that connect through Dom0 to the cluster network.

Storage Flow

Container → virtio-blk → Protect → Dom0 filesystem → Backing storage

Container filesystem is backed by disk images managed by Protect in Dom0.

Component Summary

All Edera-developed components are written in Rust (for memory safety).

Next: Zones and Resource Management →