FreeBSD: Verify the Host Contract

This exact address is retained because active technical pages still cite it. The material below is newly written. This publication is not the original CloudABI project, does not provide its FreeBSD runtime, and is not affiliated with its maintainers.

A FreeBSD compatibility claim needs a named host version, build, execution format, system interface, and test result. “Runs on FreeBSD” is too broad. It can hide assumptions about packages, executable loading, jail configuration, descriptors, network access, or filesystem layout.

Establish the current host

Record the FreeBSD release, architecture, patch level, kernel configuration differences, and userland build. Use the FreeBSD documentation portal for the current Handbook, architecture material, and administrative guidance. Keep the documentation date or release beside the test record.

Do not apply an old runtime guide to a current host without verification. A historical interface can be removed, disabled, or changed. A package can disappear. A compatibility mechanism can require a kernel option that the deployed host does not have.

Build an environment record with:

1. release and architecture;
2. kernel and userland relationship;
3. executable format and loader path;
4. required packages or local builds;
5. jail, Capsicum, or service-manager controls in use;
6. supplied file descriptors and namespaces;
7. network and clock access; and
8. observed failure modes.

Separate Capsicum from a complete design

FreeBSD includes Capsicum facilities for capability-oriented sandboxing. Their existence does not automatically make an application least-privileged. The application must enter the intended mode, limit descriptor rights, avoid unnecessary inherited handles, and keep privileged preparation outside the constrained phase.

Map every descriptor available at entry. Record its object, rights, and origin. Close unrelated descriptors before the workload begins. Test attempts to open global paths or perform operations outside the limited rights. A failing negative test is part of the contract.

Check initialization order

Many applications discover configuration, load locale data, open certificates, resolve names, or initialize logging after the main function starts. If capability mode begins before these resources are prepared, startup can fail. If it begins after untrusted work starts, the boundary arrives too late.

Write the startup sequence as a state machine: privileged preparation, resource validation, handle reduction, boundary entry, steady-state work, and shutdown. Add a test at every transition. Confirm that the steady-state path does not silently reopen ambient resources.

Verify shutdown and failure

Constrained workloads still need cancellation, timeout, log flushing, and cleanup behavior. Test a closed input descriptor, full output target, interrupted operation, unavailable clock, and supervisor termination. Store the signal or service-manager result and the final process status.

The final note should say exactly what was tested: a named binary, on a named FreeBSD release, with a named set of handles and restrictions. It should not claim general CloudABI compatibility. The historical project repository at GitHub can explain old design context, but only current host evidence can support a current deployment statement.