Xen & Jailhouse
TEKNİK REHBER GÖMÜLÜ LİNUX XEN ARM 2026

Xen ARM
dom0/domU & xl Toolchain

Xen ARM mimarisi, Yocto meta-virtualization ile kurulum, xl toolchain, domU konfigürasyonu, dom0-less boot, device passthrough ve FLASK/XSM güvenlik modeli.

00 Xen ARM mimarisi

Xen, dünya üzerindeki en yaygın kullanılan açık kaynak Type-1 hypervisor'larından biridir. ARM desteği ARMv7-A (32-bit) ve ARMv8-A/v9-A (64-bit) mimarilerini kapsar.

Xen katman modeli

┌─────────────────────────────────────────────────────────┐
│                    Dom0 (Privileged Guest)               │
│  Linux kernel + xen-blkback/netback + xl toolstack      │
├──────────────┬──────────────────┬───────────────────────┤
│  domU-1      │   domU-2         │   domU-N              │
│  (Linux IVI) │   (RTOS)         │   (Android)           │
├──────────────┴──────────────────┴───────────────────────┤
│              Xen Hypervisor (EL2)                       │
├─────────────────────────────────────────────────────────┤
│              ARM SoC Hardware                           │
└─────────────────────────────────────────────────────────┘
    

Temel bileşenler

Xen HypervisorEL2'de çalışan ~300KB firmware; tüm guest'lerin üzerindeki katman
Dom0Ayrıcalıklı domain — donanım sürücülerine erişir, diğer domain'leri yönetir
DomUUnprivileged guest domain — sanal I/O aracılığıyla donanıma erişir
xl toolstackDom0 üzerinde çalışan hypervisor yönetim aracı
Toolstackxl → libxl → libxenctrl → hypercall → Xen hypervisor

Boot sırası

ARM Xen boot sırası U-Boot tarafından organize edilir. Xen hypervisor önce yüklenir, ardından dom0 guest olarak başlatılır.

U-Boot — Xen ARM boot komutu
# U-Boot bootscript: Xen + dom0 + FDT yükle
# Xen hypervisor image
fatload mmc 0:1 0x80200000 xen

# Dom0 Linux kernel
fatload mmc 0:1 0x80400000 Image

# Dom0 initramfs
fatload mmc 0:1 0x85000000 dom0-initramfs.cpio.gz

# Xen için DTB (Xen kendi DTB'sini oluşturur)
fatload mmc 0:1 0x83000000 imx8mp-evk-xen.dtb

# Xen'in yükleneceği adres, dom0 bilgileri DTB içinde
fdt addr 0x83000000
fdt resize 4096

# dom0 çekirdeğini ve ramdisk'i DTB'ye ekle
fdt set /chosen \#address-cells <1>
fdt set /chosen xen,xen-bootargs "console=dtuart dtuart=serial0 dom0_mem=512M"
fdt set /chosen xen,dom0-bootargs "console=hvc0 earlycon=xen earlyprintk=xen"
fdt mknod /chosen dom0
fdt set /chosen/dom0 compatible "xen,linux-zimage" "xen,multiboot-module"
fdt set /chosen/dom0 reg <0x80400000 0x2000000>

# Boot
booti 0x80200000 - 0x83000000

Bu bölümde

  • Dom0: ayrıcalıklı guest — sürücü erişimi + xl toolstack
  • DomU: normal guest — sanal I/O, dom0 backend'e bağımlı
  • U-Boot boot sırası: Xen → DTB → dom0 kernel/initrd
  • EL2'de çalışan Xen ~300KB — minimal footprint

01 Kurulum — Yocto meta-virtualization

Xen ARM için Yocto Project'in meta-virtualization katmanı standart çözümdür. Bu katman Xen hypervisor recipe'si, xl toolstack ve guest yönetim araçlarını içerir.

meta-virtualization kurulumu

bash — Yocto Xen layer kurulumu
# Poky dizinine git
cd ~/yocto/poky

# meta-virtualization klonla
git clone https://git.yoctoproject.org/meta-virtualization \
    ../meta-virtualization -b scarthgap

# meta-openembedded gereksinimi
git clone https://git.openembedded.org/meta-openembedded \
    ../meta-openembedded -b scarthgap

# Build ortamını başlat
source oe-init-build-env build-xen

# Layer'ları ekle
bitbake-layers add-layer ../meta-openembedded/meta-oe
bitbake-layers add-layer ../meta-openembedded/meta-python
bitbake-layers add-layer ../meta-openembedded/meta-networking
bitbake-layers add-layer ../meta-virtualization

local.conf Xen ayarları

conf/local.conf — Xen konfigürasyonu
# Hedef makine (i.MX8M Plus EVK örneği)
MACHINE = "imx8mp-lpddr4-evk"

# Xen'i image'a dahil et
DISTRO_FEATURES:append = " xen virtualization"

# Kernel Xen desteğini aktifleştir
KERNEL_FEATURES:append = " features/xen/xen.scc"

# Dom0 için minimum bellek
XEN_DOM0_MEM = "512M"

# Xen sürümü
PREFERRED_VERSION_xen = "4.17%"

# xl toolstack için paketler
IMAGE_INSTALL:append = " xen xen-xl xen-tools"
IMAGE_INSTALL:append = " bridge-utils iptables"

Cross-compile ile manuel build

bash — Xen cross-compile (ARM64)
# Cross-compiler hazırla
export CROSS_COMPILE=aarch64-linux-gnu-
export ARCH=arm64

# Xen kaynak kodu indir
git clone https://xenbits.xen.org/git-http/xen.git
cd xen
git checkout RELEASE-4.17.0

# Xen konfigürasyonu (ARM64)
make -C xen defconfig XEN_TARGET_ARCH=arm64

# Build
make -j$(nproc) XEN_TARGET_ARCH=arm64 \
     CROSS_COMPILE=aarch64-linux-gnu-

# Çıktı: xen/xen — EFI veya flat binary
ls -la xen/xen
# -rwxr-xr-x 1 user user 387256 ... xen/xen

# Dom0 kernel için Xen konfigürasyonu
make ARCH=arm64 xen_guest_defconfig
grep XEN .config
# CONFIG_XEN=y
# CONFIG_XEN_BLKDEV_FRONTEND=y
# CONFIG_XEN_NETDEV_FRONTEND=y

Bu bölümde

  • meta-virtualization: Yocto için Xen recipe'leri — scarthgap branch
  • DISTRO_FEATURES += "xen virtualization" — temel aktivasyon
  • Cross-compile: XEN_TARGET_ARCH=arm64 — i.MX8 için aarch64
  • Dom0 kernel: CONFIG_XEN=y, blkdev/netdev frontend

02 xl toolchain komutları

xl (Xen Light), Xen hypervisor'ı yönetmek için kullanılan komut satırı aracıdır. Dom0 üzerinde çalışır ve domain yaşam döngüsünü, ağ/disk yapılandırmasını yönetir.

Temel xl komutları

bash — xl komut referansı
# Çalışan domain'leri listele
xl list
# Name                  ID  Mem  VCPUs  State  Time(s)
# Domain-0               0  512     2   r----  120.4
# linux-domu             1  256     1   -b---   45.2

# Domain oluştur (cfg dosyasından)
xl create /etc/xen/linux-domu.cfg
# Parsing config from /etc/xen/linux-domu.cfg

# Domain oluştur ve console'a bağlan
xl create /etc/xen/linux-domu.cfg -c

# Domain konsol bağlantısı (Ctrl+] ile çıkış)
xl console linux-domu

# Domain kapat (soft shutdown)
xl shutdown linux-domu

# Domain zorla durdur
xl destroy linux-domu

# Domain duraklat
xl pause linux-domu

# Domain devam ettir
xl unpause linux-domu

# Domain'in kaynak kullanımını izle
xl top

# Domain bilgisi
xl domid linux-domu    # ID öğren
xl domname 1           # ID → isim

# Xen log
xl dmesg

# Hypervisor bilgisi
xl info
# host               : imx8mp-evk
# release            : 4.17.0
# total_memory       : 4096
# free_memory        : 3200

xl vcpu ve bellek yönetimi

bash — vCPU ve bellek işlemleri
# vCPU listesi
xl vcpu-list linux-domu
# Name     ID  VCPU CPU   State   Time(s)  Affinity (Hard)
# linux-domu 1   0   2   -b---   22.1    0-3

# vCPU pinning — belirli fiziksel CPU'ya bağla
xl vcpu-pin linux-domu 0 2
# vCPU 0 → fiziksel CPU 2'ye pinlendi

# Bellek ekleme/çıkarma (balloon sürücüsü gerekli)
xl mem-set linux-domu 384  # 384 MB'a çıkar
xl mem-max linux-domu 512  # maksimum 512 MB

# CPU scheduler bilgisi
xl sched-credit         # Credit scheduler parametreleri
xl sched-credit2        # Credit2 scheduler
xl sched-rtds           # RTDS (real-time) scheduler

# RTDS scheduler — real-time domU için
xl sched-rtds -d linux-domu -p 100000 -b 20000
# period=100ms, budget=20ms (20% CPU garantisi)

Bu bölümde

  • xl list/create/destroy/console — temel domain yaşam döngüsü
  • xl vcpu-pin: vCPU → fiziksel CPU pinleme — deterministik scheduling
  • xl sched-rtds: real-time scheduler — period + budget ile CPU garantisi
  • xl dmesg: Xen hypervisor log — debug için kritik

03 domU konfigürasyonu — xl.cfg

Her domU, bir xl.cfg konfigürasyon dosyasıyla tanımlanır. Bu dosya domU'nun bellek, CPU, disk, ağ ve kernel parametrelerini belirler.

Tam xl.cfg örneği — Linux domU

/etc/xen/linux-domu.cfg — tam örnek
# Domain adı
name = "linux-domu"

# Bellek (MB)
memory = 256
maxmem = 512      # balloon ile bu değere kadar artabilir

# vCPU sayısı
vcpus = 2
maxvcpus = 4

# vCPU affinity (fiziksel CPU 2-3'e pin)
cpus = "2-3"

# Kernel ve initrd (dom0 filesystem'inden)
kernel = "/boot/Image"
ramdisk = "/boot/initramfs.cpio.gz"

# Kernel komut satırı
cmdline = "console=hvc0 earlyprintk=xen loglevel=8 root=/dev/xvda rw"

# Disk — blktap2 veya loopback
disk = [
    "format=raw, vdev=xvda, access=rw, target=/var/lib/xen/images/domu.img",
    "format=raw, vdev=xvdb, access=ro, target=/var/lib/xen/data.img"
]

# Ağ arayüzü
vif = [
    "type=netfront, bridge=xenbr0, mac=00:16:3e:00:00:01",
    "type=netfront, bridge=xenbr1, mac=00:16:3e:00:00:02"
]

# Sanal USB (isteğe bağlı)
# usbctrl = ["type=qusb, version=2"]

# GIC versiyonu (ARM)
gic_version = "v3"

# IOMMU passthrough yok (varsayılan)
# passthrough = "no"

# Otomatik yeniden başlatma
on_poweroff = "destroy"
on_reboot = "restart"
on_crash = "restart"

# UUID (isteğe bağlı)
# uuid = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

Disk image oluşturma

bash — domU disk image hazırlama
# Boş disk image oluştur (2GB)
dd if=/dev/zero of=/var/lib/xen/images/domu.img bs=1M count=2048

# Dosya sistemi formatla
mkfs.ext4 /var/lib/xen/images/domu.img

# Image'ı mount et ve root filesystem doldur
mkdir -p /mnt/domu
mount -o loop /var/lib/xen/images/domu.img /mnt/domu

# Minimal rootfs kopyala (Yocto output'undan)
tar -xf core-image-minimal-imx8mp.tar.gz -C /mnt/domu
umount /mnt/domu

Network bridge kurulumu

bash — xenbr0 bridge kurulumu
# Bridge oluştur
brctl addbr xenbr0
ip link set xenbr0 up

# Fiziksel arayüzü bridge'e ekle
brctl addif xenbr0 eth0
ip link set eth0 up

# IP adresi bridge'e ver
ip addr add 192.168.1.100/24 dev xenbr0

# Kalıcı /etc/network/interfaces
# auto xenbr0
# iface xenbr0 inet static
#   address 192.168.1.100
#   bridge_ports eth0

Bu bölümde

  • xl.cfg: memory/vcpus/kernel/disk/vif — domU tanım dosyası
  • cpus: fiziksel CPU affinity — "2-3" ile CPU pinleme
  • disk: raw/qcow2 format, blktap2 veya loopback
  • vif + xenbr0 bridge: domU ağ erişimi

04 PV vs HVM — ARM'da fark

Xen'de ARM için iki temel guest türü vardır: PV (Paravirtualized) ve HVM (Hardware Virtual Machine). ARM'da full PV desteği kısıtlıdır; çoğu durumda PVH veya HVM tercih edilir.

ARM'da guest türleri

TürARM DesteğiStage-2 MMUI/OÖnerilen
PVSınırlı (x86 odaklı)Yok (MMU shared)HypercallHayır (ARM)
HVMTam — hardware-assistedVarEmülasyon veya virtioEvet
PVHTam — ARM64 defaultVarPV sürücülerEvet (önerilen)

ARM domU türü belirleme

xl.cfg — guest türü seçimi
# ARM64'te PVH (varsayılan)
# ARM'da type belirtilmesi çoğunlukla otomatiktir
# Xen 4.17+ ile ARM64 PVH default

# Kernel komut satırında earlyprintk Xen üzerinden
cmdline = "console=hvc0 earlyprintk=xen"

# PV sürücüler guest kernelde etkin olmalı
# CONFIG_XEN_BLKDEV_FRONTEND=y
# CONFIG_XEN_NETDEV_FRONTEND=y
# CONFIG_HVC_XEN=y  (Xen virtual console)
# CONFIG_HVC_XEN_FRONTEND=y

xen-blkfront ve xen-netfront

bash — PV sürücü doğrulama (domU içinde)
# Dom U üzerinde PV sürücüleri kontrol et
cat /sys/hypervisor/type
# xen

cat /sys/hypervisor/version/major
# 4

# Xenbus cihazları
ls /sys/bus/xen/devices/
# vbd-51712   vif-0

# Disk sürücüsü
lsblk
# xvda     202:0    0   2G  0 disk
# └─xvda1  202:1    0   2G  0 part /

# Ağ arayüzü
ip link show
# 2: eth0: ... xen_netfront

Bu bölümde

  • ARM64 Xen: PVH default — Stage-2 MMU + PV sürücüler
  • HVM: emülasyon + virtio I/O — değiştirilmemiş guest kernel
  • xen-blkfront/netfront: PV I/O — yüksek throughput
  • hvc0 console: Xen sanal seri port — debug için

05 dom0-less boot

Xen dom0-less boot, dom0 Linux başlatılmadan doğrudan domU'ların çalıştırılmasına izin verir. Bu özellik özellikle güvenlik açısından kritik: dom0 saldırı yüzeyi tamamen ortadan kalkar.

dom0-less kavramı

Geleneksel Xen modelinde dom0 hem donanım sürücülerine erişim sağlar hem de domU'ları yönetir. dom0-less modelde bu görev U-Boot veya başka bir bootloader tarafından üstlenilir. domU'lar doğrudan Xen tarafından başlatılır.

Geleneksel:   U-Boot → Xen → dom0 (Linux) → domU-1, domU-2
dom0-less:    U-Boot → Xen → domU-1 (Linux), domU-2 (RTOS)
    

Device Tree ile dom0-less konfigürasyonu

DTS — dom0-less Xen konfigürasyonu
/ {
    chosen {
        xen,xen-bootargs = "console=dtuart dtuart=serial0 dom0_mem=0 bootscrub=0";

        /* domU-1: Linux */
        domU1 {
            compatible = "xen,domain";
            #address-cells = <1>;
            #size-cells = <1>;
            memory = <0x1 0x00000000>;    /* 256MB (lo+hi) */
            cpus = <1>;
            vpl011;  /* virtual PL011 UART */

            module@1 {
                compatible = "multiboot,kernel", "multiboot,module";
                reg = <0x47000000 0x1000000>;
                bootargs = "console=ttyAMA0 root=/dev/ram0";
            };

            module@2 {
                compatible = "multiboot,ramdisk", "multiboot,module";
                reg = <0x48000000 0x2000000>;
            };
        };

        /* domU-2: bare-metal RTOS */
        domU2 {
            compatible = "xen,domain";
            memory = <0x0 0x10000000>;    /* 256MB */
            cpus = <1>;
            direct-map;  /* 1:1 bellek haritası */

            module@1 {
                compatible = "multiboot,kernel", "multiboot,module";
                reg = <0x50000000 0x200000>;
            };
        };
    };
};

dom0-less avantaj ve kısıtlar

Avantaj: GüvenlikDom0 yok → dom0 exploit edilemez → tüm sistemi kontrol eden bir kompromi noktası yok
Avantaj: HızDom0 başlatma süresi yok — domU'lar boot'tan hemen sonra çalışır
Kısıt: Yönetimxl toolstack yok — runtime domain yönetimi mümkün değil, bootloader ile statik
Kısıt: I/ODom0 backend yok — device passthrough veya ayrı driver domain gerekli

Bu bölümde

  • dom0-less: dom0 olmadan doğrudan domU boot — güvenlik artışı
  • Device Tree ile domU tanımı — bootloader tarafından yüklenir
  • vpl011: sanal UART — domU debug konsolu
  • Kısıt: xl toolstack yok — statik konfigürasyon zorunlu

06 Device passthrough — IOMMU

Device passthrough, fiziksel bir donanım aygıtını doğrudan bir domU'ya atama işlemidir. SMMU/IOMMU desteği bu özellik için zorunludur.

Passthrough konfigürasyonu

xl.cfg — device passthrough
# Tüm IOMMU grubunu domU'ya ata
passthrough = "full"

# IOMMU grubu — /sys/kernel/iommu_groups/
# PCI device passthrough
pci = [
    "0000:01:00.0,seize=1",    # PCIe NIC
    "0000:01:00.1,seize=1"     # aynı IOMMU grubundaki ikinci fonksiyon
]

# ARM platform device passthrough (non-PCI)
dtdev = ["/soc/serial@30880000"]  # UART3 passthrough
irqs = [53, 54]                   # ilgili IRQ'lar
iomem = ["0x30880,1"]             # MMIO bölgesi (0x30880000, 1 page)

IOMMU grup doğrulama

bash — IOMMU grup ve passthrough kontrolü
# Xen IOMMU etkinliğini kontrol et
xl info | grep iommu
# iommu                 : 1

# Cihaz sürücüsünü ayır (unbind)
echo 0000:01:00.0 > /sys/bus/pci/drivers/e1000e/unbind

# Cihazı Xen pciback sürücüsüne bağla
echo 0000:01:00.0 > /sys/bus/pci/drivers/pciback/new_id

# Alternatif: VFIO ile
modprobe vfio-pci
echo "8086 1234" > /sys/bus/pci/drivers/vfio-pci/new_id

# Xen'de cihaz durumu
xl pci-list-assignable-devices
# 0000:01:00.0

# Çalışan domain'e PCI cihaz ekle (hot-plug)
xl pci-attach linux-domu 0000:01:00.0

ARM platform device passthrough

ARM SoC'larda çoğu peripheral PCI bus'ta değil, platform bus'ta bulunur. Bu cihazlar için DTDEV mekanizması kullanılır. Device tree node yolu ve ilgili MMIO + IRQ atanır.

bash — ARM platform device passthrough kontrolü
# SMMU stream tablosunu kontrol et
dmesg | grep -i "smmu\|iommu" | head -20
# [  0.456789] arm-smmu-v3 9050000.smmu: probing...
# [  0.456800] arm-smmu-v3 9050000.smmu: SMMUv3 features: 0x00000e73

# Xen dmesg'de IOMMU hata var mı?
xl dmesg | grep -i "iommu\|smmu"
# (XEN) ARM: IOMMU: 9050000 initialized

Bu bölümde

  • passthrough="full": tüm IOMMU grubu domU'ya — PCI cihazlar için
  • dtdev/irqs/iomem: ARM platform device passthrough — non-PCI
  • pciback vs vfio-pci: sürücü ayırma yöntemleri
  • SMMU zorunlu: passthrough için donanım IOMMU şart

07 virtio-net ve virtio-blk

Virtio, Xen ve KVM gibi hypervisor'larda kullanılan standart paravirtualized I/O framework'üdür. Dom0 backend + domU frontend çiftiyle çalışır.

Xen virtio mimarisi

DomU (guest):
  virtio-net frontend sürücüsü
       ↓ (xenbus üzerinden)
Dom0 (host):
  xen-netback kernel modülü
       ↓
  xenbr0 bridge → fiziksel NIC
    

virtio-net kurulumu

bash — virtio-net backend (dom0)
# Dom0'da backend modülleri
modprobe xen-netback
modprobe xen-blkback

# DomU oluşturulduktan sonra vif kontrol
ip link show
# vif1.0: ... xen_netback
# Bu arayüz dom0 tarafında domU'nun NIC backend'ini temsil eder

# DomU network performans testi
# Dom0'da iperf server
iperf3 -s

# DomU'da iperf client
iperf3 -c 192.168.1.100 -t 10
# [  5]   0.00-10.00  sec  8.50 GBytes  7.30 Gbits/sec

virtio-blk disk performansı

bash — virtio disk I/O testi
# Dom0'da blktap2 veya xen-blkback
modprobe xen-blkback

# DomU içinde disk I/O testi
dd if=/dev/xvda of=/dev/null bs=1M count=512 iflag=direct
# 512+0 records out
# 536870912 bytes (537 MB) copied, 0.456 s, 1.2 GB/s

# fio ile daha kapsamlı test
fio --name=seq-read --rw=read --bs=1M \
    --filename=/dev/xvda --direct=1 --runtime=30
# READ: bw=1200MiB/s (1258MB/s)

Grant table mekanizması

Xen PV I/O transferlerinde grant table mekanizması kullanılır. DomU, bellek sayfalarını dom0'a "grant" eder; dom0 backend bu sayfaları doğrudan okur/yazar. Bu yaklaşım kopyasız (zero-copy) I/O sağlar.

Bu bölümde

  • xen-netback/blkback: dom0 backend modülleri
  • xen-netfront/blkfront: domU frontend sürücüleri
  • Grant table: zero-copy I/O için bellek paylaşımı
  • Performans: virtio-net ~7Gbps, virtio-blk ~1.2GB/s (i.MX8)

08 FLASK/XSM güvenlik modeli

Xen Security Modules (XSM), Xen hypervisor için MAC (Mandatory Access Control) politikası uygulama çerçevesidir. FLASK (Flux Advanced Security Kernel) bu çerçevenin default implementasyonudur.

XSM/FLASK mimarisi

XSM FrameworkXen içindeki hook altyapısı — her hypercall ve kaynak erişiminde politika kontrol edilir
FLASK ModuleSELinux benzeri Type Enforcement — subject/object/permission modeli
Policy DatabaseBinary politika dosyası — domain türleri, izinler ve geçişler tanımlanır
Security LabelsHer domain bir güvenlik etiketiyle (SID) ilişkilendirilir

FLASK politika örneği

policy/flask/policy.te — XSM politikası
# Dom türlerini tanımla
type dom0_t;
type domu_t;
type rtos_t;

# Dom0 her şeye erişebilir (privileged)
allow dom0_t domain_t : domain { create destroy pause unpause };
allow dom0_t domain_t : grant { map_read map_write };

# DomU yalnızca kendi operasyonlarına
allow domu_t domu_t : domain { pause unpause };
allow domu_t xen_t : xen { hypercall console_io };

# RTOS domU: iletişim yasak (izolasyon)
# rtos_t → domu_t : grant { } — izin yok = denied

# Event channel — sadece belirli domU çiftleri
allow domu_t domu_t : event { send };
allow rtos_t dom0_t : event { send };  # sadece dom0'a

FLASK etkinleştirme ve pratik

bash — FLASK kurulumu ve test (i.MX8)
# Xen bootargs: FLASK enforcing modda başlat
# /boot/extlinux.conf:
# APPEND xen.gz flask=enforcing flask_bootparam_override=1

# FLASK durumu kontrol
xenctl -e flask getenforce
# Enforcing

# Politika yükle
flask-loadpolicy /etc/xen/flask.policy

# Domain güvenlik label sorgula
xl getenforce 1
# Enforcing

# Domaine özel label (xl.cfg)
# seclabel = "system_u:system_r:domu_t"

# XSM ihlallerini izle
xl dmesg | grep "Flask"
# (XEN) Flask: avc:  denied  { map_read } for domid=2 target=0

Pratik: i.MX8 üzerinde Xen + Linux dom0 + minimal Linux domU

bash — i.MX8 tam Xen test prosedürü
# 1. Boot ve dom0 doğrulama
xl info | grep -E "host|total_memory|free_memory"
# host               : imx8mp-evk
# total_memory       : 4096
# free_memory        : 3456

# 2. Minimal Linux domU başlat
cat > /etc/xen/minimal-domu.cfg << 'EOF'
name = "minimal-linux"
memory = 256
vcpus = 1
kernel = "/boot/Image"
cmdline = "console=hvc0 init=/bin/sh"
disk = ["format=raw,vdev=xvda,access=rw,target=/var/lib/xen/minimal.img"]
vif = ["bridge=xenbr0"]
EOF

xl create /etc/xen/minimal-domu.cfg -c
# Parsing config from /etc/xen/minimal-domu.cfg
# (domU kernel başlıyor)
# / #  ← minimal shell

# 3. Dom0'dan doğrulama (başka terminalde)
xl list
# Name          ID  Mem  VCPUs  State   Time(s)
# Domain-0       0  512     2   r----   245.6
# minimal-linux  1  256     1   -b---    12.3

# 4. Dom0-domU ping testi
# DomU'da:
ip addr add 192.168.1.200/24 dev eth0
ip link set eth0 up
# Dom0'da:
ping -c 3 192.168.1.200
# 64 bytes from 192.168.1.200: icmp_seq=1 ttl=64 time=0.456 ms

Bu bölümde

  • XSM/FLASK: Xen için MAC politikası — SELinux benzeri Type Enforcement
  • FLASK enforcing: tüm domain operasyonları politikaya tabi
  • seclabel xl.cfg: her domain'e güvenlik etiketi atama
  • i.MX8 pratik: xl create + console + ping — end-to-end test