Thomas Barabosch

Running NetBSD OCI images with Apple Container

Thomas Barabosch — Thu, 03 Sep 2026 19:30:00 +0000

Finally, the public ghcr.io/tbarabosch/netbsd:11 image I built runs with Apple’s container tool on Apple silicon. The container-runtime-netbsd proof of concept pulls the netbsd/arm64 image, turns its OCI layers into a bootable FFS disk, starts NetBSD 11 with Virtualization.framework and runs the requested program through a small guest agent.

The current CLI only prints the final command output. I added the four status lines to make its otherwise silent work visible.

ghcr.io/tbarabosch/netbsd:11
              |
 OCI layers -> GPT / EFI / FFS
              |
     Apple VZ -> NetBSD 11
              |
     NVZA agent -> execve(2)

This is not NetBSD support in an unmodified Apple Container release. I had to use OpenAI’s Codex to patch Apple Container 1.3.0 and use the NetBSD platform kit from the earlier experiments. With those two pieces installed, container netbsd run behaves like a real container command: it fetches the image, boots the guest, connects the process streams and returns its exit status.

Reusing the earlier NetBSD VM

Apple Container already puts every Linux container in its own lightweight virtual machine. In Detecting Apple Container from inside the guest, I followed a request from the container CLI through container-apiserver, the Linux runtime plugin and Virtualization.framework to vminitd inside the guest. Each container gets its own VM instead of sharing one Linux kernel with the other containers.

In Porting NetBSD to Apple VZ, I replaced that Linux guest with NetBSD 11. The patched kernel booted on the virtual ARM machine, used its Virtio console, block, entropy and network devices, mounted an FFS root filesystem and shut down cleanly. However, a purpose-built Swift program still had to start a prepared kernel and disk. It was a NetBSD VM, not a container runtime.

Moving NetBSD on Apple VZ from direct boot to EFI removed another custom part. Virtualization.framework’s generic EFI firmware starts NetBSD’s unmodified bootaa64.efi, the loader starts a GENERIC64 kernel and ACPI describes the hardware. Only the three generic Virtio patches remained in the platform kit.

That left the OCI image. As described in OCI fundamentals: images, layers and registries, an OCI image normally contains a userspace filesystem and process configuration, not a kernel. The GHCR image therefore provides NetBSD userspace. The runtime adds the kernel, EFI loader, disk format and process-control agent.

What I had to patch

Apple Container supports CLI and runtime plugins. I use both. The CLI plugin adds container netbsd; the runtime plugin starts and controls one NetBSD VM. The netbsd CLI plugin asks Apple’s image service for the netbsd/arm64 manifest, assembles a RAW disk and creates a container handled by container-runtime-netbsd. It passes the disk path to the runtime as opaque data. CPU and memory still use the normal container resource settings.

There was one problem: container-apiserver assumed that every runtime needed the Linux kernel, initial filesystem and image-root snapshot prepared by Apple Container. The NetBSD runtime cannot use any of them. Its EFI disk already contains the loader, kernel and root filesystem.

The included Apple Container compatibility patch adds one explicit service capability:

[[servicesConfig.services]]
type = "runtime"
capabilities = ["runtime-owned-resources"]

When a runtime declares this capability, container-apiserver requires runtimeData and skips the Linux kernel, initial filesystem and root snapshot. Nothing changes for runtimes without the capability, and the Linux runtime still rejects a request without its Linux resources.

NetBSD still needs two corrections for the devices used by the runtime. PCI memory decoding must be enabled for modern Virtio BARs, and a Virtio 1.0 reset must wait until the device reports status zero. The earlier MTU negotiation patch is also present in the kernel, although the runtime currently does not attach a network device. None of the NetBSD changes names Apple or adds a VZ-specific platform. Neither patch set is upstream, so the stock releases of NetBSD 11 and Apple Container 1.3.0 cannot run this setup on their own.

Turn OCI layers into a bootable FFS disk

The public image contains NetBSD userspace, but no kernel, EFI loader or guest agent. The CLI checks that the image declares netbsd/arm64 and a NetBSD 11 release. It then reads each layer from Apple’s local content store and passes it to the OCI layer applier.

Layers may be plain tar archives or use gzip or zstd compression. They are applied in manifest order, including ordinary and opaque whiteouts, hardlinks, symbolic links and file modes. The applier rejects absolute paths, parent traversal, paths through existing symlinks, extended attributes and special files. Device nodes therefore do not come from an untrusted image layer.

After all layers have been staged, the disk assembler verifies that the result looks like a complete NetBSD root. At minimum, it expects init, a shell, the password database and MAKEDEV. Only then does it overlay the runtime-owned files:

the patched GENERIC64 kernel and unmodified bootaa64.efi
the statically linked NetBSD guest agent and its rc.d service
fstab, rc.conf, ttys and the EFI boot.cfg
device metadata generated by NetBSD’s own MAKEDEV

I also lock the root password, disable interactive gettys on both Virtio ports and leave DHCP, SSH, inetd and Postfix switched off. The agent starts the container process. There is no reason to log in to the guest.

NetBSD’s Darwin-hosted nbmakefs, nbgpt and nbpwd_mkdb tools do the filesystem-specific work. The resulting RAW disk has a GPT, a 64 MiB FAT32 EFI System Partition and an FFSv1 root partition labeled netbsd-root. The ESP contains the AArch64 removable-media path EFI/BOOT/BOOTAA64.EFI, and boot.cfg selects /netbsd with root=NAME=netbsd-root.

Use a serial device as the process API

The runtime service is an XPC helper launched once per container. It creates a generic VZ platform with persistent machine identity and EFI variable state, the cloned root disk, an entropy device, a small Virtio GPU for EFI output and two Virtio console ports. There is no virtual NIC.

Port ttyVI00 is the boot console. Its output is appended to boot.log, but its input comes from /dev/null and no getty listens on it. Port ttyVI10 is a private, root-owned connection between the macOS runtime and /usr/sbin/netbsd-vz-agent in the guest.

That second port carries the NetBSD VZ Agent protocol, or NVZA. Every frame has a fixed 32-byte header containing the magic, protocol version, frame type, request identifier, process identifier and payload length. Control messages are bounded JSON objects; standard input, standard output, standard error and file contents remain opaque bytes.

After a version handshake, the runtime translates Apple Container operations into agent requests. It supports process creation, start, wait, signal, terminal resize, standard-input closure, deletion and regular-file copy in both directions. Non-terminal processes keep stdout and stderr separate; a PTY merges them. The agent drains the output and sends EOF before reporting the final exit event. Otherwise, the last bytes from a short-lived command could disappear.

There is no hidden shell. The CLI combines the OCI entrypoint and command, adds environment overrides and sends the executable and its literal argument vector to the guest. The agent calls execve(2) and only searches PATH when the executable contains no slash. If you want shell operators, use /bin/sh -c yourself. Every process currently runs as root; OCI user selection is not implemented.

Virtio console works, but its tty input queue is small. NVZA permits larger stream frames, while the serial adapter sends at most 768 data bytes at a time and waits for an acknowledgement before continuing. This prevents terminal input and file transfers from overrunning the queue. A vsock transport should eventually make this workaround unnecessary.

When the main process exits, the runtime asks the agent to shut down NetBSD, waits briefly and force-stops the VZ machine only if the guest remains alive. A direct stop first signals the process and gives it a bounded wait. The process exit status then travels back through NVZA and Apple Container to the invoking CLI.

Run it and what remains

Building the runtime requires an Apple silicon Mac with macOS 26 or newer, Xcode, network access and Apple Container 1.3.0. The repository pins the Apple source revision and the NetBSD platform-kit archive. The following commands keep the locally built Apple binaries and both NetBSD plugins under the repository’s ignored .build directory:

git clone --branch v0.3.0 --depth 1 \
  https://github.com/tbarabosch/container-runtime-netbsd.git
cd container-runtime-netbsd

make compatible-container
CONTAINER_INSTALL_ROOT="$PWD/.build/apple-container-compat" make install

CLI="$PWD/.build/apple-container-compat/bin/container"
"$CLI" system stop
"$CLI" system start \
  --install-root "$PWD/.build/apple-container-compat" \
  --disable-kernel-install

system stop stops the active Apple Container service and its containers, so check existing work before running it. The locally built API server is necessary because the stock 1.3.0 server does not understand runtime-owned-resources.

The NetBSD image is public and does not require a GHCR login:

$ "$CLI" netbsd run ghcr.io/tbarabosch/netbsd:11 \
    --name hello --remove -- /usr/bin/uname -a
NetBSD container-runtime-netbsd 11.0 NetBSD 11.0 (GENERIC64) #0: Thu Aug 27 21:53:13 CEST 2026  tbarabosch@Thomass-MacBook-Neo.local:/Users/tbarabosch/code/netbsd-vz/.build/obj/sys/arch/evbarm/compile/GENERIC64 evbarm

I captured this run on an Apple silicon Mac with macOS 26.6.2, Xcode 26.6, Swift 6.3.3 and the patched Apple Container 1.3.0 source. The output is exact, including the cross-builder identity and object path embedded in the kernel version string. The command exited successfully, the --remove option deleted its container state and the runtime shut the guest down.

The important part is that the custom Swift VM runner from the first article is no longer involved. Apple Container fetched the public image, the CLI assembled the disk, Virtualization.framework booted NetBSD through EFI and NVZA started uname. Its output and exit status reached the host as expected.

There is still plenty to do:

Submit the generic Virtio corrections to NetBSD and the external-runtime changes to Apple Container.
Add guest networking, mounts, published ports and socket APIs.
Replace or complement the serial transport with vsock and handle crashed runtimes more cleanly.
Support non-root processes, recursive copy and more complete OCI filesystem metadata.
Rehash cached disks, serialize concurrent cache writes and expand negative and integration testing.
Replace the one-off base-image publisher with a reproducible, automated and attested GHCR pipeline.

That’s it. container netbsd run ghcr.io/tbarabosch/netbsd:11 now boots NetBSD 11 and runs a real NetBSD program. It still needs patched components and lacks several everyday container features. But it works, and the image is available on GHCR for others who want to try it.

Earning the BSD Specialist certification

Thomas Barabosch — Mon, 31 Aug 2026 10:00:00 +0000

On 31 August 2026, I earned the LPI BSD Specialist certification. The exam covers administration across FreeBSD, NetBSD and OpenBSD: installation, storage, networking, security, system maintenance and the Unix tools shared between them.

I am pleased to have passed, but the credential does not mark the beginning of my work with BSD. It is a formal checkpoint after years of approaching these systems from several directions.

Much of that work began on the security side. A malformed ELF header led to a FreeBSD kernel crash and memory disclosure fixed as CVE-2018-6924. Trap fuzzing exposed the OpenBSD denial of service later assigned CVE-2018-14775. Together with Maxime Villard, I designed KLEAK, the kernel memory-disclosure detector credited with finding thirteen issues in NetBSD-SA2019-001.

BSD projects also accepted reports and patches that became fixes in their source trees. Some crossed project boundaries: related mistakes in KAME-derived networking tools were corrected in both NetBSD and OpenBSD. I described that work in One BSD’s fix is another BSD’s bug.

More recently, I moved from finding faults in BSD software to maintaining a small part of its supply chain. I updated FreeBSD’s misc/xdelta3 port to version 3.2.0 and became its maintainer. Keeping build metadata, dependencies and packaging correct is the sort of quiet maintenance an operating system ecosystem needs!

The certification does not make FreeBSD, NetBSD and OpenBSD interchangeable. It confirms a useful, independent administrative baseline across all three and gives this part of my career a tidy marker. For anyone preparing for the same exam, I published the one-page BSD Specialist cheat sheet that I used for my final review.

From forty dots to an entropy map

Thomas Barabosch — Sun, 30 Aug 2026 10:00:00 +0000

In 2020, one of my triage tools printed a file’s entropy as forty colored dots. I mainly used it on executables that might be packed. It was fast, pleasantly colorful and easy to overread.

The dots never proved packing. What helped was seeing where the byte distribution changed. Six years later, I wanted the same quick view with real offsets and without the fake verdict.

The original forty dots

The core of the old tool was small. It divided the file into forty chunks and colored each chunk by its Shannon entropy:

def entropy(s):
    l = float(len(s))
    return -sum(map(lambda a: (a/l)*math.log2(a/l), Counter(s).values()))


def visualize_compression(file_path, bin_count=40):
    with open(file_path, "rb") as f:
        data = f.read()
        chunk_size = int(len(data) / float(bin_count))
        bins = []
        current_chunk = 0
        while current_chunk < len(data):
            ent = entropy(data[current_chunk:current_chunk + chunk_size])
            if ent < 5:
                bins.append(colored('.', 'green'))
            elif ent < 7:
                bins.append(colored('.', 'yellow'))
            else:
                bins.append(colored('.', 'red'))
            current_chunk += chunk_size
        return bins

It did the job in the usual quick-and-dirty RE fashion: read the complete file, chop it into chunks and print some dots. It also gets stuck on files shorter than forty bytes because chunk_size becomes zero. The bigger problem is the color scheme. Two arbitrary thresholds look surprisingly authoritative when they are green, yellow and red.

Forty bins were another shortcut. A tiny executable and a multi-gigabyte image got the same number of dots, even though each dot represented a wildly different amount of data.

A companion packed() helper went further and returned Packed, Possibly packed or Not packed. Its score included sections without raw data and sections with entropy below 1 or above 7. Those are all reasons to look closer at a PE file. They are not specific to packers. Compilers, linkers, installers and ordinary resources can produce the same measurements.

The measurement itself is still useful. Claude Shannon defined entropy from the probabilities of symbols. For bytes, it is calculated as H(X) = -sum(p(x) * log2(p(x))). One repeated byte gives 0 bits per byte. An even distribution of all 256 byte values gives 8.

Bin size really matters. A 128-byte bin cannot contain all 256 byte values, so it cannot reach 8 bits per byte. Larger bins give steadier numbers but hide small transitions. The output needs to show that resolution.

I kept the new display to one strip:

0x00000000 │▁▁▂▂▃▄▅▆▇█│ 0x00090000
            low entropy                    high entropy

A sparkline with byte offsets

The new entropy-map is still one Python file and uses only the standard library. It scans the selected range once through a bounded buffer. Every byte belongs to exactly one bin, and the output prints both the bin size and the half-open file range.

For a predictable demo, I asked OpenAI’s Codex to generate a file with nine 64 KiB regions. The first region repeats one byte, the second alternates two values, and the last cycles through all 256 values. Their entropies run from exactly 0 to 8 bits per byte.

Using eight bins per region makes the staircase obvious in both the block height and the color:

$ python3 entropy/entropy_map.py --bins 72 entropy-demo.bin

The same output without ANSI color remains readable:

'entropy-demo.bin' · 589824 bytes · range [0x00000000, 0x00090000)
72 bins · 8192 bytes/bin · H(range)=5.520 bits/byte

0x00000000 │▁▁▁▁▁▁▁▁▂▂▂▂▂▂▂▂▃▃▃▃▃▃▃▃▄▄▄▄▄▄▄▄▅▅▅▅▅▅▅▅▆▆▆▆▆▆▆▆▇▇▇▇▇▇▇▇████████████████│ 0x00090000
            0%                                 50%                              100%
                                ▁ 0.0   Shannon entropy   8.0 █

H(range) is 5.520, not the average of the nine local values. It describes the combined byte distribution. The strip shows what happens inside that range. To zoom in, --offset 0x20000 --length 0x30000 --bins 24 selects exactly [0x20000, 0x50000).

Where it fits

There are already existing entropy visualizers. Entroplot uses fixed 1,024-byte blocks and writes a PNG line chart. Binwalk combines an offset-based graph with firmware signatures and extraction. ImHex has an interactive graph and a local-entropy minimap in its hex editor. The archived Veles offers a much broader set of interactive statistical views.

I wanted something simpler: run it in the shell (including using it in ranger or a similar terminal file manager), get a quick map and continue working. There is no GUI, plotting dependency or output file. Give it a file or a byte range and it prints the offsets, resolution and entropy strip.

I read the strip as a map, not a diagnosis. Low entropy may be padding, text or another repetitive structure. High entropy may be compression, encryption, random data or media that was already compressed. A sharp edge may mark an embedded object or an entirely normal format boundary. Entropy gives me a byte range to inspect next. It still cannot prove packing. Good. That was the point of replacing the old dots.

OCI fundamentals: images, layers and registries

Thomas Barabosch — Sat, 29 Aug 2026 10:00:00 +0000

While working on the ongoing NetBSD on Apple Virtualization series, I eventually had to look beyond boot loaders and Virtio drivers. I needed to understand how to package NetBSD as an OCI image for Apple’s container tool. The actual NetBSD image deserves a separate future post. This short article is the reference material for it.

OCI stands for Open Container Initiative. Canonical’s presentation What is the Open Container Initiative? provides a good introduction to this technology.

Three specifications, not one runtime

The OCI project maintains three specifications. The Image Specification describes the packaged content. The Distribution Specification defines how registries push and pull that content. The Runtime Specification describes the filesystem bundle, configuration and lifecycle used to start a container.

build input
    |
    v
OCI image ------ Image Specification
    |
    v
registry API --- Distribution Specification
    |
    v
runtime bundle - Runtime Specification
    |
    v
container process

OCI does not build or run anything on its own. Its specifications let a tool build an image, a registry store it and another compatible tool fetch and run it.

An image is a graph of blobs

An image manifest references a configuration and an ordered list of filesystem layers. Each descriptor records a media type, size and content digest. An optional image index points to several manifests, usually one per operating-system and CPU-architecture combination.

image index (optional)
`-- manifest: linux/arm64
    |-- config: command, environment, layer order
    `-- filesystem changes
        |-- layer 2: /hello.txt
        `-- layer 1: Alpine root filesystem

Layers are changesets, not complete copies of the filesystem. A runtime applies them from the base upward to produce one root filesystem. The configuration holds properties such as the entry point, default arguments, environment and working directory. A digest identifies immutable content; a convenient tag such as 1.0 is only a movable name that resolves to a manifest.

A normal container image does not include a kernel. It supplies userspace files and process settings; the runtime supplies the execution environment. That distinction is one reason the NetBSD experiment needs more than a different FROM line.

Push an image to GitHub Container Registry

This minimal Containerfile adds one filesystem layer and one command:

FROM alpine:3.22
RUN printf 'hello from OCI\n' >/hello.txt
CMD ["cat", "/hello.txt"]

GitHub Container Registry accepts OCI images at ghcr.io. With Apple’s container commands, a local round trip looks like this:

The reference ghcr.io/OWNER/oci-demo:1.0 contains the registry, account namespace, image name and tag. During a push, the client uploads missing blobs and then the manifest. A pull resolves the tag and downloads the referenced configuration and layers.

container system start

GHCR_OWNER=your-lowercase-github-name
IMAGE="ghcr.io/${GHCR_OWNER}/oci-demo:1.0"
read -rsp 'GHCR token: ' CR_PAT
printf '\n'
printf '%s' "$CR_PAT" | container registry login \
  --username "$GHCR_OWNER" --password-stdin ghcr.io
unset CR_PAT

container build --tag "$IMAGE" .
container image push "$IMAGE"

The classic personal access token needs write:packages. New packages are private by default. After repeating the login on another Mac, fetch and run the image with:

container system start
container image pull "ghcr.io/your-lowercase-github-name/oci-demo:1.0"
container run --rm "ghcr.io/your-lowercase-github-name/oci-demo:1.0"

Public packages can be pulled without authentication. This example publishes only the builder’s platform; multi-platform NetBSD images are a subject for the follow-up.

What lives after the last PE section?

Thomas Barabosch — Fri, 28 Aug 2026 10:00:00 +0000

A Portable Executable does not necessarily end with its last mapped section. Trailing bytes form an overlay: data that Windows does not map as part of the image, but which still belongs to the file.

Removing an overlay is easy. Doing it without discarding useful information is the interesting part. This post revisits an old helper I wrote a couple of years ago and adds the missing guardrails using OpenAI’s Codex.

This somehow continues my work on PE timestamps and PE magic numbers, but at the other end of the file.

An old helper

Years ago, I wrote a small script to remove PE overlays. It is from 2021 and simple enough to show in full:

import sys
import pefile


def main(argv):

    if len(argv) != 2:
        print('Usage: pe_strip_overlay.py PATH_TO_PE_WITH_OVERLAY')

    with open(argv[1], 'rb') as f:
        data = f.read()
        try:
            pe = pefile.PE(data=data)
            if pe:
                with open(argv[1].replace('.bin', '') + '_stripped.bin', 'wb') as g:
                    g.write(pe.trim())
        except Exception as e:
            print(f'Could not trim PE file: {e}')


if __name__ == '__main__':
    main(sys.argv)

As you can see, the heavy lifting is done mostly by pefile. It looked like a good idea for a short post, so I used Codex to review its assumptions and turn it into the safer public helper described below as this is a common problem you might stumble upon while reversing Windows malware.

The old script discarded the overlay, invented a name with str.replace(), caught every exception and reported no hashes. Its filename could collide with another file. More importantly, pefile.PE.trim() does not ask whether the suffix contains a PE Certificate Table. So in summary, a classical RE script!

The section table is not the whole file

The raw end of a section is PointerToRawData + SizeOfRawData. The highest relevant end offset gives an overlay candidate:

file offset ->

+---------+---------+---------+------------------+
| headers | .text   | .idata  | appended bytes   |
+---------+---------+---------+------------------+
                              ^ overlay candidate

That boundary needs a parser. The Microsoft PE/COFF specification has one awkward exception: the Certificate Table contains a file offset, not an RVA, because the loader does not map its WIN_CERTIFICATE records.

Optional Header
  Certificate Table ---------------------+
                                          v
+---------+----------+-------------------+----------+
| headers | sections | WIN_CERTIFICATE   | more data|
+---------+----------+-------------------+----------+
                     outside mapped sections

The pinned pefile 2024.8.26 implementation skips the Security directory while finding the overlay. Its trim() therefore removes certificate bytes too. They are outside the mapped sections, but not undescribed junk.

Preserve the suffix before trimming it

The updated script uses explicit paths, exclusive output creation, SHA-256 and a hard stop for a nonempty or malformed Certificate Table. The complete helper and reusable Apple Container environment live in re-scripts at commit 06c38cc. The abbreviated excerpts below cover only its two important decisions.

First, the Security data-directory entry is either empty or a stop sign. A malformed pair of offset and size is not a reason to guess:

offset = entry.VirtualAddress
size = entry.Size
if offset == 0 and size == 0:
    return
if offset == 0 or size == 0 or offset % 8 != 0 or offset + size > file_size:
    raise OverlayError("malformed PE Certificate Table entry; refusing to trim")
raise OverlayError("PE Certificate Table present; refusing to trim")

Only after that check does the helper split the bytes at pefile’s overlay offset. It writes the evidence first and the derived executable second:

overlay_offset = pe.get_overlay_data_start_offset()
if overlay_offset is None:
    return 0
if not 0 < overlay_offset < len(data):
    raise OverlayError("invalid overlay offset")

overlay_data = data[overlay_offset:]
trimmed_data = data[:overlay_offset]

write_new(args.overlay_out, overlay_data)
write_new(args.trimmed_out, trimmed_data)

I built this no-op with x86_64-w64-mingw32-gcc 13-win32 in an Ubuntu 24.04 Apple Container:

int main(void)
{
    return 0;
}

I put OVERLAY-DEMO.txt into a ZIP, appended it and ran the helper with pefile 2024.8.26:

$ x86_64-w64-mingw32-gcc -Os -s -o hello.exe hello.c
$ zip -X payload.zip OVERLAY-DEMO.txt
$ cp hello.exe hello-overlay.exe
$ dd if=payload.zip of=hello-overlay.exe oflag=append conv=notrunc status=none
$ python3 trim_pe_overlay.py hello-overlay.exe --overlay-out recovered.zip --trimmed-out hello-trimmed.exe
input:   hello-overlay.exe (15021 bytes, sha256=223aaf2145a3d03ae375c72251a320320b3728c83ee1440221ffcf2253b6ed7a)
overlay: recovered.zip (173 bytes at 0x3a00, sha256=06dfd3404725f7152381d9e44a3fbb9021cdddd8e508b743efe3c1313d18e5dc)
trimmed: hello-trimmed.exe (14848 bytes, sha256=7c71c75a9d692a7c3436be34b487d96c1a21c6ad3868079d060675af2b070623)

$ cmp payload.zip recovered.zip
$ cmp hello.exe hello-trimmed.exe

Both comparisons succeeded: the suffix was the exact ZIP and the derived PE was the pre-append executable.

A certificate table is a stop sign

I locally signed the executable with osslsigncode. The helper found its Certificate Table and refused before creating output:

$ python3 trim_pe_overlay.py hello-signed.exe --overlay-out signed.overlay --trimmed-out hello-signed-trimmed.exe
error: PE Certificate Table present; refusing to trim (offset=0x3a00, size=1488)

A Certificate Table proves neither signature validity nor trust. It only describes certificate data at a file offset and probably not the job of this script. Authenticode verification is a separate job and shall be addressed in another blog post.

Moving NetBSD on Apple VZ from direct boot to EFI

Thomas Barabosch — Thu, 27 Aug 2026 20:00:00 +0000

The first version of netbsd-vz booted NetBSD 11 directly through Apple’s VZLinuxBootLoader. It worked, but the host had to prepare a padded AArch64 kernel image and pass a flattened device tree (FDT) to a project-specific VZ64 kernel. That experiment needed four NetBSD patch files, including changes for the early bootstrap and console.

The same guest now boots through Virtualization.framework’s generic EFI platform. EFI starts NetBSD’s vanilla bootaa64.efi, the loader enters a vanilla GENERIC64 kernel configuration, and ACPI describes the virtual hardware. Three generic Virtio fixes remain. Everything specific to direct kernel booting is gone.

direct boot                         EFI boot
-----------                         --------
host loads kernel + FDT             firmware loads stock NetBSD loader
four patch files                    three generic Virtio patches
custom VZ64 configuration           stock GENERIC64 configuration

This is not just one patch fewer, it is less Apple VZ related code that needs to be added to the upstream NetBSD kernel.

EFI on Apple VZ in a nutshell

EFI is the firmware interface between the virtual machine and its operating system loader. With Virtualization.framework, VZEFIBootLoader provides that environment in Apple VZ Framework. A VZEFIVariableStore keeps the firmware’s NVRAM-style state separately from the guest disk.

The disk contains a FAT32 EFI System Partition (ESP). When no more specific boot entry exists, the UEFI removable-media rules give AArch64 firmware a standard loader path: EFI/BOOT/BOOTAA64.EFI. The disk builder copies NetBSD 11’s unmodified bootaa64.efi there. Firmware loads it, the loader finds the kernel, and the kernel takes over.

VZEFIBootLoader
      |
      +-- EFI variable store
      |
      `-- GPT disk
            |
            +-- FAT32 ESP
            |     `-- EFI/BOOT/BOOTAA64.EFI
            |
            `-- FFS root
                  `-- /netbsd (GENERIC64)

EFI does not know anything special about this NetBSD-on-VZ experiment. It knows how to find and start an EFI application. NetBSD’s loader knows how to start NetBSD.

After the loader hands over control, GENERIC64 uses the ACPI tables exposed by VZ to discover the CPUs, GICv3 interrupt controller, timer, PCI host bridge, and the devices below it. Direct boot obtained similar information from the FDT supplied with the raw kernel image. Changing the discovery mechanism is what allows the standard kernel configuration to replace the custom VZ64.

From direct boot to EFI

The earlier direct-boot version used an API named for Linux, although the interface accepted the raw AArch64 Image format that a cross-compiled NetBSD could also produce. The runner supplied that image and a command line. VZ placed an FDT in memory and passed its address in register x0 when it entered the kernel.

That short route made the project responsible for details normally handled by firmware and the operating-system loader. The build padded the kernel to an 8 MiB reservation, regenerated its AArch64 image header, and rejected a kernel that grew into adjacent boot data. The kernel configuration enabled the FDT path and removed EFI and ACPI.

The EFI path moves those jobs into firmware and NetBSD’s normal arm64 loader:

DIRECT

VZLinuxBootLoader
        |
        v
padded raw AArch64 Image + command line
        |
        v
host-supplied FDT -> VZ64 kernel


EFI

VZEFIBootLoader
        |
        v
GPT + ESP -> stock bootaa64.efi
        |
        v
ACPI handoff -> stock GENERIC64 kernel

The result is closer to an ordinary bootable NetBSD disk. The host configures a generic machine and attaches devices; it no longer prepares the kernel’s entry format or describes the platform through a direct-boot FDT.

Less Patches, Less Issues

The direct-boot tree carried four patch files with 378 lines between them. The current patch directory contains three files with 70 lines.

DIRECT BOOT: 4 files / 378 lines
        |
        +-- viocon-console.patch ------- removed
        +-- vz64-config.patch ----------- removed
        +-- vz-platform.patch
        |      |-- FDT/bootstrap -------- removed
        |      |-- no-match console ----- removed
        |      |-- PCI memory decode ---- kept, split out
        |      `-- Virtio reset wait ---- kept, split out
        `-- vioif-mtu.patch ------------- kept
                    |
                    v
EFI BOOT: 3 files / 70 lines

The old viocon-console.patch promoted Virtio console port zero to the kernel console. EFI lets NetBSD keep its normal GOP console instead, while a vanilla getty provides the interactive serial login later. The old vz64-config.patch defined exactly the direct-boot hardware subset. GENERIC64 already includes the EFI, ACPI, PCI, and Virtio paths needed by the new machine.

The old vz-platform.patch mixed platform-specific and generic work. Its FDT mapping and empty-console accommodations disappear with direct boot. Its two reusable corrections survive as focused patches: enable PCI memory decoding for modern Virtio BARs, and wait until a Virtio 1.0 reset actually completes before configuring queues.

The current virtio-pci-memory.patch enables memory decoding alongside PCI bus mastering and I/O decoding. virtio-reset.patch polls the device status after writing zero, as required before queue setup continues. vioif-mtu.patch negotiates the MTU feature advertised by VZ’s network device and applies its value to the interface.

None of these three patches names Apple, changes EFI or ACPI, or defines a VZ platform. They are generic driver corrections and therefore much better upstream candidates than the old patches.

Less Complexity during VM Creation and Booting

EFI did not make the machine smaller. It moved complexity out of the kernel delta and into conventional firmware, storage, and display interfaces.

1,088 MiB RAW disk
+------------------------------------------------------+
| GPT | 64 MiB FAT32 ESP | FFSv1 root              | GPT |
+------------------------------------------------------+
          |                   |
          |                   `-- /netbsd + base system
          `-- BOOTAA64.EFI + boot.cfg

separate host state
+----------------------+       +----------------------+
| machine identifier   |       | EFI variable store   |
+----------------------+       +----------------------+

The runner now creates or reuses a generic machine identifier and EFI variable store. The VM also needs a Virtio GPU because EFI and early kernel output use the Graphics Output Protocol (GOP). The VZ Virtio serial device is not an EFI console, so a headless terminal stays quiet until NetBSD starts getty on /dev/ttyVI00. Earlier messages remain available through dmesg after login.

The ESP contains a small boot.cfg that asks the loader to start netbsd verbosely with root=NAME=netbsd-root. Using the GPT and FFS label avoids coupling the root filesystem to whichever device number autoconfiguration assigns. The default runner boots a copy-on-write clone of the published disk and creates temporary EFI state. Supplying explicit disk and state paths makes both persistent.

Firmware and bootaa64.efi also add work before the kernel starts. Direct boot remains attractive when a firmware-free path and a small boot chain matter more than matching ordinary hardware. For this proof of concept, however, boot speed was not the main requirement. Reducing NetBSD-specific changes was.

Wrapping It Up

Moving to EFI made netbsd-vz less of a special NetBSD platform and more of a normal arm64 guest. Stock firmware conventions select the vanilla loader. The vanilla loader starts GENERIC64. ACPI is responsible for the hardware description. The remaining changes sit in Virtio drivers without anything specific to Apple VZ.

In the end, NetBSD 11 is not unmodified yet, but the platform-specific patch set is now gone. The repository’s technical documentation documents the disk geometry, runner state, build inputs, and current patches.

Preparing for BSD Specialist with a one-page cheat sheet

Thomas Barabosch — Thu, 27 Aug 2026 10:00:00 +0000

FreeBSD, NetBSD and OpenBSD share an ancestry, but an exam question can turn on the command or configuration file they do not share. Package tools, rc service control, persistent network configuration and kernel handling are exactly where Linux muscle memory becomes unhelpful. I condensed those differences into a printable one-page BSD Specialist Cheat Sheet.

The guide covers the five weighted objective areas, common administration workflows, cross-BSD command differences and the Unix tools expected by the exam. It follows version 1.0 of the official LPI BSD Specialist objectives for exam 702-100 and is intended for a final pass after hands-on preparation, not as a replacement for the objectives or the BSD manuals, which can change.

BSD Specialist Cheat Sheet (PDF)

Preparing for GH-500 with a final review guide

Thomas Barabosch — Wed, 26 Aug 2026 10:00:00 +0000

GitHub Advanced Security is several products and workflows wearing one security label. The distinctions worth retaining are practical: which suite owns a control, where push protection ends and credential remediation begins, what the dependency graph feeds, and when CodeQL default setup stops being enough. I condensed those decision points into a printable one-page GH-500 Final Review Guide.

The guide covers Secret Protection, supply chain security, Code Security and CodeQL, administration, vulnerability terminology, abbreviations, and current high-signal limits. It follows the July 2026 blueprint and is intended for a final pass after hands-on preparation, not as a replacement for the official GH-500 study guide, whose objectives can change.

GH-500 Final Review Guide (PDF)

Preparing for AWS SAA-C03 with a final review guide

Thomas Barabosch — Sun, 23 Aug 2026 10:00:00 +0000

The last hours before an architecture exam are a bad time to rediscover whether a standby serves reads or which endpoint avoids a NAT gateway. I condensed the distinctions I wanted in front of me into a printable one-page AWS SAA-C03 Final Review Guide.

The guide focuses on service boundaries, abbreviations, current limits, resilience and cost tradeoffs, and the traps hidden in plausible answers. It is for a final pass after hands-on preparation, not a replacement for the official AWS Certified Solutions Architect - Associate exam guide, whose objectives and service scope can change.

AWS SAA-C03 Final Review Guide (PDF)

If NetBSD runs on a toaster, it must run on Apple VZ: Porting NetBSD to yet another platform

Thomas Barabosch — Tue, 18 Aug 2026 19:30:00 +0000

In 2005, Technologic Systems put a TS-7200 ARM board inside a standard two-slice toaster and ran NetBSD on it. The appliance still made toast. NetBSD 3.0 subsequently listed the TS-7200 as the “NetBSD Controlled Toaster,” turning the old portability joke into supported hardware.

Twenty-one years later, I had a less thermally ambitious target: Apple’s Virtualization.framework on an Apple silicon Mac. If NetBSD could run a toaster, it had no excuse for avoiding a virtual ARM machine. The result is netbsd-vz, a reproducible build that boots NetBSD 11.0 from a direct AArch64 kernel image, mounts an FFS root disk, drives the VZ Virtio devices and shuts the virtual machine down cleanly.

                           |\
                           | \~~~~~~~~~~~~~~~~\
                           |  \     NetBSD      \
                           |   \          /~~~~~/
                           |    \~~~~~~~~/
                           |
              .-""""-.    |
           .-'////////`-._ |
         .'/////////////  `|
        ////////////    _.-|
        \///////   _..-'   |
         `--...---'        |
             __..---.      |      .---..__
          .-'::::::::`-.__.|.__.-'::::::::`-.
        .'::::::::::::::::::::::::::::::::::::`.
       /::::::::::::::::::::::::::::::::::::::::\
      /::::::....::::::::::::::::::::::::::::::::\
     |::::..    ..:::::::::::::::::::::::::::::::|
     |:::..      ..::::::::::::::::::::::::::::::|
     |::::..    ..:::::::::::::::::::::::::::::::|
      \::::::....:::::::::::::::::::::::::::::::/
       \:::::::::::::::::::::::::::::::::::::::/
        `.:::::::::::::::::::::::::::::::::::.'
          `-._:::::::::::::::::::::::::::_.-'
              `--..__::::::::::::__..--'
                     `--.::::.--'
                         `--'

The complete boot is easier to recognize in motion. The following GIF animates a condensed transcript from an actual offline make smoke run. It omits repetitive dmesg output and machine-local paths, but retains the device attachment, root mount, login, userspace marker, clean FFS unmount and guest poweroff.

Start with the virtual hardware contract

I described the host side of Virtualization.framework in Build a tiny Linux VM with Apple VZ. The NetBSD runner uses the same small part of the framework: a generic ARM platform, one virtual CPU, 512 MiB of memory, a direct kernel loader and selected Virtio devices. Console and entropy are always present. Block storage and VZ NAT are explicit additions.

The interesting work is therefore in the guest, not another tour through the Swift configuration. Apple’s class is named VZLinuxBootLoader, and Apple documents it as a Linux kernel loader. In practice, the interface accepts the uncompressed AArch64 Image format expected by that boot path.

macOS
  |
  `-- Virtualization.framework
        |-- direct AArch64 Image loader
        |-- flattened device tree
        |-- Virtio console
        |-- Virtio entropy
        |-- Virtio block ---- 1 GiB RAW disk
        `-- optional NIC ---- VZ NAT
                    |
              NetBSD VZ64

This is close to hardware that NetBSD already understands. The evbarm-aarch64 port handles AArch64, FDT, PSCI, GICv3 and generic timers. NetBSD also has drivers for Virtio console, block, entropy and network devices. Nevertheless, there were still some issues that needed to be resolved: how VZ reserved memory around the kernel image, how the FDT was mapped, which PCI address spaces were enabled, when a Virtio reset had completed, which console became the kernel console and which network features the guest accepted.

FreeBSD took a different route through VZ

This was not the first BSD bring-up on Virtualization.framework. Thomas Fontaine’s FreeBSD-on-Apple-Virtualization work booted a prepared FreeBSD 16.0-CURRENT/aarch64 guest to multiuser, persisted data on UFS, configured vtnet0 through VZ NAT, wrote through a Virtio console and shut down cleanly.

The two experiments reached a similar device set through different boot contracts. The FreeBSD work uses VZ’s generic EFI platform. EFI starts the stock FreeBSD loader.efi, which follows the ACPI handoff into the kernel. The NetBSD experiment bypasses EFI and enters a raw AArch64 Image with an FDT. That difference decides where the investigation starts: EFI media and ACPI for FreeBSD, kernel-image placement and FDT bootstrap mappings for NetBSD.

First Things First: Prepare the Kernel Image before touching a driver

The build starts with the official NetBSD 11.0 src, gnusrc, sharesrc and syssrc sets. scripts/build.sh pins and verifies the SHA-512 digest of every archive, extracts the source, applies four tracked patches and uses NetBSD’s own build.sh to create Darwin-hosted AArch64 cross tools. This is actually one of my favorite NetBSD features: apart from it’s portability, it can be cross-compiled on several platforms. Personally, I can confirm this for Linux and macOS.

I did not keep the full GENERIC64 configuration as it included far more evbarm hardware than VZ exposes. The project-specific VZ64 configuration keeps the most important modules while also retaining DDB, symbols and tracing for failures. For instance, it removes modules, memory disks, compatibility ABIs, EFI, ACPI and drivers for physical storage, USB, display and audio hardware.

VZ placed adjacent boot data close enough to the reduced kernel image to stop the kernel from starting. The builder now reserves exactly 8 MiB, pads the payload and regenerates its AArch64 header with the final declared size and ARM\x64 magic. It also rejects a kernel that grows into the reservation. This prevents the boot inputs from colliding.

Make the FDT mapping agree with the kernel

VZ passes the flattened device tree to the kernel in register x0. NetBSD maps that FDT during the early AArch64 bootstrap. On the observed VZ layout, the FDT can share a 2 MiB L2 block with an existing kernel bootstrap mapping.

The original FDT mapping requested both unprivileged execute-never (UXN) and privileged execute-never (PXN) attributes. The existing block used UXN. pmapboot_enter could not reuse one block for two mappings with different attributes, so boot stopped before any useful console existed. The platform patch makes the attributes compatible:

 mov x2, #L2_SIZE
 mov x3, #L2_SIZE
 mov x4, #LX_BLKPAG_ATTR_NORMAL_WB | LX_BLKPAG_AP_RW
-orr x4, x4, #LX_BLKPAG_UXN | LX_BLKPAG_PXN
+/* The FDT may share an L2 block with the kernel bootstrap mapping. */
+orr x4, x4, #LX_BLKPAG_UXN
 mov x5, x26
 bl  pmapboot_enter

This is a tiny diff at a particularly problematic point in the boot. There is no filesystem, debugger transport or working console yet. The useful fact came from the mapping geometry: the FDT and kernel were not independently broken; they asked the same page-table block to describe memory in incompatible ways.

Enable the PCI path and finish resetting Virtio

Once the kernel reached device discovery, the next boundary was PCI. VZ presents modern Virtio devices with their capabilities in memory BARs (Base Address Registers). NetBSD’s Virtio PCI attach path enabled bus mastering and I/O decoding, but not PCI memory decoding. The first half of the fix is exactly as plain as it sounds:

 csr = pci_conf_read(pc, tag, PCI_COMMAND_STATUS_REG);
-csr |= PCI_COMMAND_MASTER_ENABLE | PCI_COMMAND_IO_ENABLE;
+csr |= PCI_COMMAND_MASTER_ENABLE | PCI_COMMAND_MEM_ENABLE |
+    PCI_COMMAND_IO_ENABLE;
 pci_conf_write(pc, tag, PCI_COMMAND_STATUS_REG, csr);

That made the BARs accessible. It did not make the queues reliable. The second half concerns time rather than address space.

The Virtio 1.0 specification requires a driver resetting a device to write status zero and then wait until a subsequent read returns zero. VZ completes that reset asynchronously. NetBSD wrote zero and continued into queue configuration before VZ had reported completion. The writes appeared to happen, but the queue state did not survive.

 bus_space_write_1(iot, ioh, VIRTIO_CONFIG1_DEVICE_STATUS,
     status | old);
+if (status == 0) {
+    /* Virtio 1.0 requires the driver to wait for reset completion. */
+    while (bus_space_read_1(iot, ioh,
+        VIRTIO_CONFIG1_DEVICE_STATUS) != 0)
+        DELAY(1);
+}

Waiting for the status byte closed the race. Console, block, entropy and network devices all use the same Virtio PCI transport, so this one correction sits below most of the useful machine.

Turn a Virtio port into the kernel console

VZ connects the host terminal to a Virtio console device. NetBSD 11’s viocon(4) attaches that device as a tty, but it does not promote port zero to the kernel console. A tty appearing during autoconfiguration is not enough for printf, DDB and the polling console operations used during shutdown or panic handling.

The patch is substantially derived from kernel-console support originally written by Taylor R. Campbell and carried as patch 2 in Emile “iMil” Heitor’s ongoing full VirtIO console patch series. I adapted its late-console portion to NetBSD 11 and the VZ configuration. The project does not include the series’ early Virtio-MMIO console or multiport work.

After viocon(4) has created and filled port zero’s queues, the console patch installs its consdev operations:

+if (cn_tab == NULL || cn_tab->cn_dev == NODEV ||
+    cn_tab->cn_pri < CN_NORMAL) {
+    sc->sc_ports[0]->vp_cntab = (struct consdev) {
+        .cn_pollc = viocon_cnpollc,
+        .cn_getc = viocon_cngetc,
+        .cn_putc = viocon_cnputc,
+        .cn_dev = VIOCONDEV(device_unit(self), 0),
+        .cn_pri = CN_REMOTE,
+    };
+    cn_set_tab(&sc->sc_ports[0]->vp_cntab);
+    printf("NetBSD/VZ viocon console attached\n");
+}

The distinction between late and early matters. Live output begins only after FDT, PCI, Virtio PCI and viocon(4) have attached. Messages from kernel entry through that point remain invisible on the terminal. The smoke test runs dmesg after login to recover them. This limitation makes early boot issues harder to diagnose.

Put an FFS root behind Virtio block

A kernel reaching a root-device prompt proves less than it first appears to. I wanted the normal NetBSD base system to reach init, start getty, accept a console login and shut itself down.

The disk builder downloads the official NetBSD 11.0 evbarm-aarch64 base and etc sets and verifies their SHA-512 hashes. NetBSD’s cross-built nbmakefs creates a little-endian FFSv1 filesystem. nbgpt wraps it in a fixed 1 GiB RAW disk with a protective MBR, primary and backup GPT, and one NetBSD FFS partition beginning at LBA 2048.

Both the GPT wedge and the filesystem use the label netbsd-root. The kernel command line selects root=NAME=netbsd-root, avoiding a dependency on whichever unit number autoconfiguration assigns. In the accepted run, Virtio block attached as ld0, wedge discovery created dk0, and the kernel mounted FFS from that wedge.

The root overlay changes only fstab, rc.conf and ttys. It enables a secure console login, disables ordinary network services and starts DHCP only when a vioif interface exists. The release set’s empty root password is retained for this isolated console proof. Networking remains opt-in, and enabling remote services without first setting a password is not recommended.

Negotiate the MTU that VZ advertises

At this point, the offline guest has no NIC. Adding a VZVirtioNetworkDeviceConfiguration with VZ NAT exposes another Virtio PCI function, but the first attempts did not produce a usable vioif interface.

VZ advertises the Virtio network VIRTIO_NET_F_MTU feature. In this configuration, feature negotiation failed until the NetBSD driver accepted that feature and read the advertised MTU. The network patch adds the bit to the requested feature set and applies the device value to the interface:

+#define VIRTIO_NET_F_MTU        __BIT(3)

 req_features =
-    VIRTIO_NET_F_MAC | VIRTIO_NET_F_STATUS | VIRTIO_NET_F_CTRL_VQ |
-    VIRTIO_NET_F_CTRL_RX | VIRTIO_F_NOTIFY_ON_EMPTY;
+    VIRTIO_NET_F_MTU | VIRTIO_NET_F_MAC | VIRTIO_NET_F_STATUS |
+    VIRTIO_NET_F_CTRL_VQ | VIRTIO_NET_F_CTRL_RX |
+    VIRTIO_F_NOTIFY_ON_EMPTY;

+if (features & VIRTIO_NET_F_MTU)
+    ifp->if_mtu = virtio_read_device_config_2(vsc,
+        VIRTIO_NET_CONFIG_MTU);

With that change, vioif0 attached with an MTU of 1500, reported active carrier, acquired an IPv4 address by DHCP and installed the VZ NAT gateway as its default route.

Companion Code

The companion code separates building from booting. An Apple silicon Mac, the selected Xcode or Command Line Tools, make, network access to the official NetBSD archives and roughly 10 GiB of free space are enough for the first build. No prebuilt NetBSD cross compiler is assumed.

$ git clone https://github.com/tbarabosch/netbsd-vz.git
$ cd netbsd-vz
$ make build
$ make disk
$ make smoke

make build verifies the source archives, builds the cross tools and produces the 8 MiB VZ64 Image. make disk verifies the binary sets and assembles the GPT/FFSv1 root disk. The default make smoke invocation does not attach a network device. It proves the console, root mount, userspace and guest-driven poweroff without giving the guest an external path.

Networking is a separate test:

$ make smoke-network

This adds VZ NAT, waits for DHCP and checks both the local gateway and public IPv4 reachability (8.8.8.8).

Both automated targets boot a copy-on-write clone of the default RAW disk and delete it after success. Interactive make run and make run-network do the same. Supplying an explicit DISK=/absolute/path/root.raw instead attaches that file directly and makes guest changes persistent.

Summing Up

I tested the result on Apple silicon with macOS 26.6.1, Xcode 26.6 and Swift 6.3.3. The runner used one virtual CPU and 512 MiB of RAM. The following are selected, non-contiguous lines from fresh offline and network runs; device unit numbers, addresses and timings can change between boots.

NetBSD/VZ viocon console attached
ld0 at virtio1: features: 0x110002244<V1,INDIRECT_DESC,DISCARD,FLUSH,BLK_SIZE,SEG_MAX>
viornd0 at virtio2: features: 0x110000000<V1,INDIRECT_DESC>
dk0 at ld0: "netbsd-root", 2093056 blocks at 2048, type: ffs
root on dk0
root file system type: ffs

NetBSD 11.0 (VZ64) #0: Tue Aug 18 20:55:23 CEST 2026
NETBSD_VZ_USERSPACE_OK

vioif0 at virtio0: features: 0x130010028<V1,EVENT_IDX,INDIRECT_DESC,STATUS,MAC,MTU>
vioif0: flags=0x8b43<UP,BROADCAST,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST> mtu 1500
        status: active
        inet 192.168.65.12/24 broadcast 192.168.65.255 flags 0
NETBSD_VZ_NETWORK_GATEWAY_192.168.65.1
NETBSD_VZ_NETWORK_PUBLIC_8.8.8.8
NETBSD_VZ_NETWORK_OK

unmounted /dev/dk0 on / type ffs
Observed NETBSD_VZ_USERSPACE_OK and NETBSD_VZ_NETWORK_OK and guest poweroff; smoke test passed.

The offline test separately rejects an unexpected vioif attachment. The network variant requires an active interface, a non-link-local DHCP address, a default route, one successful ping to the VZ gateway and one to 8.8.8.8. Both variants log in through the Virtio console, execute a userspace marker, issue shutdown -p now, wait for a clean FFS unmount and require the VZ virtual machine to reach its stopped state.

This shows that NetBSD support yet another platform. All in all, getting a NetBSD kernel to boot was easier than expected. First, NetBSD’s stellar cross-compilation feature and portability capabilities made it easy to achieve that directly on my macOS machine. Second, partnering with Codex to overcome the obstacles during boot and later stages helped me to overcome technical isseus that would have taken days to solve in a couple of hours only.

The patched NetBSD 11 kernel and root disk boot on the VZ platform and drive console, entropy, block and optional network devices through shutdown. I did not enable an early console, EFI boot, graphics, shared directories, suspend and resume, multiple volumes or support in an unmodified NetBSD release. The full build, patch rationale and disk layout are documented in the companion repository’s technical account.

As a next step, I’d like to engage with the NetBSD community and see which patches could actually reach NetBSD-current. The console work should remain aligned with the existing VirtIO work mentioned before, while the reset, PCI and network changes probably need testing beyond this single VZ device model.

Furthermore, there is already an open request for FreeBSD support in Apple’s Containerization project. The next experiment is to find out whether this NetBSD guest can be integrated into Apple Container, but that belongs to another article.