feat: add host-backed entropy device support and update kernel configuration

USAGE.md

@@ -169,7 +169,7 @@ UVM detects the host architecture and selects matching Firecracker and kernel
 downloads and native Ubuntu packages. NVIDIA DGX Spark uses `aarch64` artifacts
 and `arm64` packages; the `arm64` architecture alias is also accepted:
 
-- Kernel: `https://s3.amazonaws.com/spec.ccfc.min/img/quickstart_guide/aarch64/kernels/vmlinux.bin`
+- Kernel: `https://s3.amazonaws.com/spec.ccfc.min/firecracker-ci/v1.15/aarch64/vmlinux-6.1.155`
 - Rootfs: Ubuntu 22.04 built with `debootstrap` from `ports.ubuntu.com/ubuntu-ports`.
 
 Use the installation commands below with checksums for the ARM64 kernel
@@ -180,6 +180,12 @@ On ARM64, the kernel must be an uncompressed ARM64 Linux `Image` (PE format),
 and the rootfs must be an ARM64 ext4 filesystem. UVM adds `keep_bootcon` to the
 guest boot arguments for ARM64 console output.
 
+Both architectures default to the pinned Linux 6.1.155 kernel from the published
+`v1.15` CI artifact series, independently of the Firecracker binary version.
+These kernels have `CONFIG_HW_RANDOM=y` and `CONFIG_HW_RANDOM_VIRTIO=y` built in.
+UVM configures Firecracker's entropy device before boot; custom kernels also
+need these drivers to receive host-backed randomness.
+
 ### Scenario: Strict First Installation
 
 Obtain trusted checksums independently, then run:
@@ -1222,6 +1228,58 @@ External firewall integration (including UFW, firewalld, Docker, and libvirt)
 is deferred. A UVM policy readback does not prove that external rules permit
 traffic, or that they will not later remove UVM's rules.
 
+### SSH Startup and Guest Entropy
+
+`running` checks the Firecracker process, and `enforced` checks the private
+firewall policy. Neither probes the guest's SSH listener. If ping works but
+TCP/22 returns `Connection refused`, inspect the guest boot log:
+
+```sh
+sudo ./uvm.py logs VM --tail 200
+sudo ./uvm.py inspect VM --json
+```
+
+An SSH service stuck at `Starting OpenBSD Secure Shell server...`, together
+with an unfinished `Load/Save Random Seed` service and no `random: crng init done`,
+strongly suggests entropy starvation. A login prompt can still appear while
+SSH is waiting for its cryptographic random generator. On the old ARM demo
+kernel, `random: fast init done` is not full cryptographic RNG initialization.
+
+Earlier UVM versions downloaded a Linux 4.14.174 ARM quickstart kernel without
+the built-in virtio RNG driver and did not attach an entropy device. Recovery
+requires **both** the updated UVM boot code and an RNG-capable kernel. A restart
+with the old cached kernel is insufficient.
+
+From the updated checkout, stop the affected VM before refreshing assets.
+Stop any other VMs using the same installed Firecracker binary before the
+forced reinstall as well. Use the Firecracker archive checksum for the configured
+release and a new trusted checksum for the selected architecture's Linux 6.1.155
+kernel; the old kernel checksum will not match:
+
+```sh
+sudo ./uvm.py stop VM
+sudo env -u UVM_KERNEL_URL \
+  UVM_FIRECRACKER_SHA256='<trusted-firecracker-archive-sha256>' \
+  UVM_KERNEL_SHA256='<trusted-new-kernel-sha256>' \
+  ./uvm.py install --force
+sudo ./uvm.py start VM
+sudo ./uvm.py logs VM --tail 100
+sudo ./uvm.py ssh VM
+```
+
+This uses the default kernel URL and boots the retained private disk with the
+updated device configuration. The VM's identity, files, credentials, and SSH
+host keys are retained. `install --force` also refreshes the shared rootfs
+template for future creates. If using a custom kernel, supply its URL and
+matching checksum with the required drivers instead. For an explicitly
+unverified development installation, retain the existing
+`UVM_ALLOW_UNVERIFIED_DOWNLOADS=1` setting as described in the installation section.
+
+Restart a running UVM API server to load the updated code before using dashboard
+start/restart actions. Look for `Started OpenBSD Secure Shell server` in the new
+boot log and confirm an actual SSH connection. `start` on an already-running
+VM only refreshes networking; use a stopped VM or `restart` to attach the device.
+
 ## 16. Important Limitations
 
 Keep these constraints in mind when deciding whether UVM fits a scenario: