Hairizuan Noorazman
Life is too exciting to just keep still!
Practical implementation notes, experiments, and lessons learned from building and operating software.
Recent
Capturing OAuth Flows Inside an Electron App
CLI tools like gh auth login, gcloud auth login, and aws sso login all share a pattern: they print a URL or open the system browser for OAuth authentication, wait for the callback, and then continue in the terminal. When running these commands inside Worklayer’s terminal panels, the browser opens externally and the user has to leave the app to complete the flow.
Modern Filesystems: Journaling vs Copy-on-Write, the Kernel Write Path, and Data Correctness
··3861 words·19 mins
When engineers discuss storage and file systems, the conversation often starts and stops with the classics: ext4 on Linux, NTFS on Windows, and perhaps XFS for large database servers. For decades, the dominant answer to filesystem reliability was straightforward: journaling.
Making This Blog Available Offline for In-Flight Reading
··2316 words·11 mins
Whenever I board a flight, one of the first things I do after reaching cruising altitude is open my laptop or tablet to read through saved technical articles, documentation, or past notes. In-flight Wi-Fi is either non-existent, prohibitively expensive, or throttled to the point where simple page requests time out.
How Hypervisors Isolate Virtual Machine Memory
··3255 words·16 mins
While investigating the isolation boundary of Multikernel Linux containers, I kept returning to one comparison: why can a compromised virtual-machine guest kernel not simply map the host’s memory, while a compromised Multikernel child kernel can attempt to map memory outside its allocation?
Introducing CNI to a Multikernel Linux Runtime
··4137 words·20 mins
My first Multikernel container networking experiment built a static /30 link for each child. The primary owned a TUN interface, routes, NAT, and firewall rules; mk-agent owned another TUN inside the child; and an authenticated packet pump transported IP frames between them.
The Isolation Boundary of Multikernel Linux Containers
··2348 words·12 mins
The phrase “one kernel per container” sounds like a stronger isolation claim than “one process namespace per container.” In a Multikernel Linux runtime, each child really does have its own kernel, process table, boot ID, CPUs, memory description, and root filesystem. That still does not make it equivalent to a virtual machine.
Designing a Runtime Protocol Across Multikernel Linux Kernels
··1955 words·10 mins
The components in my Multikernel container runtime do not share one ordinary process hierarchy. The containerd shim and mkruntimed run in the primary Linux system, while mk-agent and the workload run under a child kernel. Calls that would normally be local runtime operations therefore become protocol messages.
Running OCI Processes Inside a Multikernel Linux Child
··1541 words·8 mins
In Turning Container Images into Multikernel Linux Roots, I described how an unpacked image becomes a private root for a child kernel. That gets the files into the right place, but files are not yet a running container. Something inside the child still has to interpret the OCI process configuration, establish its safety boundaries, start the executable, and translate later exec, signal, terminal, and wait requests.
Recovering Multikernel Runtime State After a Crash
··1357 words·7 mins
My earlier walkthrough of a Multikernel container from the primary Linux system followed a successful task from containerd through a shim, mkruntimed, Kerf, and finally a child kernel. The normal path is only half of a runtime, though. The harder question is what to do when one of those steps succeeds but the caller disappears before learning the result.
Anatomy of a Multikernel Container from the Primary Linux Host
··3145 words·15 mins
My earlier posts looked at individual parts of the Multikernel container path: building image-derived roots, providing mediated networking, and implementing a containerd Runtime v2 shim. This post puts those pieces together from one particular viewpoint: what happens on the primary Linux system when containerd creates a container whose process will run under another kernel?